What Is Amazon RDS? Multi-AZ, Read Replicas and Backups

Amazon RDS is AWS's managed service for running relational databases in the cloud. AWS operates the underlying database infrastructure and handles tasks such as patching, backups and failure recovery, while you choose the engine and configure how your application uses it.

This guide explains RDS engines, instances and storage, then separates the problems solved by Multi-AZ, read replicas, backups and RDS Proxy. It also covers Aurora, customer examples, companion services and pricing, before working through the distinctions tested by AWS certification practice questions. The whiteboard video at the end draws these parts together.

What is Amazon RDS?

Amazon Relational Database Service lets you use a relational database without installing and maintaining the database host yourself. Your application still works with a database engine, tables and SQL. The managed service takes care of much of the operational work around that engine, as described in the RDS overview.

The six engines covered by the RDS User Guide are IBM Db2, MariaDB, Microsoft SQL Server, MySQL, Oracle Database and PostgreSQL. Amazon Aurora is a related, separately documented engine family compatible with MySQL and PostgreSQL. Keep that distinction in mind when a question names a particular deployment type or engine.

Instances, classes and storage

A DB instance is an isolated database environment, and it can contain multiple databases. The instance class determines its type and size: db.m7g.2xlarge is an example. Families include db.m for general purpose, db.r for memory optimized and db.t for burstable workloads; you can change the class later to scale up.

RDS storage is backed by Amazon EBS. AWS recommends gp3 for General Purpose SSD storage and io2 Block Express for Provisioned IOPS SSD storage, with the latter supporting up to 256,000 IOPS for demanding workloads. The storage documentation explains the options; deprecated magnetic storage should not be a new deployment choice.

Instance capacity, storage capacity and read capacity are separate decisions. A larger class changes the resources available to the instance, storage autoscaling adds disk space, and read replicas provide somewhere else to send reads. Diagnose which resource is under pressure before choosing a scaling feature.

What AWS manages and what you manage

With a database you operate on EC2, you install and patch the operating system and database software and build the backup and availability arrangements. RDS provides managed mechanisms for those tasks, including failure detection and recovery. You still choose the configuration, such as whether to deploy Multi-AZ and how long to retain backups.

Your application remains your responsibility: the schema, queries and query tuning do not move to AWS. You also decide which clients can connect and what database access they receive. Moving a poorly tuned workload to RDS does not remove the need to understand its queries.

Standard RDS does not give you SSH or Telnet access to the underlying host. Engine settings are managed through parameter groups, with defaults available and custom groups for your own settings. If host administration is a requirement, recognize that standard RDS has this boundary; RDS Custom for SQL Server is a separate option with more administrative access and more responsibility.

Maintenance and controlled changes

RDS uses a weekly maintenance window, with a 30-minute slot, for maintenance and deferred modifications. Choosing when changes happen is part of operating your application even though AWS performs the underlying work. See the maintenance guide when deciding whether to apply a modification immediately or defer it.

For MariaDB, MySQL and PostgreSQL, Blue/Green Deployments provide a staging environment kept in sync with production. You test changes on green before switching production over; AWS describes switchover as typically under a minute, with no data loss. This gives you a controlled change process alongside the managed deployment feature.

Encryption is a creation decision

RDS encryption at rest uses AWS KMS keys and AES-256, covering storage, logs, automated backups, read replicas and snapshots. You enable encryption when creating the instance. You cannot toggle an existing unencrypted instance to encrypted in place, or turn encryption off afterward.

The snapshot method for an existing unencrypted database is:

1. Take a snapshot of the source instance.
2. Copy that snapshot with encryption enabled.
3. Restore a new instance from the encrypted copy.

The distinction is the encrypted copy: simply taking a snapshot does not perform the conversion. Blue/green deployments can also provide a path to encryption, as covered in the RDS encryption documentation. An encrypted source and its read replica cannot mix encrypted and unencrypted storage.

Multi-AZ vs read replicas

Start with the failure or capacity problem you need to solve. Availability means recovering when an instance or Availability Zone fails; read scaling means moving read work away from the source. RDS has features for both, but their replication and connection behavior differ.

Multi-AZ DB instance: a standby for availability

A Multi-AZ DB instance deployment maintains a synchronous standby in another Availability Zone. Committed writes are protected on both sides, and RDS handles failover automatically. The standby does not accept application reads, so enabling this deployment does not offload reporting queries. AWS makes that restriction explicit in its Multi-AZ DB instance guide.

