CloudWatch Agent（IAMロール要件）難易度 標準無料
EC2インスタンスにCloudWatch Agentをインストールしたが、エージェントのログに AccessDenied エラーが出力され、メトリクスがCloudWatchに送信されない。このインスタンスにはIAMロールがアタッチされていなかった。この問題を解消するために必要な対応として最も適切なものを選べ。（単一選択）
- A
CloudWatchAgentServerPolicyをアタッチしたIAMロールを作成し、対象EC2インスタンスにインスタンスプロファイルとして割り当てる - BIAMユーザーを新規作成してアクセスキーIDとシークレットアクセスキーを発行し、CloudWatch Agentの設定ファイルに直接埋め込む
- Cエージェントが使うポート（デフォルトのStatsDポート等）をセキュリティグループのインバウンドルールで開放する
- DインスタンスをリブートしてCloudWatch Agentのプロセスを再起動する
正解・解説・誤答理由・ひっかけを見る▼ open
✓ 正解：AAI作成・独立検証済
解説
CloudWatch Agentは、収集したメトリクス・ログをCloudWatchへ送信する際、あるいは設定をSSM Parameter Storeから取得する際に、
インスタンスにアタッチされたIAMロールの認証情報を使ってAWS APIを呼び出す。IAMロールが無ければ、
cloudwatch:PutMetricData や logs:PutLogEvents 等の呼び出しがすべてAccessDeniedになる。
- 最小限の対応は、AWS管理ポリシー
CloudWatchAgentServerPolicy（メトリクス・ログの送信や、SSMパラメータ・EC2タグの読み取りを許可） をアタッチしたIAMロールを作成し、対象インスタンスに割り当てることである。 - 加えて、エージェント設定をSSM Parameter Store経由で一元管理・配布したい場合は
CloudWatchAgentAdminPolicy（設定の書き込み権限を含む）を 設定側の管理者に付与する（エージェントを実行するだけのインスタンス側には不要）。 - IAMユーザーのアクセスキーをインスタンス内に埋め込む方式は、長期認証情報の漏えいリスクがあるためベストプラクティスに反する。
- B長期のアクセスキーをインスタンス内に保存することになり漏えいリスクが高い。EC2にはIAMロール（インスタンスプロファイル）を使うのがベストプラクティス。
- Cエラーの原因はAWS APIへの認証・認可（IAM）の欠如であり、ネットワークのポート開放とは無関係。CloudWatchへの送信はHTTPSアウトバウンドで行われる。
- DIAMロールが無い状態のままリブートしても、権限不足自体は解消されずAccessDeniedが再発する。
ひっかけ： 「IAMユーザーを作成してアクセスキーをエージェントの設定ファイルに直接記載する」という発想はEC2運用における典型的なアンチパターン。
EC2にはIAMロール（インスタンスプロファイル）を使うのが定石であり、長期キーの埋め込みは避ける。
公式ドキュメント・関連Amazon CloudWatch User Guide ― Create IAM roles and users for use with the CloudWatch agent↗
AIが作成し、独立した検証を経た解説です（有資格者による監修は経ていません）