While preparing for the AWS SAP-C02, many candidates get confused by DynamoDB billing models. In the real world, this is fundamentally a decision about predictable capacity planning vs. operational flexibility vs. TCO optimization. Let’s drill into a simulated scenario.
The Scenario #
GreenLeaf Analytics, a SaaS provider for supply chain analytics, recently deployed their core analytics engine on AWS using Amazon DynamoDB as the primary data store. The engineering team has completed a 6-week performance baseline and identified the following workload characteristics:
- Average baseline load: 500 WCU / 200 RCU continuously
- Weekly peak load: Every Sunday 2 PM - 6 PM (4 hours), load doubles to 1000 WCU / 400 RCU
- Access pattern: Write-heavy operations (80% writes, 20% reads) due to real-time inventory event ingestion
- Predictability: Peak timing is highly consistent and business-critical
The CFO has mandated a minimum 30% cost reduction on the DynamoDB spend without impacting performance during peak windows.
Key Requirements #
Implement a solution that minimizes DynamoDB table costs while maintaining performance SLAs during predictable weekly peak loads.
The Options #
- A) Implement AWS Application Auto Scaling to increase capacity during peak periods; purchase Reserved Capacity (RCU and WCU) matching average baseline load.
- B) Configure the table to use On-Demand capacity mode.
- C) Deploy DynamoDB Accelerator (DAX) in front of the table; reduce provisioned read capacity to match the new peak load after caching.
- D) Deploy DynamoDB Accelerator (DAX) in front of the table; configure the table to use On-Demand capacity mode.
Correct Answer #
Option A.
Quick Insight: The FinOps Imperative #
This scenario tests your ability to quantify the cost difference between DynamoDB billing models. The key decision factor is workload predictability. With a consistent 4-hour weekly peak that is only 2x baseline, Reserved Capacity + Auto Scaling delivers 40-60% savings compared to On-Demand pricing. DAX (Options C/D) is a read optimization tool—useless for a write-heavy workload.
💎 The Architect’s Deep Dive: Why Options Fail #
Correct Answer #
Option A — Implement AWS Application Auto Scaling to increase capacity during peak periods; purchase Reserved Capacity (RCU and WCU) matching average baseline load.
Step-by-Step Winning Logic #
This solution represents the optimal FinOps strategy for predictable, cyclical workload patterns:
-
Reserved Capacity for Baseline (500 WCU / 200 RCU)
- Delivers ~53% cost savings vs. on-demand provisioned capacity
- Commitment: 1-year term, paid upfront or monthly
- Covers the 164 hours/week (98% of time) at average load
-
Application Auto Scaling for Peak (scale to 1000 WCU / 400 RCU)
- Automatically adds 500 WCU / 200 RCU during Sunday 2-6 PM window
- Charged at standard provisioned rates (not Reserved) for 4 hours/week
- Total peak exposure: 16 hours/month at on-demand provisioned pricing
-
Cost Breakdown (Monthly Estimate - us-east-1):
- Reserved WCU (500): ~$130/month (vs. $292 on-demand)
- Reserved RCU (200): ~$13/month (vs. $26 on-demand)
- Auto-scaled capacity (16 hours): ~$24/month
- Total: ~$167/month vs. ~$318 for full on-demand provisioned = 47% savings
-
Why This Beats On-Demand Mode (Option B):
- On-Demand charges $1.25 per million WRU (vs. $0.25 per million for provisioned WCU equivalent)
- 5x cost multiplier is only justified for unpredictable workloads
- GreenLeaf’s workload is highly predictable = waste of capital
The Traps (Distractor Analysis) #
-
Why not Option B (On-Demand)?
On-Demand mode costs 5x more per write request unit. This is designed for unpredictable workloads or new applications without baseline data. With 6 weeks of metrics showing consistent patterns, you’re burning budget for operational convenience you don’t need. For write-heavy workloads at scale, this can cost $800-1200/month vs. $167 with Option A. -
Why not Option C (DAX + Reduced Read Capacity)?
DAX is a read cache—it does nothing for write operations. The scenario explicitly states “writes far exceed reads” (80/20 split). Even if you cache 100% of reads, you’re only optimizing 20% of the workload. Moreover, DAX cluster costs ($0.30-0.68/hour for cache.t3.small) add $220-500/month, completely negating any RCU savings. This is a solution looking for a problem. -
Why not Option D (DAX + On-Demand)?
Combines the worst of both worlds: DAX operational overhead + On-Demand’s 5x cost premium. Unless you have microsecond read latency SLAs (not mentioned), this is architectural over-engineering with negative ROI.
The Architect Blueprint #
graph TD
A[GreenLeaf Analytics App] -->|Writes 80%| B[DynamoDB Table]
A -->|Reads 20%| B
B -->|Baseline 500 WCU/200 RCU| C[Reserved Capacity Pricing]
B -->|Peak Detection| D[CloudWatch Metrics]
D -->|Target Utilization 70%| E[Application Auto Scaling]
E -->|Sunday 2-6 PM| F[Scale to 1000 WCU/400 RCU]
F -->|Peak Period Only| G[On-Demand Provisioned Pricing]
style C fill:#2ecc71,stroke:#27ae60,color:#fff
style E fill:#3498db,stroke:#2980b9,color:#fff
style G fill:#e67e22,stroke:#d35400,color:#fff
Diagram Note: Reserved Capacity handles baseline load with maximum discount; Auto Scaling triggers during predictable Sunday peaks, incurring standard provisioned pricing only for the 4-hour window.
The Decision Matrix #
| Option | Est. Complexity | Est. Monthly Cost | Pros | Cons |
|---|---|---|---|---|
| A) Reserved + Auto Scaling | Medium (Requires Auto Scaling policy setup) | $167 (Reserved: $143, Peak: $24) | • 47% cost savings • Performance guaranteed • Predictable billing |
• Requires 1-year commitment • 15 min setup for scaling policies |
| B) On-Demand | Low (Zero configuration) | $850-1200 (Pay-per-request at 5x rate) | • Zero capacity planning • Instant elasticity |
• 5x cost premium for writes • Unpredictable monthly bills • No volume discounts |
| C) DAX + Reduced RCU | High (DAX cluster management) | $340-620 (DAX: $220-500, DDB: $120) | • Sub-millisecond reads (if needed) | • Solves wrong problem (workload is write-heavy) • Adds operational overhead • Higher TCO than Option A |
| D) DAX + On-Demand | High | $1100-1700 (DAX + On-Demand premium) | • Maximum flexibility + caching | • Worst TCO • Architectural over-engineering • No business justification |
FinOps Insight: Option A delivers the lowest TCO while maintaining operational simplicity. The 1-year Reserved Capacity commitment is low-risk given 6 weeks of stable baseline metrics.
Real-World Practitioner Insight #
Exam Rule #
For the AWS SAP-C02 exam, always choose Reserved Capacity + Auto Scaling when you see:
- Predictable workload patterns (daily, weekly cycles)
- Write-heavy operations (eliminates DAX as a solution)
- Cost optimization as the primary requirement
DAX is ONLY the answer when:
- Scenario mentions “microsecond read latency” requirements
- Read-heavy workloads (e.g., product catalogs, session stores)
Real World #
In reality, I would implement Option A but with these production safeguards:
- Start with 3-month Reserved Capacity (not 1-year) for the first commitment cycle—validates cost model before locking in longer terms
- Set up CloudWatch Alarms for throttling events (consumed capacity > 80%) to catch unexpected load spikes
- Enable DynamoDB Contributor Insights to identify if specific partition keys are causing hot partitions during peaks
- Implement cost anomaly detection in AWS Cost Explorer to alert if On-Demand charges exceed $50/month (signals Auto Scaling misconfiguration)
- Consider Savings Plans instead of Reserved Capacity if the organization has multiple DynamoDB tables—provides more flexibility across workloads
The hidden gotcha: If Sunday peak traffic grows beyond 2x baseline (e.g., Black Friday-style surge), Auto Scaling has a warm-up period of 2-5 minutes. For truly mission-critical workloads, I’d provision Reserved Capacity at 1.5x baseline (750 WCU) and only auto-scale the remaining 250 WCU to reduce scale-out latency.