CloudWatch Metric Guide
CPUUtilizationAmazon ElastiCache CloudWatch metric
CPUUtilization measures the percentage of CPU used by the entire cache node host, across all vCPUs — including the engine process plus OS and background management processes.
What it measures
About CPUUtilization
CPUUtilization measures the percentage of CPU used by the entire cache node host, across all vCPUs — including the engine process plus OS and background management processes.
| Namespace | AWS/ElastiCache |
| Metric name | CPUUtilization |
| Unit | Percent |
| AWS docs | Official Amazon ElastiCache metrics reference |
Why this metric matters
CPUUtilization is a host-level metric — it reports load across every vCPU on the node, not just the engine thread. That distinction matters a lot for Redis and Valkey, which run as a single-threaded process: a node with 4 vCPUs pegged at 100% on one core will only show 25% CPUUtilization, masking the fact that the engine itself is already maxed out. AWS's own guidance is to watch CPUUtilization on smaller nodes (2 vCPUs or fewer) and on Memcached (which is multi-threaded and can legitimately use all cores), but to add EngineCPUUtilization for Redis/Valkey nodes with 4 or more vCPUs so you see engine-thread saturation directly.
When CPUUtilization does climb, it's rarely a single bad command — it's usually a sustained shift in workload shape: an expensive command pattern (large SCAN, KEYS, unbounded SORT/ZRANGE), a spike in total request rate the current node size can't absorb, or (on the host side) other management/monitoring processes competing for cycles on a small instance type.
Recommended alarm threshold for CPUUtilization
Recommended threshold
> (90 ÷ number of vCPUs on the node)% sustained for 5 minutes — e.g. 45% on a 2-vCPU node
This is an AWS-published recommendation, not a Nuberio estimate: AWS's ElastiCache documentation states you should set your CPU threshold at 90% of available CPU, then divide by the node's vCPU count because Redis/Valkey is single-threaded and can only ever fully saturate one core. A 2-vCPU node's real ceiling is therefore ~45% of CPUUtilization, not 90%.
Is your CPUUtilization alarm already set up correctly?
The free Nuberio 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 Nuberio sees them across customer AWS accounts.
Expensive O(N) commands (KEYS, unbounded SCAN, large SORT/SMEMBERS/ZRANGE) blocking the single engine thread
Request-rate growth outpacing the node size, with CPUUtilization understating true engine load on 4+ vCPU nodes (watch EngineCPUUtilization instead)
A hot key or hot shard concentrating disproportionate traffic on one node while others sit idle
Background save (BGSAVE) or AOF rewrite forking and competing for host CPU during snapshot windows
Undersized node type for Memcached, whose multi-threaded model can legitimately consume all vCPUs under normal load
How the Nuberio Audit checks CPUUtilization
The free Audit scans every Amazon ElastiCache resource in your account and checks whether a CPUUtilization 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 CPUUtilization alarms. Free, 5-minute read-only scan.
Related Amazon ElastiCache metrics
CPUUtilization rarely fails in isolation. These metrics tend to correlate — monitor them together for complete Amazon ElastiCache coverage.
FAQ
Frequently asked questions about CPUUtilization
Common questions about setting up CloudWatch alarms for CPUUtilization in Amazon ElastiCache.
What is the recommended CloudWatch alarm threshold for CPUUtilization?+
> (90 ÷ number of vCPUs on the node)% sustained for 5 minutes — e.g. 45% on a 2-vCPU node. This is an AWS-published recommendation, not a Nuberio estimate: AWS's ElastiCache documentation states you should set your CPU threshold at 90% of available CPU, then divide by the node's vCPU count because Redis/Valkey is single-threaded and can only ever fully saturate one core. A 2-vCPU node's real ceiling is therefore ~45% of CPUUtilization, not 90%.
Which CloudWatch namespace does CPUUtilization belong to?+
CPUUtilization is published in the AWS/ElastiCache namespace with a unit of Percent. You can find it in the CloudWatch console under "Metrics" → "AWS/ElastiCache". See the Amazon ElastiCache CloudWatch metrics reference in the AWS documentation.
Does Nuberio automatically create CloudWatch alarms for CPUUtilization?+
No — the free Nuberio Audit does not create alarms for you. It scans your CloudWatch setup and tells you which Amazon ElastiCache resources are missing a CPUUtilization alarm, then gives you the exact CLI command to create it yourself.
Can I use Nuberio without already having a CPUUtilization alarm set up?+
Yes. The free Audit works whether or not you have any CPUUtilization 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, and DynamoDB. To find which Amazon ElastiCache alarms your account is missing — including CPUUtilization — run the free CloudWatch alarm audit. The scan takes under 5 minutes and requires no account.