Reserved capacity in DynamoDB - Deep Dive

Overview - Reserved capacity

What is it?

Reserved capacity in DynamoDB is a way to pre-pay for a set amount of read and write capacity units for your database tables. This means you commit to a certain level of usage ahead of time, which can save money compared to paying for capacity on demand. It helps ensure your application has the capacity it needs without unexpected costs or throttling.

Why it matters

Without reserved capacity, you pay for database capacity as you use it, which can be expensive and unpredictable for steady workloads. Reserved capacity solves this by offering a lower, fixed price for guaranteed capacity, helping businesses plan budgets and avoid performance issues. This is especially important for applications with consistent traffic, where cost savings and reliability matter.

Where it fits

Before learning reserved capacity, you should understand DynamoDB basics like tables, items, and capacity units. After reserved capacity, you can explore auto scaling, on-demand capacity mode, and cost optimization strategies to manage DynamoDB costs effectively.

Mental Model

Core Idea

Reserved capacity is like buying a monthly subscription for database capacity to save money and guarantee performance.

Think of it like...

Imagine you have a gym membership where you pay a fixed monthly fee for unlimited access instead of paying each time you visit. Reserved capacity works similarly by paying upfront for a set amount of database capacity, so you don’t worry about extra charges or running out of access.

┌───────────────────────────────┐
│         Reserved Capacity      │
├─────────────┬───────────────┤
│ Prepaid     │ Fixed monthly │
│ capacity    │ cost          │
├─────────────┼───────────────┤
│ Guaranteed  │ Cost savings  │
│ throughput  │ vs on-demand  │
└─────────────┴───────────────┘

Build-Up - 6 Steps

1

Foundation

Understanding DynamoDB Capacity Units

Concept: Learn what read and write capacity units mean in DynamoDB.

DynamoDB measures how much you can read or write per second using capacity units. One write capacity unit lets you write one item per second up to 1 KB in size. One read capacity unit lets you read one strongly consistent item per second up to 4 KB. Knowing this helps you plan how much capacity your app needs.

Result

You can estimate how many capacity units your application requires based on item size and request rate.

Understanding capacity units is essential because reserved capacity is purchased in these units, so you know what you are paying for.

2

Foundation

On-Demand vs Provisioned Capacity Modes

Concept: Learn the difference between paying per request and pre-allocating capacity.

DynamoDB offers two modes: on-demand, where you pay for each request, and provisioned, where you set capacity units ahead of time. Reserved capacity applies only to provisioned mode, where you commit to a fixed amount of capacity.

Result

You understand when reserved capacity can be used and when it cannot.

Knowing capacity modes helps you decide if reserved capacity fits your workload pattern.

3

Intermediate

How Reserved Capacity Pricing Works

🤔Before reading on: do you think reserved capacity charges you only for what you use or for the full amount you reserve? Commit to your answer.

Concept: Reserved capacity is a pre-paid commitment for a fixed amount of capacity, regardless of actual usage.

When you buy reserved capacity, you pay upfront for a set number of read or write capacity units for a 1 or 3 year term. You pay this fixed price whether you use all the capacity or not. This can save money if your usage is steady and predictable.

Result

You know that reserved capacity is a financial commitment, not a pay-as-you-go model.

Understanding the payment model prevents surprises and helps you plan your budget and capacity needs accurately.

4

Intermediate

Applying Reserved Capacity to Multiple Tables

🤔Before reading on: do you think reserved capacity applies to each table separately or can it be shared? Commit to your answer.

Concept: Reserved capacity can be shared across multiple tables within the same AWS account and region.

When you purchase reserved capacity, it is not tied to a single table. Instead, the capacity units are pooled and can be used by any table in your account and region. This flexibility helps optimize usage and reduce waste.

Result

You can allocate reserved capacity efficiently across your DynamoDB tables.

Knowing capacity sharing helps you maximize cost savings and avoid over-provisioning.

5

Advanced

Reserved Capacity and Auto Scaling Interaction

🤔Before reading on: do you think auto scaling adjusts reserved capacity or only provisioned capacity? Commit to your answer.

Concept: Auto scaling adjusts provisioned capacity but does not change reserved capacity commitments.

Auto scaling can increase or decrease your table’s provisioned capacity based on traffic. However, reserved capacity is a fixed commitment and does not change. If auto scaling increases capacity beyond reserved units, you pay on-demand rates for the extra capacity.

Result

You understand how reserved capacity and auto scaling work together and their cost implications.

Knowing this prevents unexpected charges when auto scaling exceeds reserved capacity.

6

Expert

Optimizing Reserved Capacity for Cost and Performance

🤔Before reading on: do you think buying more reserved capacity than needed is safer or wasteful? Commit to your answer.

Concept: Balancing reserved capacity purchase with actual usage avoids waste and throttling.

Experts analyze historical usage patterns to buy reserved capacity close to average demand. They combine reserved capacity with auto scaling to handle spikes. Overbuying wastes money; underbuying risks throttling and higher on-demand costs. Monitoring and adjusting reserved capacity over time is key.

Result

You can design a cost-effective and reliable capacity plan using reserved capacity.

Understanding this balance is crucial for real-world DynamoDB cost management and performance.

Under the Hood

