翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
Amazon CloudWatch Observability Access Manager を使用してモニタリングを一元化する
作成者: Anand Krishna Varanasi (AWS)、Jimmyorgan (AWS)、Ashish Kumar (AWS)、Balaji Vedagiri (AWS)JAGDISHKOMAKULA、 (AWS)、Satra Chandra Pothula (AWS)、Vivek Thangamuthu (AWS)
概要
オブザーバビリティは、アプリケーションのモニタリング、理解、トラブルシューティングに不可欠です。 AWS Control Tower またはランディングゾーンの実装と同様に、複数のアカウントにまたがるアプリケーションは、多数のログとトレースデータを生成します。問題の迅速なトラブルシューティングを行ったり、ユーザー分析やビジネス分析を理解したりするには、すべてのアカウントにまたがる共通のオブザーバビリティプラットフォームが必要です。Amazon CloudWatch Observability Access Manager を使用すると、複数のアカウントログに一元的にアクセスして制御できます。
オブザーバビリティアクセスマネージャーを使用して、ソースアカウントによって生成されたオブザーバビリティデータログを表示および管理できます。ソースアカウントは AWS アカウント 、リソースのオブザーバビリティデータを生成する個々のアカウントです。オブザーバビリティデータは、ソースアカウントとモニタリングアカウントの間で共有されます。共有オブザーバビリティデータには、Amazon のメトリクス CloudWatch、Amazon CloudWatch Logs のログ、トレースを含めることができます AWS X-Ray。詳細については、「オブザーバビリティアクセスマネージャー 文書」を参照してください。
このパターンは、複数の で実行されるアプリケーションまたはインフラストラクチャを持ち AWS アカウント 、ログを表示するために共通の場所を必要とするユーザーを対象としています。これらのアプリケーションやインフラストラクチャの状態や状態を監視するために、Terraform を使用して オブザーバビリティアクセスマネージャーをセットアップする方法を説明します。このソリューションは、複数の方法でインストールできます。
手動でセットアップしたスタンドアロンの Terraform モジュールとして
継続的インテグレーションと継続的デリバリー (CI/CD) パイプラインを使用する
AWS Control Tower Account Factory for Terraform (AFT) などの他の ソリューションと統合する
エピックセクションの手順では、手動の実装について説明しています。AFT インストール手順については、 GitHub Observability Access Manager
前提条件と制限
前提条件
Terraform
は、システムまたは自動パイプラインにインストールまたは参照されています。(最新バージョン の使用をお勧めします。) 中央監視アカウントとして使用できるアカウント。他のアカウントは、ログを表示するために、中央監視アカウントへのリンクを作成します。
(オプション) Atlassian Bitbucket GitHub AWS CodeCommitなどのソースコードリポジトリ、または同様のシステム。自動 CI/CD パイプラインを使用している場合、ソースコードリポジトリは必要ありません。
(オプション) コードレビューとコードコラボレーションのためのプルリクエスト (PRs) を作成するアクセス許可 GitHub。
制約事項
オブザーバビリティアクセスマネージャーには、以下のサービスクォータがあります。これらのクォータは変更できません。この特徴量を導入する前に、これらのクォータを検討します。詳細については、 CloudWatch ドキュメントのCloudWatch 「 サービスクォータ」を参照してください。
ソースアカウントリンク: 各ソースアカウントを最大 5 つの監視アカウントにリンクできます。
シンク: アカウントに対して複数のシンクを構築できますが、 ごとに AWS リージョン 1 つのシンクしか使用できません。
加えて:
シンクとリンクは同じ で作成する必要があります AWS リージョン。クロスリージョンにすることはできません。
クロスリージョンとクロスアカウントのモニタリング
クロスリージョン、クロスアカウントのモニタリングでは、次のいずれかのオプションを選択できます。
アラームとメトリクスのクロスアカウントダッシュボードとクロスリージョン CloudWatch ダッシュボードを作成します。このオプションは、ログとトレースをサポートしていません。
Amazon OpenSearch Service を使用して集中ログ記録を実装します。
すべてのテナントアカウントからリージョンごとに 1 つのシンクを作成し、(このパターンで説明されているように) 一元化されたモニタリングアカウントにメトリクスをプッシュしてからCloudWatch 、メトリクスストリームを使用して、共通の外部宛先または Datadog、Dynatrace、Sumo Logic、Splunk、New Relic などのサードパーティーのモニタリング製品にデータを送信します。
アーキテクチャ
コンポーネント
CloudWatch Observability Access Manager は、クロスアカウントオブザーバビリティを有効にする 2 つの主要なコンポーネントで構成されています。
シンクは、ソースアカウントがオブザーバビリティデータを中央モニタリングアカウントに送信できるようにします。シンクは基本的に、ソースアカウントが接続するためのゲートウェイジャンクションを提供します。シンクゲートウェイまたは接続は 1 つしかありませんが、複数のアカウントが接続できます。
各ソースアカウントには、シンクゲートウェイジャンクションへのリンクがあり、オブザーバビリティデータはこのリンクを介して送信されます。各ソースアカウントからリンクを作成する前に、シンクを作成する必要があります。
アーキテクチャ
次の図表は、オブザーバビリティアクセスマネージャーとそのコンポーネントの説明です。