During failover, RDS changes the endpoint's DNS record to point to the standby. Your connection string stays the same, but existing database connections must be re-established. Applications therefore need reconnect behavior even when the database has automatic failover.

AWS says failover typically takes 60–120 seconds, and large transactions or lengthy recovery can increase that time. Failover can follow an unhealthy primary, storage failure, operating system patching or a reboot with failover requested. The failover documentation also explains how DNS caching affects reconnection.

Multi-AZ DB cluster: readable standbys

A Multi-AZ DB cluster has a writer and two readable standbys across three Availability Zones. It uses semisynchronous replication and combines high availability with capacity for read workloads, as the cluster architecture guide explains. This deployment is available for RDS for MySQL and RDS for PostgreSQL.

Its failover is typically under 35 seconds, according to the cluster failover guide. Do not apply the unreadable-standby rule from DB instance deployments to this design. A Multi-AZ DB cluster is also distinct from an Aurora cluster, despite the shared word “cluster.”

Read replicas: asynchronous copies for reads

A read replica is a read-only copy updated asynchronously from its source. Because updates can lag, a replica may return data that is behind the source. It suits read traffic that can tolerate that delay; consider freshness before moving a query there.

Each replica has its own endpoint, and your application must direct its reads to that endpoint. Creating a replica does not reroute existing queries, and RDS does not automatically scale the number of read replicas. RDS for MySQL, MariaDB and PostgreSQL support up to 15 replicas per source; the read replica documentation describes their operation.

Replicas can be cross-Region, and you can initiate promotion to a standalone database for disaster recovery. Promotion is a different operation from automatic Multi-AZ instance failover. For the broader recovery choices, use the AWS disaster recovery strategies guide.

The comparison to remember is:

• Replication: Multi-AZ DB instance: synchronous standby / Read replica: asynchronous copy that can lag.
• Read traffic: Multi-AZ DB instance: standby cannot serve reads / Read replica: application reads use the replica endpoint.
• Recovery: Multi-AZ DB instance: automatic failover with the same endpoint name / Read replica: you initiate promotion to a standalone database with its own endpoint.
• Deployment distinction: Multi-AZ DB instance: an unreadable standby / Multi-AZ DB cluster: two readable standbys across three Availability Zones.

Backups and point-in-time recovery

Replication preserves availability, including when the application makes a bad change. A standby or read replica also receives that change, so neither is a historical copy you can assume still contains the earlier data. Backups solve the separate problem of recovering an earlier database state.

Automated backups and retention

For DB instances, automated backup retention can be 0–35 days, with 0 disabling automated backups and point-in-time recovery. The default is seven days when creating through the console and one day through the CLI or API. Explicitly choose retention rather than assuming every creation method produces the same setting; see the retention documentation.

RDS stores backups in Amazon S3 and uploads transaction logs every five minutes. Backups and logs let you select a recovery point within the available retention window. Check that window when planning recovery instead of assuming every recent write is already restorable.

A restore creates a new database

Point-in-time recovery creates a new DB instance, leaving the source instance unchanged. The replacement has a new endpoint, so recovery includes validating the restored database and redirecting the application. This is different from Multi-AZ failover, which retains the existing endpoint name, as the point-in-time restore guide explains.

For a faulty migration, choose a recovery point before the bad change. That choice also excludes later valid transactions from the restored state. Recovery planning therefore involves deciding which point is acceptable as well as knowing which restore operation to run.

Manual snapshots and deletion

Manual snapshots remain until you delete them, whereas automated backups are deleted with an instance unless you choose to retain them. The initial snapshot is full and later snapshots are incremental. Review the backup lifecycle before deleting a database you might need to recover.

Snapshots can be copied across Regions and shared with other accounts. To share an automated snapshot, first copy it to a manual snapshot. A snapshot restore also creates a new instance, so a retained snapshot is a recovery source rather than an already running replacement.

RDS Proxy

RDS Proxy addresses database connections. Many short application requests can otherwise create many separate database connections, with repeated setup work. The proxy maintains a pool and shares connections so clients can reuse database capacity.

Lambda functions are a useful example because they make frequent, short connections. The application connects to the proxy endpoint, and the proxy connects to the database in the same VPC; the proxy cannot be publicly accessible. The AWS Lambda guide explains the function side, while the RDS Proxy guide covers pooling and authentication.

The proxy can use IAM database authentication or credentials in Secrets Manager to connect to the database. It also connects to a standby during failover while preserving application connections. AWS says bypassing DNS caches can reduce Multi-AZ DB instance failover times by up to 66%, a qualified figure in its proxy planning documentation.

