ある CloudOps エンジニアは、NAT ゲートウェイ経由でインターネットに接続する Amazon EC2 インスタンスで、CloudWatch エージェントを使用してメトリクスを送信しています。エージェントの設定ファイルにアプリケーションログの収集を正しく追加して再起動すると、メトリクスは引き続き届きますが、ロググループが作成されずログも表示されません。 CloudOps エンジニアはどのようにしてこの問題を解決できますか。
メトリクスは届くのにログだけが届かないエージェントに、足りないアクセス許可を与える
インスタンスプロファイルのロールの信頼ポリシーに、CloudWatch Logs のサービスプリンシパルを追加する。
信頼ポリシーは、そのロールを誰が引き受けられるかを決める設定です。インスタンスプロファイルのロールでは ec2.amazonaws.com を信頼していれば足り、メトリクスが届いていることから、エージェントはすでにロールの認証情報を使えています。
logs.amazonaws.com を足しても、CloudWatch Logs のサービスがこのロールを引き受けられるようになるだけです。エージェントが呼べる API を決めるのはアクセス許可ポリシーの側で、logs: のアクションが許可されていない状態は変わらないため、ロググループの作成もログの送信も拒否されたままです。
インスタンスプロファイルのロールのアクセス許可ポリシーで、エージェントが使用する logs: のアクションを許可する。
メトリクスが届いているので、ロールには cloudwatch:PutMetricData が許可されています。しかし CloudWatch Logs のアクションは logs: で始まり、ロググループの作成とログの送信には別の許可が要ります。
ロールのアクセス許可ポリシーで logs:CreateLogGroup、logs:CreateLogStream、logs:PutLogEvents などを許可すると、エージェントはロググループとログストリームを作成してログを送信できます。AWS 管理ポリシーの CloudWatchAgentServerPolicy をアタッチしても、これらの許可がまとめて入ります。
CloudWatch Logs のインターフェイス VPC エンドポイントを、インスタンスのサブネットに作成する。
インターフェイス VPC エンドポイントを作ると、インターネットを経由せずに CloudWatch Logs へ届く経路ができます。ただしこのインスタンスは NAT ゲートウェイ経由で CloudWatch Logs のエンドポイントに到達できるうえ、同じ経路でメトリクスも届いています。経路を増やしても、ロールに logs: のアクセス許可がない状態は変わらず、呼び出しは拒否されたままです。
CloudWatch Logs のロググループを、設定ファイルに指定した名前で事前に作成する。
ロググループを事前に作成すれば、logs:CreateLogGroup のアクセス許可は使わずに済みます。しかしエージェントはログストリームの作成 (logs:CreateLogStream) とログの送信 (logs:PutLogEvents) も行うため、ロールにこれらの許可がなければ、ロググループは空のままでログは表示されません。
「エージェントは動いているのに、ログが CloudWatch Logs に出ない」は、インスタンスのロールのアクセス許可を疑う定番の出題です。
・EC2 上のエージェントは、インスタンスプロファイルのロールの一時的な認証情報で API を呼び出します。エージェントを導入した人の IAM ユーザーに許可を足しても効きません。
・CloudWatch Logs のアクションは logs: で始まります。cloudwatch:PutMetricData だけでは、メトリクスは届いてもログは届きません。
・ロールのアクセス許可ポリシーで logs:CreateLogGroup、logs:CreateLogStream、logs:PutLogEvents などを許可します。CloudWatchAgentServerPolicy をアタッチすると、これらがまとめて入ります。
・信頼ポリシーはロールを引き受けられる相手を決める設定です。サービスプリンシパルを足しても、呼べる API は増えません。