A developer is troubleshooting a CloudWatch Logs subscription filter that streams log events from a Lambda function's log group to an Amazon Kinesis Data Firehose delivery stream. The delivery stream successfully writes data to an Amazon S3 bucket, but the developer notices that no logs from the subscription filter are arriving in S3. The CloudWatch metric DeliveryErrors for the subscription filter shows a consistently high count. The developer verifies that the Firehose delivery stream is active and that the IAM role specified in the subscription filter has a permissions policy allowing firehose:PutRecord and firehose:PutRecordBatch on the delivery stream. Which of the following is the most likely cause of this issue?
- AThe CloudWatch Logs log group is missing an IAM resource policy that allows the Kinesis Data Firehose delivery stream to read logs.
- BThe IAM role specified in the subscription filter is missing the logs:PutLogEvents and logs:CreateLogStream permissions required to read the log group.
- The trust policy of the IAM role specified in the subscription filter does not list the CloudWatch Logs service principal (logs.amazonaws.com) as a trusted entity.Cevap
- DThe trust policy of the IAM role specified in the subscription filter does not list the Kinesis Data Firehose service principal (firehose.amazonaws.com) as a trusted entity.
Cevap
The trust policy of the IAM role specified in the subscription filter does not list the CloudWatch Logs service principal (logs.amazonaws.com) as a trusted entity.
To stream logs via a subscription filter, CloudWatch Logs must assume the IAM role specified in the subscription filter to write events to Kinesis Data Firehose. If the trust policy of that IAM role does not list the CloudWatch Logs service principal (logs.amazonaws.com) as a trusted entity, the sts:AssumeRole call fails, preventing logs from being delivered and causing DeliveryErrors.
Adım Adım Çözüm
Anahtar Kavram
IAM Role Trust Relationships for CloudWatch Logs Subscription Filters