Bird
Raised Fist0
DynamoDBquery~30 mins

On-demand vs provisioned cost comparison in DynamoDB - Hands-On Comparison

Choose your learning style10 modes available
On-demand vs Provisioned Cost Comparison in DynamoDB
📖 Scenario: You are managing a DynamoDB table for a small online store. You want to compare the monthly costs between using on-demand capacity mode and provisioned capacity mode based on your expected read and write requests.
🎯 Goal: Build a simple DynamoDB cost comparison by creating a data structure for request counts, setting capacity units, calculating costs for both on-demand and provisioned modes, and then outputting the cost comparison.
📋 What You'll Learn
Create a dictionary called monthly_requests with exact keys 'read' and 'write' and values 1000000 and 500000 respectively
Create variables read_capacity_units and write_capacity_units with values 50 and 25 respectively
Calculate provisioned_cost using the formula: (read_capacity_units * 0.00013 + write_capacity_units * 0.00065) * 730
Calculate on_demand_cost using the formula: (monthly_requests['read'] * 0.25 / 1000000 + monthly_requests['write'] * 1.25 / 1000000)
Create a dictionary called cost_comparison with keys 'provisioned' and 'on_demand' and their respective cost values
💡 Why This Matters
🌍 Real World
This project helps you understand how to estimate and compare costs for different DynamoDB capacity modes, which is important for budgeting and optimizing cloud expenses.
💼 Career
Database administrators and cloud engineers often need to analyze cost trade-offs between on-demand and provisioned capacity to make informed decisions for scalable and cost-efficient database management.
Progress0 / 4 steps
1
Create monthly request counts
Create a dictionary called monthly_requests with keys 'read' and 'write' and values 1000000 and 500000 respectively.
DynamoDB
Hint

Use curly braces to create a dictionary with the exact keys and values.

2
Set provisioned capacity units
Create two variables called read_capacity_units and write_capacity_units and set them to 50 and 25 respectively.
DynamoDB
Hint

Assign the numbers 50 and 25 to the variables exactly as named.

3
Calculate provisioned and on-demand costs
Calculate provisioned_cost using the formula (read_capacity_units * 0.00013 + write_capacity_units * 0.00065) * 730 and calculate on_demand_cost using the formula (monthly_requests['read'] * 0.25 / 1000000 + monthly_requests['write'] * 1.25 / 1000000).
DynamoDB
Hint

Use the exact variable names and formulas given to calculate costs.

4
Create cost comparison dictionary
Create a dictionary called cost_comparison with keys 'provisioned' and 'on_demand' and assign the variables provisioned_cost and on_demand_cost as their values.
DynamoDB
Hint

Use curly braces to create the dictionary with the exact keys and assign the cost variables as values.

Practice

(1/5)
1. Which DynamoDB billing mode charges you only for the read and write requests you actually use, without any upfront capacity planning?
easy
A. Provisioned mode
B. Reserved mode
C. On-demand mode
D. Manual mode

Solution

  1. Step 1: Understand billing modes in DynamoDB

    DynamoDB offers two main billing modes: on-demand and provisioned. On-demand charges per request without pre-allocating capacity.
  2. Step 2: Identify the mode with no upfront capacity planning

    On-demand mode does not require capacity planning and bills you based on actual usage.
  3. Final Answer:

    On-demand mode -> Option C
  4. Quick Check:

    On-demand charges per request = On-demand mode [OK]
Hint: On-demand means pay per request, no setup needed [OK]
Common Mistakes:
  • Confusing provisioned mode as pay-per-request
  • Thinking reserved mode exists in DynamoDB billing
  • Assuming manual mode is a billing option
2. Which of the following is the correct way to specify provisioned capacity in a DynamoDB table creation command?
easy
A. ProvisionedThroughput: { ReadCapacityUnits: 5, WriteCapacityUnits: 5 }
B. BillingMode: 'ON_DEMAND'
C. CapacityUnits: { Read: 5, Write: 5 }
D. Throughput: { Read: 5, Write: 5 }

