プライベートサブネットのCloudWatchエージェント

ある決済会社は、3つのプライベートサブネットに合計60台のAmazon EC2 Linuxインスタンスを配置しています。インスタンスにはパブリックIPv4アドレスがなく、NATゲートウェイもありません。SSM AgentとCloudWatchエージェントはAMIに導入済みで、ssm、ssmmessages（および既存リージョンで必要なec2messages）のインターフェイスVPCエンドポイントを通じてSystems Managerのマネージドノードとして稼働しています。

運用チームは、標準のEC2メトリクスに加えて、OSのメモリ・ディスク使用率、/var/log/settlement/*.log、および複数のワーカープロセスを生成するsettlementdのCPU使用率・メモリ使用量・プロセス数を収集したいと考えています。エージェント設定はSystems Manager Parameter Storeで一元管理し、Run Commandで全インスタンスへ展開します。インスタンスへ長期アクセスキーを置かず、インターネット経路も追加せず、実行時権限は最小限にする必要があります。

要件を満たすために実施すべき対応はどれですか。（2つ選択）

2つ選択してください

0 / 2件選択中

AEC2詳細モニタリングを有効化し、CloudWatch Logsの旧エージェントを導入する。settlementdの各PIDをディメンションとして詳細モニタリングへ登録し、ログファイルも同じエージェントで送信する。BCloudWatchエージェント設定のmetrics_collectedにprocstatとOSメトリクスを、logsに対象ファイルを定義する。設定をAmazonCloudWatch-で始まるParameter Storeパラメータに保存し、各インスタンスのIAMロールにCloudWatchAgentServerPolicy相当の送信・取得権限を付与する。C各インスタンスのIAMロールにCloudWatchAgentAdminPolicyを付与する。これにより、実行中のエージェント自身がParameter Storeの設定を更新でき、すべてのサーバーで設定が自動的に同期される。DCloudWatchメトリクス用のmonitoringとCloudWatch Logs用のlogsのインターフェイスVPCエンドポイントを作成し、プライベートDNSとTCP 443の到達性を確保する。既存のSystems Manager用エンドポイントは、Run CommandとParameter Storeからの設定取得に使用する。ECloudWatch用のインターフェイスVPCエンドポイントだけを作成する。CloudWatch LogsとParameter Storeへの通信もCloudWatchのエンドポイントへ自動的に集約されるため、ほかのエンドポイントは不要である。

2つ選ぶと回答できます。