RDS Multi-AZ, Read Replicas and Recovery

Deploy a resilient RDS MySQL instance, force a failover, and restore lost data.

Introduction

30 Second Summary

Every production database will eventually face a failure. An entire data center can go dark, a disk can corrupt, or someone can accidentally delete a critical table. The difference between a minor blip and a catastrophic outage comes down to how well your database is prepared to recover.

In this project, you will build a resilient Amazon RDS MySQL deployment and then deliberately break it. You will force a failover, watch it recover automatically, scale reads with a replica, and restore deleted data from a point in time.

What You'll Build

By the end of this lab, you will have a database you personally crashed and recovered, with the logs and events to prove every resilience mechanism works.

By the end of this project, you'll have:

  • A Multi-AZ RDS MySQL instance with encryption at rest that you triggered a live failover on, watching RDS automatically switch to a standby in a different Availability Zone within 60-120 seconds.
  • A read replica receiving asynchronous updates from your primary instance, where you can query replicated data and confirm the read-only constraint firsthand.
  • A point-in-time recovery that brings back data you deliberately deleted, proving your automated backup retention window works down to the second.
  • Secret Mission: Configure cross-Region automated backup replication for full disaster recovery across AWS Regions.

Are there any prerequisites?

You need an AWS account with console access. All work happens in the AWS Management Console. No local tools or installations are required.

Before We Start

Before We Start...

Before we dive in, let's lock in what you're about to build and why it matters.

Provision an Encrypted Multi-AZ RDS MySQL Instance

Every resilience feature you will test in this project needs a database to test against. You need an instance that mirrors a production setup from the start: encrypted storage, automated backups, and high availability across multiple Availability Zones.

In this step, you will provision an RDS MySQL instance with encryption at rest, enable Multi-AZ for automatic failover, and insert test data that you will use throughout the project.

In this step, get ready to:
  • Create an encrypted RDS MySQL instance with automated backups.
  • Enable Multi-AZ for high availability.
  • Connect and insert test data to verify the database works.

This step incurs AWS charges

Multi-AZ doubles the cost of your db.t3.micro instance because a synchronous standby runs in a separate AZ. The read replica you create later adds another instance charge. Total cost for 2-3 hours of lab time is approximately $0.15-0.20. Delete all resources in the Before You Go section when you finish to avoid ongoing charges.

Create the RDS instance
  • Open the RDS console at https://console.aws.amazon.com/rds/.
  • In the navigation pane, choose Databases.
  • Choose Create database.
  • Select Standard create as the database creation method.
  • Under Engine options, choose MySQL.
  • Under Templates, select Free tier or Sandbox. Free tier appears for legacy free plan accounts. Sandbox appears for paid plan accounts. Both pre-select the db.t3.micro instance class.

Why start with the Free tier or Sandbox template?

These templates pre-fill sensible defaults for a small, low-cost instance. You will override the Multi-AZ setting in a later substep because both templates disable it by default.

  • In the Settings section, set DB instance identifier to rds-resilience-lab.
  • Set Master username to admin (or leave the default).
  • Under Credentials management, select Self managed.
  • Clear the Auto generate a password checkbox if it is selected.
  • Enter a Master password and confirm it. Write this password down. You will need it to connect later.

Choose a memorable password

Pick something you can remember for the next hour. This is a short-lived lab instance, not a production database.

  • In the Storage section, confirm Allocated storage is set to 20 GiB and storage type is General Purpose SSD (gp3).
  • In the Connectivity section, keep the default VPC selected.
  • Set Public access to Yes. This allows you to connect from CloudShell for testing.
  • Expand the Additional configuration section.
  • Set Backup retention period to 7 days.
  • Under Encryption, confirm Enable encryption is checked. Leave the AWS KMS key set to the default aws/rds managed key.
  • Choose Create database.

Why enable encryption at creation?

You can only encrypt an RDS instance at creation time. To add encryption to an existing unencrypted instance, you would need to snapshot it, copy the snapshot with encryption enabled, and restore from the encrypted copy. Enabling it now avoids that complexity.

Your new instance appears in the Databases list with status Creating. Wait 5-10 minutes for it to reach Available status before continuing.

Instance stuck in Creating?

RDS provisioning typically takes 5-10 minutes. If it takes longer than 15 minutes, check that your region has capacity for db.t3.micro instances. Try a different Availability Zone or region if you see a capacity error.

