DynamoDB capacity modes (on-demand, provisioned) in AWS - Step-by-Step Execution

Process Flow - DynamoDB capacity modes (on-demand, provisioned)

Start

↓

Choose Capacity Mode

↓

On-Demand

↓

Auto scales

↓

Pay per request

↓

Handle Traffic

↓

End

You start by choosing a capacity mode. On-demand mode automatically handles traffic and charges per request. Provisioned mode requires setting capacity units and monitoring usage.

Execution Sample

AWS

CreateTable(
  CapacityMode='ON_DEMAND'
)

UpdateTable(
  CapacityMode='PROVISIONED',
  ReadCapacityUnits=5,
  WriteCapacityUnits=5
)

This code creates a DynamoDB table first with on-demand mode, then updates it to provisioned mode with 5 read and write units.

Process Table

Step	Action	Capacity Mode	Read Units	Write Units	Billing	Result
1	Create table	ON_DEMAND	N/A	N/A	Pay per request	Table created with on-demand mode
2	Traffic starts	ON_DEMAND	N/A	N/A	Auto scales	Handles any traffic automatically
3	Update table	PROVISIONED	5	5	Pay per capacity unit	Table updated to provisioned mode
4	Traffic continues	PROVISIONED	5	5	Fixed capacity billing	Uses set capacity units, throttles if exceeded
5	Adjust capacity	PROVISIONED	10	10	Updated billing	Capacity units increased to handle more traffic
6	Traffic spikes beyond capacity	PROVISIONED	10	10	Throttling occurs	Requests above capacity are throttled
7	Switch back to on-demand	ON_DEMAND	N/A	N/A	Pay per request	Table switches back to on-demand mode
8	Traffic spikes	ON_DEMAND	N/A	N/A	Auto scales	Handles spikes without throttling
9	End	-	-	-	-	Capacity mode choice affects billing and scaling

💡 Execution ends after switching modes and handling traffic with different billing and scaling behaviors.

Status Tracker

Variable	Start	After Step 1	After Step 3	After Step 5	After Step 7	Final
CapacityMode	None	ON_DEMAND	PROVISIONED	PROVISIONED	ON_DEMAND	ON_DEMAND
ReadUnits	None	N/A	5	10	N/A	N/A
WriteUnits	None	N/A	5	10	N/A	N/A
Billing	None	Pay per request	Pay per capacity unit	Updated billing	Pay per request	Pay per request

Key Moments - 3 Insights

Why does the ReadUnits value show 'N/A' in on-demand mode?

In on-demand mode, you don't set read or write units because DynamoDB automatically handles capacity. This is shown in execution_table rows 1 and 2 where ReadUnits is 'N/A'.

What happens if traffic exceeds provisioned capacity units?

When traffic goes beyond provisioned units, requests get throttled as shown in step 6 of the execution_table. This means some requests are delayed or rejected until capacity is increased.

How does billing differ between on-demand and provisioned modes?

On-demand billing charges per request automatically (rows 1,2,8). Provisioned billing charges based on set capacity units regardless of usage (rows 3,4,5).

Visual Quiz - 3 Questions

Look at the execution_table, what is the CapacityMode after step 5?

A N/A

B ON_DEMAND

C PROVISIONED

D UNKNOWN

💡 Hint

Check the CapacityMode column in execution_table row for step 5.

At which step does throttling occur due to traffic exceeding capacity?

A Step 4

B Step 6

C Step 2

D Step 8

💡 Hint

Look for 'Throttling occurs' in the Result column of execution_table.

If you switch from provisioned to on-demand mode, what happens to ReadUnits and WriteUnits?

A They become N/A

B They stay the same

C They reset to zero

D They double

💡 Hint

Check variable_tracker values after step 7 for ReadUnits and WriteUnits.

Concept Snapshot

DynamoDB Capacity Modes:
- On-Demand: No capacity units set, auto scales, pay per request.
- Provisioned: Set read/write units, fixed billing, may throttle if exceeded.
- Switch modes anytime to balance cost and performance.
- Monitor usage to adjust provisioned units as needed.

Full Transcript

This visual execution shows how DynamoDB capacity modes work. You start by creating a table in on-demand mode, which automatically scales and charges per request. Then you update the table to provisioned mode, setting fixed read and write capacity units. Traffic is handled within these limits, and if exceeded, throttling occurs. You can adjust capacity units to handle more traffic. Switching back to on-demand removes capacity limits and throttling, charging per request again. The execution table tracks each step, showing capacity mode, units, billing, and results. Variable tracker shows how capacity mode and units change over time. Key moments clarify common confusions about capacity units in on-demand mode, throttling in provisioned mode, and billing differences. The quiz tests understanding of these execution steps. This helps beginners see how capacity modes affect DynamoDB behavior and cost.

Practice

1. What is the main advantage of using DynamoDB's on-demand capacity mode?

easy

A. It offers a lower cost for steady, predictable workloads.

B. It automatically scales to handle any workload without manual capacity planning.

C. It requires you to set fixed read and write capacity units.

D. It limits the number of requests per second to a fixed amount.

Solution

1. Step 1: Understand on-demand mode behavior

   On-demand mode automatically adjusts capacity to meet traffic demands without manual input.

