Pricing Model
Amazon DynamoDB is a serverless, NoSQL key-value and document database. Unlike traditional relational databases where you often pay for provisioned instance hours, DynamoDB charges based on data storage, read/write throughput, and optional features.1
The single most important factor in keeping DynamoDB costs low and performance high is designing for your access patterns. DynamoDB rewards you for knowing exactly what data you need and where to find it. Every table and index should be structured so your most common operations use Query instead of Scan.
When you design tables and indexes around specific access patterns—using partition keys that match how you actually query your data—you unlock efficient, low-cost operations. When you don’t, you’re forced into expensive, slow scans of entire datasets.
Note: Advanced DynamoDB design patterns are out of the scope of this documentation, as this is a very complex topic. Here we will review some of the fundamentals of indexing, but we won’t get into advanced concepts.
How DynamoDB Pricing Works
DynamoDB uses Read Capacity Units (RCUs) and Write Capacity Units (WCUs) to measure and charge for throughput.
Capacity Unit Pricing:
- 1 RCU: One strongly consistent read per second for items up to 4KB (eventually consistent reads consume 0.5 RCU)
- 1 WCU: One write per second for items up to 1KB
If your item is 5KB, reading it consumes 2 RCUs. A 2.5KB write consumes 3 WCUs.
Capacity Modes:
- On-Demand: Pay per request. DynamoDB scales automatically. Higher per-request cost but no capacity planning needed.
- Provisioned: Reserve RCUs and WCUs in advance. Lower per-request cost but you pay for reserved capacity whether you use it or not. Comes with auto-scaling options.
Transaction Types:
- Eventually Consistent Reads: Half the RCU cost of strongly consistent reads (default for most operations)
- Strongly Consistent Reads: Full RCU cost, guaranteed latest data
- Transactional Operations: Cost 2x standard RCUs/WCUs for ACID guarantees across multiple items
Indexes:
- LSI (Local Secondary Index) and GSI (Global Secondary Index) both consume additional RCUs/WCUs depending on read/write operations and increase storage costs for projected attributes
Additional Costs:
- Storage: Charged per GB-month for data stored in standard or infrequent access (IA) classes
- Backup & Restore: Costs for continuous backups (PITR) and on-demand backups
- Data Transfer: Standard AWS data transfer rates apply (e.g., cross-region replication)
- Global Tables: Replicated write capacity units (rWCUs) and storage are charged for each additional region
Major Cost Drivers
In DynamoDB, costs often scale with usage rather than uptime, but inefficiencies can still lead to waste:
- Wrong Capacity Mode: Using On-Demand for high-volume, steady-state workloads (more expensive per unit) or Provisioned for spikey workloads (paying for unused capacity).
- Inefficient Access Patterns: Scanning entire tables (consuming many RCUs) instead of using efficient
GetItemorQueryoperations. - Unused Provisioned Capacity: Setting provisioned limits too high without auto-scaling, paying for idle capacity.
- Old/Unused Data: Storing massive amounts of historical data in the standard storage class instead of archiving to S3 or using the Standard-IA class.
- Global Tables: Replicating all data to regions where it isn’t actually needed.