2025年9月17日 のアップデート
Amazon CloudWatch でクロスアカウントおよびクロスリージョンのログの一元化が利用可能になりました。
- Amazon CloudWatch でクロスアカウントおよびクロスリージョンのログの一元化が利用可能に - AWS
- Amazon CloudWatch Logs の一元化を使用したログ管理の簡素化 | Amazon Web Services ブログ
1. はじめに
システム規模が拡大し、AWSアカウントの数が増えてくると、「どのログがどこにあるか分からない」「調査のためにアカウントを切り替えるのが手間」といった、オブザーバビリティ（可観測性）の課題に直面することも多いのではないでしょうか。
AWSではこうした課題に対し、主に2つのアプローチが用意されているようです。
- CloudWatch OAM (Observability Access Manager) ※ Link monitoring accounts with source accounts - Amazon CloudWatch
- CloudWatch Logs のデータ一元化機能 (Logs Centralization) ※ Cross-account cross-Region log centralization - Amazon CloudWatch Logs
どちらも「複数のアカウントをまとめて管理したい」という目的は共通していますが、そのアーキテクチャや得意分野は異なるようです。本記事では、最新のアップデート情報を踏まえ、コストや管理の手間、ガバナンスといった観点から、それぞれの特徴と選び方のヒントについて整理してみたいと思います。
2. 大きな違いは「見るだけ」か「集めるか」
どちらを選ぶべきか迷った際は、データを「資産」としてどう扱いたいか、という点に着目してみると良いかもしれません。
OAM（参照型）
- イメージ: 「データは ソースアカウント に置いたまま、見るための『権限』だけを共有する」というスタイルです。
- 特徴: データそのものを動かさないため、転送費用や保管費用の重複を抑えられる点がメリットと言えそうです。あたかも一つの画面であるかのように、状況を確認できる仕組みになっています。
- 構成図: Amazon CloudWatch オブザーバビリティアクセスマネージャーを使用してモニタリングを一元化 - AWS 規範ガイダンス より抜粋)：
データ一元化（複製型）
- イメージ: 「データを物理的に一箇所に集めて、コピー（複製）を保存する」というスタイルです。
- 特徴: データが確実に一箇所に集まるため、万が一 ソースアカウント のデータが消えてしまった場合でも安心感があります。監査対応や長期保存などに向いていると考えられます。
- 構成図: (Amazon CloudWatch Logs の一元化を使用したログ管理の簡素化 | Amazon Web Services ブログ より抜粋)：
3. 詳細比較：コスト・機能・管理のポイント
最新の仕様に基づき、検討のポイントとなりそうな項目をまとめてみました。特にコスト面での変更点に注目です。
| 比較項目 | OAM (参照型) | CloudWatch Logs データ一元化 (複製型) | 検討のヒント |
|---|---|---|---|
| データの場所 | ソースアカウント のみ 見る側のアカウントには、原則としてデータは保存されないようです。 |
ソースアカウント ＋ 宛先アカウント 宛先のアカウントにコピーが作成され、保存される形になります。 |
容量の節約を重視するならOAM、バックアップ的な意味合いを持たせるなら一元化機能、といった使い分けができそうです。 |
| コスト感 | 安価 (参照のみ) 保存料は1回分で済みます。 ※検索時のクエリ量に応じた課金となります。 |
意外と高コスパ (転送費無料) 保存料は二重にかかりますが、1つ目のコピーのリージョン間転送費と追加取り込み料は無料のようです。 ※2つ目のコピー（バックアップ等）からは有料となります。 |
「クロスリージョン転送費」がかからないため、以前の自前転送ソリューションより大幅に安くなる可能性があります。ただしストレージ費の重複には注意が必要です。 |
| 対象データ | 包括的 (ログ, メトリクス, トレース) メトリクス や X-Ray トレース なども含め、幅広く確認できるようです。 |
限定的 (ログのみ) 基本的にはログデータのみが対象となるようです。 ※ログ変換設定は引き継がれない点に注意が必要です。 |
運用監視（SRE）用ならOAM、ログ分析用なら一元化機能の方が適しているかもしれません。 |
| 組織管理 | 柔軟 AWS Organizations を使っていなくても連携可能なようです。 |
条件あり AWS Organizations の利用が前提となるようです。 |
組織全体の管理基盤がある場合は一元化機能もスムーズに導入できるでしょう。 |
| リージョン | 原則、リージョン ごとの管理 リージョン をまたぐ場合は、ダッシュボード等での工夫が必要になるかもしれません。 |
クロスリージョン 対応 海外 リージョン のログを国内に集約する、といった構成も可能なようです。 |
DR対策などでデータを遠隔地に送りたい場合は、「一元化機能」が有力な候補になりそうです。 |
| データ加工 | ソースアカウント で実施 各アカウント側での設定が必要になることが多いようです。 |
宛先アカウント で実施可能 集めた後に、まとめて加工（メトリクス化など）できるメリットがありそうです。 |
分析担当者がデータを自由に扱いたい場合は、「一元化機能」が便利かもしれません。 |
| ノイズの制御 | ソースアカウント 側で制御 共有するリソースをポリシーで絞り込むアプローチです。 |
一元化ルールで制御 (入り口) 管理者がルール作成時に、特定の文字列を含むロググループのみを転送対象にするなどの絞り込みが可能なようです。 |
どちらも入り口での制御は可能ですが、一元化の方は「ロググループ名」ベースでの選別が基本になりそうです。 |
| 検索の見やすさ | アカウントごとに分離 ドロップダウンで対象アカウントを切り替えて表示します。 |
混在して表示 一つのロググループに集約されるため、検索時に自動付与される @aws.account 等での絞り込みが必須になるかもしれません。 |
「混ざってほしくない」場合はOAMの方が直感的に操作できるかもしれません。 |
4. 「必要なデータだけを見る」ためのフィルタリングの違い
大量のログを集約した結果、「情報が多すぎて逆に重要なエラーが見つけにくい」という状況は避けたいものです。両者では、この「情報の絞り込み（フィルタリング）」のアプローチにも違いがあるようです。
OAM の場合：入り口で選別し、見る時に切り替える
OAMは、「ソースアカウント側で何を共有するか」を定義するところから始まります。
- 入り口の絞り込み: ソースアカウントのリンク設定で、「全てのロググループ」を共有することもできますし、「/aws/lambda/ で始まるロググループのみ」のように、ロググループ名の前方一致（プレフィックス）で対象を絞る運用が一般的なようです。これにより、監視アカウント側に見せる情報をあらかじめ減らしておくことができます
- 見る時の切り替え: 監視アカウントのコンソールには「アカウントラベル」や「アカウントセレクター」が表示されます。「今はAアカウントの状況を見たい」「次はBアカウント」といったように、物理的に視点を切り替えて確認するスタイルと言えるでしょう。
ソースアカウントのリンク設定：
アカウントラベルの表示例：
アカウントセレクター：
データ一元化機能の場合：ロググループを選別して集め、集約後に加工する
こちらは、物理的にログをコピーするため、ストレージコストを抑える意味でも入り口での選別が重要になりそうです。
- 入り口の絞り込み: 管理者がルール作成時に「ロググループ名」や特定のパターン（
*ERROR*など）を指定して、必要なロググループだけを一元化することが可能なようです。 - 集約後の加工: 宛先アカウントに集まったログに対して、メトリクスフィルターやサブスクリプションフィルターを設定できる点が強みです。公式情報によると、ソースアカウントで行っていた「ログ変換」は反映されないため、集約した後に中央アカウント側で統一した変換ルールを適用するのが推奨されているようです。
- 検索時の工夫: 一つのロググループに複数アカウントのログが混在しますが、転送時に
@aws.accountや@aws.regionといったシステムフィールドが自動付与されます。CloudWatch Logs Insights で検索する際は、これらのフィールドを使って効率的にフィルタリングできるようです。
ロググループのフィルタリング設定
CloudWatch Logs Insights で @aws.account, @aws.region を付けたクエリができる。
fields @timestamp, @aws.account, @aws.region, @message
同じロググループに複数の AWS アカウントからのログが存在する例。アカウント番号とリージョン名をストリーム名に含んでいることがわかる。
複数リージョンのログが集約される。
メトリクスフィルターを作成するときにディメンションを付与できるようになっている。
メトリクスにディメンションが付与された 1。
メトリクスにディメンションが付与された 2。
サブスクリプションフィルターを作成するときにもシステムフィールドを付与できる。
システムフィールドは extractedFields（和訳：「抽出されたフィールド」）というところに出力されていた。
5. どちらを選ぶのが良さそう？
状況や目的に応じて、以下のような使い分けが考えられそうです。特にコスト面の仕様により、一元化機能の利用シーンが広がったと言えるかもしれません。
パターンA：現場の運用効率とコスト最適化を重視したい場合
- 向いているのは: OAM (参照型) かもしれません。
- 想定されるケース:
- アカウント数が増え、監視画面を行き来するのが手間に感じている。
- ログだけでなく、メトリクス や トレース もまとめて見たい。
- ログは「今の状態」を確認するためのもので、二重保管までは求めていない。
- なるべく余計なストレージコストはかけたくない。
パターンB：コンプライアンスとデータの保全を重視したい場合
- 向いているのは: CloudWatch Logs データ一元化 (複製型) かもしれません。
- 想定されるケース:
- 社内規定などで、ログの長期保存や改ざん防止が求められている。
- 万が一の際にログを消されないよう、別のアカウントへ退避させておきたい。
- 海外 リージョン のログを、日本のメインアカウントに集約したい（最初のコピーはリージョン間転送コストがかからないため、非常に有利です）。
- さらに堅牢性を高めるため、メインの集約リージョンとは別に、バックアップリージョンへの同期コピーも自動化したい。
- 分析ツールへログを送るための「集積所（データレイク）」を作りたいと考えている。
パターンC：いいとこ取りの組み合わせ（ハイブリッド）
- 向いているのは: OAM ＋ データ一元化 の併用 という選択肢です。
- 想定されるケース:
- 日常の監視: OAMを使用し、開発者や担当者が手軽に状況を確認できるようにする。
- 重要な記録: セキュリティログだけを、「データ一元化」機能で専用アカウントへ集める。
- メリット: 運用は便利にしつつ、守るべきデータはしっかり守る。すべてのログを複製するわけではないので、費用対効果のバランスも取りやすい構成と言えそうです。
6. おわりに
「監視の一元化」という言葉には、大きく分けて2つのニュアンスが含まれているようです。
- 「見る場所 (View)」を一つにまとめたいのか。
- 「データそのもの (Data)」を一箇所に集めて守りたいのか。
ご自身のチームやプロジェクトにおいて、優先すべきなのは「アジリティやコスト」なのか、それとも「ガバナンスやコンプライアンス」なのか。そのあたりを一度整理してみることが、最適な選択への近道になるのではないでしょうか。迷われる場合は、まずはコストリスクの少ないOAMから試してみるのも一つの手かもしれません。
余談
休日に西伊豆のトレイルを少し歩いてきました。海が綺麗でした。
