CloudWatch Metric Guide
MemoryUtilizationAmazon ECS CloudWatch metric
MemoryUtilization for ECS measures the percentage of memory reserved by the tasks in a service that is in use, averaged across the running tasks.
What it measures
About MemoryUtilization
MemoryUtilization for ECS measures the percentage of memory reserved by the tasks in a service that is in use, averaged across the running tasks.
| Namespace | AWS/ECS |
| Metric name | MemoryUtilization |
| Unit | Percent |
| AWS docs | Official Amazon ECS metrics reference |
Why this metric matters
Memory pressure in ECS containers is more abrupt than CPU pressure. When a container's memory usage reaches the hard limit set in the task definition, ECS kills the task immediately — there is no gradual degradation, no warning shot. The task is restarted, creating a brief service disruption that appears as a spike in error rate or a brief drop in RunningTaskCount.
Memory leaks in long-running containers are a particularly common failure mode. A container that starts healthy at 40% memory utilization and slowly climbs to 95% over 12 hours will be killed by ECS at exactly the wrong moment — typically during a traffic peak when the container's lifespan overlaps maximum load. Monitoring MemoryUtilization with a trend view catches leaks before they cause OOM kills.
Recommended alarm threshold for MemoryUtilization
Recommended threshold
> 85% averaged across the service
The ECS task definition hard memory limit triggers an OOM kill when reached. The 85% threshold (ConvOps recommendation) gives a buffer to investigate before the kill occurs. For services with tasks that have memory leaks, combine this alarm with a CloudWatch Metric Insight anomaly detection rule to catch slope-based growth rather than only threshold crossings.
Is your MemoryUtilization alarm already set up correctly?
The free Nuberio Audit scans your CloudWatch setup and flags missing or misconfigured alarms — including MemoryUtilization — in 5 minutes.
Common failures that show up in MemoryUtilization
When MemoryUtilization reaches an alarm threshold, these are the most common root causes — in order of how often Nuberio sees them across customer AWS accounts.
Memory leak in application code — objects accumulate in heap without being garbage collected, causing slow upward creep in MemoryUtilization over hours
Undersized task definition — memory reservation set to minimum at launch, insufficient for actual working set under load
Large payload processing — a request or background job processes an unexpectedly large payload that temporarily inflates memory usage beyond the reservation
Too many concurrent requests per task — each request holds allocated memory; at high concurrency, per-request allocations add up beyond the container limit
Java heap sizing — JVM default heap size often doesn't match container memory limits, causing the heap to grow until ECS kills the container
How Nuberio debugs MemoryUtilization alarms
When MemoryUtilization triggers an alarm, Nuberio 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 MemoryUtilization reaches you as a proactive alert (via Nuberio 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.
Nuberio Watch
Detects MemoryUtilization anomalies with z-score against 30-day time-bucketed baselines. 9 verification checks before any alert.
Nuberio Diagnose
When a MemoryUtilization alarm fires, reads logs, CloudTrail, and resource state. Sends root cause + fix options to WhatsApp or Slack.
Nuberio Audit
Scans your CloudWatch setup for missing or misconfigured MemoryUtilization alarms. Free, 5-minute read-only scan.
Related Amazon ECS metrics
MemoryUtilization rarely fails in isolation. These metrics tend to correlate — monitor them together for complete Amazon ECS coverage.
FAQ
Frequently asked questions about MemoryUtilization
Common questions about setting up CloudWatch alarms for MemoryUtilization in Amazon ECS.
What is the recommended CloudWatch alarm threshold for MemoryUtilization?+
> 85% averaged across the service. The ECS task definition hard memory limit triggers an OOM kill when reached. The 85% threshold (ConvOps recommendation) gives a buffer to investigate before the kill occurs. For services with tasks that have memory leaks, combine this alarm with a CloudWatch Metric Insight anomaly detection rule to catch slope-based growth rather than only threshold crossings.
Which CloudWatch namespace does MemoryUtilization belong to?+
MemoryUtilization 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 Nuberio automatically create CloudWatch alarms for MemoryUtilization?+
Nuberio does not create alarms for you by default — it debugs the alarms you already have (or identifies missing ones). The free Nuberio Audit scans your CloudWatch setup and tells you which Amazon ECS resources are missing a MemoryUtilization alarm. Nuberio Watch then monitors MemoryUtilization using z-score anomaly detection against a 30-day baseline, running 9 verification checks before alerting you.
Can I use Nuberio without already having a MemoryUtilization alarm set up?+
Yes. Nuberio Watch monitors MemoryUtilization 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 MemoryUtilization alarm and provide the copy-paste AWS CLI command to create it.
This page is part of the CloudWatch metric guide — thresholds and debugging guidance for every metric across RDS, Lambda, ECS, ALB, EC2, and DynamoDB. To find which Amazon ECS alarms your account is missing — including MemoryUtilization — run the free CloudWatch alarm audit. The scan takes under 5 minutes and requires no account.