CloudWatchでちょっと楽してマルチアカウント監視

CloudWatchでちょっと楽してマルチアカウント監視須永響伊藤忠テクノソリューションズ株式会社

@gravitas580 須永響 Hibiki Sunaga CTC(伊藤忠テクノソリューションズ株式会社 ) 新卒３年目業務：AWSインフラ基盤の設計・構築得意なAWS技術：マルチアカウント設計、NW設計
:@gravitas580 About Me

@gravitas580 Why マルチアカウント構成 ? 権限・責任を分けることでセキュリティ・ガバナンスを向上させる IAMの権限はアカウントで分割される ➢ 各システム・チーム・環境(本番、検証、開発)ごとに分けることで誤った操作を防ぐ ➢ 意図して繋げない限りリソースが繋がることはない
料金はアカウントごとに請求される ➢ タグベースでも金額は計算できるが、NW通信料、セキュリティサービスの費用など厳密に分けたい場合にはアカウントを分ける必要がある ➢ Account = 口座

@gravitas580 権限を分割することでセキュリティ・ガバナンスUP バラバラすぎて運用負荷が高くなってしまう

@gravitas580 アカウントを増やすことによる監視の悩み複数のアカウントを行き来してメトリクス・ログの確認アカウントを追加するごとに同じような監視の設定を追加

@gravitas580 マルチアカウント環境下で使えるCloudWatch 統合機能 Organizationsと統合して利用できる機能 ⚫ CloudWatchクロスアカウントオブザーバビリティ(OAM) ⚫ クロスアカウントクロスリージョン ⚫ クロスアカウントクロスリージョンログ一元化
アカウント間およびリージョン間でモニタリングする - Amazon CloudWatch 3つあるので違いを確認対象のアカウントのメトリクスなどを統合

@gravitas580 マルチアカウント環境下で使えるCloudWatch 統合機能 Organizationsと統合して利用できる機能 ⚫ CloudWatchクロスアカウントオブザーバビリティ(OAM) ⚫ クロスアカウントクロスリージョン ⚫ クロスアカウントクロスリージョンログ一元化
アカウント間およびリージョン間でモニタリングする - Amazon CloudWatch 3つあるので違いを確認対象のアカウントのメトリクスなどを統合どう見えるのかをチェックしていきます

@gravitas580 CloudWatch クロスアカウントオブザーバビリティ ⚫ 統合されたダッシュボード ⚫ 設定すると、監視アカウントのダッシュボードにアカウントラベルが追加 ⚫ 別アカウントのメトリクスからアラームを作
ることも可能

@gravitas580 クロスアカウントクロスリージョン ⚫ アカウントをプルダウンから選択 ⚫ アカウントごとのダッシュボードに切り替えるイメージ

@gravitas580 クロスアカウントクロスリージョンログ一元化 ⚫ 一元化先アカウントのログ一覧画面に送信元アカウントのログも見えるように ⚫ 各ログ内のアカウントIDからどのアカウントのログか確認可能 ⚫ 一元化設定前のログは共有されない

@gravitas580 CloudWatch 統合方式の機能比較項目クロスアカウントオブザーバビリティ (OAM) クロスアカウントクロスリージョンクロスアカウントクロ
スリージョンログの一元化統合可能な項目メトリクス ◦ ◦ × アラーム ◦(他アカウントのメトリクスを使用して作成可能) △(参照のみ、編集不可) × ログ ◦ × ◦ トレース(X-Ray) ◦ × × Application Insights ◦ × × 特徴表示方法統合ビュー切り替え式統合ビューリージョンごとの設定必要不要不要

@gravitas580 どっちを使えばいいの？クロスアカウントオブザーバビリティが推奨集中して管理したいので、OAMが最適 ✓ ログ、トレースなどをモニターアカウントから確認可能 ✓ 他アカウントのメトリクスを使用して、モニターアカウントでアラームを作成可能 ✓
組み合わせて使用することも可能なので、使用感に応じて併用しても良いユーザーガイド：クロスアカウントクロスリージョン CloudWatch コンソール - Amazon CloudWatch リージョン内のメトリクス、ログ、トレースに対するクロスアカウントのオブザーバビリティと検出を最大限に活用するために、CloudWatch クロスアカウントオブザーバビリティを使用することをお勧めします。

@gravitas580 クロスアカウントオブザーバビリティの構築方法を簡単にご紹介します

@gravitas580 クロスアカウントオブザーバビリティ(OAM)の構成用語 ➢ モニタリングアカウント：統合先アカウント。ログアーカイブアカウントが推奨 ➢ ソースアカウント：統合元アカウント。システムが動くようなワークロードアカウント ➢ シンク：モニタリングアカウントに作成。データを受け取るゲートウェイ ➢
リンク：ソースアカウントに作成。シンクにアクセスしてデータを共有する

@gravitas580 クロスアカウントオブザーバビリティ(OAM)を構築していく構築手順 CloudFormation StackSets & Organizations統合機能を活用してアカウントを追加しても自動で設定されるようにします 1. モニタリングアカウントでシンクの作成
2. 管理アカウントからソースアカウントへCFn StackSetsでリンクをまとめて作成 ➢ 管理アカウント：CloudFormation StackSets実行権限あり ➢ ログアーカイブアカウント：モニタリングアカウント ➢ メンバーアカウント：ソースアカウント ➢ Workload OU：メンバーアカウント全体が配置 ➢ System1 OU：ソースアカウントが配置

@gravitas580 シンクの作成：モニタリングアカウントで設定モニタリングアカウントの設定ソースアカウントの設定

@gravitas580 シンクの作成：モニタリングアカウントで設定取得するデータを選択ソースアカウント記入のポイント OUを対象とする場合、 {組織ID}/{ルートID}/{親OU ID}/{対象OU ID}/ ✓ OU
IDだけではだめ ⇒ 組織IDから記載 ✓ 親OUだけではだめ ⇒ ソースアカウント直下のOU ✓ 最後の / を忘れるとだめソースアカウントを記入ダッシュボードに表示されるラベルを選択

@gravitas580 シンクの作成：モニタリングアカウントで設定シンクが作成が完了リンク作成用のCloudFormationテンプレートが生成ダウンロードして、管理アカウントへ移動する

@gravitas580 リンクの作成：管理アカウントで設定 CloudFormation StackSets作成のポイント ✓ OU IDは親OUではなく、ソースアカウント直下のOU IDを選択 ✓
自動デプロイをオンにすることで、アカウント追加時に自動でリンク作成

@gravitas580 構築完了ソースアカウントのリンク作成＆モニタリングアカウントから確認できました～! ソースアカウントモニタリングアカウント

@gravitas580 おまけマルチアカウントでの統合はこれでできましたが、アラーム設定をするためには各アカウントの各メトリクス分だけ設定しなければいけなそうです。 (結局アカウントを追加する度に作業が必須。。。) 2025/9のアップデートにより、タグベースでアラームを作成にできるようになりました！ Amazon CloudWatch がベンディングされたメトリクスのモニタリングでリソースタグをサポート -
AWS これにより、タグベースのアラームを設定 ⇒アカウントを追加すると、自動でメトリクス統合＆アラーム対象に

CloudWatchでちょっと楽してマルチアカウント監視

CloudWatchでちょっと楽してマルチアカウント監視

Hibiki

Transcript