AWS DynamoDB Provisioned Capacity Over-Allocation Detector
Locate Amazon DynamoDB tables running provisioned read/write capacity units with < 20% peak utilization that should switch to On-Demand capacity or scale down provisioned units.
1. Detection Scope & Operational Boundaries
Every ArthaOps detector enforces strict epistemic honesty. We clearly separate what can be mathematically proven via agentless telemetry from what requires contextual human judgement.
What This Detector Identifies
- DynamoDB tables provisioned with static RCU/WCU where peak ConsumedReadCapacityUnits and ConsumedWriteCapacityUnits remain below 20% of provisioned capacity across 14 consecutive days.
- Tables with highly spiky or sporadic traffic padded with 5x–10x over-provisioned capacity to avoid throttles.
- Global Secondary Indexes (GSIs) with excessive provisioned write throughput bottlenecking costs.
What It Cannot Establish Alone
- Whether scheduled flash sales, annual marketing events, or predictable month-end batch crons require retaining high provisioned headroom to prevent ThrottledRequests.
- Whether enterprise Savings Plans or EDP commitments provide volume discounting that changes the economic break-even point between Provisioned and On-Demand (PAY_PER_REQUEST).
2. Telemetry & Evidence Requirements
ArthaOps operates strictly via Plane 1 (Read-Only Discovery). The following CloudFormation / IAM permissions and CloudWatch metrics are evaluated:
AWS::DynamoDB::TableVerification Protocol: Tested against synthetic DynamoDB table fixtures provisioned with 500 WCU / 1,000 RCU consuming < 20% capacity.
Validation Context: Validated in high-throughput microservices where legacy tables retained peak launch capacity allocations years after traffic settled.
3. Reproducible AWS CLI Verification Recipe
Inspect DynamoDB table billing mode, provisioned throughput, and table status in ap-south-1.
# Inspect DynamoDB table billing mode and provisioned throughput in ap-south-1
aws dynamodb describe-table \
--region ap-south-1 \
--table-name staging-user-sessions \
--query "Table.{TableName:TableName,BillingMode:BillingModeSummary.BillingMode,RCU:ProvisionedThroughput.ReadCapacityUnits,WCU:ProvisionedThroughput.WriteCapacityUnits,Status:TableStatus}" \
--output table-------------------------------------------------------------------------------------------------
| DescribeTable |
+--------------------------+---------------------+-------+------------------------+-------------+
| BillingMode | RCU | Status| TableName | WCU |
+--------------------------+---------------------+-------+------------------------+-------------+
| PROVISIONED | 1000 | ACTIVE| staging-user-sessions | 500 |
+--------------------------+---------------------+-------+------------------------+-------------+💡 Table is configured with 1,000 RCU and 500 WCU provisioned capacity. In staging environments with minimal traffic, this incurs continuous hourly reservation charges 24/7.
4. Transparent Economic Model
- Illustrative scenario based on a typical over-provisioned staging/dev table (500 WCU + 1,000 RCU).
- 730 operational hours per standard calendar month at static ₹84.00/USD conversion.
- Table consuming < 20% average provisioned capacity across 14-day analysis window.
- Actual savings depend on individual table request distribution, read/write ratios, and burst headroom needs.
- DynamoDB Streams and Point-in-Time Recovery (PITR) storage fees are excluded from capacity calculation.
5. False-Positive Scenarios & Operational Risks
Never delete or terminate cloud resources blindly. These validated architectural scenarios must be reviewed before initiating remediation:
Documented False-Positive Scenarios
- Predictable Batch Peak Cycles: Tables utilized for high-volume end-of-month batch reconciliations that consume 100% capacity during a 4-hour window once a month.
- Steep Traffic Bursts: Applications with instantaneous >2x traffic spikes in under 1 second without pre-warming may experience brief throttling when running On-Demand mode.
Blast Radius & Remediation Risks
- AWS 24-Hour Billing Mode Quota: AWS strictly permits switching a DynamoDB table from PAY_PER_REQUEST back to PROVISIONED only once every 24 hours.
- Mitigation: Verify CloudWatch ThrottledRequests metric is strictly 0 for the prior 14 days before triggering billing mode mutation.
6. Remediation Procedure & Rollback Runbook
Follow this ordered sequence of verified AWS CLI actions to remediate the resource with complete rollback availability:
Inspect 14-Day Consumed vs Provisioned Capacity
Verify that peak consumption is consistently below 20% of provisioned capacity.
aws cloudwatch get-metric-data --region ap-south-1 --metric-data-queries file://dynamodb_metric_query.json --start-time $(date -u -v-14d +%Y-%m-%dT%H:%M:%SZ) --end-time $(date -u +%Y-%m-%dT%H:%M:%SZ)Switch Billing Mode to On-Demand
Update the table billing mode to PAY_PER_REQUEST to pay strictly for executed read and write requests.
aws dynamodb update-table --region ap-south-1 --table-name staging-user-sessions --billing-mode PAY_PER_REQUESTForensic Rollback Procedure
To revert back to Provisioned capacity, execute `aws dynamodb update-table --region ap-south-1 --table-name staging-user-sessions --billing-mode PROVISIONED --provisioned-throughput ReadCapacityUnits=1000,WriteCapacityUnits=500` after the 24-hour AWS rate limit window expires.
🔒 ArthaOps Assurance: ArthaOps checks ThrottledRequests and requires explicit human approval before toggling DynamoDB billing modes.
AWS strictly enforces a 24-hour rate limit on switching a table from PAY_PER_REQUEST back to PROVISIONED. Once converted, you cannot revert for 24 hours.
How This Appears in the ArthaOps Control Plane
Table provisioned with 1,000 RCU and 500 WCU operates at < 3% average utilization across 14 days.
Test Your Infrastructure in 180 Seconds
Explore our zero-setup interactive sample report covering real Mumbai findings, or launch a 100% read-only agentless scan across your AWS environment.