Table capacity modes decide how you pay for and handle the speed of your database. They help you manage costs and performance easily.
Table capacity modes (on-demand vs provisioned) in DynamoDB
Start learning this pattern below
Jump into concepts and practice - no test required
CreateTable {
TableName: string,
BillingMode: 'PROVISIONED' | 'PAY_PER_REQUEST',
ProvisionedThroughput?: {
ReadCapacityUnits: number,
WriteCapacityUnits: number
}
}BillingMode can be PROVISIONED or PAY_PER_REQUEST (on-demand).
If you choose PROVISIONED, you must specify ProvisionedThroughput.
CreateTable {
TableName: 'Users',
BillingMode: 'PAY_PER_REQUEST'
}CreateTable {
TableName: 'Orders',
BillingMode: 'PROVISIONED',
ProvisionedThroughput: {
ReadCapacityUnits: 5,
WriteCapacityUnits: 5
}
}This command creates a DynamoDB table named ExampleTable using the on-demand capacity mode. You don't need to set read or write capacity units.
aws dynamodb create-table \ --table-name ExampleTable \ --attribute-definitions AttributeName=Id,AttributeType=S \ --key-schema AttributeName=Id,KeyType=HASH \ --billing-mode PAY_PER_REQUEST
On-demand mode is great for unpredictable workloads but can cost more if traffic is steady and high.
Provisioned mode lets you save money with steady traffic but requires you to guess capacity needs.
You can switch between modes later if your needs change.
Table capacity modes control how you pay and handle traffic in DynamoDB.
On-demand mode charges per request and adjusts automatically.
Provisioned mode requires setting fixed read/write capacity but can save money for steady use.
Practice
Solution
Step 1: Understand capacity modes in DynamoDB
DynamoDB offers two main capacity modes: on-demand and provisioned. On-demand mode automatically adjusts capacity based on traffic.Step 2: Identify the mode that adjusts automatically
On-demand mode charges per request and scales automatically without manual settings, unlike provisioned mode which requires fixed capacity.Final Answer:
On-demand mode -> Option AQuick Check:
Automatic scaling = On-demand mode [OK]
- Confusing provisioned mode as automatic
- Thinking reserved or manual modes exist
- Assuming manual capacity adjustment is automatic
Solution
Step 1: Recall AWS CLI syntax for provisioned capacity
Provisioned mode requires specifying read and write capacity units using --provisioned-throughput with ReadCapacityUnits and WriteCapacityUnits.Step 2: Match correct syntax option
--provisioned-throughput ReadCapacityUnits=5,WriteCapacityUnits=5 uses the correct syntax. The --billing-mode PAY_PER_REQUEST and --capacity-mode ON_DEMAND options specify on-demand mode, while --read-write-capacity is invalid.Final Answer:
--provisioned-throughput ReadCapacityUnits=5,WriteCapacityUnits=5 -> Option BQuick Check:
Provisioned throughput syntax = --provisioned-throughput ReadCapacityUnits=5,WriteCapacityUnits=5 [OK]
- Using PAY_PER_REQUEST flag for provisioned mode
- Confusing capacity mode flags
- Using invalid flags like --read-write-capacity
Solution
Step 1: Understand provisioned capacity limits
Provisioned mode sets fixed read/write capacity units. Here, 5 read units allow about 5 strongly consistent reads per second.Step 2: Analyze traffic exceeding capacity
Sending 20 read requests exceeds the provisioned 5 units. DynamoDB throttles excess requests instead of automatically scaling or switching modes.Final Answer:
Some read requests may be throttled due to exceeding capacity -> Option CQuick Check:
Exceeding provisioned units causes throttling [OK]
- Assuming automatic scaling in provisioned mode
- Thinking all requests always succeed
- Believing table switches modes automatically
aws dynamodb create-table --table-name MyTable --billing-mode PROVISIONED
But you forgot to specify provisioned throughput. What will happen?
Solution
Step 1: Check requirements for provisioned mode
Provisioned mode requires specifying ReadCapacityUnits and WriteCapacityUnits explicitly during table creation.Step 2: Understand AWS CLI behavior on missing parameters
Omitting provisioned throughput causes AWS CLI to return an error because required parameters are missing.Final Answer:
Table creation fails with an error about missing provisioned throughput -> Option DQuick Check:
Missing provisioned throughput causes creation error [OK]
- Assuming default capacity is assigned
- Thinking table switches to on-demand mode
- Believing capacity is unlimited without settings
Solution
Step 1: Analyze startup traffic pattern
Unpredictable spikes mean traffic varies a lot, so automatic scaling is important to avoid throttling or overpaying.Step 2: Evaluate capacity mode options for cost and performance
On-demand mode charges per request and scales automatically, ideal for unpredictable traffic and cost control. Provisioned mode requires manual adjustments and risks throttling or wasted capacity.Final Answer:
Use on-demand mode to automatically handle spikes and pay per request -> Option AQuick Check:
Unpredictable traffic = On-demand mode best [OK]
- Choosing high provisioned capacity wastes money
- Manually adjusting capacity is slow and error-prone
- Switching modes daily is not supported
