CloudWatch Agent
CloudWatch エージェントのデプロイ
CloudWatch エージェントは、単一のインストールとして、分散構成ファイルを使用して、複数の構成ファイルをレイヤー化して、または完全に自動化を通じてデプロイできます。どのアプローチが適切かは、ニーズによって異なります。1
Windows および Linux ホストへのデプロイメントは、どちらも Systems Manager Parameter Store に設定を保存および取得する機能を備えています。この自動化されたメカニズムを通じて CloudWatch エージェント設定のデプロイメントを処理することがベストプラクティスです。
AWS 外部へのデプロイ
CloudWatch エージェントの使用は AWS 内に限定されず、オンプレミスおよび他のクラウド環境の両方でサポートされています。ただし、AWS 外で CloudWatch エージェントを使用する場合は、留意すべき 2 つの追加の考慮事項があります。
- エージェントが必要な API 呼び出しを行えるように IAM 認証情報2を設定します。EC2 内であっても、CloudWatch API3への認証されていないアクセスはありません。
- エージェントが要件を満たすルートを使用して CloudWatch、CloudWatch Logs、およびその他の AWS エンドポイント4への接続を確保します。これは、インターネット経由、AWS Direct Connect の使用、またはプライベートエンドポイント(通常は VPC エンドポイントと呼ばれます)を介して行うことができます。
環境と CloudWatch 間のトランスポートは、ガバナンスとセキュリティの要件に一致する必要があります。大まかに言えば、AWS 外部のワークロードにプライベートエンドポイントを使用することで、最も厳しく規制された業界の顧客のニーズにも対応できます。ただし、大多数の顧客は、パブリックエンドポイントを使用することで十分に対応できます。
プライベートエンドポイントの使用
メトリクスとログをプッシュするには、CloudWatch エージェントが CloudWatch および CloudWatch Logs エンドポイントに接続できる必要があります。これを実現する方法は、エージェントがインストールされている場所に応じていくつかあります。
VPC から
a. EC2 で実行されるエージェントの VPC と CloudWatch 間で完全にプライベートで安全な接続を確立するために、VPC Endpoints(CloudWatch および CloudWatch Logs 用)を利用できます。このアプローチでは、エージェントのトラフィックがインターネットを経由することはありません。
b. もう 1 つの方法は、パブリック NAT gateway を使用することです。これにより、プライベートサブネットはインターネットに接続できますが、インターネットから未承諾のインバウンド接続を受信することはできません。
このアプローチでは、エージェントのトラフィックは論理的にインターネット経由でルーティングされることに注意してください。
c. 既存の TLS および Sigv4 メカニズムを超えてプライベートまたはセキュアな接続を確立する必要がない場合、最も簡単なオプションは Internet Gateway を使用してエンドポイントへの接続を提供することです。