Skip to main content
Welcome. This lesson explains Amazon RDS availability options — the features and patterns that provide redundancy, resiliency, and high availability for managed relational databases. Consider an e-commerce site that handles product catalogs, orders, and user profiles. A robust, scalable, and highly available database is essential to maintain customer experience and business continuity.
A diagram titled "Relational Database Service (RDS)" showing users sending requests to an e-commerce website which reads and writes data to Amazon RDS. It also indicates managing user information and lists RDS attributes like robust, scalable, and reliable.
Amazon RDS is a managed service that eliminates much of the operational burden of running a relational database. With RDS you don’t manage the underlying hardware, the OS, or routine database maintenance tasks — RDS handles provisioning, patching, backups, and many operational tasks so you can focus on application logic.
A presentation slide titled "Relational Database Service (RDS)" showing a central managed database icon. Icons for Hardware, Software, and Human Resources are on the left and an Availability icon is on the right.
Key benefits of using Amazon RDS:
  • Fully managed provisioning, automated patching, backups, and maintenance.
  • Built-in scalability (compute and storage) and read-scaling via replicas.
  • Automated OS and database engine patching.
  • Multiple high-availability and disaster recovery strategies.
  • Durable storage backed by Amazon EBS with snapshotting to S3.
A slide titled "Why AWS RDS?" listing five benefits: Fully Managed Service, Scalability, Automatic OS Patching, High Availability and Disaster Recovery, and Storage Backed by EBS. Each benefit is shown in a rounded card with a colored circular icon and a number.
RDS supports multiple database engines: Amazon Aurora (MySQL- and PostgreSQL-compatible), MySQL, PostgreSQL, MariaDB, Oracle, and SQL Server. Aurora is a cloud-native engine designed for high performance and cloud scale and offers a storage layer that automatically grows to large sizes without manual intervention. RDS also offers storage auto-scaling for many engines so volumes can grow as your data grows. For example, RDS can automatically expand from 100 GB to 150 GB (or larger) when storage thresholds are reached, reducing operational intervention.
A diagram titled "Storage AutoScaling" showing Amazon RDS automatically increasing storage from 100GB to 150GB when a storage threshold is reached. It uses RDS icons and an arrow to illustrate the resize.
RDS integrates automated backups and manual snapshots stored on S3-backed storage. Snapshots let you restore copies of production for reporting, QA, or audits. You can also create read replicas from a production instance to offload read traffic or support reporting workloads. Core high-availability and redundancy strategies in RDS:
  • Multi‑AZ (synchronous standby with automatic failover)
  • Automated backups and snapshots (cold backups)
  • Read replicas (asynchronous, for read scaling and DR)
A slide titled "RDS HA Options" with three blue circular icons labeled Multi-AZ, Backups, and Read Replica. Each icon uses a simple stacked-database symbol to represent different high-availability strategies.
Multi‑AZ deployments
  • Multi‑AZ provides synchronous replication between a primary instance and a standby instance in a different Availability Zone (AZ).
  • Writes are acknowledged only after both primary and standby have the data, protecting against AZ failure and minimizing data loss.
  • Failover to the standby is automatic; clients continue connecting to the same endpoint while RDS redirects traffic to the new primary.
A diagram of an RDS Multi-AZ deployment. It shows a primary RDS instance in Availability Zone A reading/writing to a primary EBS and synchronously replicating to a standby RDS replica and EBS in Availability Zone B.
Read replicas and asynchronous replication
  • Read replicas are asynchronous copies of the primary and are ideal for scaling read-heavy workloads (reporting, analytics, storefront reads).
  • Replication can be within an AZ, across AZs, or cross-region. Because replication is asynchronous there can be replication lag — typically small but present.
  • Read replicas can be promoted to become a primary, but promotion is a manual or orchestrated action and may lead to data loss for in-flight transactions that hadn’t replicated yet.
A diagram of an RDS read-replica architecture showing a Master RDS and two Read Replicas in Region A. A client has read/write access to the master and read access to the replicas, with asynchronous replication arrows between them.
Synchronous replication (Multi‑AZ) maximizes durability and enables automatic failover. Asynchronous replicas prioritize read scalability and lower write latency but can exhibit replication lag and potential for lost in‑flight transactions if you promote a replica too soon.
Multi‑AZ patterns to know
  • Instance (standard) Multi‑AZ: One primary and one synchronous standby in a separate AZ. The standby is not directly accessible for reads; clients connect to the primary endpoint only.
  • Cluster Multi‑AZ (cluster deployments): Architectures with a writer endpoint and reader endpoints (common for Aurora and some cluster-based engines). These provide writer/read separation and can allow reader instances to serve traffic while still offering a resilient storage layer.
In cluster deployments the storage layer often provides synchronous durability across AZs while compute nodes can be scaled separately. In instance deployments, the standby is used exclusively for failover and is not a read endpoint. Cross‑region and cross‑AZ replication
  • Cross‑region read replicas are always asynchronous and are intended for geo‑distributed reads and disaster recovery (DR). Synchronous cross‑region replication would make writes prohibitively slow and is not offered.
  • You can combine Multi‑AZ for local high availability with cross‑region replicas for DR and geo‑distribution.
A network diagram titled "RDS for SQL Server – Cross-Region Read Replicas" showing a Primary DB instance in Region A with standby and in-region read replicas and an async cross-region read replica in Region B. Arrows indicate read/write access, always-on synchronous replication within the region, and distributed asynchronous replication across regions.
Summary of options and behaviors
  • Multi‑AZ standby replicas: synchronous replication for automatic failover and strong durability.
  • In‑region read replicas: asynchronous, used to scale reads within a region.
  • Cross‑region read replicas: asynchronous, used for geo‑distributed reads and disaster recovery.
  • Cluster deployments: provide separate writer and reader endpoints for workload separation and can combine high availability with read scalability.
  • Use automated backups, snapshots, and cross‑region replication strategies to build cold or warm backups and DR solutions.
A slide titled "Summary" listing five database replication and availability features. It mentions Multi‑AZ standby replicas, in‑region read replicas, cross‑region replicas for geo‑distributed reads and DR, combined synchronous/asynchronous replication, and separation of read/write vs read‑only traffic.
Quick decision guide Design considerations
  • Use Multi‑AZ for production databases where automatic failover and data durability are required.
  • Use read replicas to offload reads and to create reporting or analytics environments, keeping in mind asynchronous lag.
  • Use cluster deployments when you need separate writer and reader endpoints and want high read scalability.
  • Combine local synchronous Multi‑AZ and asynchronous cross‑region replicas for a layered DR strategy.
Avoid relying on asynchronous read replicas for workloads that require strict transactional consistency. If you need zero data loss, design with synchronous Multi‑AZ options and test failover behavior regularly.
Links and references Thanks for reading. A future article will dive deeper into resiliency patterns and include step‑by‑step configuration examples and failover demonstrations.

Watch Video