Solution

  1. Step 1: Recall DynamoDB table creation syntax for provisioned mode

    Provisioned mode requires specifying ProvisionedThroughput with ReadCapacityUnits and WriteCapacityUnits.
  2. Step 2: Match the correct syntax

    ProvisionedThroughput: { ReadCapacityUnits: 5, WriteCapacityUnits: 5 } uses the exact correct keys: ProvisionedThroughput with ReadCapacityUnits and WriteCapacityUnits.
  3. Final Answer:

    ProvisionedThroughput: { ReadCapacityUnits: 5, WriteCapacityUnits: 5 } -> Option A
  4. Quick Check:

    Provisioned capacity uses ProvisionedThroughput [OK]
Hint: Provisioned capacity uses ProvisionedThroughput keys [OK]
Common Mistakes:
  • Using BillingMode for provisioned capacity
  • Incorrect key names like CapacityUnits or Throughput
  • Confusing ON_DEMAND with provisioned syntax
3. Consider a DynamoDB table with provisioned capacity of 10 read units and 5 write units. If your application performs 8 strongly consistent reads and 3 writes per second, which billing mode will likely cost less?
medium
A. Cannot determine without data size
B. On-demand mode
C. Both cost the same
D. Provisioned mode

Solution

  1. Step 1: Analyze usage vs provisioned capacity

    The app uses 8 reads and 3 writes per second, which is below the provisioned 10 reads and 5 writes capacity.
  2. Step 2: Compare cost implications

    Provisioned mode charges fixed capacity regardless of usage, so if usage is steady and below provisioned, it is cheaper than on-demand which charges per request.
  3. Final Answer:

    Provisioned mode -> Option D
  4. Quick Check:

    Steady low usage < provisioned = Provisioned cheaper [OK]
Hint: If usage steady and below capacity, provisioned is cheaper [OK]
Common Mistakes:
  • Assuming on-demand is always cheaper
  • Ignoring provisioned capacity limits
  • Thinking cost depends only on data size
4. You set a DynamoDB table to provisioned mode with 5 read and 5 write capacity units, but your app suddenly needs 20 reads per second. What is the likely problem and how to fix it?
medium
A. Provisioned capacity too low; increase capacity or switch to on-demand
B. On-demand mode is enabled; switch to provisioned mode
C. Table is in on-demand mode; reduce read requests
D. Provisioned capacity too high; reduce capacity units

Solution

  1. Step 1: Identify the mismatch between capacity and usage

    The app needs 20 reads per second but provisioned capacity is only 5 reads, causing throttling.
  2. Step 2: Determine the fix

    To fix, increase provisioned capacity or switch to on-demand mode which scales automatically.
  3. Final Answer:

    Provisioned capacity too low; increase capacity or switch to on-demand -> Option A
  4. Quick Check:

    Low provisioned capacity causes throttling; increase or switch [OK]
Hint: If usage > provisioned, increase capacity or use on-demand [OK]
Common Mistakes:
  • Confusing on-demand and provisioned modes
  • Reducing capacity when usage is high
  • Ignoring throttling symptoms
5. A startup expects unpredictable traffic spikes but wants to control costs. They plan to use DynamoDB. Which billing strategy best balances cost and flexibility?
hard
A. Use provisioned mode with high capacity to handle spikes
B. Use provisioned mode with low capacity and enable auto scaling
C. Use on-demand mode but limit requests manually
D. Use on-demand mode to pay only for actual requests

Solution

  1. Step 1: Understand startup needs

    They want to handle unpredictable spikes but also control costs.
  2. Step 2: Evaluate billing options

    Provisioned mode with auto scaling adjusts capacity automatically, balancing cost and flexibility better than fixed provisioned or pure on-demand.
  3. Step 3: Compare with other options

    High fixed provisioned is costly; on-demand can be expensive at scale; manual limits reduce flexibility.
  4. Final Answer:

    Use provisioned mode with low capacity and enable auto scaling -> Option B
  5. Quick Check:

    Auto scaling balances cost and spikes well [OK]
Hint: Auto scaling provisioned mode balances cost and spikes [OK]
Common Mistakes:
  • Choosing high fixed provisioned capacity unnecessarily
  • Assuming on-demand always cheaper for spikes
  • Trying to limit requests manually in on-demand mode
Recommended

Ready to prove it?

Pass the test and this pattern moves unknown strong while earning +1 Grip toward your certificate.

10 questions~5 mineasy hard