Amazon RDS Backups, Multi-AZ, and Read Replicas | CloudWebSchool
Amazon RDS gives you four tools for protecting your database: automated backups and point-in-time recovery for data recovery, Multi-AZ for automatic failover when infrastructure fails, read replicas for scaling read traffic, and Blue/Green deployments for zero-downtime upgrades. Each solves a different problem. A complete production database strategy needs a deliberate combination of all four.
Simple explanation
If you are new to Amazon RDS, here is a plain-English breakdown of each concept before we go deeper.
Backups are your time machine. RDS takes daily snapshots and logs every transaction continuously. If a developer accidentally runs DELETE FROM orders without a WHERE clause, you can restore the database to a point just before it happened. Backups do not keep your database running during a failure. They let you recover data after one.
Multi-AZ is your hot standby. RDS quietly maintains an exact copy of your database in a separate Availability Zone within the same region. If the primary instance fails due to a hardware fault, AZ outage, or database crash, RDS flips the DNS record to the standby. Your application reconnects to the same hostname, usually within 60 to 120 seconds. You do not approve this; it happens automatically.
Read replicas are reading assistants. They are asynchronous copies of your database that accept SELECT queries. If your application spends most of its time reading data, routing those reads to a replica reduces load on the primary. Read replicas lag slightly behind the primary and are not a substitute for Multi-AZ failover.
Blue/Green deployments are your rehearsal stage. When you need to upgrade your database engine, apply a major schema change, or test a risky configuration change, Blue/Green lets you do it on an identical copy of production, verify everything looks right, and then switch production traffic over to the new version, typically in under a minute.
Enable automated backups and Multi-AZ on every production database from day one. Add read replicas when you have a measurable read bottleneck. Use Blue/Green when you are making a change that carries real risk.
Backups vs Multi-AZ vs read replicas vs Blue/Green
Before enabling features, understand what each one actually protects against.
| Feature | Primary goal | Protects against | Does not protect against | Replication type | Downtime impact |
|---|---|---|---|---|---|
| Automated backups + PITR | Data recovery | Accidental deletion, bad migrations, data corruption | Infrastructure failure (no auto-failover) | Daily snapshot + continuous transaction logs | Restoring creates a new instance; original stays up |
| Manual snapshots | Long-term restore points | Accidental deletion, pre-migration safety net | Infrastructure failure; restores create new instances | On-demand point-in-time snapshot | Brief I/O increase during snapshot; no downtime |
| Multi-AZ | Automatic failover | AZ outage, hardware failure, database crash | Accidental deletion, bad SQL, region outage | Synchronous (every write confirmed on standby) | 60–120 seconds during automatic failover |
| Read replicas | Read scaling | Primary read overload | Infrastructure failure (not automatic failover) | Asynchronous (may lag seconds to minutes) | None until you choose to promote |
| Blue/Green deployments | Safe upgrades and changes | Failed upgrades disrupting production | Infrastructure failure; not a backup mechanism | Asynchronous sync during staging period | Under 1 minute at switchover |
Multi-AZ is not a backup. If you run DROP TABLE users on the primary, that command replicates to the standby immediately. Multi-AZ cannot undo logical errors. Only backups can. You need both.
How it works
Automated backups and transaction logs. RDS takes a daily snapshot of your database storage during a backup window you configure. It also captures transaction log files every 5 minutes throughout the day. Together, these give you the ability to restore to any specific second within your retention window, not just to the time of the daily snapshot.
Point-in-time recovery. When you trigger a PITR restore, RDS takes the most recent daily snapshot before your target time, launches a new instance from it, and replays transaction logs forward until it reaches the exact second you specified. The original database is untouched. You get a second instance containing your data as it was at that precise moment.
Multi-AZ failover. When you enable Multi-AZ, RDS provisions a standby instance in a different Availability Zone. Every write to the primary is synchronously replicated to the standby before RDS acknowledges the write to your application. If the primary becomes unavailable, RDS promotes the standby to primary and updates the DNS record for your database endpoint. Your application reconnects to the same hostname. You never update a connection string.
Read replica replication. Read replicas use asynchronous replication. When you write to the primary, the transaction is committed and acknowledged, then shipped to replicas. Replicas may lag seconds or minutes behind the primary under write load, which means reads from a replica may not reflect the most recent writes.
Blue/Green switchover. RDS creates a copy of your production instance (the green environment) and keeps it in sync using binlog or logical replication. You apply your changes to the green environment and test it. When you trigger the switchover, RDS blocks writes to blue, catches up any remaining replication lag, flips connections to green, and completes the switch, typically in under 60 seconds.
PITR and snapshot restores always create a new RDS instance. Your production database is never overwritten or paused during a restore. This means restoring does not fix your current instance — it gives you a separate copy to verify and then migrate from.
When to use what
The right combination depends on what you are building. Here are four common scenarios:
Development or test database. Enable automated backups with a short retention period (1–3 days). Multi-AZ is not worth the cost for non-production environments. Use a smaller instance class and disable Multi-AZ entirely.
Standard production application. Enable Multi-AZ and automated backups with a 14-day retention period. This combination protects against infrastructure failure and gives you a two-week recovery window for data errors. Most production databases are well covered by this combination.
Read-heavy production workload. Add one or more read replicas alongside Multi-AZ and automated backups. Direct reporting queries, analytics, and search lookups to a replica. Monitor replication lag and replica CPU. For MySQL on RDS or PostgreSQL on RDS, read replicas are configured at the engine level and managed through the RDS console or CLI.
Workload with strong disaster recovery requirements. Multi-AZ and backups protect you within a single region. If your RPO or RTO requires region-level resilience, add cross-region snapshot copies or cross-region read replicas. See Disaster Recovery Strategies in AWS for how to structure this correctly.
Blue/Green deployments apply across all of these scenarios when you have a change that carries meaningful risk: a major engine upgrade, a large schema migration, or a parameter group change that needs validation before reaching production.
Automated backups
RDS takes a daily snapshot of your database during a configurable backup window and captures transaction logs every 5 minutes throughout the day.
The backup retention period controls how long these backups are kept. The default is 7 days; you can set it from 1 to 35 days. Beyond 35 days, you need manual snapshots.
The following command sets a 14-day retention period and schedules the daily backup window during a low-traffic overnight period:
aws rds modify-db-instance \
--db-instance-identifier myapp-mysql-prod \
--backup-retention-period 14 \
--preferred-backup-window "02:00-03:00" \
--apply-immediatelySetting --backup-retention-period 0 disables automated backups entirely. Never do this on a production database.
The backup window is a daily slot during which RDS takes the daily snapshot. Brief increased I/O latency is possible during this window. Schedule it during your lowest traffic period, not during business hours.
Monitor backup status and query performance using AWS Performance Insights and RDS metrics in CloudWatch.
Point-in-time recovery
Because RDS captures transaction logs every 5 minutes, you can restore your database to any second within your retention window. This is called point-in-time recovery (PITR).
Think of PITR like a flight recorder for your database. RDS continuously captures every transaction as it happens. When something goes wrong, you specify the exact moment just before the problem and RDS rebuilds the database to that state, from scratch, on a new instance. You are not rewinding the original — you are pressing play on a recording.
PITR always restores to a new database instance. It does not overwrite your existing database. You restore to a new instance, verify the data, and then either migrate your application to the new instance or extract the specific rows you need from it.
The following command creates a new RDS instance with the database state from a specific timestamp:
aws rds restore-db-instance-to-point-in-time \
--source-db-instance-identifier myapp-mysql-prod \
--target-db-instance-identifier myapp-mysql-restored \
--restore-time 2026-03-15T14:30:00Z \
--db-instance-class db.t3.micro \
--no-publicly-accessibleThe restore takes time. For smaller databases (under 100 GB), expect 15 to 30 minutes. Large databases take considerably longer because RDS must replay more transaction logs to reach the target time. Build this into your recovery time objective planning.
Once the restored instance is available, connect to it using the same approach you use for your production instance. See Connecting to Amazon RDS Securely for the right connection pattern for your environment.
You can only restore within your retention window. If your retention period is 7 days and you need data from 10 days ago, you cannot recover it from automated backups unless you have a manual snapshot from that period.
Manual snapshots
Automated backup snapshots are deleted when the retention period ends. Manual snapshots persist until you explicitly delete them. Use manual snapshots in situations where automated backups are not enough:
- Before risky migrations. Take a snapshot before schema changes that are hard to reverse: column drops, type changes, table renames.
- Before engine upgrades. A major version upgrade can fail or cause unexpected issues. A manual snapshot gives you a clean rollback path before you start.
- Long-term retention. If compliance or audit requirements mean you need a restore point from six months ago, you cannot rely on automated backups. A manual snapshot persists indefinitely.
- Cross-region DR. Copying a snapshot to another region is the simplest region-level disaster recovery option for RDS. If your primary region becomes unavailable, you can restore the database in another region from the copied snapshot.
The following commands cover the most common snapshot operations:
# Create a manual snapshot before a risky migration
aws rds create-db-snapshot \
--db-instance-identifier myapp-mysql-prod \
--db-snapshot-identifier myapp-mysql-before-migration-20260315
# List available snapshots for an instance
aws rds describe-db-snapshots \
--db-instance-identifier myapp-mysql-prod
# Restore from a manual snapshot (creates a new instance)
aws rds restore-db-instance-from-db-snapshot \
--db-instance-identifier myapp-mysql-restored \
--db-snapshot-identifier myapp-mysql-before-migration-20260315
# Copy a snapshot to another region for cross-region disaster recovery
aws rds copy-db-snapshot \
--source-db-snapshot-identifier myapp-mysql-before-migration-20260315 \
--target-db-snapshot-identifier myapp-mysql-backup-eu-west-1 \
--source-region eu-west-2 \
--region eu-west-1A manual snapshot takes a few minutes and gives you an instant rollback point. If something goes wrong mid-migration, restoring from a snapshot is far faster than diagnosing and reversing complex schema changes under pressure.
For long-term cold storage of archived database snapshots, Amazon Glacier is worth evaluating when the cost of indefinite snapshot storage becomes a concern.
Multi-AZ deployments
A Multi-AZ deployment runs a synchronous standby replica in a different Availability Zone within the same region. Every write to the primary is synchronously replicated to the standby before the write is acknowledged to your application.
Multi-AZ is like keeping an exact carbon copy of a document as you write it, stored in a different building. The copy is always current, including every word you typed up to this second. If your building burns down, you walk to the other building and continue from exactly where you left off. But if you typed the wrong words, the copy has the wrong words too. That is why you also need backups.
What Multi-AZ protects against:
- AZ outage (hardware, power, or networking failure in one AZ)
- Instance hardware failure
- Database software crash
- Planned maintenance reboots
What Multi-AZ does not protect against:
- Region-wide outage, because both AZs are in the same region
- Data corruption, accidental DELETE, or failed schema migrations, because both replicas receive the same writes instantly
- Cross-region disaster recovery
For guidance on building systems that survive these scenarios, see Designing Highly Available Systems in AWS.
| Scenario | Multi-AZ response |
|---|---|
| Primary instance hardware failure | Automatic failover to standby in 60–120 seconds |
| AZ becomes unavailable | Automatic failover to standby in a different AZ |
| Database patching / maintenance reboot | Standby is patched first, then promoted with a brief DNS flip |
| Accidental table drop | No protection. Use PITR to restore from before the DROP. |
| Full region outage | No protection. Requires cross-region snapshot copy or Aurora Global Database. |
The standby replica receives every write, including accidental ones. Dropping a table, corrupting rows, or running a failed migration all propagate immediately to the standby. Multi-AZ protects your uptime. Backups protect your data. Both are required for any production database.
Read replicas
Read replicas are asynchronous copies of your database designed to serve SELECT queries. Their purpose is one thing: offloading read traffic from the primary to scale read throughput horizontally.
Think of a read replica like a photocopy of a busy reference book in a library. Staff keep updating the original. Readers can use the photocopy without queuing for the original. The photocopy is usually current but may be a few pages behind the latest edits. You would not use the photocopy to submit corrections — and you would not rely on it in an emergency if the original was destroyed.
Unlike Multi-AZ standbys, read replicas:
- Are queryable directly. You connect to them and run SELECT queries against them.
- Replicate asynchronously. A write confirmed on the primary may take seconds or minutes to appear on a replica. Do not use replicas for queries that must reflect the most recent data.
- Can be in a different region. A cross-region read replica reduces read latency for users in another region and doubles as a cross-region DR option.
- Can be promoted. You can promote a read replica to a standalone primary, but this is a manual process and breaks replication.
Promoting a read replica to primary takes several minutes and may involve data loss from replication lag. If you need automatic, sub-two-minute failover, use Multi-AZ. That is what it is built for. Read replicas are a performance tool, not a high availability feature.
The practical case for read replicas is a production application where a measurable portion of the load is reads: reporting dashboards, analytics queries, search indexes, or API endpoints serving read-heavy traffic. Set up CloudWatch alerts on replica lag so you catch replication falling behind before it becomes a problem.
Blue/Green deployments for safer upgrades
RDS Blue/Green deployments are a mechanism for making risky database changes safely. They are not a backup solution or a high availability feature. Think of them as a controlled rehearsal for production changes.
RDS creates a staging environment (the green environment) that is an exact copy of your production database (the blue environment), kept in sync via replication. You apply your change to the green environment: a major engine version upgrade, a schema migration, a parameter group change. You test it against real data. If everything looks right, you trigger the switchover.
During switchover, RDS blocks new writes to blue, waits for green to catch up on any remaining replication lag, and flips connections to green, typically in under 60 seconds. Your application reconnects to the same endpoint. If testing found a problem, you simply do not switch over.
The following commands create a Blue/Green deployment and trigger the switchover once the green environment is verified:
# Create a Blue/Green deployment to test a PostgreSQL version upgrade
aws rds create-blue-green-deployment \
--blue-green-deployment-name myapp-upgrade-postgres15-to-16 \
--source arn:aws:rds:eu-west-2:123456789012:db:myapp-postgres-prod \
--target-engine-version 16.1
# After verifying the green environment, switch production traffic to it
aws rds switchover-blue-green-deployment \
--blue-green-deployment-identifier bgd-xxxxxxxxxxxxBlue/Green is most valuable for major engine upgrades that cannot be rolled back once applied in-place. If you are doing a minor patch, it is probably not worth the overhead. If you are jumping from PostgreSQL 14 to 16, it is worth every minute of setup time.
For the general Blue/Green pattern across AWS services, see Blue/Green Deployments in AWS.
Backups vs disaster recovery
These terms are frequently used interchangeably. They describe different things.
Backups give you data recovery within a single region. Automated backups and manual snapshots both live in the same region as your RDS instance by default. If that region experiences a prolonged outage, your backups are unavailable too.
Multi-AZ is high availability within a single region. The primary and standby are both in the same region. A regional disaster takes down both simultaneously.
Region-level disaster recovery is a separate, deliberate strategy. The two most common approaches for RDS are:
- Cross-region snapshot copies. After each backup, copy the snapshot to a second region. If your primary region fails, restore from the copied snapshot. Recovery time is measured in hours and data loss equals the gap since your last copy.
- Cross-region read replicas. Promote a cross-region replica to primary when needed. Recovery time is faster (minutes rather than hours) and data loss is minimal, but cross-region replicas cost more and require replication lag monitoring.
Both AZs in a Multi-AZ deployment sit inside the same AWS region. A full regional event takes down the primary and the standby. If your application needs to survive a regional outage, you need a cross-region strategy in addition to Multi-AZ.
If you need higher cross-region availability with lower latency, Aurora Global Database is worth evaluating. See RDS vs Aurora for the trade-offs.
For a full treatment of RPO, RTO, and region-level resilience for RDS and other AWS services, see Disaster Recovery Strategies in AWS and Multi-Region Architectures in AWS.
Common mistakes
- Assuming Multi-AZ replaces backups. Multi-AZ replicates every operation, including accidental DELETEs, corrupt writes, and failed migrations. If bad data hits the primary, it immediately hits the standby. You still need automated backups with a meaningful retention period to recover from logical data errors.
- Treating read replicas as automatic failover targets. Promoting a read replica to primary is a manual process that takes several minutes and may cause data loss from replication lag. If you need automatic failover, enable Multi-AZ. That is what it is designed for.
- Never testing restores. A backup you have never successfully restored from is not a reliable backup. Run a quarterly restore drill: pick a recent snapshot, restore it to a test instance, and verify the data and application connectivity. Discovering that restores are broken during an actual incident is far more expensive than finding out during a scheduled test.
- Ignoring region-level disaster recovery. Multi-AZ and automated backups are both region-scoped. If your application requires region-level resilience and you have not set up cross-region snapshot copies or cross-region read replicas, a full regional outage takes your database offline regardless of how well Multi-AZ is configured.
- Scheduling backup windows during peak traffic. The daily automated backup snapshot can cause brief I/O spikes. Scheduling it during your busiest hours adds unnecessary latency risk. Set the backup window to your lowest-traffic period, typically overnight.
- Relying on the default 7-day retention period for production. Seven days is often too short. A data corruption issue may not be discovered until several days after it occurred. Set retention to at least 14 days for production databases, and consider 30 days for workloads with compliance or audit requirements.
Summary
- Automated backups capture daily snapshots plus transaction logs, enabling point-in-time recovery to any second within your retention window (1–35 days).
- PITR always restores to a new instance. Your original database is untouched during the restore process.
- Manual snapshots persist indefinitely and should be taken before risky operations, major upgrades, and for cross-region DR.
- Multi-AZ maintains a synchronous standby in another AZ; failover is automatic and typically takes 60–120 seconds.
- Multi-AZ is not a backup. Destructive operations replicate immediately to the standby. Both backups and Multi-AZ are required for production databases.
- Read replicas scale read traffic, not availability. They replicate asynchronously and require manual promotion to become primary.
- Blue/Green deployments provide a safe staging path for engine upgrades and risky changes, not a backup or high availability mechanism.
- Region-level DR requires a separate strategy: cross-region snapshot copies or cross-region read replicas, independent of Multi-AZ.
Frequently asked questions
Does Multi-AZ replace backups?
No. Multi-AZ and backups solve different problems. Multi-AZ keeps your database available when infrastructure fails: it automatically fails over to a standby if the primary instance goes down. Backups let you recover data after a logical error such as accidental deletion, a bad migration, or data corruption. Both features replicate every write, which means a destructive SQL statement lands on both the primary and the standby immediately. You need backups to undo that. Multi-AZ cannot help with logical data loss.
What is the difference between Multi-AZ and read replicas?
Multi-AZ is for high availability. It runs a synchronous standby in another Availability Zone and fails over automatically when the primary goes down. You cannot query the standby directly. Read replicas are for read scaling. They are asynchronous copies you direct SELECT queries to, reducing load on the primary. Read replicas are not automatic failover targets; promoting one to primary is a manual process and may involve a small amount of data loss due to replication lag.
How long does point-in-time recovery usually take?
PITR restores your database to a new instance rather than overwriting the existing one. For smaller databases under 100 GB, this typically takes 15 to 30 minutes. Larger databases can take significantly longer because RDS must replay transaction logs from the most recent daily snapshot to reach the exact second you specified. Plan for this when defining your recovery time objectives.
Do manual snapshots expire?
No. Manual snapshots persist until you explicitly delete them. Automated backup snapshots are deleted automatically when the retention window expires (1 to 35 days). If you want a long-lived restore point (for example, a snapshot before a major migration), take it manually. It will remain available indefinitely regardless of your backup retention setting.
What do I need for region-level disaster recovery?
Multi-AZ and automated backups are both region-scoped. If your entire AWS region becomes unavailable, neither protects you. Region-level DR requires a separate strategy: copying manual snapshots to another region, using cross-region read replicas, or deploying Aurora Global Database. Your recovery time and data loss tolerance determine which approach is appropriate. The Disaster Recovery Strategies guide covers these options in detail.