CloudWatch Metric Guide
ConsumedWriteCapacityUnitsAmazon DynamoDB CloudWatch metric
ConsumedWriteCapacityUnits reports the number of write capacity units consumed over the specified time period for a DynamoDB table or global secondary index, for both provisioned and on-demand capacity modes.
What it measures
About ConsumedWriteCapacityUnits
ConsumedWriteCapacityUnits reports the number of write capacity units consumed over the specified time period for a DynamoDB table or global secondary index, for both provisioned and on-demand capacity modes.
| Namespace | AWS/DynamoDB |
| Metric name | ConsumedWriteCapacityUnits |
| Unit | Count |
| AWS docs | Official Amazon DynamoDB metrics reference |
Why this metric matters
ConsumedWriteCapacityUnits is the write-side mirror of ConsumedReadCapacityUnits, and it matters just as much — arguably more, since write throttling blocks data from being persisted at all, rather than just delaying a read. For provisioned capacity tables, DynamoDB begins rejecting write requests with ProvisionedThroughputExceededException the moment consumed write capacity exceeds the provisioned WCU limit. The AWS SDK retries these with exponential backoff, but every retry adds latency to the write path and, if the backlog keeps growing, eventually surfaces as an application-level error.
AWS also emits this metric with a Source dimension (Customer vs. GlobalTable) for tables using global tables replication. That distinction matters operationally: a spike in ConsumedWriteCapacityUnits attributed to GlobalTable means replication traffic from another region is consuming your local table's write capacity, not your own application — a very different root cause and fix than a genuine surge in customer writes. For on-demand tables, this metric is also a direct cost driver, since on-demand write pricing scales with consumed WCU.
Recommended alarm threshold for ConsumedWriteCapacityUnits
Recommended threshold
> 80% of provisioned write capacity (for provisioned mode tables)
DynamoDB begins throttling write requests once consumed write capacity crosses the provisioned WCU limit, per AWS documentation. The 80% threshold (Nuberio recommendation) mirrors the read-capacity alarm and gives enough lead time to raise provisioned capacity, let auto-scaling catch up, or investigate a hot partition before writes start failing. For on-demand tables, treat sustained growth in this metric as a cost-anomaly signal rather than a throttle signal, since on-demand capacity scales automatically up to roughly double the table's previous peak.
Is your ConsumedWriteCapacityUnits alarm already set up correctly?
The free Nuberio Audit scans your CloudWatch setup and flags missing or misconfigured alarms — including ConsumedWriteCapacityUnits — in 5 minutes.
Common failures that show up in ConsumedWriteCapacityUnits
When ConsumedWriteCapacityUnits reaches an alarm threshold, these are the most common root causes — in order of how often Nuberio sees them across customer AWS accounts.
Bulk write job or data migration — an import, backfill, or ETL process writes faster than provisioned WCU allows, exhausting capacity in a short burst
Hot partition key on writes — items sharing a partition key (e.g., a single 'today' timestamp bucket) concentrate write traffic on one physical partition regardless of table-level WCU headroom
Global secondary index write amplification — every write to the base table also consumes write capacity on each GSI it projects into, so a table can throttle on GSI capacity even when base-table WCU looks healthy
Global tables replication surge — cross-region replica writes (Source=GlobalTable) consume local write capacity, which is easy to mistake for a spike in application traffic if the Source dimension isn't checked
Auto-scaling lag on provisioned tables — write traffic grows faster than DynamoDB auto-scaling can react, since scale-up decisions take a few minutes to apply
How the Nuberio Audit checks ConsumedWriteCapacityUnits
The free Audit scans every Amazon DynamoDB resource in your account and checks whether a ConsumedWriteCapacityUnits 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 ConsumedWriteCapacityUnits alarms. Free, 5-minute read-only scan.
Related Amazon DynamoDB metrics
ConsumedWriteCapacityUnits rarely fails in isolation. These metrics tend to correlate — monitor them together for complete Amazon DynamoDB coverage.
FAQ
Frequently asked questions about ConsumedWriteCapacityUnits
Common questions about setting up CloudWatch alarms for ConsumedWriteCapacityUnits in Amazon DynamoDB.
What is the recommended CloudWatch alarm threshold for ConsumedWriteCapacityUnits?+
> 80% of provisioned write capacity (for provisioned mode tables). DynamoDB begins throttling write requests once consumed write capacity crosses the provisioned WCU limit, per AWS documentation. The 80% threshold (Nuberio recommendation) mirrors the read-capacity alarm and gives enough lead time to raise provisioned capacity, let auto-scaling catch up, or investigate a hot partition before writes start failing. For on-demand tables, treat sustained growth in this metric as a cost-anomaly signal rather than a throttle signal, since on-demand capacity scales automatically up to roughly double the table's previous peak.
Which CloudWatch namespace does ConsumedWriteCapacityUnits belong to?+
ConsumedWriteCapacityUnits 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 Nuberio automatically create CloudWatch alarms for ConsumedWriteCapacityUnits?+
No — the free Nuberio Audit does not create alarms for you. It scans your CloudWatch setup and tells you which Amazon DynamoDB resources are missing a ConsumedWriteCapacityUnits alarm, then gives you the exact CLI command to create it yourself.
Can I use Nuberio without already having a ConsumedWriteCapacityUnits alarm set up?+
Yes. The free Audit works whether or not you have any ConsumedWriteCapacityUnits 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 DynamoDB alarms your account is missing — including ConsumedWriteCapacityUnits — run the free CloudWatch alarm audit. The scan takes under 5 minutes and requires no account.