CloudWatch Metric Guide
CPUUtilizationAmazon ECS CloudWatch metric
CPUUtilization for ECS measures the percentage of CPU units reserved by the tasks in a service that are in use, averaged across the tasks in the service.
What it measures
About CPUUtilization
CPUUtilization for ECS measures the percentage of CPU units reserved by the tasks in a service that are in use, averaged across the tasks in the service.
| Namespace | AWS/ECS |
| Metric name | CPUUtilization |
| Unit | Percent |
| AWS docs | Official Amazon ECS metrics reference |
Why this metric matters
CPU saturation in ECS has a compounding effect on latency. Unlike a single server that degrades gracefully, an ECS service at CPU saturation is simultaneously throttling every container's CPU allocation. Requests queue behind each other, and P99 latency climbs much faster than average latency — the metrics that matter most for user experience deteriorate fastest.
ECS CPUUtilization is also the trigger metric for Auto Scaling policies. If your scale-out threshold is set at 80% but the metric doesn't alarm until 90%, you're scaling reactively — new tasks take 30–60 seconds to become healthy, and your existing tasks have been degraded for that entire window. Tight monitoring of this metric is what separates proactive from reactive scaling.
Recommended alarm threshold for CPUUtilization
Recommended threshold
> 85% sustained for 3 minutes
ECS services typically use CPUUtilization as the Auto Scaling target metric. An alarm threshold slightly above the scaling target (ConvOps recommendation: 85% for services with an 80% scaling target) catches cases where scaling is not keeping pace with traffic growth. The 3-minute evaluation period avoids alarm on brief CPU spikes during container startup or garbage collection.
Is your CPUUtilization alarm already set up correctly?
The free ConvOps Audit scans your CloudWatch setup and flags missing or misconfigured alarms — including CPUUtilization — in 5 minutes.
Common failures that show up in CPUUtilization
When CPUUtilization reaches an alarm threshold, these are the most common root causes — in order of how often ConvOps sees them across customer AWS accounts.
Under-provisioned task CPU reservation — tasks CPU limit set lower than peak workload requirements, throttling the container at peak
Auto Scaling policy too conservative — scale-out cooldown too long, or minimum capacity set too low for traffic patterns
Garbage collection pauses in JVM containers — GC stop-the-world events spike CPU periodically and cause the service to appear CPU-healthy between measurements
Noisy neighbor at the cluster level — in EC2 launch type, other services on the same host compete for CPU
Missing horizontal scaling — service relies on vertical scaling assumptions, but ECS task sizes are fixed at deploy time
How ConvOps debugs CPUUtilization alarms
When CPUUtilization triggers an alarm, ConvOps Diagnose reads CloudWatch Logs, CloudTrail (recent API calls, deploys, config changes), and the current resource state in parallel. It correlates these with AWS/ECS metrics on the same resource — giving you a plain-English root cause with numbered fix options, sent to WhatsApp or Slack, usually within 60 seconds of the alarm firing.
Before any anomaly in CPUUtilization reaches you as a proactive alert (via ConvOps Watch), it passes through 9 verification checks: a Recovery check (did the metric self-heal?), an AWS Status check (is AWS itself having an incident?), a Deploy check (was there a recent Lambda update, ECS deploy, or RDS parameter change in the last 120 minutes?), a Quota check, an Infrastructure check, a Security check, a Flap check (has this metric been anomalous more than 5 times in the last 24 hours?), a TLS check, and a Vulnerability check. Only anomalies that pass all relevant checks reach you — with full context attached.
ConvOps Watch
Detects CPUUtilization anomalies with z-score against 30-day time-bucketed baselines. 9 verification checks before any alert.
ConvOps Diagnose
When a CPUUtilization alarm fires, reads logs, CloudTrail, and resource state. Sends root cause + fix options to WhatsApp or Slack.
ConvOps Audit
Scans your CloudWatch setup for missing or misconfigured CPUUtilization alarms. Free, 5-minute read-only scan.
Related Amazon ECS metrics
CPUUtilization rarely fails in isolation. These metrics tend to correlate — monitor them together for complete Amazon ECS coverage.
FAQ
Frequently asked questions about CPUUtilization
Common questions about setting up CloudWatch alarms for CPUUtilization in Amazon ECS.
What is the recommended CloudWatch alarm threshold for CPUUtilization?+
> 85% sustained for 3 minutes. ECS services typically use CPUUtilization as the Auto Scaling target metric. An alarm threshold slightly above the scaling target (ConvOps recommendation: 85% for services with an 80% scaling target) catches cases where scaling is not keeping pace with traffic growth. The 3-minute evaluation period avoids alarm on brief CPU spikes during container startup or garbage collection.
Which CloudWatch namespace does CPUUtilization belong to?+
CPUUtilization is published in the AWS/ECS namespace with a unit of Percent. You can find it in the CloudWatch console under "Metrics" → "AWS/ECS". See the Amazon ECS CloudWatch metrics reference in the AWS documentation.
Does ConvOps automatically create CloudWatch alarms for CPUUtilization?+
ConvOps does not create alarms for you by default — it debugs the alarms you already have (or identifies missing ones). The free ConvOps Audit scans your CloudWatch setup and tells you which Amazon ECS resources are missing a CPUUtilization alarm. ConvOps Watch then monitors CPUUtilization using z-score anomaly detection against a 30-day baseline, running 9 verification checks before alerting you.
Can I use ConvOps without already having a CPUUtilization alarm set up?+
Yes. ConvOps Watch monitors CPUUtilization independently of your CloudWatch alarm configuration — it reads the metric directly from CloudWatch every 5 minutes on the Growth plan. If you run the free Audit first, it will tell you which resources need a CPUUtilization alarm and provide the copy-paste AWS CLI command to create it.