2. Step 2: Compare with provisioned mode

   Provisioned mode requires fixed capacity settings, unlike on-demand.

3. Final Answer:

   It automatically scales to handle any workload without manual capacity planning. -> Option B

4. Quick Check:

   On-demand = auto scaling without setup [OK]

Hint: On-demand means auto scale, no manual setup needed [OK]

Common Mistakes:

• Confusing on-demand with provisioned fixed capacity
• Thinking on-demand limits requests
• Assuming on-demand is cheaper for steady workloads

2. Which of the following is the correct way to specify provisioned capacity in a DynamoDB table creation JSON?

easy

A. { "Throughput": { "Reads": 5, "Writes": 10 } }

B. { "CapacityMode": "ON_DEMAND" }

C. { "ProvisionedThroughput": { "ReadCapacityUnits": 5, "WriteCapacityUnits": 10 } }

D. { "ReadUnits": 5, "WriteUnits": 10 }

Solution

1. Step 1: Recall provisioned capacity syntax

   Provisioned mode requires specifying ReadCapacityUnits and WriteCapacityUnits inside ProvisionedThroughput.

2. Step 2: Check options for correct JSON structure

   { "ProvisionedThroughput": { "ReadCapacityUnits": 5, "WriteCapacityUnits": 10 } } matches the correct AWS DynamoDB API format for provisioned throughput.

3. Final Answer:

   { "ProvisionedThroughput": { "ReadCapacityUnits": 5, "WriteCapacityUnits": 10 } } -> Option C

4. Quick Check:

   ProvisionedThroughput with Read/Write units = correct syntax [OK]

Hint: Provisioned capacity uses ProvisionedThroughput with Read/Write units [OK]

Common Mistakes:

• Using CapacityMode for provisioned capacity
• Missing ProvisionedThroughput wrapper
• Incorrect property names like ReadUnits

3. Given a DynamoDB table in provisioned mode with 5 read capacity units and 5 write capacity units, what happens if your application suddenly sends 20 write requests per second?

medium

A. Some write requests are throttled because they exceed the provisioned write capacity.

B. All 20 write requests succeed immediately without throttling.

C. DynamoDB automatically increases write capacity to 20 units instantly.

D. The table switches automatically to on-demand mode to handle the load.

Solution

1. Step 1: Understand provisioned capacity limits

   Provisioned mode limits throughput to the set capacity units (5 writes per second here).

2. Step 2: Analyze effect of exceeding capacity

   Sending 20 writes exceeds 5 units, causing throttling of excess requests.

3. Final Answer:

   Some write requests are throttled because they exceed the provisioned write capacity. -> Option A

4. Quick Check:

   Provisioned mode throttles excess requests [OK]

Hint: Provisioned mode throttles requests above set capacity [OK]

Common Mistakes:

• Assuming automatic capacity increase in provisioned mode
• Thinking on-demand mode applies automatically
• Believing all requests always succeed

4. You configured a DynamoDB table with provisioned capacity: 10 read units and 10 write units. Your application experiences throttling errors during peak hours. What is the best immediate fix to reduce throttling without downtime?

medium

A. Switch the table to on-demand capacity mode.

B. Reduce the size of items stored in the table.

C. Delete and recreate the table with higher capacity.

D. Increase the provisioned read and write capacity units.

Solution

1. Step 1: Identify cause of throttling

   Throttling occurs because provisioned capacity is too low for peak traffic.

2. Step 2: Choose immediate fix without downtime

   Increasing provisioned capacity units can be done live without deleting the table.

3. Final Answer:

   Increase the provisioned read and write capacity units. -> Option D

4. Quick Check:

   Increase capacity units to reduce throttling [OK]

Hint: Increase provisioned units live to fix throttling fast [OK]

Common Mistakes:

• Deleting and recreating table causes downtime
• Assuming switching to on-demand is instant and free
• Reducing item size does not fix capacity limits

5. A startup expects unpredictable traffic spikes and wants to minimize cost during low usage while avoiding throttling during spikes. Which DynamoDB capacity mode should they choose and why?

hard

A. On-demand mode because it charges per request and scales instantly without manual setup.

B. Provisioned mode with auto scaling enabled to adjust capacity automatically.

C. Provisioned mode with fixed capacity to control costs strictly.

D. On-demand mode but with a fixed maximum request limit to save costs.

Solution

1. Step 1: Understand startup's needs

   They want to avoid throttling during spikes and save cost during low usage.

2. Step 2: Compare capacity modes for unpredictable traffic

   On-demand mode charges per request and auto scales instantly, ideal for unpredictable spikes.

3. Step 3: Evaluate other options

   Provisioned with auto scaling helps but requires setup and may lag; fixed capacity risks throttling or cost waste.

4. Final Answer:

   On-demand mode because it charges per request and scales instantly without manual setup. -> Option A

5. Quick Check:

   Unpredictable traffic = on-demand mode best [OK]

Hint: Unpredictable spikes? Choose on-demand for auto scaling [OK]

Common Mistakes:

• Choosing fixed provisioned capacity for unpredictable traffic
• Assuming auto scaling is instant and always perfect
• Thinking on-demand has fixed request limits