翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。 # Amazon CloudWatch オブザーバビリティアクセスマネージャーを使用してモニタリングを一元化 *Amazon Web Services、Anand Krishna Varanasi、JAGDISH KOMAKULA、Ashish Kumar、Jimmy Morgan、Sarat Chandra Pothula、Vivek Thangamuthu、Balaji Vedagiri* ## 概要 オブザーバビリティは、アプリケーションのモニタリング、理解、トラブルシューティングに不可欠です。 AWS Control Tower またはランディングゾーンの実装と同様に、複数のアカウントにまたがるアプリケーションは、多数のログとトレースデータを生成します。問題の迅速なトラブルシューティングを行ったり、ユーザー分析やビジネス分析を理解したりするには、すべてのアカウントにまたがる共通のオブザーバビリティプラットフォームが必要です。Amazon CloudWatch オブザーバビリティアクセスマネージャーは、複数のアカウントログに一元的にアクセスし制御できます。 オブザーバビリティアクセスマネージャーを使用して、ソースアカウントによって生成されたオブザーバビリティデータログを表示および管理できます。ソースアカウントは AWS アカウント 、リソースのオブザーバビリティデータを生成する個々のアカウントです。オブザーバビリティデータは、ソースアカウントとモニタリングアカウントの間で共有されます。共有されるオブザーバビリティデータには、Amazon CloudWatch のメトリクス、Amazon CloudWatch Logs、 AWS X-Rayのトレースを含めることができます。詳細については、「[オブザーバビリティアクセスマネージャー 文書](https://docs.aws.amazon.com/OAM/latest/APIReference/Welcome.html)」を参照してください。 このパターンは、複数の で実行され AWS アカウント 、ログを表示するために共通の場所を必要とするアプリケーションまたはインフラストラクチャを持つユーザーを対象としています。これらのアプリケーションやインフラストラクチャの状態や状態を監視するために、Terraform を使用して オブザーバビリティアクセスマネージャーをセットアップする方法を説明します。このソリューションは、複数の方法でインストールできます。 + 手動で設定したスタンドアロンの Terraform モジュールとして + 継続的インテグレーションと継続的デリバリー (CI/CD) パイプラインを使用 + [AWS Control Tower Account Factory for Terraform (AFT)](https://docs.aws.amazon.com/controltower/latest/userguide/aft-overview.html) などの他のソリューションと統合 「[エピック](#centralize-monitoring-by-using-amazon-cloudwatch-observability-access-manager-epics)」セクションの手順では、手動による実装についても説明しています。AFT のインストール手順については、GitHub [オブザーバビリティアクセスマネージャー](https://github.com/aws-samples/cloudwatch-obervability-access-manager-terraform)リポジトリの README ファイルを参照してください。 ## 前提条件と制限 **前提条件** + [Terraform](https://www.terraform.io/) は、システムまたは自動パイプラインにインストールまたは参照されています ([最新バージョン](https://releases.hashicorp.com/terraform/)の使用をお勧めします)。 + 中央監視アカウントとして使用できるアカウント。他のアカウントは、ログを表示するために、中央監視アカウントへのリンクを作成します。 + (オプション) GitHub、 AWS CodeCommit Atlassian Bitbucket、または同様のシステムなどのソースコードリポジトリ。自動化された CI/CD パイプラインを使用する場合、ソースコードリポジトリは必要ありません。 + (オプション) GitHub でコードレビューとコードコラボレーションのためのプルリクエスト (PR) を作成する権限。 **制限事項** オブザーバビリティアクセスマネージャーには、以下のサービスクォータがあります。これらのクォータは変更できません。この特徴量を導入する前に、これらのクォータを検討します。詳細については、「CloudWatch ドキュメント」の「[CloudWatch Service Quotas](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch_limits.html)」を参照してください。 + **ソースアカウントリンク**: 各ソースアカウントを最大 5 つの監視アカウントにリンクできます。 + **シンク**: アカウントに対して複数のシンクを構築できますが、 あたり 1 つのシンクのみが許可され AWS リージョン ます。 加えて: + シンクとリンクは同じ で作成する必要があります AWS リージョン。クロスリージョンにすることはできません。 **クロスリージョンとクロスアカウントのモニタリング** クロスリージョンとクロスアカウントモニタリングでは、次のいずれかのオプションを選択できます。 + アラームとメトリクスを使用するための、[クロスアカウントおよびクロスリージョン CloudWatch ダッシュボード](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Cross-Account-Cross-Region.html)を作成します。このオプションでは、ログとトレースはサポートされません。 + Amazon OpenSearch Service を使用して、[一元的なログ記録](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Cross-Account-Cross-Region.html)を実装します。 + すべてのテナントアカウントから、リージョンごとに 1 つのシンクを作成します。一元化されたモニタリングアカウントにメトリクスをプッシュし (このパターンで説明)、[CloudWatch メトリクスストリーム](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-Metric-Streams.html)を使用して、共通の外部宛先またはサードパーティーのモニタリング製品 (Datadog、Dynatrace、Sumo Logic、Splunk、New Relic など) にデータを送信します。 ## アーキテクチャ **コンポーネント** CloudWatch オブザーバビリティアクセスマネージャーは、クロスアカウントオブザーバビリティを可能にする、次の 2 つの主要コンポーネントで構成されています。 + *シンク*は、ソースアカウントがオブザーバビリティデータを中央モニタリングアカウントに送信できるようにします。シンクは基本的に、ソースアカウントが接続するためのゲートウェイジャンクションを提供します。シンクゲートウェイまたは接続は 1 つしかありませんが、複数のアカウントが接続できます。 + 各ソースアカウントには、シンクゲートウェイジャンクションへの*リンク*があり、オブザーバビリティデータはこのリンクを介して送信されます。各ソースアカウントからリンクを作成する前に、シンクを作成する必要があります。 **アーキテクチャ** 次の図表は、オブザーバビリティアクセスマネージャーとそのコンポーネントの説明です。 ![\[シンクとリンクを使用したクロスアカウントオブザーバビリティのアーキテクチャ。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/00603763-4f99-456e-85e7-a80d803b087d/images/5188caf9-348b-4d91-b560-2b3d6ea81191.png) ## ツール **AWS のサービス** + [Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html) は、 AWS リソースと で実行しているアプリケーションのメトリクスを AWS リアルタイムでモニタリングするのに役立ちます。 + [AWS Organizations](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_introduction.html) は、作成して一元管理する AWS アカウント 組織に複数の を統合するのに役立つアカウント管理サービスです。 + [AWS Identity and Access Management (IAM)](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction.html) は、誰を認証し、誰に使用する権限を付与するかを制御することで、 AWS リソースへのアクセスを安全に管理するのに役立ちます。 **ツール** + 「[Terraform](https://www.terraform.io/)」は、HashiCorpのinfrastructure as code (IaC) ツールで、クラウドとオンプレミスのリソースの作成と管理を支援します。 + [AWS Control Tower Account Factory for Terraform (AFT)](https://docs.aws.amazon.com/controltower/latest/userguide/aft-overview.html) は、アカウントのプロビジョニングとカスタマイズに役立つ Terraform パイプラインを設定します AWS Control Tower。オプションで AFT を使用して、複数のアカウントにまたがるオブザーバビリティアクセスマネージャーを大規模にセットアップできます。 **コードリポジトリ** このパターンのコードは、GitHub 内の「[オブザーバビリティアクセス マネージャー](https://github.com/aws-samples/cloudwatch-obervability-access-manager-terraform)」リポジトリで利用できます。 ## ベストプラクティス + AWS Control Tower 環境では、ログ記録アカウントを中央モニタリングアカウント (シンク) としてマークします。 + に複数のアカウントを持つ複数の組織がある場合は AWS Organizations、個々のアカウントではなく組織を設定ポリシーに含めることをお勧めします。アカウントの数が少ない場合や、アカウントがシンク設定ポリシーの組織に含まれていない場合は、代わりに個別のアカウントを含めることを決定できます。 ## エピック ### シンクモジュールをセットアップします | タスク | 説明 | 必要なスキル | | --- | --- | --- | | リポジトリのクローン作成 | GitHub オブザーバビリティアクセスマネージャーのリポジトリをクローニングします：
git clone https://github.com/aws-samples/cloudwatch-obervability-access-manager-terraform
| AWS DevOps、クラウド管理者、AWS 管理者 | | シンクモジュールのプロパティ値を指定します。 | `main.tf` ファイル (リポジトリの `deployments/aft-account-customizations/LOGGING/terraform/`** **フォルダー内)で、以下のプロパティの値を指定します：[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/centralize-monitoring-by-using-amazon-cloudwatch-observability-access-manager.html)詳細については、 CloudFormation ドキュメントの[AWS::Oam::Sink](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-oam-sink.html)」を参照してください。 | AWS DevOps、クラウド管理者、AWS 管理者 | | シンクモジュールをインストールします。 | モニタリングアカウントとして AWS アカウント 選択した の認証情報をエクスポートし、オブザーバビリティアクセスマネージャーシンクモジュールをインストールします。
Terraform Init
Terrafom Plan
Terraform Apply
| AWS DevOps、クラウド管理者、AWS 管理者 | ### リンクモジュールをセットアップします。 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | リンクモジュールのプロパティ値を指定します。 | `main.tf ` ファイル (リポジトリの `deployments/aft-account-customizations/LOGGING/terraform/`** **フォルダー内) で、以下のプロパティの値を指定します：[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/centralize-monitoring-by-using-amazon-cloudwatch-observability-access-manager.html)詳細については、 CloudFormation ドキュメントの[AWS::Oam::Link](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-oam-link.html)」を参照してください。 | AWS DevOps、クラウド管理者、クラウドアーキテクト | | 個々のアカウントにリンクモジュールをインストールします。 | 個々のアカウントの認証情報をエクスポートし、オブザーバビリティアクセスマネージャーリンクモジュールをインストールします
Terraform Plan
Terraform Apply
リンクモジュールはアカウントごとに個別に設定することも、[AFT](https://docs.aws.amazon.com/controltower/latest/userguide/aft-overview.html) を使用してこのモジュールを多数のアカウントに自動的にインストールすることもできます。 | AWS DevOps、クラウド管理者、クラウドアーキテクト | ### シンクからリンクへの接続を承認 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | ステータスメッセージ。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/centralize-monitoring-by-using-amazon-cloudwatch-observability-access-manager.html)右側に、緑色のチェックマークが付いた**「監視アカウントの有効化」**というステータスメッセージが表示されます。つまり、モニタリングアカウントには、他のアカウントのリンクが接続されるオブザーバビリティアクセスマネージャーシンクがあることを意味します。 | | | リンクとシンク間の接続を承認します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/centralize-monitoring-by-using-amazon-cloudwatch-observability-access-manager.html)詳細については、CloudWatch ドキュメントの「[モニタリングアカウントをソースアカウントにリンクする](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-Unified-Cross-Account-Setup.html)」を参照してください。 | AWS DevOps、クラウド管理者、クラウドアーキテクト | ### クロスアカウントオブザーバビリティデータを検証 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | クロスアカウントデータを表示します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/centralize-monitoring-by-using-amazon-cloudwatch-observability-access-manager.html) | AWS DevOps、クラウド管理者、クラウドアーキテクト | ### (オプション) ソースアカウントがモニタリングアカウントを信頼できるようにする | タスク | 説明 | 必要なスキル | | --- | --- | --- | | 他のアカウントのメトリクス、ダッシュボード、ログ、ウィジェット、アラームを表示します。 | 追加の特徴量として、** ** CloudWatch メトリクス、ダッシュボード、ログ、ウィジェット、アラームを他のアカウントと共有できます。各アカウントは、**CloudWatch-CrossAccountSharingRole** と呼ばれる IAM ロールを使用して、このデータにアクセスします。中央モニタリングアカウントと信頼関係にあるソースアカウントは、このロールを引き受け、モニタリングアカウントのデータを表示できます。CloudWatch には、ロールを作成するためのサンプル CloudFormation スクリプトが用意されています。［**IAM でロールを管理する**］を選択し、データを表示したいアカウントでこのスクリプトを実行します。
{
    "Version": "2012-10-17",		 	 	 
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "AWS": [
                    "arn:aws:iam::XXXXXXXXX:root",
                    "arn:aws:iam::XXXXXXXXX:root",
                    "arn:aws:iam::XXXXXXXXX:root",
                    "arn:aws:iam::XXXXXXXXX:root"
                ]
            },
            "Action": "sts:AssumeRole"
        }
    ]
}
詳細については、CloudWatch ドキュメントの「[CloudWatch でのクロスアカウントクロスリージョン機能の有効化](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Cross-Account-Cross-Region.html#enable-cross-account-cross-Region)」を参照してください。 | AWS DevOps、クラウド管理者、クラウドアーキテクト | ### (オプション) モニタリングアカウントから、クロスアカウント/クロスリージョンを表示 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | クロスアカウント、クロスリージョンアクセスを設定します。 | 中央監視アカウントでは、オプションでアカウントセレクターを追加して、認証なしで簡単にアカウントを切り替えたり、そのデータを表示したりできます。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/centralize-monitoring-by-using-amazon-cloudwatch-observability-access-manager.html)ステップや情報については、CloudWatch ユーザーガイドの「[クロスアカウントクロスリージョン CloudWatch コンソール](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Cross-Account-Cross-Region.html)」を参照してください。 | AWS DevOps、クラウド管理者、クラウドアーキテクト | ## 関連リソース + 「[CloudWatch クロスアカウントオブザーバビリティ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-Unified-Cross-Account.html)」 (Amazon CloudWatch ドキュメント) + 「[Amazon CloudWatch オブザーバビリティアクセスマネージャー API リファレンス」](https://docs.aws.amazon.com/OAM/latest/APIReference/Welcome.html) (Amazon CloudWatch ドキュメント) + 「[リソース:aws\$1oam\$1sink](https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/oam_sink)」 (テラフォームドキュメント) + 「[データソース: aws\$1oam\$1link](https://registry.terraform.io/providers/hashicorp/aws/latest/docs/data-sources/oam_link)」 (テラフォームドキュメンテーション) + [CloudWatchObservabilityAccessManager](https://boto3.amazonaws.com/v1/documentation/api/latest/reference/services/oam.html) (AWS Boto3 ドキュメント)