集約型モニタリング「クロスアカウントクロスリージョン CloudWatch コンソール」を有効化してみた
どうも、こんにちは kaz です。
はじめに
複数アカウントを持っていると「あれ?このアカウントのメトリクスってどうなってるんだっけ?」と、ふと思うことがありますよね。
でも、アカウントを切り替えるのが面倒で「今日はもう退勤しよう・・・」なんてこともあるかと思います(冗談です)。
そんなときに便利なのが 「CloudWatch クロスアカウントオブザーバビリティ」 と 「クロスアカウントクロスリージョン CloudWatch コンソール」 という機能です!
どちらも CloudWatch で複数アカウントのテレメトリを効率的にモニタリングするために利用できる機能ですが、パッと見でどっちが何なのかわかりづらいと思います。
このエントリーでは、「クロスアカウントクロスリージョン CloudWatch コンソール」 をメインにそれぞれの違いや設定方法について紹介します!
「CloudWatch クロスアカウントオブザーバビリティ」と「クロスアカウントクロスリージョン CloudWatch コンソール」の違い
ざっくりと・・・以下のイメージでしょうか。
- CloudWatch クロスアカウントオブザーバビリティ
- Observability Access Manager (OAM) サービスによって、単一リージョン内のオブザーバビリティを提供
- アカウントをリンクすると、アカウント間でメトリクス、ログ、トレース、その他のテレメトリを簡単に表示できる
- 共有されたテレメトリをネイティブであるかのように中央モニタリングアカウントでオブザーバビリティを統一できる
- つまり、単一リージョンのみだが、より多くのテレメトリと複数アカウントを 1 画面上に表示できる統合型機能
- クロスアカウントクロスリージョン CloudWatch コンソール
- コンソールエクスペリエンスの提供
- アカウントを柔軟に切り替えて、他アカウントかつ各リージョン間のメトリクス、ダッシュボード、アラームを表示できる
- クロスアカウントクロスリージョンメトリクスを含むダッシュボードを設定して、アカウント内で一元的に可視化することも可能
- つまり、セレクトしたアカウント(および複数リージョン)のテレメトリを切り替えて表示できる集約型機能
ただし、ドキュメント にもあるとおり、2 つの機能は相互に補完し合い一緒に使用することもできます。
もう少し細かい 2 つの機能の比較は、次の表を参照してください。
機能比較表
機能 | CloudWatch クロスアカウントオブザーバビリティ | クロスアカウントクロスリージョン CloudWatch コンソール |
---|---|---|
サポートされるテレメトリ | ・メトリクス ・トレース ・ログ |
・メトリクス ・トレース |
サポートされる機能 | ・ダッシュボード ・アラーム ・Metrics Insights ・異常検出 ・CloudWatch Logs Insights ・Application Insights ・その他の機能(詳細はこちら) |
・メトリクス、アラーム、トレースのコンソールでアカウントとリージョンを切り替える ・他のアカウントやリージョンからのメトリクスとアラームを含むカスタムダッシュボード ・その他の機能(詳細はこちら) |
使用できるアカウント数 | 最大 100,000 個のソースアカウントのリソースを同時に表示 | リンクできるアカウントの数に制限なし |
テレメトリデータを移動するか? | コピーされたトレース (X-Ray) を除き、移動されない | 移動されない |
利用料が発生するか? | ・共有ログとメトリクスには料金は発生しない ・コピーしたトレース (X-Ray) は発生する(最初のトレースコピーは無料) |
発生しない |
リージョン間のオブザーバビリティをサポートしているか? | いいえ | はい |
プログラムによるアクセスをサポートしているか? | AWS CLI, AWS CDK, API などでサポート | いいえ |
プログラムによる設定をサポートしているか? | はい | はい |
AWS Organizations をサポートしているか? | はい | はい |
以下より「クロスアカウントクロスリージョン CloudWatch コンソール」について紹介します!
前提条件と用語の定義
- AWS Organizations が有効になっていること
- Organizations を使用していない場合はアカウント ID を指定して個別に設定できますが、ここでは Organizations を活用した方法で進めます
- モニタリングアカウントをどのアカウントにするか決めておくこと
- 1 つまたはいくつかのソースアカウントがあること
- CloudFormation StackSets サービスの管理アカウントまたは委任管理者アカウントから全メンバーアカウントに IAM リソースをデプロイできること
また、事前に以下の用語を定義しておきます。
- モニタリングアカウント(監視者)
- クロスアカウントクロスリージョン機能を利用して、各メンバーアカウントの CloudWatch の関連データを確認するアカウント
- ソースアカウント(モニタリングされるアカウント)
- CloudWatch の関連データを提供する各メンバーアカウント
動作の仕組み
ソースアカウントに CloudWatch-CrossAccountSharingRole
をセットアップして、モニタリングアカウントがソースアカウントでオペレーションを実行できるようにします。
モニタリングアカウントは ソースアカウント
を指定することによって、コンソール上でソースアカウントに切り替えることができます。
(切り替え時、CloudWatch コンソールはソースアカウントに作成された CloudWatch-CrossAccountSharingRole
を CloudWatch が引き受けることを許可するサービスにリンクされたロールの存在をチェックする)
イメージだと以下のような感じですね〜。
設定手順
それでは「クロスアカウントクロスリージョン CloudWatch コンソール」を設定していきましょう!
導入方法は下記のドキュメント通りとなりますが、ここではスクショ付きで紹介したいと思います。
Step1. クロスアカウントクロスリージョン CloudWatch コンソールの設定
モニタリングアカウント(監視者) で以下の手順を実施します。
今回は AWS Organizations の管理アカウントをモニタリングアカウント とします。
-
CloudWatch コンソールにアクセスして[設定]->[クロスアカウントクロスリージョンを表示]を選択
※わかりづらいですが画面下部の青枠が「クロスアカウントクロスリージョン」の設定欄です
メンバーアカウントをモニタリングアカウントにする際の注意点
通常、メンバーアカウントでは Organizations の組織リストへのアクセス権限がないため、[クロスアカウントクロスリージョンを表示]を選択すると赤枠のような警告文が表示されます。
このため、Organizations の管理アカウントから組織リストの共有を行っておく必要があります。
一度 管理アカウントにログイン して下記を設定してください。- CloudWatch コンソールにアクセスして[設定]->[組織のアカウントリストを共有する]を選択
- 共有したいメンバーアカウント ID を入力し[CloudFormation 起動テンプレート]を選択
- プレビュー画面でチェックボックスにチェックを入れて[スタックの作成]を選択
- モニタリングアカウント(メンバーアカウント)にログインしてみると、アクセス権が許可されていることが確認できる
ここまでの設定が完了したら、以降の手順に進んでください。
- CloudWatch コンソールにアクセスして[設定]->[組織のアカウントリストを共有する]を選択
-
[コンソールにセレクタを表示する]にチェックを入れておき、[AWS 組織アカウントセレクタ]を選択し[有効化]をクリック
※[コンソールにセレクタを表示する]は CloudWatch メトリクスなどのコンソール上で組織内のアカウントを選択できるようになります
ここで「クロスアカウントクロスリージョン CloudWatch コンソール」の設定は完了なのですが、このままだとメンバーアカウントの CloudWatch メトリクスなどを確認することはできません。
下記を見ると、メンバーアカウントにある CloudWatch-CrossAccountSharingRole
ロールに AssumeRole しようとして失敗してますね。
ここまでの手順ではメンバーアカウント側でなにも準備をしていないので、これは当然の挙動だと思います。
では、メンバーアカウント内に CloudWatch-CrossAccountSharingRole
ロールを作成して AssumeRole できるように権限を付与します。
Step2. メンバーアカウントに CloudWatch-CrossAccountSharingRole ロールを作成
同じく モニタリングアカウント(監視者) で以下の手順を実施します。
複数のメンバーアカウントがある場合、個々に作成するのは非常に手間なので CloudFormation StackSets で一括作成するのがオススメです!
-
CloudShell または AWS CLI を準備
-
以下のコマンドを実行して StackSet を作成
※MONITORING_ACCOUNT_ID
にはモニタリングアカウントのアカウント ID を指定してください
※POLICY
は他にもありますが、今回はCloudWatch-AutomaticDashboards-and-ServiceLens
を指定しています# 環境変数の定義 MONITORING_ACCOUNT_ID="モニタリングアカウントのアカウント ID" # 例: 123456789012,987654321098 (複数指定も可) POLICY="CloudWatch-AutomaticDashboards-and-ServiceLens" # CloudWatch メトリクス、ダッシュボード、ログウィジェット、アラーム、CloudWatch 自動ダッシュボード、ServiceLens の X-Ray 読み取り専用アクセスへの読み取り専用アクセスを提供 TEMPLATE_URL="https://cloudwatch-console-static-content-prod-nrt.s3.ap-northeast-1.amazonaws.com/1e98d631a8f4b50a66601030cf6d329b27ae71fb/cross-account/CloudWatch-CrossAccountSharingRole-AccountList-aws.yaml" # StackSet を作成 aws cloudformation create-stack-set \ --description "Enables CloudWatch in central monitoring accounts to assume permissions to view CloudWatch data in the member accounts (Auto Deploy: Enabled)" \ --stack-set-name CloudWatch-CrossAccountSharingRole \ --template-url "${TEMPLATE_URL}" \ --permission-model SERVICE_MANAGED \ --auto-deployment Enabled=true,RetainStacksOnAccountRemoval=false \ --managed-execution "Active=true" \ --capabilities CAPABILITY_NAMED_IAM \ --parameters \ ParameterKey=MonitoringAccountIds,ParameterValue="${MONITORING_ACCOUNT_ID}" \ ParameterKey=Policy,ParameterValue="${POLICY}" \ --tags \ "Key=CreatedBy,Value=OpsTeam" \ --call-as SELF
コマンド実行時にエラーが発生する場合
以下のエラーが発生した場合、CFn テンプレートの参照先が変更されている可能性があります。
An error occurred (ValidationError) when calling the CreateStackSet operation: S3 error: Access Denied For more information check http://docs.aws.amazon.com/AmazonS3/latest/API/ErrorResponses.html
その場合、以下の手順でテンプレートの URL を確認してください。
- CloudWatch コンソールにアクセスして[設定]->[CloudWatch データを共有]を選択
- なにも入力せずに[CloudFormation テンプレートを起動]を選択
※確認画面が出るので「確認」を入力して進めてください
- [テンプレート URL]をコピーして、上記の
TEMPLATE_URL
を置き換えて再度実行してください
- CloudWatch コンソールにアクセスして[設定]->[CloudWatch データを共有]を選択
-
StackSet にスタックインスタンスをデプロイ
※OU_ID
には OU ID を指定してください(こだわりがなければ、個人的には Root OU にデプロイしてしまっていいと思います)
※本テンプレートでは IAM Role のみを作成するため、リージョンはus-east-1
に固定していますOU_ID="OU ID" # 例: ou-xxxx-yyyy,ou-xxxx-yyyy (複数指定も可) # StackInstances を作成 aws cloudformation create-stack-instances \ --stack-set-name "CloudWatch-CrossAccountSharingRole" \ --deployment-targets OrganizationalUnitIds="${OU_ID}" \ --regions us-east-1 \ --operation-preferences RegionConcurrencyType=PARALLEL,MaxConcurrentPercentage=25,FailureTolerancePercentage=20,ConcurrencyMode=STRICT_FAILURE_TOLERANCE \ --call-as SELF
StackSet のオペレーションが開始されるので
RUNNING
からSUCCEEDED
になるまで待ちます。
オペレーションが完了すると、メンバーアカウントに CloudWatch-CrossAccountSharingRole
ロールが作成され、モニタリングアカウントから AssumeRole できるようになります!
それでは、モニタリングアカウント(監視者) で CloudWatch コンソールを開いて、メンバーアカウントのメトリクスデータを確認してみましょう。
おお、いいですね!
これで クロスアカウントクロスリージョン CloudWatch コンソール の設定が完了です!おつかれさまでした!
めちゃくちゃ便利な Switch Role 機能
IAM Role を各メンバーアカウントに作成しているのでスムーズなアクセス権限の切り替えを行うことができます!
ある意味、目玉機能かな??
その方法は以下の通りです。
- メンバーアカウントを選択して[このアカウントに切り替える]をクリック
- [ロールの切り替え]をクリック
- メンバーアカウントに切り替わる
これによって、わざわざアカウントを切り替える必要がなくなり、とても便利ですね!
なお、「Step2. メンバーアカウントに CloudWatch-CrossAccountSharingRole ロールを作成」の箇所で IAM Role のポリシーを設定していたかと思いますが、ここで設定していたのは CloudWatch に関する権限なので他の AWS サービスを閲覧しようとするとエラーが発生します(以下は EC2 コンソールを開いた際のエラー画面)。
これも確認のための最小権限の原則に基づいているので、安心ですね!
まとめ
今回は 「クロスアカウントクロスリージョン CloudWatch コンソール」 を設定することで、モニタリングアカウントからメンバーアカウントのメトリクスデータを一元的に確認することができました。
Organizations で複数のアカウントを管理するのは便利な反面、各アカウントのリソースを一元的に管理するのはよくある課題だと思います。
また、CloudFormation StackSets を使って複数のメンバーアカウントにリソースを一括作成することで、手間を大幅に削減できました!
すでに上述していますが「CloudWatch クロスアカウントオブザーバビリティ」と「クロスアカウントクロスリージョン CloudWatch コンソール」は相互に補完し合って一緒に使用できます。
このような便利機能をうまく活用して運用を効率化していきましょう!
「CloudWatch クロスアカウントオブザーバビリティ」の設定方法は、以下をご参照ください。
アノテーション株式会社について
アノテーション株式会社 は、クラスメソッド社のグループ企業として「オペレーション・エクセレンス」を担える企業を目指してチャレンジを続けています。
「らしく働く、らしく生きる」のスローガンを掲げ、さまざまな背景をもつ多様なメンバーが自由度の高い働き方を通してお客様へサービスを提供し続けています。
現在当社では AWS の構築・運用経験があり、以下の業務に携わってくれるメンバーを募集中です。
- AWS 環境の運用設計支援や構築
- 運用監視とインシデント対応
- 定型業務などの自動化
AWS 関連資格をお持ちの方、クラウドネイティブな運用経験者は大歓迎です。
少しでもご興味がありましたら 募集職種 よりご応募ください!!
一緒に働ける日を心待ちにしています!