4.3 Database Cost Optimization

AWS Solutions Architect Associate SAA-C03

Track your progress as you read

Finished sections get a check mark.

1 Introduction

About the AWS Solutions Architect Associate (SAA-C03) Exam Study Strategies and Exam Tips for SAA-C03 The AWS Well-Architected Framework

2 Domain 1: Design Secure Architectures (30%)

1.1 IAM Fundamentals — Users, Groups, Roles, and Policies 1.2 AWS Organizations, SCPs, and Multi-Account Strategy 1.3 VPC Security — Security Groups, NACLs, and VPC Endpoints 1.4 Encryption, KMS, and Secrets Management 1.5 AWS WAF, Shield, and Network Firewall 1.6 GuardDuty, Inspector, Macie, and Security Hub 1.7 The Shared Responsibility Model for Solutions Architects 1.8 Data Protection, Compliance, and Audit Services

3 Domain 2: Design Resilient Architectures (26%)

2.1 Elastic Load Balancing (ELB) — ALB, NLB, and GWLB 2.2 EC2 Auto Scaling — Dynamic, Predictive, and Scheduled 2.3 Multi-AZ and Multi-Region Architectures 2.4 Disaster Recovery Strategies — RTO and RPO 2.5 Decoupling with SQS, SNS, and EventBridge 2.6 AWS Step Functions and Workflow Orchestration

4 Domain 3: Design High-Performing Architectures (24%)

3.1 EC2 Instance Types, Purchasing Options, and Placement Groups 3.2 Lambda, Serverless Compute, and Container Services 3.3 Amazon S3 - Storage Classes, Lifecycle, and Performance 3.4 Block and File Storage - EBS, EFS, and FSx 3.5 Database Services - RDS, Aurora, DynamoDB, and More 3.6 CloudFront, Route 53, and Global Accelerator 3.7 Data Ingestion and Transformation - Kinesis, Glue, and EMR

5 Domain 4: Design Cost-Optimized Architectures (20%)

4.1 Compute Cost Optimization — Right-Sizing, RIs, Savings Plans, and Spot 4.2 Storage Cost Optimization — S3 Tiers, EBS, and Data Transfer 4.3 Database Cost Optimization 4.4 AWS Cost Management and Monitoring Tools

6 VPC and Networking Deep Dive

5.1 VPC Architecture — Subnets, Route Tables, and Gateways 5.2 VPC Connectivity — Peering, Transit Gateway, and Direct Connect 5.3 Amazon API Gateway 5.4 CloudFormation and Infrastructure as Code 5.5 AWS PrivateLink and Endpoint Services

7 Migration, Transfer, and Hybrid Services

6.1 The 7 Rs of Cloud Migration 6.2 AWS Snow Family — Snowball Edge Devices 6.3 CloudWatch, CloudTrail, and AWS Config 6.4 Amazon Cognito and Identity Federation 6.5 AWS DataSync and Transfer Family

8 Serverless Architecture and Application Services

7.1 Serverless Architecture Patterns 7.2 Advanced SQS Patterns — DLQ, Backpressure, and FIFO 7.3 Analytics Services — Athena, OpenSearch, and QuickSight 7.4 Container Orchestration — ECS, EKS, and ECR

9 Advanced Topics and Exam Scenarios

8.1 Advanced IAM — Permission Boundaries, Federation, and Cross-Account 8.2 Caching Strategies and ElastiCache Patterns 8.3 Hybrid Architecture — DNS, Storage, and Compute 8.4 SAA-C03 Scenario Practice — Putting It All Together

4.3 Database Cost Optimization

Key Takeaways Explain This Topic AI

Aurora Serverless v2 bills per ACU-second and can now scale to 0 ACUs with automatic pause and resume — ideal for dev/test and intermittent workloads.

RDS Reserved Instances save up to ~69% (3-year) for steady-state production databases; Graviton instances add ~20% price-performance.

DynamoDB On-Demand bills per request for unpredictable traffic; Provisioned with auto-scaling (and Reserved Capacity, up to ~77% off) is cheaper when predictable.

Read replicas scale reads out onto cheaper instances and can let you downsize the primary; Aurora supports up to 15 replicas with auto load balancing.

ElastiCache and DynamoDB DAX cut expensive repeated reads, lowering required IOPS/RCU and letting you run a smaller, cheaper database.

Last updated: June 2026

RDS Cost Optimization

Right-size before committing. Use Performance Insights to find true CPU/memory/IO usage, CloudWatch for freeable memory and IOPS, and Compute Optimizer for recommendations. Switching to Graviton (arm64) RDS instances typically yields ~20% better price-performance with no schema change.

RDS pricing option Savings Commitment
On-Demand baseline none
Reserved, 1-year ~40% 1 year
Reserved, 3-year up to ~69% 3 years
Aurora Serverless v2 pay per ACU-second none