Keep the problem categories separate when choosing it. A proxy manages connections, a read replica provides read capacity, and Multi-AZ provides availability. Pooling does not remove the need to tune queries or choose appropriate database capacity.

RDS vs Aurora

The engines above give you managed deployments of those databases. Aurora is part of Amazon RDS, but it has its own engine family, compatible with MySQL and PostgreSQL, and its own user guide. Its storage model uses a cluster volume with data copied across three Availability Zones, as described in the Aurora overview.

Compare the specific engine and deployment rather than treating “managed relational database” as a complete architecture. RDS for PostgreSQL, an RDS Multi-AZ DB cluster and an Aurora PostgreSQL-compatible cluster have related terminology, but that does not make their deployment behavior interchangeable. Read the full service name in a scenario before applying a feature.

• Engine choice: RDS: the six named database engines / Aurora: MySQL- and PostgreSQL-compatible engines.
• Storage model: RDS DB instance: EBS-backed storage / Aurora: a cluster volume with copies across three Availability Zones.
• Cluster terminology: RDS Multi-AZ DB cluster: an RDS deployment with readable standbys / Aurora cluster: a deployment of the Aurora engine family.

Who uses RDS

AWS-published customer stories illustrate different reasons to adopt managed databases. They describe particular workloads and outcomes, so use them as examples rather than savings or recovery guarantees for your own application.

• Intuit Mint: An AWS case study describes moving MySQL databases from EC2 to RDS for MySQL. Mint reported costs down 25% and failover improving from up to 30 minutes to about one minute.
• Tradeshift: In a post on the AWS Database Blog, Tradeshift describes migrating an 18 TB PostgreSQL database from self-managed EC2 to RDS for PostgreSQL. It used native PostgreSQL logical replication and a short cutover; recovery before the move could take nearly 48 hours.
• Linedata CapitalStream: On AWS's PostgreSQL customer page, Linedata reports reducing database costs by up to 40% after moving from Oracle to RDS for PostgreSQL and eliminating Oracle licensing fees.

Services RDS works with

RDS runs inside your VPC. A DB subnet group contains the subnets designated for database placement, typically private subnets spanning at least two Availability Zones. A security group can restrict database access to the application servers' security group, as the RDS overview shows.

In the layout from the VPC networking guide, EC2 application servers occupy public subnets and the database sits in private subnets. Internet clients reach the application, and only the permitted application tier reaches the database. Subnet placement and access rules remain decisions you configure.

Credentials and database authentication

RDS can generate, store and rotate the master password through AWS Secrets Manager. Its default rotation interval is seven days. This moves credential management into a dedicated service, as explained in the Secrets Manager integration guide.

For MariaDB, MySQL and PostgreSQL, IAM database authentication uses a token valid for 15 minutes in place of a password. That validity applies to authentication; it is not a 15-minute query timeout. AWS also documents SSL/TLS encryption of traffic with this method in the IAM database authentication guide.

Caching, migration and monitoring

Amazon ElastiCache can reduce repeated database reads through lazy loading: the application checks the cache, reads the database on a miss, and caches the result. The caching strategies guide explains the application pattern, which differs from maintaining a read replica.

AWS Database Migration Service supports an initial data load or ongoing change replication into RDS. When changing engines, DMS Schema Conversion helps convert the schema before data migration. The DMS overview separates these roles; do not assume every customer migration uses DMS, as Tradeshift's example used native PostgreSQL replication.

CloudWatch provides database metrics, while CloudWatch Database Insights breaks down database load by waits, SQL, hosts and users. Enhanced Monitoring adds operating system metrics. Use the RDS monitoring documentation to connect infrastructure symptoms with the workload you need to investigate.

AWS Backup can manage RDS protection centrally. Its periodic RDS snapshots count as manual backups, while continuous backups count as automated backups and support point-in-time recovery. Enabling continuous protection also gives AWS Backup control of the backup window and retention, as described in the AWS Backup RDS guide.

Pricing

RDS cost includes DB instance usage, provisioned storage, provisioned IOPS and backup storage. Instance usage is billed per second with a 10-minute minimum. Read replicas are billed as standard DB instances, so copying data for read scale also adds running database capacity. Use the billing guide to identify the components of your chosen deployment.

For steady usage, Reserved DB instances provide a billing discount with a one- or three-year term. They are a purchasing arrangement rather than a different physical database or a scaling feature. The reservation guide explains how they apply to matching usage.

