翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

# CloudWatch デプロイを計画する
<a name="planning-cloudwatch-deployment"></a>

ロギングとモニタリングのソリューションの複雑さと範囲は、以下のようないくつかの要因に依存します。
+ 使用されている環境、リージョン、およびアカウントの数と、この数がどのように増加するかです。
+ 既存のワークロードとアーキテクチャの多様性と種類。
+ ログに記録、および監視する必要のあるコンピューティングタイプと OS です。
+ オンプレミスの場所と AWS インフラストラクチャの両方があるかどうか。
+ 複数のシステム、アプリケーションの集計、および分析要件です。
+ ログやメトリクスの不正な流出を防ぐためのセキュリティ要件です。
+ 運用プロセスをサポートするために、ロギングおよびモニタリングソリューションと統合する必要がある製品とソリューションです。

新規または更新されたワークロードの導入に伴い、ロギングおよびモニタリングソリューションを定期的に見直し、更新する必要があります。ロギング、モニタリング、およびアラームの更新は、問題が観察されたときに特定し、適用する必要があります。将来的に、このような問題はプロアクティブに特定され、防止することができます。

ログとメトリクスを取得・取り込むためのソフトウェアとサービスを一貫してインストール、および構成していることを確認する必要があります。確立されたログ記録とモニタリングのアプローチでは、さまざまなドメイン (セキュリティ、パフォーマンス、ネットワーク、分析など) に複数の AWS 、または独立したソフトウェアベンダー (ISV) のサービスとソリューションを使用します。各ドメインには、独自の展開および構成要件があります。

