DynamoDB Capacity Modes: What It Is and When to Use It

Definition

Amazon DynamoDB capacity modes are the settings that control how you manage and pay for the read and write throughput of your database tables. They solve the critical problem of matching database performance resources to your application's workload pattern, allowing you to balance cost-effectiveness with performance and scalability.

How It Works

DynamoDB offers two distinct capacity modes for handling read and write requests on a per-table basis: On-Demand and Provisioned.

On-Demand Capacity Mode

On-Demand is the simplest model, functioning on a pay-per-request basis. You don't need to perform any capacity planning; DynamoDB automatically and instantly scales to accommodate your application's traffic, whether it's a few requests per hour or millions per second. This serverless approach is ideal for applications with unpredictable, spiky, or unknown traffic patterns, as it eliminates the risk of performance throttling due to insufficient capacity.

When a table is in on-demand mode, it can instantly serve traffic up to double its previous peak within a 30-minute window. If traffic establishes a new sustained peak, that becomes the new baseline for future scaling. New on-demand tables start with a generous default capacity (e.g., 4,000 writes and 12,000 reads per second) that can scale up from there.

Provisioned Capacity Mode

In Provisioned mode, you explicitly specify the throughput your application requires in terms of Read Capacity Units (RCUs) and Write Capacity Units (WCUs). You are billed on an hourly basis for the capacity you provision, regardless of whether you consume it all. This model provides predictable costs and is the most cost-effective option for applications with stable, predictable traffic.

• Read Capacity Unit (RCU): One RCU represents one strongly consistent read per second, or two eventually consistent reads per second, for an item up to 4 KB in size.
• Write Capacity Unit (WCU): One WCU represents one write per second for an item up to 1 KB in size.

If your application's traffic exceeds the provisioned capacity, DynamoDB will throttle the excess requests, which results in an error (ProvisionedThroughputExceededException) that your application must handle, typically with a retry mechanism.

Provisioned Mode with Auto Scaling

To mitigate the risks of over-provisioning (wasted cost) or under-provisioning (throttling), Provisioned mode is almost always used with DynamoDB Auto Scaling. This feature leverages AWS Application Auto Scaling to monitor your table's actual consumption via Amazon CloudWatch alarms and automatically adjusts the provisioned RCUs and WCUs to maintain a target utilization percentage you define (e.g., 70%). You set a minimum and maximum capacity, and Auto Scaling operates within those bounds, providing an elastic yet cost-controlled solution. It's important to note that auto scaling reacts to sustained traffic changes over a few minutes and is not designed for instantaneous spikes, which On-Demand mode handles better.

Key Features and Limits

• Per-Table Setting: Capacity mode is configured independently for each DynamoDB table.
• GSI Independence: Global Secondary Indexes (GSIs) have their own capacity mode settings, which can be different from the base table, allowing for mixed-mode configurations to optimize costs for different access patterns.
• LSI Shared Capacity: Local Secondary Indexes (LSIs) do not have their own capacity settings; they share the throughput of their base table.
• Mode Switching: You can switch a table between modes. A switch from On-Demand to Provisioned can happen at any time. A switch from Provisioned to On-Demand is limited, for example to once every 24 hours.
• On-Demand Quotas: On-demand tables have a default account-level quota of 40,000 RCUs and 40,000 WCUs per table, which can be increased via a service quota request.
• Partition Limits: Regardless of capacity mode, each underlying physical partition in DynamoDB has a hard limit of 3,000 RCUs and 1,000 WCUs. Throttling can still occur with a "hot key" design even if the table-level limits are not reached.

Common Use Cases

On-Demand Mode

1. New Applications: When launching a new product, traffic patterns are often completely unknown. On-Demand mode provides performance assurance without requiring a capacity forecast.
2. Unpredictable & Spiky Workloads: Ideal for applications like social media, gaming, or e-commerce sites that experience sudden, massive traffic spikes.
3. Development & Test Environments: Dev/test workloads are typically intermittent and low-volume, making the pay-per-request model of On-Demand highly cost-effective as you pay nothing for idle time.

Provisioned Mode

1. Steady, Predictable Traffic: A backend service for an established enterprise application with consistent, high-volume usage is a perfect fit for the cost savings of Provisioned mode.
2. Cost-Optimized Workloads: For applications where budget predictability is paramount and traffic patterns are well-understood, Provisioned mode offers the lowest possible cost at scale.
3. Long-Term Commitment Savings: Applications with a stable baseline of traffic can leverage Reserved Capacity on top of Provisioned mode to achieve discounts of up to 77%.

Pricing Model