ツール
AWS のサービス
Amazon CloudWatch は、 AWS リソースと で実行しているアプリケーションのメトリクスを AWS リアルタイムでモニタリングするのに役立ちます。
AWS Organizations は、作成して一元管理する AWS アカウント 組織に複数の を統合するのに役立つアカウント管理サービスです。
AWS Identity and Access Management (IAM) は、誰を認証し、誰に使用を許可するかを制御することで、 AWS リソースへのアクセスを安全に管理できます。
ツール
Terraform
は、クラウドおよびオンプレミスのリソースの作成と管理に役立つ HashiCorp の Infrastructure as Code (IaC) ツールです。 AWS Control Tower Account Factory for Terraform (AFT) は、アカウントのプロビジョニングとカスタマイズに役立つ Terraform パイプラインを設定します AWS Control Tower。オプションAFTで、 を使用して、複数のアカウントにわたって大規模にオブザーバビリティアクセスマネージャーをセットアップできます。
コードリポジトリ
このパターンのコードは、 GitHub Observability Access Manager
ベストプラクティス
AWS Control Tower 環境では、ログ記録アカウントを中央モニタリングアカウント (シンク) としてマークします。
に複数のアカウントを持つ複数の組織がある場合は AWS Organizations、個々のアカウントではなく組織を設定ポリシーに含めることをお勧めします。アカウントの数が少ない場合や、アカウントがシンク設定ポリシーの組織に含まれていない場合は、代わりに個別のアカウントを含めることを決定できます。
エピック
タスク | 説明 | 必要なスキル |
---|---|---|
リポジトリをクローン作成します。 | GitHub Observability Access Manager リポジトリのクローンを作成します。
| AWS DevOps、クラウド管理者、AWS管理者 |
シンクモジュールのプロパティ値を指定します。 |
詳細については、 AWS CloudFormation ドキュメントのAWS「::Oam::Sink」を参照してください。 | AWS DevOps、クラウド管理者、AWS管理者 |
シンクモジュールをインストールします。 | モニタリングアカウントとして AWS アカウント 選択した の認証情報をエクスポートし、オブザーバビリティアクセスマネージャーシンクモジュールをインストールします。
| AWS DevOps、クラウド管理者、AWS管理者 |
タスク | 説明 | 必要なスキル |
---|---|---|
リンクモジュールのプロパティ値を指定します。 |
詳細については、 AWS CloudFormation ドキュメントのAWS「::Oam::Link」を参照してください。 | AWS DevOps、クラウド管理者、クラウドアーキテクト |
個々のアカウントにリンクモジュールをインストールします。 | 個々のアカウントの認証情報をエクスポートし、オブザーバビリティアクセスマネージャーリンクモジュールをインストールします
リンクモジュールは、アカウントごとに個別に設定することも、 AFT を使用して多数のアカウントにこのモジュールを自動的にインストールすることもできます。 | AWS DevOps、クラウド管理者、クラウドアーキテクト |
タスク | 説明 | 必要なスキル |
---|---|---|
ステータスメッセージ。 |
右側に、緑色のチェックマークが付いた「監視アカウントの有効化」というステータスメッセージが表示されます。つまり、モニタリングアカウントには、他のアカウントのリンクが接続されるオブザーバビリティアクセスマネージャーシンクがあることを意味します。 | |
接続を承認します link-to-sink。 |
詳細については、 CloudWatch ドキュメントの「モニタリングアカウントとソースアカウントをリンクする」を参照してください。 | AWS DevOps、クラウド管理者、クラウドアーキテクト |
タスク | 説明 | 必要なスキル |
---|---|---|
クロスアカウントデータを表示します。 |
| AWS DevOps、クラウド管理者、クラウドアーキテクト |
タスク | 説明 | 必要なスキル |
---|---|---|
他のアカウントのメトリクス、ダッシュボード、ログ、ウィジェット、アラームを表示します。 | 追加の機能として、 CloudWatch メトリクス、ダッシュボード、ログ、ウィジェット、アラームを他のアカウントと共有 できます。各アカウントは、 CloudWatchCrossAccountSharingRole という IAMロールを使用して、このデータにアクセスします。 中央モニタリングアカウントと信頼関係にあるソースアカウントは、このロールを引き受け、モニタリングアカウントのデータを表示できます。 CloudWatch には、ロールを作成するためのサンプル CloudFormation スクリプトが用意されています。データを表示するアカウントでこのスクリプトを実行する IAM でロールを管理する を選択します。
詳細については、 CloudWatch ドキュメントの「 でのクロスアカウント機能の有効化 CloudWatch」を参照してください。 | AWS DevOps、クラウド管理者、クラウドアーキテクト |
タスク | 説明 | 必要なスキル |
---|---|---|
クロスアカウント、クロスリージョンアクセスを設定します。 | 中央監視アカウントでは、オプションでアカウントセレクターを追加して、認証なしで簡単にアカウントを切り替えたり、そのデータを表示したりできます。
詳細については、 CloudWatch ドキュメントの「クロスアカウントクロスリージョン CloudWatch コンソール」を参照してください。 | AWS DevOps、クラウド管理者、クラウドアーキテクト |
関連リソース
CloudWatch クロスアカウントオブザーバビリティ (Amazon CloudWatch ドキュメント)
Amazon CloudWatch Observability Access Manager APIリファレンス (Amazon CloudWatch ドキュメント)
「リソース:aws_oam_sink
」 (テラフォームドキュメント) 「データソース: aws_oam_link
」 (テラフォームドキュメンテーション) CloudWatchObservabilityAccessManager
(AWS Boto3 ドキュメント)