CloudWatch を使用して、複数の OS とコンピューティングタイプのログとメトリクスを取得することをお勧めします。多くの AWS サービスでは、CloudWatch を使用してログとメトリクスをログに記録し、モニタリングし、公開します。さらに設定する必要はありません。CloudWatch は [ソフトウェアエージェント](https://docs.aws.amazon.com//AmazonCloudWatch/latest/monitoring/Install-CloudWatch-Agent.html) を提供しており、様々な OS や環境に合わせてインストールや設定ができます。以下のセクションでは、複数のアカウント、リージョン、構成に対して CloudWatch エージェントをデプロイ、インストール、および設定する方法について説明します。

**Topics**
+ [

# 集中型、または分散型アカウントで CloudWatch を使用する
](cloudwatch-centralized-distributed-accounts.md)
+ [

# CloudWatch エージェント設定ファイルの管理
](create-store-cloudwatch-configurations.md)

# 集中型、または分散型アカウントで CloudWatch を使用する
<a name="cloudwatch-centralized-distributed-accounts"></a>

CloudWatch は 1 つのアカウントとリージョンのサービス AWS またはリソースをモニタリングするように設計されていますが、中央アカウントを使用して複数のアカウントとリージョンからログとメトリクスをキャプチャできます。複数のアカウント、またはリージョンを使用する場合は、集中型アカウントのアプローチを使用するか、個々のアカウントを使用してログとメトリクスを取得するかを評価する必要があります。通常、セキュリティ、分析、運用、ワークロードの所有者の要件をサポートするために、マルチアカウント、およびマルチリージョンデプロイにはハイブリッドアプローチが必要です。

次の表は、集中型、分散型、またはハイブリッドアプローチを選択する際に考慮すべき事項を示しています。


****  

|  |  | 
| --- |--- |
| アカウント構造 | 組織では、特定の環境内の単一のアプリケーションに対して複数の個別のアカウント（例えば、非本番ワークロードと本番ワークロードのアカウントなど）または数千のアカウントがある場合があります。ワークロードが実行されるアカウントでアプリケーションのログとメトリクスを管理し、ワークロードの所有者がログとメトリクスにアクセスできるようにすることを推奨します。これにより、ロギングとモニタリングでアクティブなロールを持つことができます。また、分析、集計、傾向、および集中操作のために、すべてのワークロードログを集約する別のログ用アカウントを使用することを推奨します。個別のログ記録アカウントは、セキュリティ、アーカイブとモニタリング、および分析にも使用できます。 | 
| アクセス要件 | チームメンバー（たとえば、ワークロード所有者や開発者）は、トラブルシューティングや改善のためにログやメトリクスにアクセスする必要があります。ログは、アクセスやトラブルシューティングを容易にするために、ワークロードのアカウントで管理する必要があります。ログと測定基準をワークロードとは別のアカウントで管理する場合、ユーザーは、定期的にアカウントを交互に切り替える必要があるかもしれません。集中型アカウントを使用すると、ワークロードアカウントへのアクセスを許可せずに、承認されたユーザーにログ情報が提供されます。これにより、複数のアカウントで実行されているワークロードから集約が必要な分析ワークロードのアクセス要件を簡素化できます。集中型ログ記録アカウントには、Amazon OpenSearch Service クラスターなどの代替の検索および集約オプションも使用できます。Amazon OpenSearch Service [は、ログのフィールドレベルまできめ細かなアクセスコントロール](https://docs.aws.amazon.com//opensearch-service/latest/developerguide/fgac.html)を提供します。特殊なアクセスや許可を必要とする機密データを扱う場合、きめ細かなアクセス制御が重要になります。 | 
| オペレーション | 多くの組織では、集中管理された運用・セキュリティチームや、運用支援のための外部組織があり、モニタリングのためのログへのアクセスが必要です。ログとモニタリングを一元化することで、すべてのアカウントとワークロードの傾向の把握、検索、集計、分析の実行が容易になります。組織が DevOps のために「[構築し、実行する](https://aws.amazon.com//blogs/enterprise-strategy/enterprise-devops-why-you-should-run-what-you-build/)」アプローチを使用している場合、ワークロードの所有者は自分のアカウントでログとモニタリング情報を必要とします。分散したワークロードの所有権に加えて、中央の運用と分析を満足させるには、ハイブリッドなアプローチが必要になるかもしれません。 | 
| 環境 |  セキュリティ要件とアカウントのアーキテクチャに応じて、本番用アカウントではログとメトリクスを中央でホストし、その他の環境（例えば、開発またはテスト）ではログとメトリクスを同じアカウントまたは別のアカウントに保持することを選択できます。これにより、本番環境で作成された機密データが、より多くのユーザーによってアクセスされることを防ぐことができます。   | 

CloudWatch は、CloudWatch サブスクリプションフィルタでリアルタイムにログを処理するための [複数のオプション](https://docs.aws.amazon.com//AmazonCloudWatch/latest/logs/Subscriptions.html) を提供します。サブスクリプションフィルターを使用して、ログを AWS サービスにリアルタイムでストリーミングし、カスタム処理、分析、他のシステムにロードできます。これは、集中管理されたアカウントとリージョンだけでなく、個々のアカウントとリージョンでもログと測定基準を利用できるハイブリッドアプローチをとっている場合に特に役立ちます。次のリストは、このために使用できる AWS サービスの例を示しています。
+ [Amazon Data Firehose](https://docs.aws.amazon.com//firehose/latest/dev/what-is-this-service.html) – Firehose は、生成されるデータボリュームに基づいて自動的にスケーリングおよびサイズ変更するストリーミングソリューションを提供します。Amazon Kinesis データストリーム内のシャード数を管理する必要はなく、追加のコーディングなしで Amazon Simple Storage Service (Amazon S3)、Amazon OpenSearch Service、または Amazon Redshift に直接接続できます。Firehose は、これらの AWS サービスにログを一元化する場合に効果的なソリューションです。
+ [Amazon Kinesis Data Streams](https://docs.aws.amazon.com//streams/latest/dev/introduction.html) – Firehose がサポートしていないサービスと統合し、追加の処理ロジックを実装する必要がある場合、Kinesis Data Streams は適切なソリューションです。中央アカウントで Kinesis データストリームを指定するアカウントとリージョンに Amazon CloudWatch Logs 送信先を作成し、ストリームにレコードを配置するアクセス許可を付与する AWS Identity and Access Management (IAM) ロールを作成できます。Kinesis Data Streams は、ログデータのための柔軟でオープンエンドなランディングゾーンを提供し、その後、さまざまなオプションで使用することができます。Kinesis Data Streams のログデータをアカウントに読み込み、前処理を行い、選択した宛先にデータを送信することができます。

  ただし、生成されるログデータに合わせて適切なサイズになるように、ストリーミングのシャードを構成する必要があります。Kinesis Data Streams は、ログデータの一時的な仲介またはキューとして機能し、データを Kinesis ストリーム内に 1 ～ 365 日間保存できます。Kinesis Data Streams は再生機能もサポートしており、使用されなかったデータを再生することができます。
+ [Amazon OpenSearch Service](https://docs.aws.amazon.com//opensearch-service/latest/developerguide/what-is.html) – CloudWatch Logs は、ロググループのログを、個別または一元化されたアカウントの OpenSearch クラスターにストリーミングできます。OpenSearch クラスターにデータをストリーミングするようにロググループを設定すると、ロググループと同じアカウントとリージョンに Lambda 関数が作成されます。Lambda 関数には、OpenSearch クラスターとのネットワーク接続が必要です。Lambda 関数をカスタマイズして、Amazon OpenSearch Service への取り込みをカスタマイズするだけでなく、追加の前処理を実行することもできます。Amazon OpenSearch Service による一元的なログ記録により、クラウドアーキテクチャの複数のコンポーネントにわたる問題の分析、検索、トラブルシューティングが容易になります。
+ [Lambda](https://docs.aws.amazon.com//lambda/latest/dg/welcome.html) - Kinesis Data Streams を使用する場合、ストリーミングからデータを消費するコンピューティングリソースをプロビジョニングおよび管理する必要があります。これを回避するには、処理のためにログデータを直接 Lambda にストリーミングし、ロジックに基づいて送信先に送信します。つまり、受信データをを処理するためのコンピューティングリソースをプロビジョニングして管理する必要がありません。Lambda を使用することを選択した場合、ソリューションが [Lambda クォータ](https://docs.aws.amazon.com//lambda/latest/dg/gettingstarted-limits.html) と互換性があることを確認してください。

CloudWatch Logs にファイル形式で保存されているログデータを処理または共有する必要がある場合があります。特定の日付または時間範囲のロググループを [Amazon S3 にエクスポートする](https://docs.aws.amazon.com//AmazonCloudWatch/latest/logs/S3Export.html) エクスポートタスクを作成することができます。例えば、分析や監査のために、Amazon S3 に毎日ログをエクスポートすることを選択することができます。Lambda を使用すると、このソリューションを自動化することができます。また、このソリューションを Amazon S3 レプリケーションと組み合わせることで、複数のアカウントやリージョンから 1 つの集中アカウントやリージョンにログを出荷し、一元管理することができます。

CloudWatch エージェントの設定では、`credentials`[セクション](https://docs.aws.amazon.com//AmazonCloudWatch/latest/monitoring/CloudWatch-Agent-Configuration-File-Details.html#CloudWatch-Agent-Configuration-File-Agentsection) に `agent` フィールドを指定することも可能です。これは、メトリクスやログを別のアカウントに送信する際に使用する IAM ロールを指定するものです。指定した場合、このフィールドは `role_arn` パラメータが含まれています。このフィールドは、特定の集中型アカウントおよびリージョンで集中ロギングとモニタリングのみが必要な場合に使用できます。

[AWS SDK](https://aws.amazon.com/developer/tools/) を使用して、任意の言語で独自のカスタム処理アプリケーションを記述したり、アカウントからログやメトリクスを読み取ったり、データを一元管理されたアカウントや他の送信先に送信して、さらなる処理やモニタリングを行ったりすることもできます。

# CloudWatch エージェント設定ファイルの管理
<a name="create-store-cloudwatch-configurations"></a>

すべての Amazon Elastic Compute Cloud (Amazon EC2) インスタンスとオンプレミスサーバーでキャプチャするシステムログとメトリクスを含む、標準の Amazon CloudWatch エージェント設定を作成することをお勧めします。Amazon EC2 CloudWatch エージェント [設定ファイルウィザード](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/create-cloudwatch-agent-configuration-file-wizard.html) を使用すると、設定ファイルの作成に役立ちます。構成ウィザードを複数回実行することで、異なるシステムや環境に対して固有の構成を生成することができます。また、[設定ファイルのスキーマ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-Agent-Configuration-File-Details.html) を使用して、設定ファイルを変更したり、バリエーションを作成したりすることもできます。CloudWatch エージェント設定ファイルは、 [AWS Systems Manager パラメータストア](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-parameter-store.html)パラメータに保存できます。 [複数の CloudWatch エージェント設定ファイル](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-Agent-common-scenarios.html#CloudWatch-Agent-multiple-config-files)がある場合は、個別の Parameter Store パラメータを作成できます。複数の AWS アカウントまたは AWS リージョンを使用している場合は、各アカウントとリージョンで Parameter Store パラメータを管理および更新する必要があります。または、CloudWatch 設定を Amazon S3 または任意のバージョン管理ツールのファイルとして一元管理することもできます。 

CloudWatch エージェントに含まれる `amazon-cloudwatch-agent-ctl` スクリプトでは、設定ファイル、Parameter Store パラメータ、またはエージェントのデフォルト設定を指定することができます。デフォルトの設定は、ベーシックな事前定義されたメトリクスセットに合わせ、CloudWatch にメモリとディスクスペースのメトリクスを報告するようにエージェントを構成しています。ただし、ログファイルの設定は含まれません。CloudWatch エージェントに [Systems Manager Quick Setup](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-quick-setup.html) を使用した場合にも、デフォルトの設定が適用されます。

デフォルト設定にはログ記録が含まれず、要件に合わせてカスタマイズされていないため、要件に合わせてカスタマイズされた独自の CloudWatch 設定を作成して適用することをお勧めします。

## CloudWatch 設定の管理
<a name="store-cloudwatch-configuration-s3"></a>

デフォルトでは、CloudWatch 設定は Parameter Store パラメータまたは CloudWatch 設定ファイルとして保存および適用できます。最適な選択肢は、要件によって異なります。このセクションでは、これら 2 つのオプションの長所と短所について説明します。また、複数の AWS アカウントと AWS リージョンの CloudWatch 設定ファイルを管理するための代表的なソリューションについても詳しく説明します。

**Systems Manager パラメータストアのパラメータ**

パラメータストアパラメータを使用して CloudWatch 設定を管理するのは、少数の AWS アカウントとリージョンに適用して管理する単一の標準 CloudWatch エージェント設定ファイルがある場合に適しています。CloudWatch 設定をパラメータストアパラメータとして保存すると、CloudWatch エージェント設定ツール (`amazon-cloudwatch-agent-ctl`Linux の場合) を使用して、設定ファイルをインスタンスにコピーすることなく、パラメータストアから設定を読み取って適用できます。**AmazonCloudWatch-ManageAgent **Systems Manager コマンドドキュメントを使用して、1 回の実行で複数の EC2 インスタンスの CloudWatch 設定を更新できます。Parameter Store パラメータはリージョン別であるため、各 AWS リージョンと AWS アカウントで CloudWatch Parameter Store パラメータを更新および維持する必要があります。各インスタンスに適用する複数の CloudWatch 設定がある場合は、**AmazonCloudWatch-ManageAgent** コマンドドキュメントをカスタマイズ** **して、これらのパラメータを含める必要があります。

**CloudWatch 設定ファイル**

ファイルとしての CloudWatch 設定の管理は、AWS アカウントとリージョンが多数あり、複数の CloudWatch 設定ファイルを管理している場合にうまく機能する可能性があります。このアプローチを使用して、フォルダ構造で参照、整理、管理できます。  セキュリティルールを個々のフォルダまたはファイルに適用して、更新や読み取りのアクセス許可などのアクセスを制限および付与できます。コラボレーションのために AWS の外部で共有および転送できます。ファイルをバージョン管理して、変更を追跡および管理できます。各設定ファイルを個別に適用せずに、設定ファイルを CloudWatch エージェント設定ディレクトリにコピーすることで、CloudWatch 設定をまとめて適用できます。 CloudWatch Linux の場合、CloudWatch 設定ディレクトリは `/opt/aws/amazon-cloudwatch-agent/etc/amazon-cloudwatch-agent.d` にあります。。Windows の場合、設定ディレクトリは `C:\ProgramData\Amazon\AmazonCloudWatchAgent\Configs` にあります。

CloudWatch エージェントを起動すると、エージェントは自動的にこれらのディレクトリで見つかった各ファイルを追加し、CloudWatch コンポジットコンフィギュレーションファイルを作成します。設定ファイルは、必要なアカウントとリージョンがアクセスできる中央ロケーション（例えば、S3 バケット）に保存する必要があります。このアプローチを使用したソリューションの例を示します。

**CloudWatch 設定の整理**

CloudWatch 設定の管理に使用されるアプローチに関係なく、CloudWatch 設定を整理します。次のようなアプローチを使用して、設定をファイルまたは Parameter Store パスに整理できます。


|  |  | 
| --- |--- |
| */config/standard/windows/ec2* | Amazon EC2 用の Windows 標準の CloudWatch 設定ファイルを保存します。このフォルダでは、さまざまな Windows バージョン、EC2 インスタンスタイプ、環境の標準オペレーティングシステム (OS) 設定をさらに分類できます。 | 
| */config/standard/windows/onpremises* | オンプレミスサーバー用の Windows 標準の CloudWatch 設定ファイルを保存します。また、このフォルダのさまざまな Windows バージョン、サーバータイプ、環境の標準 OS 設定をさらに分類します。 | 
| */config/standard/linux/ec2* | Amazon EC2 用の Linux 標準の CloudWatch 設定ファイルを保存します。このフォルダでは、さまざまな Linux ディストリビューション、EC2 インスタンスタイプ、環境の標準 OS 設定をさらに分類できます。 | 
| */config/standard/linux/onpremises* | オンプレミスサーバー用の Linux 固有の標準的な CloudWatch 設定ファイルを保存します。このフォルダでは、さまざまな Linux ディストリビューション、サーバータイプ、環境の標準 OS 設定をさらに分類できます。 | 
| */config/ecs* | Amazon ECS コンテナインスタンスを使用する場合は、Amazon Elastic Container Service (Amazon ECS) に固有の CloudWatch 設定ファイルを保存します。これらの設定は、Amazon ECS 固有のシステムレベルのロギングとモニタリングのために、Amazon EC2 の標準設定に追加することができます。 | 
| */config/ <application\$1name>* | アプリケーション固有の CloudWatch 設定ファイルを保存します。環境とバージョンの追加のフォルダとプレフィックスを使用して、アプリケーションをさらに分類できます。 | 

## 例: CloudWatch 設定ファイルを S3 バケットに保存する
<a name="example"></a>

このセクションでは、Amazon S3 を使用して CloudWatch 設定ファイルを保存し、カスタム Systems Manager ランブックを使用して CloudWatch 設定ファイルを取得して適用する例を示します。このアプローチでは、CloudWatch 設定に Systems Manager パラメータストアパラメータを大規模に使用するという課題の一部に対処できます。
+ 複数のリージョンを使用する場合は、各リージョンの Parameter Store で CloudWatch 設定の更新を同期する必要があります。パラメータストアはリージョンのサービスであり、CloudWatch エージェントを使用する各リージョンで同じパラメータを更新する必要があります。
+ 複数の CloudWatch 設定がある場合は、各パラメータストア設定の取得と適用を開始する必要があります。パラメータストアから各 CloudWatch 設定を個別に取得し、新しい設定を追加するたびに取得メソッドを更新する必要があります。対照的に、CloudWatch は、設定ファイルを保存するための設定ディレクトリを提供し、個別に指定する必要なく、ディレクトリ内の各設定を適用します。
+ 複数のアカウントを使用する場合は、新しい各アカウントのパラメータストアに必要な CloudWatch 設定があることを確認する必要があります。また、構成の変更が今後これらのアカウントとそのリージョンに適用されていることを確認する必要があります。

CloudWatch 設定は、すべてのアカウントとリージョンからアクセス可能な S3 バケットに保存することができます。その後、Systems Manager オートメーションランブックと Systems Manager、ステートマネージャーを使用して、S3 バケットから CloudWatch 設定ディレクトリにこれらの設定をコピーできます。 [cloudwatch-config-s3-bucket.yaml](https://github.com/aws-samples/logging-monitoring-apg-guide-examples/blob/main/cloudwatch-config-s3-bucket.yaml) AWS CloudFormation テンプレートを使用して、AWS Organizations 内の組織内の複数のアカウントからアクセスできる S3 バケットを作成できます。このテンプレートには、[組織](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_getting-started_concepts.html) 内のすべてのアカウントに読み取りアクセスを許可する `OrganizationID` パラメータが含まれています。

このガイドの「Set [up State Manager and Distributor for CloudWatch agent deployment and configuration](https://docs.aws.amazon.com/prescriptive-guidance/latest/implementing-logging-monitoring-cloudwatch/install-cloudwatch-systems-manager.html#set-up-systems-manager-distributor) 」セクションにある拡張サンプル Systems Manager ランブックは、cloudwatch-config-s3-bucket.yaml AWS CloudFormation テンプレートによって作成された S3 バケットを使用してファイルを取得するように設定されています。 [https://github.com/aws-samples/logging-monitoring-apg-guide-examples/blob/main/cloudwatch-config-s3-bucket.yaml](https://github.com/aws-samples/logging-monitoring-apg-guide-examples/blob/main/cloudwatch-config-s3-bucket.yaml) 

または、バージョン管理システム (GitHub など) を使用して設定ファイルを保存することもできます。バージョン管理システムに保存されている設定ファイルを自動的に取得する場合は、認証情報ストレージを管理または一元化し、アカウントと 全体の認証情報を取得するために使用される Systems Manager Automation ランブックを更新する必要があります AWS リージョン。