CloudWatch Metric Guide
CPUUtilizationAmazon RDS CloudWatch metric
CPUUtilization measures the percentage of CPU capacity consumed by the RDS instance across all available vCPUs. It is the aggregate across all cores.
What it measures
About CPUUtilization
CPUUtilization measures the percentage of CPU capacity consumed by the RDS instance across all available vCPUs. It is the aggregate across all cores.
| Namespace | AWS/RDS |
| Metric name | CPUUtilization |
| Unit | Percent |
| AWS docs | Official Amazon RDS metrics reference |
Why this metric matters
Sustained high CPU on an RDS instance indicates a workload the instance class cannot handle at its current scale. Unlike application CPU, database CPU spikes have a multiplier effect: each additional query that arrives during a high-CPU period waits in queue, stacking latency for all concurrent users.
The most common root cause is not traffic volume but query efficiency — a missing index, an N+1 query pattern, or a schema change that invalidates a query plan can turn a previously fast query into a CPU-intensive full-table scan overnight. High CPUUtilization rarely resolves on its own and is a leading indicator of connection saturation and OOM pressure to follow.
Recommended alarm threshold for CPUUtilization
Recommended threshold
> 80% sustained for 5 minutes or more
CPU bursting is normal and expected during backup windows, index builds, and traffic spikes. Sustained elevation above 80% for 5+ minutes (ConvOps recommendation) distinguishes a temporary burst from an ongoing workload problem that requires intervention. For db.t3 instances that use CPU credits, the alarm should also account for CPU credit balance depletion.
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.
Missing index on a frequently queried column — a code change adds a WHERE clause on an unindexed column, forcing full table scans
N+1 query pattern introduced in ORM code — each row in a result set triggers a separate query, multiplying the workload
Statistics not updated after bulk load — query planner uses stale statistics and chooses an inefficient execution plan
Autovacuum running on a large table during peak traffic — resource-intensive background maintenance competes with user queries
Backup window conflict — automated snapshot creation overlaps with peak traffic, consuming CPU and I/O simultaneously
How Nuberio debugs CPUUtilization alarms
When CPUUtilization 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/RDS 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 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 CPUUtilization anomalies with z-score against 30-day time-bucketed baselines. 9 verification checks before any alert.
Nuberio Diagnose
When a CPUUtilization 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 CPUUtilization alarms. Free, 5-minute read-only scan.
Related Amazon RDS metrics
CPUUtilization rarely fails in isolation. These metrics tend to correlate — monitor them together for complete Amazon RDS coverage.
FAQ
Frequently asked questions about CPUUtilization
Common questions about setting up CloudWatch alarms for CPUUtilization in Amazon RDS.
What is the recommended CloudWatch alarm threshold for CPUUtilization?+
> 80% sustained for 5 minutes or more. CPU bursting is normal and expected during backup windows, index builds, and traffic spikes. Sustained elevation above 80% for 5+ minutes (ConvOps recommendation) distinguishes a temporary burst from an ongoing workload problem that requires intervention. For db.t3 instances that use CPU credits, the alarm should also account for CPU credit balance depletion.
Which CloudWatch namespace does CPUUtilization belong to?+
CPUUtilization is published in the AWS/RDS namespace with a unit of Percent. You can find it in the CloudWatch console under "Metrics" → "AWS/RDS". See the Amazon RDS CloudWatch metrics reference in the AWS documentation.
Does Nuberio automatically create CloudWatch alarms for CPUUtilization?+
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 RDS resources are missing a CPUUtilization alarm. Nuberio Watch then monitors CPUUtilization 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 CPUUtilization alarm set up?+
Yes. Nuberio 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.
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 RDS alarms your account is missing — including CPUUtilization — run the free CloudWatch alarm audit. The scan takes under 5 minutes and requires no account.