CloudWatch Metric Guide
ConsumedReadCapacityUnitsAmazon DynamoDB CloudWatch metric
ConsumedReadCapacityUnits reports the number of read capacity units consumed over the specified time period for a DynamoDB table or global secondary index.
What it measures
About ConsumedReadCapacityUnits
ConsumedReadCapacityUnits reports the number of read capacity units consumed over the specified time period for a DynamoDB table or global secondary index.
| Namespace | AWS/DynamoDB |
| Metric name | ConsumedReadCapacityUnits |
| Unit | Count |
| AWS docs | Official Amazon DynamoDB metrics reference |
Why this metric matters
For provisioned capacity DynamoDB tables, ConsumedReadCapacityUnits directly determines when throttling begins. Each table has a provisioned read capacity unit (RCU) limit. When consumption exceeds that limit, DynamoDB returns ProvisionedThroughputExceededException for the excess requests. These requests are retried by the AWS SDK with exponential backoff — but until they succeed, your application's read operations are slower than expected.
For on-demand capacity tables, this metric is still important for cost visibility. On-demand pricing scales with consumed capacity, and an unexpected spike in ConsumedReadCapacityUnits translates directly to a cost spike. Monitoring this metric gives you both a throttle signal (provisioned) and a cost signal (on-demand) for the same underlying behavior.
Recommended alarm threshold for ConsumedReadCapacityUnits
Recommended threshold
> 80% of provisioned read capacity (for provisioned mode tables)
DynamoDB begins throttling at the provisioned capacity limit. The 80% threshold (ConvOps recommendation) provides headroom to increase provisioned capacity or enable auto-scaling before throttling begins. For tables with auto-scaling enabled, this alarm catches cases where scaling isn't keeping pace with demand. For on-demand tables, use this metric for cost anomaly detection rather than throttle prevention.
Is your ConsumedReadCapacityUnits alarm already set up correctly?
The free ConvOps Audit scans your CloudWatch setup and flags missing or misconfigured alarms — including ConsumedReadCapacityUnits — in 5 minutes.
Common failures that show up in ConsumedReadCapacityUnits
When ConsumedReadCapacityUnits reaches an alarm threshold, these are the most common root causes — in order of how often ConvOps sees them across customer AWS accounts.
Missing GSI read capacity — a global secondary index has its own separate capacity allocation; scans or queries on the GSI can consume GSI capacity independently of table capacity
Hot partition — all reads concentrate on items with the same partition key, causing a single partition to exceed its per-partition throughput limit even when table-level RCU is under the limit
Scan operation on large table — a full table scan by an analytics or reporting process consumes large amounts of RCU in a short period
Inefficient query — a query without a proper key condition expression fetches more items than needed, consuming excess read capacity to return a small result set
Cache miss cascade — an application-side cache failure causes all requests to fall through to DynamoDB simultaneously, multiplying read consumption
How ConvOps debugs ConsumedReadCapacityUnits alarms
When ConsumedReadCapacityUnits 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/DynamoDB 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 ConsumedReadCapacityUnits 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 ConsumedReadCapacityUnits anomalies with z-score against 30-day time-bucketed baselines. 9 verification checks before any alert.
ConvOps Diagnose
When a ConsumedReadCapacityUnits 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 ConsumedReadCapacityUnits alarms. Free, 5-minute read-only scan.
Related Amazon DynamoDB metrics
ConsumedReadCapacityUnits rarely fails in isolation. These metrics tend to correlate — monitor them together for complete Amazon DynamoDB coverage.
FAQ
Frequently asked questions about ConsumedReadCapacityUnits
Common questions about setting up CloudWatch alarms for ConsumedReadCapacityUnits in Amazon DynamoDB.
What is the recommended CloudWatch alarm threshold for ConsumedReadCapacityUnits?+
> 80% of provisioned read capacity (for provisioned mode tables). DynamoDB begins throttling at the provisioned capacity limit. The 80% threshold (ConvOps recommendation) provides headroom to increase provisioned capacity or enable auto-scaling before throttling begins. For tables with auto-scaling enabled, this alarm catches cases where scaling isn't keeping pace with demand. For on-demand tables, use this metric for cost anomaly detection rather than throttle prevention.
Which CloudWatch namespace does ConsumedReadCapacityUnits belong to?+
ConsumedReadCapacityUnits is published in the AWS/DynamoDB namespace with a unit of Count. You can find it in the CloudWatch console under "Metrics" → "AWS/DynamoDB". See the Amazon DynamoDB CloudWatch metrics reference in the AWS documentation.
Does ConvOps automatically create CloudWatch alarms for ConsumedReadCapacityUnits?+
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 DynamoDB resources are missing a ConsumedReadCapacityUnits alarm. ConvOps Watch then monitors ConsumedReadCapacityUnits 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 ConsumedReadCapacityUnits alarm set up?+
Yes. ConvOps Watch monitors ConsumedReadCapacityUnits 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 ConsumedReadCapacityUnits alarm and provide the copy-paste AWS CLI command to create it.