An e-commerce team runs 120 ECS services and an EKS cluster for recommendations. During flash sales, they struggle to pinpoint CPU-throttled tasks, pod restarts, and service dependencies quickly in one view with actionable alarms. Which monitoring solution provides container-aware observability?

The correct choice is right because Container Insights provides container-aware telemetry for both ECS and EKS, automatically collecting CPU, memory, throttling, restart and network metrics with embedded performance log format and curated CloudWatch dashboards that correlate clusters, services, tasks and pods in one view while supporting metric alarms for fast triage during flash sales. Deploying the CloudWatch agent for host-level EC2 metrics fails by granularity because host CPU cannot isolate throttled tasks or restarted pods across 120 services and lacks container dependency mapping. Enabling X-Ray tracing fails by signal type because distributed traces and service maps reveal request latency and dependencies but do not provide container resource metrics or restart counts needed for throttling diagnosis. Using Managed Prometheus with Grafana-only visualization fails by actionability because although PromQL dashboards show cluster health, without CloudWatch alarms there is no automated paging for throttling and restarts. An exam caveat is to distinguish resource monitoring from tracing from host monitoring, as stems asking for CPU, memory and restarts in one view point to Container Insights while dependency latency alone points to X-Ray. A practical check is to verify Container Insights performance logs, confirm dashboard population for ECS services and EKS namespaces, and test CPU utilization and task-count alarms before the next sale event.