• On-Demand: You are billed for the number of actual read and write requests your application performs, typically priced per million requests. There is no charge for throughput when the table is idle, though you still pay for data storage.
• Provisioned: You are billed per hour based on the number of RCUs and WCUs you provision, regardless of consumption.
• Reserved Capacity: For Provisioned mode tables with a predictable baseline, you can purchase 1-year or 3-year term Reserved Capacity. This involves an upfront payment in exchange for a significantly discounted hourly rate on the reserved RCUs and WCUs, offering savings up to 77% compared to standard provisioned rates.

In addition to throughput, all tables incur charges for data storage, continuous backups with Point-in-Time Recovery (PITR), data transfer out of AWS, and features like Global Tables and DynamoDB Streams. For detailed estimates, use the AWS Pricing Calculator.

Pros and Cons

On-Demand Mode

• Pros:
  • No capacity planning required, simplifying operations.
  • Instantly scales to handle massive traffic spikes.
  • Eliminates the risk of application throttling.
  • Cost-effective for idle or low-traffic tables.
• Cons:
  • Can be significantly more expensive for sustained, high-volume workloads.
  • Less predictable monthly costs compared to Provisioned mode.

Provisioned Mode

• Pros:
  • Highly cost-effective for predictable workloads, with per-request costs being 5-7x cheaper than On-Demand at high utilization.
  • Provides predictable, stable monthly billing.
  • Enables the use of Reserved Capacity for maximum cost savings.
• Cons:
  • Requires careful capacity planning and monitoring.
  • Risk of throttling if capacity is under-provisioned.
  • Risk of wasted spend if capacity is over-provisioned.
  • Auto Scaling has a reaction delay of a few minutes, which may not be fast enough for sudden spikes.

Comparison with Alternatives

• On-Demand vs. Provisioned with Auto Scaling: This is the primary decision point. Choose On-Demand for unpredictable, spiky, or new workloads where operational simplicity and performance are paramount. Choose Provisioned with Auto Scaling for established workloads with predictable patterns where cost-efficiency is the main driver. A common strategy is to launch with On-Demand, monitor traffic for several weeks, and then switch to Provisioned with Auto Scaling once a baseline is established.

• DynamoDB Capacity vs. Aurora Serverless v2 Capacity: While both offer serverless scaling, they serve different database models. DynamoDB's capacity modes scale read/write throughput for a NoSQL key-value/document database. Amazon Aurora Serverless v2 scales compute and memory resources (ACUs) for a relational, SQL-compatible database. The choice depends entirely on whether your application requires a relational (SQL) or non-relational (NoSQL) data model.

Exam Relevance

DynamoDB Capacity Modes are a frequent and critical topic on several AWS certification exams, including:

• AWS Certified Developer - Associate (DVA-C02)
• AWS Certified Solutions Architect - Associate (SAA-C03)
• AWS Certified Solutions Architect - Professional (SAP-C02)
• AWS Certified Database - Specialty (DBS-C01)

Examinees must know the difference between On-Demand and Provisioned modes, including their pricing models and ideal use cases. Scenario-based questions will often require you to select the most cost-effective or operationally efficient capacity mode for a given workload (e.g., "a new application with unknown traffic" points to On-Demand; "a predictable workload with a focus on cost" points to Provisioned). Understanding the concepts of RCUs, WCUs, throttling, and the function of Auto Scaling is essential.

Frequently Asked Questions

Q: Can I switch from On-Demand to Provisioned mode without downtime?

A: Yes, you can switch between capacity modes at any time without downtime or data loss. The table remains fully available during the transition, which can take a few minutes. Note that there are limits on how often you can switch, particularly from Provisioned to On-Demand (e.g., once every 24 hours).

Q: How does Auto Scaling work with Provisioned mode?

A: DynamoDB Auto Scaling monitors your table's consumed capacity using Amazon CloudWatch metrics. You define a target utilization percentage (e.g., 70%). If consumed capacity rises above this target for a sustained period, Application Auto Scaling issues a command to increase your provisioned RCUs or WCUs. Conversely, if consumption drops, it scales down the provisioned capacity to save costs, never going below your configured minimum.

Q: Do Global Secondary Indexes (GSIs) have their own capacity modes?

A: Yes, each GSI has its own capacity mode setting that is independent of the base table. This allows for flexible cost optimization. For example, you could have a Provisioned base table for your primary, predictable access pattern, and an On-Demand GSI to handle an occasional, spiky query pattern on a different attribute.

---

This article reflects AWS features and pricing as of 2026. AWS services evolve rapidly — always verify against the official AWS documentation before making production decisions.