Read replicas scale reads horizontally onto smaller instances and offload the primary so you can sometimes downsize it. Aurora supports up to 15 read replicas with automatic load balancing via the reader endpoint. A stop/start schedule also zeroes compute charges for non-production RDS (a stopped instance still bills storage and auto-restarts after 7 days).

Aurora Serverless v2 — Now Scales to Zero

Aurora Serverless v2 measures capacity in Aurora Capacity Units (ACUs) — each ~2 GiB RAM plus CPU/network. It bills per ACU-second , scaling smoothly between a configured min and max. The minimum can be set as low as 0.5 ACU , and — since late 2024 — to 0 ACUs , where the instance automatically pauses after an inactivity window and resumes on the first new connection . While paused you pay nothing for compute (storage still bills).

Workload Provisioned Aurora Serverless v2
Dev/test, ~8 hr/day ~$730/mo (r6g.large 24/7) far less; pauses to 0 ACU off-hours
Variable, peaks 4x baseline ~$1,460/mo (sized for peak) ~$500/mo (scales dynamically)
Steady 24/7 high load ~$730/mo ~$800/mo (per-ACU overhead)

Key insight: Serverless v2 wins for variable or intermittent loads; for flat 24/7 load, a provisioned instance on a Reserved Instance is cheaper.

DynamoDB Cost Optimization

Mode Pricing (us-east-1) Best for
On-Demand $1.25/M writes, $0.25/M reads Spiky/unknown traffic
Provisioned $0.00065/WCU-hr, $0.00013/RCU-hr Steady, predictable
Provisioned + Reserved up to ~77% off provisioned Long-term steady

Save more with: TTL to auto-expire items free, DAX to cache hot reads and cut RCU, smaller item sizes, and GSI attribute projection limited to needed attributes. Enable Provisioned + auto-scaling for predictable traffic with daily peaks; switch to On-Demand when swings are extreme (e.g., 10 to 10,000 reads/sec).

Caching to Cut Database Cost

A cache layer reduces reads hitting the database, lowering required IOPS/RCU and letting you run a smaller instance, while improving latency.

Cache Pairs with Hit latency
ElastiCache (Redis/Valkey) any DB sub-millisecond
DynamoDB DAX DynamoDB only microseconds
CloudFront API/web responses edge milliseconds
API Gateway caching API responses milliseconds

On the Exam: "Read-heavy, reduce DB cost" → add ElastiCache or read replicas. "Variable/unpredictable DB load" → Aurora Serverless v2 or DynamoDB On-Demand. "DynamoDB microsecond reads" → DAX, not ElastiCache.

Worked Example: Scale Out Instead of Up

A reporting application runs on a single large RDS instance that is CPU-bound only because of heavy read traffic; writes are light. The instinctive fix — upsize the primary — doubles the cost of an instance that is mostly idle on writes. The cost-optimized answer is to scale reads out : add one or two read replicas on smaller instance classes, point analytics and dashboard queries at the replica endpoint, and then downsize the primary because it now handles only writes and OLTP.

With Aurora, the reader endpoint load-balances across up to 15 replicas automatically, so you add read throughput in cheap increments rather than buying one oversized primary. Layering ElastiCache in front for the hottest repeated queries cuts read volume further, which can let you shrink instances again — caching and replicas compound.

Worked Example: Part-Time and Scale-to-Zero Databases

Consider a dev/test database used only ~8 hours on weekdays. Three options compete. A Reserved Instance is wrong — it pays for a full year including the ~75% of hours the database is idle. RDS stop/start on a schedule works but needs automation and still bills storage, and RDS auto-restarts any instance stopped longer than 7 days. Aurora Serverless v2 with a 0-ACU minimum is the cleanest answer: it pauses automatically after the inactivity window, resumes on the first connection, and bills only storage while paused.

This scale-to-zero behavior (introduced late 2024) is the modern exam-correct response for intermittent or unpredictable database workloads where you want zero compute cost during idle periods without writing stop/start scripts. For a flat 24/7 production database, reverse the logic: a provisioned instance on a 3-year Reserved Instance beats Serverless v2, whose per-ACU pricing carries overhead at constant high load.

Database-Cost Trap Table

Tempting wrong answer Why it fails
Upsize primary to fix read load Pays for write capacity you don't need; replicas are cheaper
Reserved Instance for a part-time dev DB Bills a full year for an idle-most-of-the-time instance
Aurora Serverless v2 for flat 24/7 load Per-ACU overhead exceeds a Reserved provisioned instance
DynamoDB Provisioned fixed at peak Wastes capacity during lulls; On-Demand or auto-scaling fits
ElastiCache for DynamoDB microsecond cache DAX is the DynamoDB-native microsecond cache