help me troubleshoot my RDS instance stuck in Creating status

Enable Multi-AZ

The Free tier template creates a Single-AZ instance. You need to modify it to enable Multi-AZ, which places a synchronous standby replica in a different Availability Zone.

  • Once your instance status shows Available, select the rds-resilience-lab instance.
  • Choose Modify.
  • Under Availability & durability, select Multi-AZ DB instance.
  • Scroll to the bottom and choose Continue.
  • Select Apply immediately and choose Modify DB instance.

The instance status changes to Modifying. Wait another 5-10 minutes for it to return to Available.

What is Multi-AZ doing behind the scenes?

RDS is provisioning a synchronous standby in a different Availability Zone. Every write to your primary is replicated synchronously to the standby before being acknowledged. The standby is not readable. It exists solely to take over if the primary fails.

🙋‍♀️ Modification taking a long time?

The Multi-AZ modification involves creating a standby and synchronizing data. For a fresh db.t3.micro with 20 GB storage, this typically takes 5-10 minutes. Refresh the console page if the status has not updated.

help me with my RDS Multi-AZ modification

Connect and insert test data

With the instance running, you need to insert test data that you will use to verify failover, replication, and point-in-time recovery in later steps.

  • Select your rds-resilience-lab instance in the RDS console.
  • Choose the Connectivity & security tab.
  • Copy the Endpoint value. It looks something like rds-resilience-lab.xxxxxxxxxxxx.us-east-1.rds.amazonaws.com.

What is this endpoint?

The endpoint is a DNS name that always resolves to your primary instance. When a Multi-AZ failover happens, RDS updates the DNS record to point to the new primary. Your applications reconnect to the same endpoint without any code changes.

  • Before connecting, you need to allow your CloudShell IP address in the security group. On the Connectivity & security tab, click the link under VPC security groups to open the security group.
  • Choose Edit inbound rules.
  • Choose Add rule. Set Type to MySQL/Aurora, and Source to My IP.
  • Choose Save rules.

Now open AWS CloudShell by clicking the terminal icon in the top navigation bar of the AWS console.

  • Install the MySQL command-line client by running this command:
sudo dnf install mariadb105 -y
  • Connect to your RDS instance by running this command:
mysql -h [[RDS_ENDPOINT="your-rds-endpoint.region.rds.amazonaws.com"]] -P 3306 -u admin -p

Enter your master password when prompted. You should see the MySQL monitor prompt.

Connection timed out?

If you see a timeout error, the security group is not allowing traffic from CloudShell. CloudShell IP addresses change between sessions. Go back to the security group inbound rules and add a new rule with Type set to MySQL/Aurora and Source set to Anywhere-IPv4 (for testing only).

help me connect to my RDS instance from CloudShell

  • Create a test database and table by running these SQL statements:
CREATE DATABASE testdb;
USE testdb;

CREATE TABLE employees (
    id INT AUTO_INCREMENT PRIMARY KEY,
    name VARCHAR(100),
    department VARCHAR(50)
);

INSERT INTO employees (name, department) VALUES
('Alice Johnson', 'Engineering'),
('Bob Smith', 'Marketing'),
('Carol Williams', 'Engineering');

What does this SQL do?

This creates a database called testdb with a simple employees table containing three rows. You will use this data throughout the project to confirm that failover preserves data, replicas receive updates, and point-in-time recovery restores deleted rows.

  • Verify the data was inserted by running:
SELECT * FROM employees;

You should see three rows: Alice Johnson, Bob Smith, and Carol Williams.

  • Leave the MySQL session open. You will reconnect in the next step to verify data after failover.

Before you check the final configuration, think about what you expect to see. You enabled encryption at creation and then modified to Multi-AZ.

What do you predict the Configuration tab will show for Multi-AZ and Encryption?

  • In the RDS console, select your rds-resilience-lab instance.
  • Choose the Configuration tab.
  • Confirm that Multi-AZ shows Yes.
  • Under Storage, confirm that Encryption shows Enabled.

Your instance is fully configured: encrypted storage with the aws/rds KMS key, 7-day backup retention, and a synchronous standby in a different AZ.

Your production-grade database is live with encryption, automated backups, and Multi-AZ failover. Next up, you will put Multi-AZ to the test by forcing a failover and watching RDS recover automatically.

Force a Multi-AZ Failover

Your database is live, encrypted, and running across two Availability Zones. But how do you know the standby actually takes over when disaster strikes?

