Configuring CloudWatch Alarm for Error Rate Percentage

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✗

  Enable VPC Flow Logs and analyze them with Amazon Athena to detect error rates.

  Why it's wrong here

  VPC Flow Logs capture network-layer metadata (IP addresses, ports, protocol, packet/byte counts) for every flow through an elastic network interface, but they do not include application-layer details such as HTTP status codes. Querying them with Amazon Athena can reveal traffic volumes, rejected connections, or retransmission patterns, yet a 5xx error rate is an application-level metric that is simply absent from flow log entries. Therefore, Flow Logs cannot be used to directly calculate HTTP error rates for an ALB.

• ✓

  Use a CloudWatch alarm on the ALB's 'HTTPCode_ELB_5XX_Count' metric with a math expression to calculate error rate.

  Why this is correct

  The ALB emits the CloudWatch metric HTTPCode_ELB_5XX_Count, which counts the number of 5xx HTTP response codes generated by the load balancer itself (e.g., 502, 503, 504) for each target group and LoadBalancer dimension. By creating a metric math expression that divides this metric by the RequestCount metric (or a sliding window sum of both), you can calculate a 5xx error rate in real time. A CloudWatch alarm can be attached directly to that expression, evaluating at a chosen period (e.g., 5 minutes) and triggering an SNS notification when the calculated rate crosses a threshold, providing operational monitoring that is immediate and built into the ALB service.

• ✗

  Enable CloudTrail for the ALB and create a metric filter for 5xx errors.

  Why it's wrong here

  AWS CloudTrail records API calls made by users, roles, or services against the Elastic Load Balancing API, such as CreateLoadBalancer, ModifyListener, or SetSecurityGroups. These log entries contain information about the control plane—who made the call, when, and from which IP—but not the data plane of HTTP requests flowing through the load balancer. CloudTrail metric filters are pattern-based matchers on those API event records; they can filter for event names like 'CreateLoadBalancer' but cannot inspect HTTP status codes in request traffic. Hence, CloudTrail is unsuitable for detecting or alarming on application response error rates.

• ✗

  Use AWS Config rules to monitor the ALB configuration and trigger a notification on changes.

  Why it's wrong here

  AWS Config evaluates resource configurations against desired policies—for example, ensuring an ALB has a WAF associated, that deregistration delay is set, or that SSL/TLS policies are current—and records configuration history when a resource changes. It has no visibility into traffic metrics such as request counts, latency, or HTTP status codes; those are emitted as CloudWatch metrics, not as configuration items. Config rules are triggered on a schedule or by configuration change, not continuously in response to network traffic patterns, so a spike in 5xx errors would not trigger a Config evaluation. Even a misconfigured ALB could produce a change that Config might notify about, but this is not a real-time error-rate monitoring solution.

Go deeper

Related to this question