AWS Certified Cloud Practitioner / Databases & Analytics

RDS Deployments Options

🏗️ RDS Deployment Architectures

RDS offers different architectures for performance, high availability, and disaster recovery.

💡 There's no single "best" architecture — it depends on your app's requirements.

📚 The Three Architectures

  • 📖 Read Replicas — improve read performance

  • 🌍 Multi-AZ — improve high availability

  • 🌎 Multi-Region Read Replicas — improve global performance & disaster recovery

📖 1. Amazon RDS Read Replicas

As your app grows, thousands of users browse, search, and view reports — all read operations. Eventually the primary database struggles to keep up.

💡 A Read Replica is a copy of your primary database dedicated to handling reads, spreading the load instead of hitting one database every time.

🏗️ How It Works

  • 📖 Reads — can come from the primary or any Read Replica

  • ✍️ Writes — always go to the primary; replicas auto-sync from it and can't be written to directly

🚀 Benefits

  • Improves read performance

  • Distributes read traffic

  • Reduces load on the primary

  • Supports up to 15 Read Replicas

📌 Use When

Read-heavy traffic — many users browsing, dashboards, reports, high-traffic storefronts.

🎯 Exam tip: "Improve read performance" / "scale read traffic" → Read Replicas

🌍 2. Amazon RDS Multi-AZ Deployment

Read Replicas fix performance. Multi-AZ fixes availability.

If hardware fails, an AZ has an outage, or there's a network issue, your app goes down without a backup database — that's what Multi-AZ solves.

💡 A Multi-AZ deployment keeps a standby copy of your primary DB in a different AZ, continuously synced but idle until needed.

🚨 On Failure

AWS automatically fails over — the standby becomes primary, and your app reconnects with minimal disruption. Fully managed by AWS.

⚠️ The standby is idle during normal operation — all reads and writes go to the primary. It only activates on failover.

🚀 Benefits

High availability, automatic failover, better fault tolerance, improved disaster recovery within a Region.

📌 Key Points

  • Only one standby per deployment

  • Standby lives in a different AZ

  • Apps can't connect to the standby directly

  • Failover is fully automatic

🎯 Exam tip: "High availability" / "automatic failover" / "AZ outage" → Multi-AZ

🌎 3. Amazon RDS Multi-Region Read Replicas

Global users mean latency — a database in one Region is slow for users on the other side of the world. Multi-Region Read Replicas fix this by placing replicas closer to users.

Example:

  • Primary → Mumbai (ap-south-1)

  • Replica → Hyderabad (ap-south-2)

  • Replica → N. Virginia (us-east-1)

🌍 Why Use It

  • 🚀 Better performance — users read from the nearest replica, cutting latency

  • 🛡️ Disaster recovery — a Region-wide outage still leaves copies elsewhere

⚠️ Reads are local, but writes always travel back to the primary Region.

💰 Cross-Region replication adds network transfer costs — Multi-Region setups cost more than single-Region ones.

🎯 Exam tip: "Global users" / "lower cross-Region latency" / "Region-level disaster recovery" → Multi-Region Read Replicas

📊 Quick Comparison

Feature

📖 Read Replica

🌍 Multi-AZ

🌎 Multi-Region

Purpose

Read performance

High availability

Global performance + DR

Handles reads?

✅

❌

✅

Handles writes?

❌

❌

❌

Writes go to

Primary

Primary

Primary

Auto failover?

❌

✅

❌

Different AZ?

Optional

✅

N/A

Different Region?

❌

❌

✅

Max replicas

Up to 15

1 standby

Varies

🎯 Exam Tips Recap

  • 📖 Read Replicas scale read workloads

  • ✍️ Writes always go to the primary, even with replicas in play

  • 🌍 Multi-AZ = high availability via a standby in another AZ

  • 🔄 AZ failure → AWS auto-fails-over to standby

  • 🌎 Multi-Region Read Replicas = global performance + disaster recovery

  • 💰 Cross-Region replication costs more than single-Region setups