In this step, you will deliberately break your database by forcing a Multi-AZ failover. This simulates a real AZ failure and lets you observe the recovery time and DNS switchover firsthand.

In this step, get ready to:
  • Record the current Availability Zone of your instance.
  • Trigger a failover using Reboot with failover.
  • Observe the failover event and verify your data survived intact.
Record the current state

Before you break anything, you need a baseline. Recording the current Availability Zone lets you confirm that the failover actually moved your database to a different location.

  • In the RDS console, choose Databases in the navigation pane.
  • Select your rds-resilience-lab instance.
  • Click the Connectivity & security tab.
  • Find the Availability Zone field and write down the value (for example, us-east-1a).
  • Note the current time so you can measure how long the failover takes.

Why write down the AZ?

After a failover, RDS promotes the standby in a different AZ to become the new primary. The only way to prove that happened is to compare the AZ before and after.

Trigger the failover

For a Multi-AZ DB instance, you force a failover by rebooting with a special checkbox selected. This tells RDS to switch to the standby instead of restarting the same host.

  • With your rds-resilience-lab instance selected, click Actions in the top-right area.
  • Choose Reboot from the dropdown menu.
  • On the Reboot DB instance page, select the Reboot with failover? checkbox.
  • Click Reboot to confirm.

The instance status changes to "Rebooting". The failover has begun.

What happens during a Multi-AZ failover?

RDS switches to the synchronous standby in a different AZ and updates the DNS record to point to the new primary. Your endpoint stays the same, but connections must be re-established.

The standby was receiving synchronous writes the entire time, so no data is lost. This is different from a read replica, which uses asynchronous replication.

💡 Reboot with failover vs. Failover action

For Multi-AZ DB instances, you use the "Reboot with failover?" checkbox. A separate "Failover" action exists only for Multi-AZ DB clusters (which have a different architecture with 2 readable standbys). Know this distinction for the SAA-C03 exam.

Observe the failover

Now you wait and watch. The failover typically completes in 60-120 seconds. Your job is to confirm three things: the instance recovered, the AZ changed, and your data survived.

  • Watch the instance status in the Databases list. Refresh the page every 30 seconds or so until the status returns to Available.
  • Click on your rds-resilience-lab instance and open the Connectivity & security tab.
  • Check the Availability Zone field. It should now show a different AZ than the one you wrote down earlier.

That AZ change is proof that RDS promoted the standby to become your new primary.

  • In the left navigation pane, click Events.
  • Look for the event message: "The user requested a failover of the DB instance".

What should I see in Events?

You will see several events logged in sequence. The key one is "The user requested a failover of the DB instance". You may also see events about the multi-AZ failover completing and the instance recovering.

The final check is confirming your data survived the failover. Before you reconnect, what do you expect to find in your test table?

  • Reconnect to the database using the same endpoint from the Connectivity & security tab (the endpoint has not changed, only the underlying host).
  • Query your test table to verify all rows are still present.

Your data is intact. Because Multi-AZ uses synchronous replication, the standby had an identical copy of every write before the failover happened. Zero data loss.

Can't reconnect after failover?

Existing connections are dropped during failover. Close your current session completely and open a new connection using the same endpoint and credentials.

If the instance still shows "Rebooting" after 5 minutes, refresh the console page. The status sometimes takes a moment to update in the UI.

Help me troubleshoot my RDS failover reconnection issue

You just proved that Multi-AZ failover works. Your database went down, RDS promoted the standby in a different AZ within 60-120 seconds, and not a single row was lost. Next up, you will tackle a different problem: scaling reads with a read replica.

Create a Read Replica and Observe Replication

Your database can now survive an entire Availability Zone going offline. You proved that in the last step by forcing a failover and watching RDS switch to the standby automatically.

However, your single instance still handles every read and every write. A busy application sends far more reads than writes. A read replica lets you offload read traffic to a separate copy of your database, giving the primary breathing room for writes.

In this step, get ready to:
  • Create a read replica of your primary instance in a different Availability Zone.
  • Confirm that data written on the primary appears on the replica within seconds.
  • Prove that the replica is read-only by attempting a write and observing the error.
Create the read replica

