In the SAA-C03 exam, database cost optimization boils down to two principles: choose the right capacity mode for your workload pattern, and use caching to reduce the load on your database. Keeping an instance running at full capacity at all times is not always the best approach — matching your billing model to your actual usage patterns can yield significant savings.
What Is Aurora Serverless v2?
Why does it exist? Traditional databases charge you for the instance whether anyone is using it or not. For services with unpredictable or intermittent traffic, this means paying for a lot of idle time.
What is it? Think of an electricity meter. When you use a lot of power, the meter spins fast. When no one is home, it nearly stops. Aurora Serverless v2 works the same way. When traffic spikes, capacity automatically scales up. When things quiet down, capacity scales back down to near zero. You pay only for the computing capacity you actually consume.
How does it work? Capacity is measured in ACUs (Aurora Capacity Units). You set a minimum and maximum ACU. Aurora automatically adjusts within that range. Set the minimum to 0.5 ACU and idle time costs almost nothing.
When to use it: Development and testing environments that are idle at night and on weekends Small SaaS applications with low or variable user counts Report generation or event-driven services that occasionally receive large bursts of traffic
Provisioned Aurora vs Aurora Serverless v2
| Item | Provisioned Aurora | Aurora Serverless v2 | |------|--------------------|---------------------| | Billing | Instance size (hourly) | ACU usage (per second) | | Traffic Pattern | Predictable and stable | Intermittent or unpredictable | | Idle Cost | Always incurred | Near zero | | Auto-scaling | Manual configuration | Automatic |
Tip: If your traffic is stable and predictable, Provisioned Aurora with Reserved Instances will be cheaper than Serverless.
!Provisioned Aurora versus Aurora Serverless v2
DynamoDB Capacity Modes
Why do they exist? DynamoDB costs scale directly with the number of read and write requests. Knowing your traffic pattern lets you choose the billing model that minimizes your bill.
What are they? DynamoDB offers two capacity modes.
Provisioned Capacity: You set the number of Read Capacity Units (RCU) and Write Capacity Units (WCU) in advance. Like choosing a monthly internet plan — you commit to "100 GB per month." Best for stable, predictable traffic. Pair with Auto Scaling to handle traffic variations automatically while keeping costs low. Purchase Reserved Capacity for up to 76% discount.
On-Demand Capacity: You pay per request, based on actual traffic. Like a pay-as-you-go data plan — you pay exactly for what you use. Best for unpredictable traffic or new services where you have not yet established usage patterns. No capacity planning required, but the per-request price is higher than Provisioned.
| Mode | Best For | Unit Price | Cost Predictability | |------|----------|-----------|---------------------| | Provisioned + Reserved | Stable, predictable traffic | Low | Easy | | Provisioned + Auto Scaling | Variable but foreseeable traffic | Low to medium | Medium | | On-Demand | Irregular, intermittent traffic | High | Difficult |
Reducing Database Costs with Caching
Why does it exist? Database costs scale with the number of read and write requests. Re-fetching the same data from the database repeatedly is wasteful. Storing frequently-read data in a fast cache reduces database requests — and therefore database costs.
Imagine an ice cream shop. Every time a customer asks "What is today's popular flavor?", the counter staff walks to the back room to check inventory. That is slow and tiring. But if there is a chalkboard at the counter saying "Today's pick: chocolate," the staff can answer immediately without going to the back. That chalkboard is your cache.
ElastiCache for Redis
What is it? A high-performance, in-memory data store. Frequently-queried database results are stored in memory. When the same request comes in again, Redis responds instantly from cache instead of hitting the database.
When to use it: Session management (keeping users logged in) Caching results of complex queries Real-time leaderboards and counters High-availability environments requiring replication and cluster support
ElastiCache for Memcached
What is it? A simple key-value cache. Less feature-rich than Redis, but its multi-threaded architecture delivers high throughput for simple caching use cases.
When to use it: Simple object caching High-throughput environments that need multi-threaded processing When replication or data persistence is not required
DynamoDB DAX (DynamoDB Accelerator)
Why does it exist? When you are using DynamoDB but read costs are high or response times are slow, you can add a caching layer with minimal code changes.
What is it? An in-memory cache that sits transparently in front of DynamoDB. Your application calls the DAX endpoint. On a cache hit, DAX responds immediately. On a cache miss, DAX queries DynamoDB, caches the result, and returns it to the caller.
Key characteristics: DynamoDB-only — cannot be used with other databases Minimal code change (swap the endpoint URL) Microsecond response times (vs DynamoDB's millisecond)
RDS Cost Optimization
Beyond caching, you can also optimize RDS itself.
Instance right-sizing: Use AWS Compute Optimizer to review actual CPU and memory utilization of your RDS instances A db.r5.xlarge running at 20% CPU can likely be downsized to db.r5.large
Reserved Instances: 1-year term: up to 40% discount 3-year term: up to 60% discount RDS is often a long-running stable workload, making Reserved Instances very effective
Multi-AZ review: Multi-AZ keeps an automatic standby instance at all times for high availability, which roughly doubles the cost Development and test environments rarely need high availability, so switching to Single-AZ cuts the cost in half
Combining Read Replicas with caching: Instead of running multiple Read Replicas, introducing a caching layer (ElastiCache) can reduce the number of Read Replicas needed — double savings
Exam Key Points
"Intermittent or unpredictable DB traffic, minimize idle cost" -- Aurora Serverless v2
"Like an electricity meter — pay only for what you consume" -- Core characteristic of Aurora Serverless
"Stable DynamoDB traffic, lowest possible cost" -- Provisioned Capacity + Reserved Capacity
"Irregular DynamoDB traffic, no need for capacity planning" -- On-Demand mode
"Reduce DB read load with a caching layer" -- ElastiCache (Redis or Memcached)
"DynamoDB-only cache, minimal code changes" -- DAX
"Redis vs Memcached: need replication or sessions" -- Redis / "simple key-value, multi-threaded" -- Memcached
"Reduce DB costs in development environments" -- Single-AZ RDS (no need for Multi-AZ)
"Right-size your RDS instance" -- AWS Compute Optimizer
Adding a cache can reduce the number of Read Replicas, delivering double cost savings