An e-commerce platform runs checkout microservices on ECS behind an ALB across two Regions, requiring early warning when latency rises or tasks become unhealthy before customers notice failures. The team already collects metrics but lacks proactive workload health signals. Which monitoring strategy should the engineer implement for workload health?
Select an answer to reveal the explanation.
Short Explanation
Metrics sitting in dashboards won’t wake you up at 2 a.m. Pairing health checks with alarms gives you that early tap on the shoulder before checkout breaks.
Full Explanation
The correct strategy is right because Route 53 health checks give cross-Region endpoint visibility while CloudWatch alarms on ALB UnHealthyHostCount and target latency catch rising latency and failing ECS tasks early, and SNS provides proactive notification before customers notice checkout failures. The primary-Region alarm approach uses the right latency and unhealthy-host signals with SNS but misses the stated two-Region coverage, so degradation in the second Region would go undetected. The Container Insights CPU and memory alarm approach gives sound proactive capacity alerting but misses workload health, since high CPU does not equal target health or checkout latency and tasks can fail behind the ALB while utilization looks normal. The Athena weekly log review covers both Regions and latency trends correctly but misses early warning, since retrospective queries surface issues after impact rather than firing real-time alarms on health signals. For exams, separate real-time workload health with latency and target health from infrastructure utilization, security auditing, or retrospective analytics when the stem asks for proactive signals. In practice, validate p99 TargetResponseTime and UnHealthyHostCount alarms per target group in each Region, test SNS delivery, and confirm Route 53 failover triggers as expected.