Amazon Web Services ブログ
New – Amazon CloudWatch のクロスアカウントオブザーバビリティ
複数の AWS アカウントを使用してアプリケーションをデプロイすることは、チーム間のセキュリティと請求の境界を確立し、運用上のイベントの影響を軽減するための優れた方法です。マルチアカウント戦略を採用する場合、複数のアカウントに分散しているテレメトリデータを分析する必要があります。本日、アプリケーションのすべてのコンポーネントを一元的にモニタリングできる柔軟性を提供するために、Amazon CloudWatch のクロスアカウントオブザーバビリティを導入します。これは、メトリクス、ログ、トレースなど、CloudWatch に保存されているクロスアカウントテレメトリデータを検索および分析したり、相互に関連付けたりするための新機能です。
この機能により、一元的なモニタリング用の AWS アカウントを設定し、他のアカウントをソースとして接続できるようになりました。その後、アプリケーション全体のログを検索、監査、分析して、運用上の問題をほんの数秒で詳しく確認できます。多数のアカウントのメトリクスを 1 か所で検出して視覚化し、他のアカウントのメトリクスを評価するアラームを作成できます。まず、アプリケーションの集約クロスアカウントビューでエラーが発生しているリソースを視覚的に特定し、相関するトレース、メトリクス、ログを詳しく調べて根本原因を見つけることができます。このシームレスなクロスアカウントデータアクセスとナビゲーションは、問題のトラブルシューティングに必要な時間と労力を削減するのに役立ちます。
実際にどのように機能するのかを見てみましょう。
CloudWatch のクロスアカウントオブザーバビリティの設定
クロスアカウントオブザーバビリティを実現するために、CloudWatch はモニタリングとソースアカウントの概念を導入しました。
- モニタリングアカウントは、他のアカウントによって共有されるオブザーバビリティデータを表示して操作できる中心的な AWS アカウントです。
- ソースアカウントは、オブザーバビリティデータとリソースを 1 つ以上のモニタリングアカウントと共有する個々の AWS アカウントです。
必要な可視性レベルで複数のモニタリングアカウントを設定できます。CloudWatch のクロスアカウントオブザーバビリティも AWS Organizations と統合されています。例えば、組織内のすべてのアカウントに幅広くアクセスできるモニタリングアカウントを中心的なセキュリティチームと運用チームのために作成し、ビジネスユニットに対する可視性がより制限された他のモニタリングアカウントを個々のサービスオーナーのために設定できます。
まず、モニタリングアカウントを設定します。CloudWatch コンソールのナビゲーションペインで [Settings] (設定) を選択します。[Monitoring account configuration] (モニタリングアカウント設定) セクションで、[Configure] (設定) を選択します。
これで、モニタリングアカウントと共有できるテレメトリデータ ([Logs] (ログ)、[Metrics] (メトリクス)、[Traces] (トレース)) を選択できるようになりました。3 つすべてを有効のままにします。
このモニタリングアカウントとデータを共有するソースアカウントを一覧表示するために、アカウント ID、組織 ID、または組織パスを使用できます。組織 ID を使用して組織内のすべてのアカウントを含めることも、組織パスを使用して部門またはビジネスユニットのすべてのアカウントを含めることもできます。ここでは、リンクするソースアカウントは 1 つしかないので、アカウント ID を入力します。
モニタリングアカウントで CloudWatch コンソールを使用してテレメトリデータを検索および表示すると、そのデータを共有したアカウント ID が表示されます。アカウント ID は覚えにくいので、よりわかりやすい「アカウントラベル」を表示できます。 コンソールを介してラベルを設定する場合、アカウント名またはアカウントを識別するために使用するメールアドレスのいずれかを選択できます。メールアドレスを使用する場合、ドメインを含めるかどうかを選択することもできます。例えば、アカウントを識別するために使用されるすべてのメールアドレスが同じドメインを使用している場合は、そのドメインのないメールアドレスをラベルとして使用できます。
クロスアカウントオブザーバビリティは選択したリージョンでのみ機能する旨の簡単なリマインダーが表示されます。複数のリージョンにリソースがある場合は、各リージョンでクロスアカウントオブザーバビリティを設定できます。モニタリングアカウントの設定を完了するには、[Configure] (設定) を選択します。
モニタリングアカウントが有効になったので、[Resources to link accounts] (アカウントをリンクするリソース) を選択し、ソースアカウントのリンク方法を決定します。
AWS 組織のソースアカウントをリンクするために、AWS CloudFormation テンプレートをダウンロードして CloudFormation の委任された管理アカウントにデプロイできます。
個々のアカウントをリンクするには、各アカウントにデプロイする CloudFormation テンプレートをダウンロードするか、コンソールを使用してアカウントを設定するのに役立つ URL をコピーします。ここでは、URL をコピーして、ソースアカウントとしてサインインしている別のブラウザに貼り付けます。その後、共有するテレメトリデータ (ログ、メトリクス、トレース) を設定できます。前のステップで URL をコピーして貼り付けたため、モニタリングアカウント設定の Amazon リソースネーム (ARN) は事前に入力されています。URL を使用しない場合は、モニタリングアカウントから ARN をコピーしてここに貼り付けることができます。ソースアカウントを識別するために使用されているラベルを確認し、[Link] (リンク) を選択します。
[Confirm monitoring account permission] (モニタリングアカウントの許可を確認) ダイアログで、[Confirm] (確認) と入力してソースアカウントの設定を完了します。
CloudWatch のクロスアカウントオブザーバビリティの使用
クロスアカウントオブザーバビリティの仕組みを確認するために、2 つの AWS Lambda 関数を使用して簡単なクロスアカウントアプリケーションをデプロイします。1 つはソースアカウント (multi-account-function-a)、もう 1 つはモニタリングアカウント (multi-account-function-b) にデプロイします。トリガーされると、ソースアカウントの関数は、モニタリングアカウントの Amazon EventBridge イベントバスにイベントを発行します。そこで、EventBridge ルールがモニタリングアカウント内の関数の実行をトリガーします。これは 2 つのアカウントのみを使用する簡単な設定です。おそらく、お客様はワークロードを複数のソースアカウントで実行していることでしょう。
Lambda コンソールでは、2 つの Lambda 関数により [Active tracing] (アクティブトレーシング) と [Enhanced monitoring] (拡張モニタリング) が有効になっています。テレメトリデータを収集するために、AWS Distro for OpenTelemetry (ADOT) Lambda レイヤーを使用します。[Enhanced monitoring] (拡張モニタリング) オプションを使用すると、Amazon CloudWatch Lambda Insights がオンになり、Lambda 関数のランタイムパフォーマンスメトリクスを収集および集計できます。
ソースアカウントの Lambda コンソールでテストイベントを準備します。その後、[Test] (テスト) を選択し、関数を数回実行します。
ここで、さまざまなアカウントで実行されているアプリケーションのコンポーネントがどのように機能しているのかを見てみましょう。ログから始めて、メトリクスとトレースに移ります。
モニタリングアカウントの CloudWatch コンソールで、ナビゲーションペインの [Logs] (ログ) セクションで [Log groups] (ロググループ) を選択します。そこで、異なる AWS アカウントで実行されている 2 つの Lambda 関数によって作成されたロググループを検索して見つけます。想定どおり、各ロググループはデータの元となったアカウント ID とラベルを表示します。両方のロググループを選択し、[View in Logs Insights] (Logs Insights で表示) を選択します。
CloudWatch Logs Insights クエリ構文を使用して、さまざまな AWS アカウントのログを検索して分析できるようになりました。例えば、簡単なクエリを実行して、2 つのロググループの最後の 20 件のメッセージを確認します。@log フィールドを含めて、ログが属するアカウント ID を確認します。
クロスアカウントのロググループでも Contributor Insights のルールを作成できるようになりました。これにより、例えば、アカウント全体で発生しているセキュリティイベントの全体像を把握したり、複数のアカウントで実行されているサーバーレスアプリケーションでコストが最も高い Lambda リクエストを特定したりできます。
その後、ナビゲーションペインの [Metrics] (メトリクス) セクションで [All metrics] (すべてのメトリクス) を選択します。 CloudWatch Lambda Insights によって収集された Lambda 関数のランタイムパフォーマンスメトリクスを確認するには、LambdaInsights を選択し、その後に function_name を選択します。そこで、multi-account と memory を検索して、メモリメトリクスを確認します。繰り返しになりますが、これらのメトリクスが 2 つの異なるアカウントからのものであることを示すアカウント ID とラベルが表示されます。ここから、関心のあるメトリクスを選択して、クロスアカウントダッシュボードとアラームを作成できます。メトリクスを選択した状態で、[Actions] (アクション) ドロップダウンの [Add to dashboard] (ダッシュボードに追加) を選択します。
新しいダッシュボードを作成し、[Stacked area] (スタックエリア) ウィジェットタイプを選択します。その後、[Add to dashboard] (ダッシュボードに追加) を選択します。
CPU とメモリのメトリクスについても同じ操作を実行して (ただし、異なるウィジェットタイプを使用します)、マルチアカウントの設定を管理できるクロスアカウントダッシュボードを迅速に作成できます。まだトラフィックは多くありませんが、期待しています。
最後に、ナビゲーションペインの [X-Ray traces] (X-Ray トレース) セクションから [Service map] (サービスマップ) を選択して、マルチアカウントアプリケーションのフローを確認します。サービスマップでは、クライアントはソースアカウントの Lambda 関数をトリガーします。その後、イベントが別のアカウントに送信され、他の Lambda 関数を実行します。
サービスマップでは、ソースアカウント (multi-account-function-a) で実行されている関数の歯車アイコンを選択し、[View traces] (トレースを表示) を選択して個々のトレースを確認します。トレースには複数の AWS アカウントからのデータが含まれます。次のような構文を使用して、特定のアカウントからのトレースを検索できます。
サービスマップでは、複数のアカウントからのテレメトリが 1 か所にまとめられ、クロスアカウントアプリケーションをモニタリングするための統合ビューが提供されるようになりました。これは、問題を迅速に特定し、解決時間を短縮するのに役立ちます。
利用可能なリージョンと料金
Amazon CloudWatch のクロスアカウントオブザーバビリティは、現在、AWS マネジメントコンソール、AWS コマンドラインインターフェイス (CLI)、および AWS SDK を使用して、すべての商用 AWS リージョンで利用できます。AWS CloudFormation のサポートは近日中に提供開始予定です。CloudWatch のクロスアカウントオブザーバビリティでは、ログやメトリクスの追加コストは発生せず、最初のトレースコピーは無料です。詳細については、「Amazon CloudWatch pricing」(Amazon CloudWatch の料金) のページを参照してください。
使用するすべての AWS アカウントをモニタリングする一元的な視点を持つことで、全体的なアクティビティをより良く理解でき、複数のアカウントにまたがるアプリケーションの問題を解決するのに役立ちます。
CloudWatch のクロスアカウントオブザーバビリティを使用してすべてのリソースをモニタリングしてみましょう。
– Danilo
原文はこちらです。