A read replica uses asynchronous replication to keep a near-real-time copy of your primary database. RDS for MySQL uses the engine's native binary log replication under the hood.

  • In the RDS console, choose Databases in the navigation pane.
  • Select your rds-resilience-lab instance.
  • Choose Actions, then Create read replica.
  • Set the DB instance identifier to rds-resilience-lab-replica.
  • Under Availability Zone, choose a different AZ from the one your primary is currently running in.
  • Keep the instance class as db.t3.micro.
  • Choose Create read replica.

Why place the replica in a different AZ?

For the SAA-C03 exam, remember that read replicas can be in the same AZ, a different AZ, or even a different Region. Placing it in a different Availability Zone here mirrors a common production pattern where you want both high availability and read scaling.

Read replicas are billed as standard DB instances. There is no data transfer charge for same-Region replication.

The replica takes 5-10 minutes to create. You can watch the status in the Databases list. Wait for it to change from "Creating" to "Available" before continuing.

Replica stuck in Creating?

Replica creation can take up to 10 minutes depending on database size. If it stays in "Creating" for longer than 15 minutes, check that your source instance has automated backups enabled (backup retention must be greater than 0).

help me understand why my RDS read replica is stuck in creating status

Test replication

Now that the replica is running, you can confirm it has a copy of your data and that new writes on the primary flow through automatically.

  • Select the rds-resilience-lab-replica instance in the Databases list.
  • Open the Connectivity & security tab and copy the replica's Endpoint. This is a separate address from your primary.
  • Connect to the replica using your MySQL client and the replica endpoint (use the same master credentials).
  • Query your test table to confirm the data from the primary is present:
SELECT * FROM test_data;

You should see the same rows you inserted on the primary in the earlier steps. This confirms the initial snapshot replicated successfully.

Next, prove that ongoing changes replicate in near-real-time. Switch back to your primary connection and insert a new row:

  • In your MySQL client connected to the primary (rds-resilience-lab endpoint), insert a new row by running:
INSERT INTO test_data VALUES (100, 'replication_test');
  • Switch back to your replica connection and query the table again:
SELECT * FROM test_data;

The new row should appear within a few seconds. This is asynchronous replication in action. The primary does not wait for the replica to confirm receipt before committing the write.

What is asynchronous replication?

Unlike Multi-AZ's synchronous standby (which must acknowledge every write before the primary commits), a read replica receives changes asynchronously via the MySQL binary log. This means there can be a brief lag between a write on the primary and its appearance on the replica.

For the SAA-C03 exam, remember this distinction. Multi-AZ is for high availability (synchronous). Read replicas are for read scaling (asynchronous).

Understand replica limits

You have confirmed the replica receives data. But what happens if you try to write directly to it?

Before you run the next command, predict: what do you think happens when you attempt an INSERT on a read replica?

  • In your MySQL client connected to the replica, attempt to insert a row:
INSERT INTO test_data VALUES (200, 'write_attempt');

You will see an error indicating the server is running in read-only mode. The replica rejects the write because RDS configures it with read-only access by default. This is the expected behaviour.

Why are read replicas read-only?

Allowing writes on a replica would cause data to diverge from the primary, breaking replication. RDS enforces read-only mode to prevent this. If you need a replica to accept writes (for example, during a migration), you must promote it to a standalone instance first.

Now confirm the replication health in the console:

  • Return to the RDS console and select your rds-resilience-lab-replica instance.
  • Scroll down to the Replication section.
  • Confirm that Replication state shows "Replicating".
  • Note the Replica Lag metric. For a lightly loaded instance like this one, lag is typically 0 or a few milliseconds.

What does Replica Lag mean?

Replica Lag reports how many seconds behind the primary the replica currently is. Under heavy write load on the primary, this number grows. In production, you would monitor this metric and alert if it exceeds acceptable thresholds for your application's consistency requirements.

🙋‍♀️ Replication state showing Error?

If the Replication state shows "Error" instead of "Replicating", check the Replication Error field for the specific MySQL error message. A common cause is schema changes made directly on the replica that conflict with changes from the primary.

help me troubleshoot my RDS read replica replication error

Your database is now both highly available and horizontally scalable for reads. Next up, you will test the last resilience pillar: recovering your data to a specific point in time using automated backups.

Perform a Point-in-Time Recovery

Your database can now survive an entire Availability Zone failure and scale reads across a replica.

But what happens when someone accidentally deletes a critical table? Multi-AZ replicates the deletion to the standby instantly. Your read replica replicates it too. Every copy of the data is gone. Point-in-time recovery (PITR) solves this by letting you restore your database to any second within your backup retention window. In this step, you will deliberately destroy data and then bring it back.

