- 公開日
- 最終更新日
【CloudWatch】OAM (Observability Access Manager) を使用してモニタリングを一元化する
この記事を共有する
目次
はじめに
皆さんこんにちは！パーソル＆サーバーワークスの三宅です。
複数のAWSアカウントを運用していると、各アカウントのメトリクスやログを個別に確認する必要があり、運用が煩雑になりがちです。 そこで今回は、マルチアカウント環境でAmazon CloudWatch (以下、CloudWatch) の監視を一元化できる「Amazon CloudWatch OAM (Observability Access Manager)」についてご紹介します。 この機能を使えば、複数のAWSアカウントから監視データを1箇所に集約し、単一のモニタリングアカウントで一元管理できるようになります。
本記事では、CloudWatch OAMの概要と実際のセットアップ手順を試してみます。
CloudWatch OAM とは
CloudWatch OAMは、複数のAWSアカウントから監視データを集約し、単一のアカウントで一元管理できる機能です。 正式名称は「Amazon CloudWatch Observability Access Manager」で、クロスアカウントオブザーバビリティ機能とも呼ばれています。
集約可能なデータタイプ
CloudWatch OAMでは、以下のような監視に必要なデータを集約できます。
- CloudWatchメトリクス
- CloudWatch Logsロググループ
- X-Ray トレース
- CloudWatch Application Insights アプリケーション
- CloudWatch Internet Monitor モニタリング
- Application Signals
全体像の把握
CloudWatch OAMの全体的な構成を図で確認してみましょう。
引用元AWS公式ドキュメント: Amazon CloudWatch オブザーバビリティアクセスマネージャーを使用してモニタリングを一元化 - AWS 規範ガイダンス
シンク（Sink）の役割
シンクは、データを受け取る側、つまりモニタリングアカウントに作成するリソースです。
- データの受け皿となる役割
- 1つのアカウント×リージョンの組み合わせにつき1つだけ作成可能
- 複数のソースアカウントからのリンク接続を受け付ける
- 受け入れるデータタイプを制御できる
リンク（Link）の役割
リンクは、データを送信する側、つまりソースアカウントに作成するリソースです。
- モニタリングアカウントのシンクに接続する
- 送信するリソースタイプを選択できる（メトリクス、ログなど）
- 特定のロググループやメトリクスにフィルタリング可能
- 1つのアカウント内に最大5個まで作成可能
このシンク・リンクの関係により、複数のソースアカウントから1つのモニタリングアカウントへデータを集約できる仕組みになっています。
セットアップ手順
ここからは実際の設定手順を、ステップバイステップで解説していきます。 今回は、モニタリングアカウントへ複数のソースアカウントからデータを集約する構成を構築します。
セットアップは大きく分けて以下の2ステップで完了します。
- モニタリングアカウント側の設定：シンクを作成
- ソースアカウント側の設定：リンクを作成
ステップ1: モニタリングアカウントでシンクを作成する
最初に、データを集約する側のモニタリングアカウントでシンクを作成します。 CloudWatchコンソールに移動し、ナビゲーションペインから「Setup」＞「設定」を選択します。 CloudWatch設定ページが表示されたら、「モニタリングアカウント設定」を選択します。
「データを選択」セクションで、モニタリングアカウントで受け入れるデータタイプを指定します。 今回は以下のすべてのデータタイプにチェックを入れました。
「ソースアカウントを一覧表示」では、シンクへの接続を許可するソースアカウントの範囲を定義します。 以下の3つの方法で指定できます。
- 個別のAWSアカウントIDを指定（例：123456789012）
- AWS Organizations環境の場合：
- 組織単位（OU）パスを指定（例：o-xxxxx/r-xxxxx/ou-xxxxx-yyyyyyyy）
- 組織ID全体を指定（例：o-xxxxx）
今回はAWS Organizationsを利用しているため、組織ID「o-xxxxx」を指定して、組織内の全アカウントからの接続を許可しました。
「ソースアカウントを識別するのに役立つラベルを定義する」では、モニタリングアカウントでデータを確認する際に、どのアカウントからのデータかを識別するためのラベル形式を選択します。 選択できるラベル形式は以下の4種類です。
- アカウント名：AWSアカウントの名前で表示
- グローバルに一意のEメール：アカウントに紐づくメールアドレス全体
- ドメインなしのEメール：@マーク以前の部分のみ
- カスタムラベル：独自のラベルを定義
今回は「アカウント名」を選択しました。これにより、モニタリングコンソールでどのアカウントのデータかが直感的に分かりやすくなります。
ここまでの設定内容を確認し、問題がなければ「設定」ボタンをクリックします。 設定が正常に完了すると、「モニタリングアカウントを正常に有効化しました」というメッセージが表示されます。
これでシンクの作成は完了です！
ステップ2: ソースアカウントでリンクを作成
次に、各ソースアカウントにリンクを作成して、モニタリングアカウントへデータを送信できるようにします。 複数のソースアカウントに同じ設定を効率的に展開するため、AWS CloudFormation (以下、CloudFormation) StackSetsの利用を推奨します。
モニタリングアカウントのコンソールから、CloudFormationテンプレートをダウンロードできます。 「モニタリングアカウント設定 」>「アカウントをリンクするためのリソース」 を選択します。
「AWS組織」を選んでテンプレートをダウンロードします。
ダウンロードしたテンプレートは以下のような構造になっています。
AWSTemplateFormatVersion: 2010-09-09
Conditions:
SkipMonitoringAccount: !Not
- !Equals
- !Ref AWS::AccountId
- "000000000000"
Resources:
Link:
Type: AWS::Oam::Link
Condition: SkipMonitoringAccount
Properties:
LabelTemplate: "$AccountName"
ResourceTypes:
- "AWS::CloudWatch::Metric"
- "AWS::Logs::LogGroup"
- "AWS::XRay::Trace"
- "AWS::ApplicationInsights::Application"
- "AWS::InternetMonitor::Monitor"
- "AWS::ApplicationSignals::ServiceLevelObjective"
- "AWS::ApplicationSignals::Service"
SinkIdentifier: "arn:aws:oam:ap-northeast-1:000000000000:sink/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"
Conditionsセクションでは、データ受信側であるモニタリングアカウント自身にはリンクリソースを作成しないよう制御しています。 ResourceTypesプロパティでは、モニタリングアカウントへ送信するデータの種類（メトリクス、ログ、トレースなど）を指定できます。 LinkConfigurationプロパティを追加することで、特定のロググループやメトリクス名でフィルタリングすることも可能です。
次は、組織の管理アカウント、またはCloudFormation StackSetsの委任された管理者アカウントで操作を行います。
CloudFormationコンソールに移動し、「StackSets」>「スタックを作成」を選択し、ダウンロードしたテンプレートファイルをアップロードします。
任意のスタックセット名を入力します。今回は「CloudWatchOAM-Link」を入力します。
「組織へのデプロイ」を選択します。これにより、組織内の複数アカウントに一括展開できます。
自動デプロイオプション：
- 自動デプロイ：新規アカウントがOUに追加された時に自動でStackが作られる
- アカウント削除時の動作：OUから外れた時にStackを消すか残すか
今回は、デフォルト設定のまま進めます。
設定内容を確認し、「送信」を選択します。 StackSetsの処理が完了すると、各メンバーアカウントのStack作成状況を「スタックインスタンス」タブで確認できます。 全てのアカウントで「SUCCEEDED」ステータスになれば完了です。
モニタリングアカウントで、他のソースアカウントのデータが見られるか確認しましょう。
モニタリングアカウントのCloudWatchコンソールにアクセスします。コンソール右上に「モニタリングアカウント」と表示されていることを確認できます。 メトリクス検索時に、ソースアカウントIDでフィルタリング可能です。
まとめ
今回はマルチアカウント環境での監視を一元化できるCloudWatch OAMについて、概要からセットアップ手順まで試してみました。 これからマルチアカウント構成を検討される方は、ぜひCloudWatch OAMも合わせて導入を検討してみてください。
この記事は私が書きました
三宅 啓右
記事一覧2025 Japan All AWS Certifications Engineers
