Which solution will meet these requirements?
Configure EC2 detailed monitoring for the EC2 instances. Create an AWS Lambda function to create a CloudWatch alarm for the bw_out_allowance_exceeded CloudWatch metric for each EC2 instance Configure the alarm to notify the DevOps team.
Configure the unified CloudWatch agent on the EC2 instances to export the bw_out_allowance_exceeded metric to CloudWatch metrics. Create a CloudWatch composite alarm to monitor all bw_out_allowance_exceeded metrics. Configure the alarm to notify the DevOps team.
Configure VPC flow logging to Amazon CloudWatch Logs for the EC2 instances. Create a CloudWatch Logs metric filter to match events in which bandwidth allowance is exceeded. Create a CloudWatch composite alarm to monitor all bw_out_allowance_exceeded metrics. Configure the alarm to notify the DevOps team.
Configure the unified CloudWatch agent on the EC2 instances to export the bw_out_allowance_exceeded metric to CloudWatch metrics. Create an AWS Lambda function to create a CloudWatch alarm for the bw_out_allowance_exceeded CloudWatch metric for each EC2 instance. Configure the alarm to notify the DevOps team.
Explanations:
EC2 detailed monitoring does not include thebw_out_allowance_exceededmetric, and there is no way to directly create CloudWatch alarms for this metric without using an agent.
The unified CloudWatch agent can collect thebw_out_allowance_exceededmetric, and a CloudWatch composite alarm can aggregate this metric across instances to notify the DevOps team if any instance exceeds the bandwidth allowance.
VPC flow logs track IP traffic but do not includebw_out_allowance_exceededas a metric, so they cannot detect bandwidth allowance exceedance directly.
The Lambda function to create CloudWatch alarms is unnecessary here, as the unified CloudWatch agent already provides thebw_out_allowance_exceededmetric, making the Lambda function redundant.