SkarpChapter 23 of 26
Cost-Optimized Databases: Amazon RDS and Related Patterns
Database choices can quietly multiply costs; analyze RDS instance classes, storage types, and deployment models to avoid overpaying for capacity you do not need.
Big Picture: Database Cost Optimization on AWS
Why DB Cost Matters
Databases often run 24/7 and get oversized "just in case", so they can quietly become one of the most expensive parts of your AWS bill.
Link to Well-Architected
The Cost optimization pillar is "the continual process of refinement and improvement... to build and operate cost-aware systems that achieve business outcomes and minimize costs."
What You Will Learn
You will learn to choose RDS instance types and storage, decide on Multi-AZ and replicas, and compare RDS vs Aurora to meet requirements at minimum cost.
Connect to Previous Modules
Think of RDS like EC2 for compute and S3 for storage: instance families, sizes, and storage classes all change both performance and cost.
RDS Fundamentals and Cost Dimensions
What is Amazon RDS?
Amazon RDS is a managed relational database service for engines like MySQL, PostgreSQL, MariaDB, SQL Server, and Oracle, with AWS handling backups, patching, and basic operations.
Main Cost Dimensions
RDS costs come from instance hours, storage (GB and type), I/O or IOPS, backups and snapshots, and data transfer for replication and cross-AZ/region traffic.
Right-Sizing Focus
To optimize cost, you must right-size instances, avoid over-provisioned storage and IOPS, and choose the simplest availability model that still meets business needs.
Exam Signal Phrases
Phrases like "dev/test", "infrequently used", or "read-heavy analytics" are clues to choose cheaper patterns like smaller instances, fewer AZs, or read replicas.
Choosing RDS Instance Classes for Cost and Performance
Burstable (T) Classes
Burstable db.t* classes use CPU credits and are cheap for low-average workloads like dev/test or small apps, but can throttle under sustained high CPU.
General Purpose (M) Classes
db.m* classes balance compute and memory, making them a strong default for many production workloads needing predictable performance.
Memory Optimized (R) Classes
db.r* classes provide more RAM per vCPU, ideal for large in-memory datasets, heavy caching, and analytics, though they cost more per hour.
Cost Patterns and Traps
Start with the smallest suitable class, prefer Graviton where possible, and remember that a smaller instance plus read replicas can beat a huge single node in cost.
RDS Storage Types and How They Affect Cost
General Purpose SSD (gp3)
gp3 is the modern default: you set GB, IOPS, and throughput separately, getting flexible, good-enough performance at a reasonable price.
Provisioned IOPS (io1/io2)
io1/io2 let you provision high, fixed IOPS for very I/O-intensive, latency-sensitive workloads, but they cost more and must be sized carefully.
Legacy Magnetic
Magnetic and other previous-generation storage are low-cost, low-performance, generally used only for tiny, low-throughput dev/test in legacy setups.
Cost Tips and Traps
Use gp3 unless you have clear evidence you need io1/io2, avoid huge unused volumes, and remember that short write spikes do not always justify provisioned IOPS.
Worked Examples: Right-Sizing Instance and Storage
Scenario 1: Dev/Test Backend
Small team, light office-hours traffic, PostgreSQL. Choose db.t4g.small, 50 GB gp3, single-AZ, no replicas, and stop the DB out of hours.
Why Scenario 1 is Cheap
Burstable fits low average CPU, single-AZ is fine for non-critical use, and a small gp3 volume with modest IOPS keeps storage costs down.
Scenario 2: Small E-commerce
Production MySQL, steady load, must survive AZ failure, read-heavy. Choose db.m7g.large, 200 GB gp3, Multi-AZ, maybe one read replica.
Why Scenario 2 is Balanced
Multi-AZ is justified by uptime needs, gp3 avoids expensive io1, and starting with a single balanced instance avoids premature, costly complexity.
Multi-AZ, Read Replicas, and When They Are Worth the Cost
Multi-AZ Basics
Multi-AZ keeps a synchronous standby in another AZ and fails over automatically. It roughly doubles instance and storage cost but boosts availability.
Read Replica Basics
Read replicas use asynchronous replication to offload reads or serve other regions. Each replica is another instance+storage, sometimes plus data transfer.
When Multi-AZ is Worth It
Use Multi-AZ for critical production systems with strict SLAs or regulatory needs. It is usually overkill for dev/test or low-impact internal tools.
When Read Replicas are Worth It
Use read replicas for read-heavy workloads or reporting, often cheaper than a larger primary. Remember they are not a full HA replacement for Multi-AZ.
Scaling Strategies: Vertical, Horizontal, and Aurora
Vertical Scaling
Vertical scaling means changing the instance class/size. It is simple but limited by the largest instance and cost grows with size.
Horizontal Scaling
Horizontal scaling adds read replicas to spread read load and serve multiple regions, often cheaper than a single very large primary.
Aurora Option
Aurora offers auto-scaling storage and shared-volume replicas; Aurora Serverless v2 can scale capacity up and down automatically, billed per ACU.
Cost Trade-Offs
Standard RDS is often cheapest for small, stable workloads. Aurora can be cheaper at scale or with spiky demand due to better utilization.
Thought Exercise: Matching Requirements to RDS Patterns
Use this exercise to practice mapping business requirements to cost-optimized database designs. Do this mentally or jot down answers.
Requirement A
- Internal reporting dashboard
- Runs heavy queries once per night
- Data can be up to 24 hours stale
- Users are analysts, tolerant of occasional slow queries
Questions:
- Would you choose Multi-AZ? Why or why not?
- Would you use read replicas? If so, how?
- What instance family and storage type might you start with?
Requirement B
- Customer-facing mobile game backend
- Highly spiky traffic (evenings/weekends)
- Global user base, mostly read-heavy
- Outage during a regional event would be very costly
Questions:
- Would you favor standard RDS or Aurora? Why?
- How would you handle global reads cost-effectively?
- Which features are "nice but unnecessary" if you must cut cost?
After you answer, compare to these hints:
- For A: Think about single-AZ vs Multi-AZ, and whether a separate reporting replica is needed at all.
- For B: Think about automatic scaling, multi-region reads, and how much downtime is acceptable.
Quick Check: Instance and Storage Choices
Answer this exam-style question to check your understanding of RDS instance and storage selection.
A startup runs a small production web app on Amazon RDS for PostgreSQL. Traffic is steady but modest. CPU averages 10%, with occasional spikes during marketing campaigns. The team wants to minimize cost while keeping performance acceptable. Which configuration is the MOST cost-optimized starting point?
- db.r6g.xlarge with 1 TB io1 storage and 50,000 provisioned IOPS in a Multi-AZ deployment
- db.t4g.medium with 100 GB gp3 storage and default IOPS in a single-AZ deployment
- db.m7g.2xlarge with 500 GB gp3 storage and high provisioned IOPS in a Multi-AZ deployment
- db.t4g.medium with 100 GB magnetic storage in a Multi-AZ deployment
Show Answer
Answer: B) db.t4g.medium with 100 GB gp3 storage and default IOPS in a single-AZ deployment
Option B is correct: a burstable db.t4g.medium fits low average CPU with occasional spikes, gp3 is the modern general-purpose SSD, and single-AZ is acceptable for a small startup app that did not state strict availability requirements. Option A is heavily overprovisioned in both instance and storage. Option C oversizes the instance and IOPS and adds Multi-AZ. Option D uses Multi-AZ (extra cost) and magnetic storage, which is legacy and not recommended for production.
Quick Check: Multi-AZ vs Read Replicas
Test your understanding of when to use Multi-AZ vs read replicas for cost and availability.
You manage an RDS MySQL database for a news website. The site is read-heavy, with occasional writes for new articles and comments. Management wants to handle traffic spikes during major events at minimum cost, and can tolerate a few minutes of downtime if the primary AZ fails. What is the MOST cost-effective design?
- Single-AZ RDS instance with one or more read replicas to handle spikes
- Multi-AZ RDS deployment with no read replicas
- Multi-AZ RDS deployment with two read replicas in the same region
- Single-AZ RDS instance with synchronous replication to a second instance using custom scripts
Show Answer
Answer: A) Single-AZ RDS instance with one or more read replicas to handle spikes
Option A is correct: a single-AZ primary with read replicas handles read-heavy spikes cost-effectively, and the scenario allows some downtime if the AZ fails, so Multi-AZ is not required. Option B and C both add Multi-AZ, which roughly doubles instance and storage cost and is unnecessary given the tolerance for downtime. Option D uses a custom replication solution, which is complex, not managed by RDS, and not an exam best practice.
Key Term Review: RDS Cost Optimization
Flip these cards to reinforce core terms and patterns that often appear in exam questions.
- Cost optimization pillar
- The cost optimization pillar includes the continual process of refinement and improvement of a system over its entire lifecycle to build and operate cost-aware systems that achieve business outcomes and minimize costs.
- Burstable RDS instance class (T family)
- An RDS instance type that uses a CPU credit model, offering low baseline performance with the ability to burst. Ideal for dev/test and low-average-load workloads at low cost, but can throttle under sustained high CPU.
- General Purpose SSD (gp3) for RDS
- The current general-purpose SSD storage type where you provision storage size, IOPS, and throughput separately. Suitable for most workloads, with a good balance of price and performance.
- Provisioned IOPS SSD (io1/io2) for RDS
- High-performance SSD storage where you provision both capacity and a fixed IOPS level. Designed for I/O-intensive, latency-sensitive workloads, but more expensive and must be sized carefully.
- Multi-AZ RDS deployment
- An RDS configuration that maintains a synchronous standby in a different Availability Zone and can fail over automatically, roughly doubling instance and storage cost but improving availability.
- RDS read replica
- An asynchronously replicated copy of an RDS database used to offload read traffic or support cross-region reads and DR. Each replica incurs its own instance and storage costs.
- Vertical vs horizontal scaling in RDS
- Vertical scaling means changing the instance class/size (scale up/down). Horizontal scaling means adding read replicas to share read load or serve multiple regions.
- Amazon Aurora (cost perspective)
- A MySQL/PostgreSQL-compatible managed database with auto-scaling storage and shared-volume replicas. It may cost more per GB or I/O but can be cheaper at scale or with spiky workloads, especially with Aurora Serverless v2.
- When Multi-AZ is usually NOT justified
- For dev/test, low-impact internal tools, or systems where brief downtime is acceptable and SLAs are relaxed, single-AZ is usually more cost-effective than Multi-AZ.
- Exam clue: "read-heavy" workload
- Often suggests using read replicas or Aurora replicas instead of only scaling up the primary instance, to handle reads more cost-effectively.
Tying It Together: RDS and the Well-Architected Cost Lens
Beyond Cost Alone
RDS choices affect the Reliability and Performance efficiency pillars as well as cost. Multi-AZ and replicas raise reliability and performance but also raise the bill.
Exam Thinking Process
Underline availability, RPO/RTO, traffic patterns, and budget sensitivity. Start from the cheapest viable pattern and add cost only when requirements demand it.
Spotting Overkill
Look out for answer options that add Multi-AZ, large instances, or io1/io2 with no clear need. These are often distractors representing over-engineering.
Next Steps in This Course
Your next Skarp mock exam and gap guide will show if you tend to over- or under-provision RDS. Missed patterns will be reinforced in your spaced review queue.
Key Terms
- gp3
- General Purpose SSD storage type for RDS and other services where you provision capacity, IOPS, and throughput separately, offering a good balance of performance and cost.
- Amazon RDS
- A managed relational database service from AWS that supports engines like MySQL, PostgreSQL, MariaDB, SQL Server, and Oracle, handling tasks such as backups, patching, and basic operations.
- Read replica
- An asynchronously replicated copy of a primary RDS database used to offload read traffic or serve other regions, with its own instance and storage costs.
- Amazon Aurora
- A MySQL/PostgreSQL-compatible relational database engine designed for the cloud, offering auto-scaling storage, shared storage for replicas, and features like Aurora Serverless v2 for fine-grained capacity scaling.
- Vertical scaling
- Scaling strategy where you change the size or class of a single RDS instance (scale up or down) to adjust capacity.
- Horizontal scaling
- Scaling strategy where you add more RDS instances, typically as read replicas, to handle increased load or distribute traffic.
- RDS instance class
- A category of RDS instances (such as burstable T, general-purpose M, or memory-optimized R) that defines CPU, memory, and networking capabilities and strongly influences cost.
- Multi-AZ deployment
- An RDS configuration that maintains a synchronous standby instance in another Availability Zone for automatic failover, improving availability at the cost of extra instances and storage.
- Aurora Serverless v2
- An Aurora configuration that automatically scales database capacity up and down in fine-grained increments based on load, billing per Aurora Capacity Unit (ACU) to better match cost to demand.
- Provisioned IOPS (io1/io2)
- High-performance SSD storage option where you specify both storage capacity and a fixed number of IOPS, designed for I/O-intensive workloads and higher cost.