In this step, get ready to:
  • Simulate accidental data loss by deleting your test table on the primary instance.
  • Restore the database to a point in time just before the deletion.
  • Verify the restored instance contains your original data.
Simulate a disaster

RDS uploads transaction logs to Amazon S3 every 5 minutes. For PITR to capture your data at a specific moment, those logs need to have been uploaded first. You will note the current time, wait for the logs to upload, then delete your data.

  • Connect to your primary instance rds-resilience-lab using the same MySQL client or CloudShell connection method you used earlier.
  • Note the current time (date and hour:minute) in your local time zone. Write it down. This is your "safe" timestamp that you will restore to later.
  • Wait 5 minutes. This gives RDS time to upload transaction logs to S3 so that everything up to your noted time is captured in the backup.
  • After the 5-minute wait, delete your test table to simulate accidental data loss by running this SQL command:
DROP TABLE test_data;
  • Confirm the table is gone by running:
SHOW TABLES;

Your test table should no longer appear in the output. The data is gone from every synchronized copy of the database.

Why wait 5 minutes before deleting?

RDS uploads transaction logs to Amazon S3 every 5 minutes. This means the recovery point objective (RPO) for PITR is 5 minutes. If you delete data immediately after noting the time without waiting, the logs covering that moment might not be uploaded yet, and your restore could miss the latest transactions.

Restore to a point in time

PITR does not overwrite your existing instance. It creates a completely new DB instance from the automated backup, restored to the exact second you specify.

  • In the RDS console navigation pane, choose Automated backups.
  • On the Current Region tab, select your rds-resilience-lab DB instance.
  • Choose Actions, then Restore to point in time.
  • In the Restore to point in time window, choose Custom.
  • Enter the date and time you noted earlier (the time just before you deleted the table). Times are shown in your local time zone.
  • For DB instance identifier, enter rds-resilience-lab-pitr.
  • Leave all other settings as defaults.
  • Choose Restore to point in time.

The new instance begins provisioning. You will see it appear in the Databases list with status "Creating". This takes 5-10 minutes.

What does Restore to point in time actually do?

RDS takes the most recent automated snapshot before your chosen time, then replays the transaction logs up to the exact second you specified. The result is a brand-new DB instance with your data as it existed at that moment.

The original instance remains untouched. This is important because it means PITR is non-destructive. You can compare the restored state against the current state, or simply swap your application endpoint to the restored instance.

🙋‍♀️ Seeing a time-range error?

If the console says your chosen time is outside the restorable range, you may have picked a time too close to the present (within the 5-minute log upload window). Choose a time a few minutes earlier than what you noted.

help me fix a time-range error when restoring my RDS instance to a point in time

Verify the restore
  • Return to the Databases list in the RDS console.
  • Wait for rds-resilience-lab-pitr to show status "Available" (5-10 minutes).
  • Select the rds-resilience-lab-pitr instance and open its Connectivity & security tab.
  • Copy the endpoint for the restored instance. It will be different from your primary instance endpoint.
  • Connect to the restored instance using the new endpoint and your original master credentials.

Before you run the next query, take a moment to predict: do you expect to see your test table and its data, or will it be gone like it is on the primary?

  • Query the test table to confirm your data is back by running:
SHOW TABLES;
SELECT * FROM test_data;

Your test table and all its rows are back, exactly as they existed at the time you chose. The deletion on the primary never happened from this restored instance's perspective.

Why is this a new instance?

The restored instance is a completely separate DB instance with its own endpoint, not a replacement of the original. This design lets you validate the restored data before making any changes to production. You could point your application to the new endpoint, or export specific tables back into the original instance.

🙋‍♀️ Test table still missing on the restored instance?

Make sure you chose a restore time before you ran the DROP TABLE command. If your restore time was after the deletion, the restored instance will also be missing the table. Try the restore again with an earlier timestamp.

Also confirm you are connecting to the rds-resilience-lab-pitr endpoint, not the original rds-resilience-lab endpoint.

help me troubleshoot why my point-in-time restored RDS instance is missing the test table

You have now proven that RDS automated backups and point-in-time recovery can bring back data that was permanently deleted from your production instance. Combined with Multi-AZ failover and read replicas, your database is protected against both infrastructure failures and human errors.

Secret mission

Cross-Region Automated Backup Replication

