A serverless Lambda function processes orders and calls an external payment API that sometimes fails. The support team should be notified in near real time only when the external API error rate exceeds 5% of transactions in an hour. An existing SNS topic already notifies the support team. Which solution meets this requirement?

Publishing custom CloudWatch metrics for payment API failures allows you to track the exact data point needed: the number of failures. Configuring a CloudWatch alarm on this custom metric, with a threshold based on the 5% failure rate over an hour, directly addresses the requirement for near real-time notification when the rate is exceeded. This is a standard and efficient pattern for monitoring application-specific metrics and triggering alerts. The other options are less efficient or don't meet the "near real-time" requirement. Querying CloudWatch Logs Insights or S3 with Athena on a schedule introduces latency and complexity compared to direct metric-based alarming. Publishing all API results to a new SNS topic would notify on every failure, not just when the rate exceeds 5%, and would require additional logic to filter.