Temporary stopping needs care: RDS automatically starts an instance after seven consecutive days stopped. You also cannot stop an instance that is a read replica or has read replicas. Check the stopping rules before treating a stopped development database as a long-term cost plan.

Storage autoscaling adds another cost consideration because allocated storage only grows. Its low-space threshold is 10% or less free space for at least five minutes, and you set a maximum storage threshold. It cannot shrink allocated storage afterward; the storage autoscaling guide explains why the maximum deserves attention alongside the initial allocation.

RDS exam traps

Cloud Practitioner focuses on managed databases and shared responsibility. Solutions Architect Associate covers resilience, performance and cost; Data Engineer Associate includes choosing a data store, and DevOps Engineer Professional includes Multi-AZ and failover testing. The same service appears at different depths, so practice identifying the requirement before selecting a feature.

• Managed service vs application ownership. AWS handles operating system and database engine patching; you retain query tuning and access configuration. A practice question on managed database responsibilities tests exactly where that boundary moves after leaving EC2.
• Automatic failover vs replica promotion. In the video's practice question on RDS Multi-AZ failover, the deciding requirements are automatic recovery, protection of committed transactions and an unchanged connection string. A Multi-AZ DB instance meets them through synchronous replication and endpoint reassignment. An asynchronous replica or backup restore does not provide that combination.
• Hardware failure vs a bad database change. Replication also copies unwanted changes. A practice question on recovering from a faulty database migration calls for point-in-time recovery before the change, followed by redirecting the application to the new instance. Failing over does not undo committed SQL.
• Connections vs query capacity. Many short Lambda connections point toward pooling. A practice question on Lambda exhausting RDS connections asks you to preserve request handling while addressing the connection pattern. Read replicas and a larger instance are tempting answers that leave that pattern in place.
• Password storage vs password-free authentication. Moving a password into a secret and replacing it with IAM tokens answer different requirements. A practice question on IAM database authentication makes the absence of a stored application password central to the choice.
• Secrets vs source code. A Data Engineer practice question on Glue database credentials applies Secrets Manager to a job reading RDS. It tests removing credentials from the script while allowing rotation and granting the job permission to retrieve the secret.
• Retention during deletion vs replacement. A DevOps practice question on retaining an RDS instance and taking a final snapshot separates stack deletion from replacement during an update. Read which event the requirement describes before choosing a lifecycle policy.
• Stable capacity vs scaling features. A practice question on Reserved DB instances describes continuously running, stable databases. The cost decision is a billing commitment rather than a database migration or a change to application capacity.

Keep the encryption sequence clear as well: snapshot, encrypted copy, restore. Also read the deployment name fully before deciding whether a standby serves reads. “Multi-AZ” alone does not tell you whether the scenario means a DB instance or DB cluster deployment.

Continue with the Cloud Practitioner question list, Solutions Architect Associate question list, Data Engineer Associate question list or DevOps Engineer Professional question list. For timed practice, start from the CLF-C02, SAA-C03, DEA-C01 and DOP-C02 certification pages.

Frequently asked questions

What is Amazon RDS used for?

RDS runs relational databases for applications that need engines such as MySQL, PostgreSQL or SQL Server. You keep the schema and SQL while AWS manages operational work such as patching, backups and failure recovery.

What is the difference between Multi-AZ and a read replica?

A Multi-AZ DB instance has a synchronous standby for automatic failover, and that standby does not serve reads. A read replica is asynchronous and serves reads through its own endpoint. A Multi-AZ DB cluster is the separate deployment with readable standbys.

Is Amazon RDS serverless?

The standard RDS DB instance model described here requires choosing an instance class and storage configuration. Managed operations do not remove those capacity decisions. Aurora has its own engine family and user guide, so check it separately when comparing options.

How long are RDS backups kept?

DB instance automated backup retention is configurable from 0–35 days, with zero disabling it. Manual snapshots remain until you delete them. Deleting an instance removes its automated backups unless you choose to retain them.

Does point-in-time recovery overwrite my database?

No: it creates a new DB instance and leaves the source unchanged. You must direct your application to the restored instance's new endpoint after checking the recovered data.

Do I need RDS Proxy for Lambda?

RDS Proxy is useful when frequent, short Lambda connections put pressure on a relational database. It pools connections and helps during failover. Decide based on the connection pattern rather than assuming every database performance issue needs a proxy.

Watch the whiteboard video

The animation follows connections and replication arrows across Availability Zones, then moves the endpoint during failover so you can see which parts change together. It also works through the Multi-AZ practice question: Amazon RDS Explained: Multi-AZ, Read Replicas, Backups and More on YouTube.