Reserved capacity works by AWS allocating a guaranteed pool of read and write capacity units to your account for a fixed term. When your application sends requests, DynamoDB consumes capacity units from this pool first. If usage exceeds reserved capacity, additional requests consume on-demand capacity units billed separately. AWS tracks usage and billing internally to apply reserved capacity discounts automatically.

Why designed this way?

Reserved capacity was designed to provide cost savings for predictable workloads by allowing customers to commit upfront. This model balances AWS’s need for capacity planning with customer desire for lower prices. Alternatives like pure on-demand pricing are flexible but more expensive for steady use. Reserved capacity offers a middle ground between cost and flexibility.

┌───────────────┐
│ Reserved Pool │
│ (Prepaid)     │
└──────┬────────┘
       │
       ▼
┌───────────────┐      ┌───────────────┐
│ DynamoDB      │◄─────│ Application   │
│ Capacity      │      └───────────────┘
│ Units Used    │
└──────┬────────┘
       │
       ▼
┌───────────────┐
│ On-Demand     │
│ Capacity      │
│ Units Used    │
└───────────────┘

Myth Busters - 4 Common Misconceptions

Quick: Does reserved capacity automatically scale up if your traffic spikes? Commit to yes or no.

Common Belief: Reserved capacity automatically adjusts to handle any traffic spikes.

Reality: Reserved capacity is fixed and does not scale. If traffic exceeds reserved units, you pay extra for on-demand capacity.

Why it matters: Believing this causes unexpected throttling or higher costs during traffic spikes.

Quick: Is reserved capacity tied to a single DynamoDB table? Commit to yes or no.

Common Belief: Reserved capacity applies only to the table you buy it for.

Reality: Reserved capacity is shared across all tables in your AWS account and region.

Why it matters: Misunderstanding this can lead to buying unnecessary capacity or missing out on cost savings.

Quick: Does reserved capacity mean you only pay for what you use? Commit to yes or no.

Common Belief: You pay only for the capacity you actually consume with reserved capacity.

Reality: You pay for the full reserved capacity amount regardless of usage during the term.

Why it matters: This misconception can cause budget surprises if usage is lower than reserved capacity.

Quick: Can reserved capacity be used with on-demand capacity mode? Commit to yes or no.

Common Belief: Reserved capacity discounts apply to on-demand capacity mode tables.

Reality: Reserved capacity applies only to provisioned capacity mode, not on-demand mode.

Why it matters: Trying to use reserved capacity with on-demand tables leads to no cost savings.

Expert Zone

1

Reserved capacity purchases are regional and account-specific, so cross-region replication requires separate reservations.

2

Reserved capacity discounts do not apply to global secondary indexes separately; their capacity is included in the total provisioned units.

3

Unused reserved capacity cannot be refunded or transferred, so accurate forecasting is critical.

When NOT to use

Reserved capacity is not suitable for unpredictable or highly variable workloads; on-demand capacity mode is better in those cases. Also, short-term projects or testing environments benefit more from on-demand pricing due to flexibility.

Production Patterns

In production, teams combine reserved capacity for baseline steady traffic with auto scaling to handle spikes. They monitor usage with CloudWatch and adjust reserved capacity purchases annually to optimize costs. Large enterprises often negotiate custom reserved capacity contracts for additional savings.

Connections

Subscription Pricing Models

Reserved capacity is a form of subscription pricing applied to cloud resources.

Understanding subscription models in business helps grasp why reserved capacity offers cost savings for committed usage.

Cloud Auto Scaling

Reserved capacity sets a baseline, while auto scaling adjusts capacity dynamically above that baseline.

Knowing how reserved capacity and auto scaling complement each other helps design cost-effective, resilient cloud systems.

Budgeting and Forecasting

Reserved capacity requires accurate forecasting to avoid overpaying or under-provisioning.

Skills in financial planning improve decisions about reserved capacity purchases and cloud cost management.

Common Pitfalls

#1 Buying reserved capacity without analyzing actual usage patterns.

Wrong approach:

aws dynamodb purchase-reserved-capacity --capacity-units 1000 --term 3 --region us-east-1

Correct approach:

Analyze CloudWatch metrics first, then buy reserved capacity matching average steady usage, e.g., 500 units if average usage is 500.

Root cause:

Lack of monitoring and understanding of workload leads to overcommitment and wasted money.

#2 Assuming reserved capacity scales automatically with traffic spikes.

Wrong approach:

Relying solely on reserved capacity for a workload with unpredictable spikes.

Correct approach:

Combine reserved capacity for baseline with auto scaling enabled to handle spikes.

Root cause:

Misunderstanding that reserved capacity is fixed and does not adjust dynamically.

#3 Trying to use reserved capacity discounts on on-demand capacity mode tables.

Wrong approach:

Purchasing reserved capacity but setting tables to on-demand mode expecting discounts.

Correct approach:

Use provisioned capacity mode tables to benefit from reserved capacity discounts.

Root cause:

Confusing capacity modes and discount applicability.

Key Takeaways

Reserved capacity lets you pre-pay for a fixed amount of DynamoDB capacity units to save money and guarantee performance.

It applies only to provisioned capacity mode and is shared across all tables in your AWS account and region.

Reserved capacity is a fixed commitment; you pay for the full amount regardless of actual usage during the term.

Combining reserved capacity with auto scaling helps balance cost savings with handling traffic spikes.

Accurate monitoring and forecasting are essential to avoid overpaying or throttling your application.