CloudWatch Metric Guide
pod_memory_utilizationAmazon EKS CloudWatch metric
pod_memory_utilization reports the percentage of memory used by a pod (or aggregated by Namespace, Service, or ClusterName), calculated as pod_memory_working_set ÷ node_memory_limit — the node's total memory capacity, not the pod's own memory limit.
What it measures
About pod_memory_utilization
pod_memory_utilization reports the percentage of memory used by a pod (or aggregated by Namespace, Service, or ClusterName), calculated as pod_memory_working_set ÷ node_memory_limit — the node's total memory capacity, not the pod's own memory limit.
| Namespace | ContainerInsights |
| Metric name | pod_memory_utilization |
| Unit | Percent |
| AWS docs | Official Amazon EKS metrics reference |
Why this metric matters
Memory pressure in Kubernetes is far less forgiving than CPU pressure: there's no throttling equivalent for memory. Once a container's actual usage exceeds its own configured memory limit, the kernel OOM-killer terminates it immediately — Kubernetes reports the pod as OOMKilled and restarts it, visible as a jump in pod_number_of_container_restarts. Because pod_memory_utilization is calculated against node_memory_limit rather than the pod's own limit, a pod that reads as a modest percentage of the whole node can already be at or near 100% of its own memory limit and about to be killed; watch pod_memory_utilization_over_pod_limit alongside this metric for OOM-kill risk specifically, and treat pod_memory_utilization itself as the node-capacity and bin-packing signal.
The more common real-world pattern this metric catches is the slow leak: a pod that starts healthy and climbs gradually over hours as objects accumulate without being freed, until it eventually crosses its limit at the worst possible moment — typically during a traffic peak, when restart churn hurts most. A rising trend in pod_memory_utilization, even well below any alarm threshold, is worth investigating before it becomes an incident.
Recommended alarm threshold for pod_memory_utilization
Recommended threshold
Namespace or ClusterName aggregate > 75% sustained for 10+ minutes; per-pod, pair with pod_memory_utilization_over_pod_limit for OOM-kill-specific alerting
AWS does not publish a universal threshold for pod_memory_utilization. The 75%-for-10-minutes aggregate threshold (Nuberio recommendation) is set at the Namespace/ClusterName level because the metric's own denominator (node_memory_limit) makes a single pod's percentage most useful as a capacity-planning signal rather than a precise per-pod OOM predictor — for that, pod_memory_utilization_over_pod_limit (usage ÷ the pod's own limit) is the more direct metric.
Is your pod_memory_utilization alarm already set up correctly?
The free Nuberio Audit scans your CloudWatch setup and flags missing or misconfigured alarms — including pod_memory_utilization — in 5 minutes.
Common failures that show up in pod_memory_utilization
When pod_memory_utilization 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 a long-running pod — objects accumulate without being freed, producing a slow, steady climb rather than a spike
Pod memory request/limit set too low (or omitted), letting the scheduler pack more pods onto a node than its actual working set safely supports
Sidecar container memory growth (service mesh proxy, logging or metrics agent) that wasn't accounted for in the pod's original capacity planning
Node undersized for pod density — many pods sharing a node with a modest node_memory_limit inflate the percentage even when each pod individually looks fine
Language-runtime heap (JVM, Node.js, .NET) not configured to respect the container's cgroup memory limit, so it grows to consume available node memory before garbage collection engages
How the Nuberio Audit checks pod_memory_utilization
The free Audit scans every Amazon EKS resource in your account and checks whether a pod_memory_utilization alarm exists, whether its threshold and evaluation period are configured sensibly, and flags it if it's missing entirely. Every finding comes with the exact CLI command to fix it — read-only access, no credit card, results in about 5 minutes.
Nuberio Audit
Scans your CloudWatch setup for missing or misconfigured pod_memory_utilization alarms. Free, 5-minute read-only scan.
Related Amazon EKS metrics
pod_memory_utilization rarely fails in isolation. These metrics tend to correlate — monitor them together for complete Amazon EKS coverage.
FAQ
Frequently asked questions about pod_memory_utilization
Common questions about setting up CloudWatch alarms for pod_memory_utilization in Amazon EKS.
What is the recommended CloudWatch alarm threshold for pod_memory_utilization?+
Namespace or ClusterName aggregate > 75% sustained for 10+ minutes; per-pod, pair with pod_memory_utilization_over_pod_limit for OOM-kill-specific alerting. AWS does not publish a universal threshold for pod_memory_utilization. The 75%-for-10-minutes aggregate threshold (Nuberio recommendation) is set at the Namespace/ClusterName level because the metric's own denominator (node_memory_limit) makes a single pod's percentage most useful as a capacity-planning signal rather than a precise per-pod OOM predictor — for that, pod_memory_utilization_over_pod_limit (usage ÷ the pod's own limit) is the more direct metric.
Which CloudWatch namespace does pod_memory_utilization belong to?+
pod_memory_utilization is published in the ContainerInsights namespace with a unit of Percent. You can find it in the CloudWatch console under "Metrics" → "ContainerInsights". See the Amazon EKS CloudWatch metrics reference in the AWS documentation.
Does Nuberio automatically create CloudWatch alarms for pod_memory_utilization?+
No — the free Nuberio Audit does not create alarms for you. It scans your CloudWatch setup and tells you which Amazon EKS resources are missing a pod_memory_utilization alarm, then gives you the exact CLI command to create it yourself.
Can I use Nuberio without already having a pod_memory_utilization alarm set up?+
Yes. The free Audit works whether or not you have any pod_memory_utilization alarm configured — it reads the resource directly from CloudWatch and tells you which resources need one, plus 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, DynamoDB, SQS, API Gateway, S3, CloudFront, ElastiCache, and EKS. To find which Amazon EKS alarms your account is missing — including pod_memory_utilization — run the free CloudWatch alarm audit. The scan takes under 5 minutes and requires no account.