Multi-AZ protects against a single Availability Zone failure. But what happens if an entire AWS Region goes down? In this secret mission, you will configure cross-Region automated backup replication to give your database full regional disaster recovery.

Clean Up Your Resources

Clean Up Your Resources

Decide whether to keep your resources running, pause them to come back later, or delete them entirely. This project uses paid RDS instances that incur ongoing charges, so cleaning up promptly keeps your costs minimal.

Cost warning

Multi-AZ doubles your primary instance cost, and both the read replica and PITR restored instance are billed as separate db.t3.micro instances. Leaving all three running costs approximately $1-3 per day depending on your Region. Delete or pause within a few hours to keep the total under $1.

Resources you used:

  • Primary RDS MySQL instance rds-resilience-lab (Multi-AZ, encrypted, 7-day backup retention).
  • Read replica rds-resilience-lab-replica (db.t3.micro in a different AZ).
  • Point-in-time restored instance rds-resilience-lab-pitr (db.t3.micro).
  • Cross-Region replicated backups in your destination Region (storage costs).

Keep everything running

No action needed. Choose this if you plan to continue experimenting with your RDS resilience setup within the next few hours.

  • All three instances remain available and billable at approximately $1-3 per day total.
  • Cross-Region replicated backups continue accumulating storage charges in the destination Region.
  • Automated backups continue running on the 7-day retention schedule.

Pause - I'll come back to this later

Shut down running instances to stop compute charges while keeping your data intact. You cannot stop a Multi-AZ instance directly, so you must first modify it to Single-AZ.

  • Delete the read replica and PITR instance first (they cannot be stopped). In the RDS console, choose Databases, select rds-resilience-lab-replica, choose Actions, then Delete. Clear the Create final snapshot? checkbox, enter delete me, and choose Delete. Repeat for rds-resilience-lab-pitr.
  • Modify the primary instance to Single-AZ. Select rds-resilience-lab, choose Modify, change Availability & durability to Single-AZ, choose Apply immediately, and confirm.
  • Once the modification completes, select rds-resilience-lab, choose Actions, then Stop temporarily. The instance stops for up to 7 days before RDS automatically restarts it.
  • Stop cross-Region backup replication. In the navigation pane, choose Automated backups. On the Current Region tab, select your DB instance. Choose Actions, then Manage cross-Region replication. Clear the Enable replication to another AWS Region checkbox and choose Save.

Delete - I don't want to use this again

Remove all project resources completely. Follow these steps in order to avoid dependency errors.

  • Stop cross-Region backup replication first. In the RDS console navigation pane, choose Automated backups. On the Current Region tab, select rds-resilience-lab. Choose Actions, then Manage cross-Region replication. Clear the Enable replication to another AWS Region checkbox and choose Save.
  • Delete the replicated backups in your destination Region. Switch to your destination Region using the Region selector. Choose Automated backups in the navigation pane. On the Replicated backups tab, select the backup for rds-resilience-lab. Choose Actions, then Delete. Enter delete me on the confirmation page and choose Delete.
  • Switch back to your source Region. Delete the read replica. Choose Databases, select rds-resilience-lab-replica, choose Actions, then Delete. Clear Create final snapshot?, enter delete me, and choose Delete.
  • Delete the PITR restored instance. Select rds-resilience-lab-pitr, choose Actions, then Delete. Clear Create final snapshot?, enter delete me, and choose Delete.
  • Delete the primary instance. Select rds-resilience-lab, choose Actions, then Delete. Clear Create final snapshot?, enter delete me, and choose Delete.
  • Check for any retained automated backups. In the navigation pane, choose Automated backups. On the Retained tab, select any backup associated with your deleted instances. Choose Actions, then Delete. Enter delete me and choose Delete.

Nice Work!

Nice Work!

You just built, broke, and recovered a production-grade RDS MySQL deployment. You have personally witnessed every resilience mechanism in action, from automatic failover to point-in-time data recovery.

You've learned how to:

  • Provision an encrypted Multi-AZ RDS instance and force a live failover, observing the standby take over in a different Availability Zone within 60-120 seconds.
  • Create a read replica for horizontal read scaling, test asynchronous replication in real time, and confirm the read-only constraint firsthand.
  • Perform a point-in-time recovery to restore accidentally deleted data, proving your automated backup retention window works.
  • Secret Mission: Configure cross-Region automated backup replication for full regional disaster recovery.

Ready to quiz yourself?