A company migrated containers to Amazon EKS and needs automated email notifications per EKS component. The plan is to use SNS topics and a Lambda function that inspects log events and publishes to the appropriate SNS topic. Which logging approach supports this design?

The correct approach is to enable Amazon CloudWatch Logs for EKS components and use CloudWatch Logs subscription filters. This directly streams log events from CloudWatch Logs to a Lambda function as they arrive. The Lambda function can then parse the log event, identify the EKS component, and publish a message to the appropriate SNS topic. This provides real-time processing and notification. Using CloudWatch Logs Insights queries tied to EventBridge events is less efficient for real-time notifications because Insights queries are typically run on demand or on a schedule, not continuously streaming. Enabling Amazon S3 logging for EKS components is not a native EKS logging mechanism for component logs; EKS control plane logs are sent to CloudWatch Logs. Even if logs were in S3, creating CloudWatch Logs subscription filters from S3 is not a direct integration. Using S3 PUT Object event notifications with Lambda would work if logs were stored in S3, but EKS component logs are primarily managed through CloudWatch Logs.