Aurora Global Database and RDS Proxy

Introduction

30 Second Summary

When a company's database goes down, every customer feels it. For global applications, a single region failure can take the entire service offline.

In this project, you will migrate a standard RDS MySQL database to Amazon Aurora, then progressively enhance it into a Global Database spanning two AWS regions with connection pooling, sub-second replication, and cross-region write forwarding.

What You'll Build

Picture showing someone your database replicating data across continents in under a second, then relocating the primary region to a different continent with zero data loss while everything keeps running.

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

• A live Aurora cluster running your migrated data, where you can query the same rows you created on standard RDS and prove the migration worked with a single SELECT statement.
• An RDS Proxy endpoint pooling and routing connections automatically, ready to handle hundreds of simultaneous Lambda functions or microservices without exhausting database connection limits.
• A Global Database with a secondary cluster in a second region, where you can insert a row on one continent and watch it appear on the other in under a second, with write forwarding letting the secondary region issue writes without any code changes.
• Secret Mission: perform a managed switchover to relocate your primary region with zero data loss, and verify the new topology works end-to-end.

Are there any prerequisites?

You need an AWS account and basic familiarity with RDS concepts like Multi-AZ, read replicas, and backups. You should be comfortable navigating the AWS Console.

Before We Start

Before any hands-on work, let's lock in what you're about to build and why it matters.

Create a Standard RDS MySQL Instance

The SAA-C03 exam frequently tests a specific scenario: your company has an existing RDS MySQL database and needs to migrate to Aurora for better performance.

To practice this migration, you first need a source database. In this step, you will create a standard RDS MySQL instance, insert sample data to verify migration later, and take a manual snapshot that you will use to migrate to Aurora in the next step.

In this step, get ready to:

• Create a standard RDS MySQL instance in us-east-1.
• Connect and insert sample data to prove migration works.
• Take a manual snapshot for the migration process.

Create the RDS MySQL instance

• In the AWS Management Console, confirm you are in the us-east-1 region (check the top-right corner).
• Open the RDS Console by searching for RDS in the search bar and selecting it.
• Click Create database.
• Select Standard create for the creation method.
• For Engine type, select MySQL.
• Under Templates, select Free tier.
• Set DB instance identifier to rds-source-db.
• Set Master username to admin.

• For Credentials management, choose Self managed and set a master password you will remember. Write it down.
• For DB instance class, confirm db.t3.micro is selected.
• Keep storage defaults (20 GiB gp2).
• Under Connectivity, set Public access to No.
• For VPC security group, choose Create new and name it rds-migration-sg.
• Expand Additional configuration. Set Initial database name to examdb.
• Scroll down and uncheck Enable deletion protection.
• Click Create database.

The instance takes approximately 5 minutes to become available. You will see the status change from Creating to Available in the databases list.

Why Free tier template?

The Free tier template automatically constrains instance size to db.t3.micro and storage to 20 GiB. This keeps your source database cost-free (or nearly so) while still giving you a realistic migration source.

💡 Note your master password

You chose the password during creation. You will need it to connect in the next substep. If you lose it, you can reset it from the RDS Console under Modify.

🙋‍♀️ Instance stuck in Creating?

RDS instance creation can take 5-10 minutes. If it stays in Creating for longer than 10 minutes, refresh the page. If the status shows an error, confirm you selected the Free tier template and did not choose Multi-AZ deployment.

help me troubleshoot why my RDS instance is not becoming available

Connect to the instance and insert sample data

With the instance available, you need to connect and insert test data. This data proves your migration to Aurora worked correctly later.

You will use AWS CloudShell with a VPC environment to connect directly to your private RDS instance without needing an EC2 bastion host.

• First, update the security group to allow MySQL connections. In the RDS Console, click on rds-source-db to open its details.
• Click the Connectivity & security tab.
• Under Security, click the security group link (rds-migration-sg) to open it in a new tab.
• Click Edit inbound rules.
• Click Add rule. Set Type to MYSQL/Aurora (port 3306). For Source, choose the same security group rds-migration-sg (start typing its name to find it).
• Click Save rules.

Why a self-referencing security group rule?

By allowing inbound traffic from the same security group, any resource that shares this security group can connect to the database on port 3306. You will assign this same security group to your CloudShell VPC environment, granting it network access.

• Open CloudShell by clicking the CloudShell icon in the top navigation bar of the AWS Console (it looks like a terminal prompt).
• In CloudShell, click the + button next to your tab to see the menu, then select Create VPC environment.
• For Name, enter rds-connect.
• For VPC, select the same VPC your RDS instance is in (the default VPC).
• For Subnet, select any subnet in the same VPC.
• For Security group, select rds-migration-sg.
• Click Create. Wait for the VPC environment to become ready (about 1 minute).

• Install the MySQL client by running this command:

sudo dnf install mariadb105 -y

• Go back to the RDS Console tab. On the Connectivity & security tab for rds-source-db, copy the Endpoint value.
• Connect to your database by running this command (replace the endpoint placeholder with your copied endpoint):

mysql -h [[RDS_ENDPOINT="your-rds-endpoint.us-east-1.rds.amazonaws.com"]] -P 3306 -u admin -p

• When prompted, enter the master password you set during instance creation.

You should see the MySQL prompt indicating a successful connection.

Connection timed out?

Confirm that your CloudShell VPC environment is using the same VPC as the RDS instance and that you selected rds-migration-sg as the security group. Also verify the inbound rule you added allows MySQL/Aurora (port 3306) from rds-migration-sg itself.

help me troubleshoot why my CloudShell VPC environment cannot connect to my private RDS MySQL instance

• Create the test table and insert sample data by running these SQL statements:

USE examdb;

CREATE TABLE products (
  id INT AUTO_INCREMENT PRIMARY KEY,
  name VARCHAR(100),
  price DECIMAL(10,2)
);

What does this table do?

This creates a simple products table with an auto-incrementing ID, a product name, and a price. You will check for this exact data after migrating to Aurora to confirm nothing was lost.

• Insert sample rows by running:

INSERT INTO products (name, price) VALUES
  ('Cloud Keyboard', 49.99),
  ('Serverless Mouse', 29.99),
  ('Lambda Lamp', 19.99);

• Verify the data was inserted by running:

SELECT * FROM products;

You should see three rows returned with the product names and prices you just inserted.

• Exit the MySQL prompt by typing:

EXIT;

Take a manual snapshot

A snapshot captures the state of your database at a specific point in time. You will use this snapshot to create your Aurora cluster in the next step.

• Return to the RDS Console in your browser.
• In the left navigation, click Databases.
• Select the radio button next to rds-source-db.
• Click Actions, then Take snapshot.
• For Snapshot name, enter rds-pre-migration-snapshot.
• Click Take snapshot.

The snapshot takes 2-3 minutes to complete. Before you check, what status do you expect the snapshot to show once it finishes?

• In the left navigation, click Snapshots.
• Wait until rds-pre-migration-snapshot shows status Available. Refresh the page if needed.

The status shows Available. Your source database and its snapshot are ready for migration.

Snapshot stuck in Creating?

Snapshot creation depends on the database size. With only a few rows of data, it should complete in under 3 minutes. If it takes longer, refresh the Snapshots page. Confirm you selected the correct instance (rds-source-db) when creating the snapshot.

help me troubleshoot why my RDS snapshot is not becoming available

Your source RDS MySQL instance is live with test data, and the snapshot is ready. Next up, you will migrate this snapshot to Aurora and explore the powerful endpoint architecture that makes Aurora different from standard RDS.

Migrate to Aurora and Explore Endpoints

In the previous step, you created an RDS MySQL instance and took a snapshot of your data. Your snapshot is ready, but your data is still sitting on a standard RDS instance.

Now you will migrate that snapshot to Amazon Aurora, which gives you a completely different storage architecture. Aurora stores 6 copies of your data across 3 Availability Zones, supports up to 15 read replicas, and auto-scales storage up to 256 TiB. This step is your early win: real data running on Aurora with separate read and write endpoints.

In this step, get ready to:

• Migrate your RDS snapshot to an Aurora MySQL cluster using Serverless v2.
• Identify the three Aurora endpoints (Cluster, Reader, and instance).
• Add a reader instance and verify data is accessible from both endpoints.

Migrate your snapshot to Aurora

The Migrate snapshot action in the RDS Console creates a new Aurora cluster directly from your existing snapshot. This is the fastest migration path and the one most commonly tested on the SAA-C03.

• In the RDS Console, click Snapshots in the left sidebar.
• Select your snapshot rds-pre-migration-snapshot.
• Click Actions, then select Migrate snapshot.
• For Engine type, choose Aurora MySQL.
• Set DB cluster identifier to aurora-exam-cluster.
• For the instance class, select Serverless v2.
• Set Minimum ACUs to 0.5 and Maximum ACUs to 2.
• Under Additional configuration, confirm the database name is examdb.
• Click Migrate.

What is Serverless v2?

Aurora Serverless v2 automatically scales compute capacity based on your workload. Each Aurora Capacity Unit (ACU) provides approximately 2 GiB of RAM and associated CPU.

With a minimum of 0.5 ACUs and maximum of 2 ACUs, your cluster scales between 1 GiB and 4 GiB of RAM on demand. You only pay for the capacity you actually use, making this ideal for a learning exercise.

Aurora Serverless v2 supports a minimum of 0 ACUs, which means your cluster can scale to zero when completely idle. For this project you use 0.5 to avoid cold-start delays, but for development or infrequent workloads, setting the minimum to 0 eliminates compute charges entirely during idle periods. The exam tests this as the cost-optimized answer for unpredictable or intermittent database workloads.

The migration takes approximately 10 minutes. Wait for the cluster status to change to Available before continuing.

What about the other migration method?

The SAA-C03 tests two migration paths: snapshot restore (what you just did) and the Aurora Read Replica method. The snapshot method is faster but involves brief downtime.

The Read Replica method creates an Aurora replica of your live RDS instance, then promotes it. It achieves near-zero downtime but takes longer to complete. Know both for the exam.

💡 When should you choose Aurora over standard RDS?

The SAA-C03 tests when Aurora is the right answer over standard RDS. Choose Aurora when you need more than 5 read replicas (Aurora supports up to 15), automatic storage scaling beyond 64 TiB (Aurora scales to 256 TiB), faster failover (typically under 30 seconds), or the shared storage model where replicas don't copy data.

Choose standard RDS when you need a simpler, lower-cost option for small workloads, when your database engine isn't MySQL or PostgreSQL, or when you want more control over storage provisioning. Aurora costs approximately 20% more per hour than equivalent RDS instances, so it's not always the cost-optimized answer for simple, predictable workloads.

Explore the Aurora endpoints and verify your data

Aurora automatically creates multiple endpoints when it provisions a cluster. Each endpoint serves a different purpose, and the exam tests when to use each one.

• In the RDS Console, click Databases in the left sidebar.
• Click on your cluster aurora-exam-cluster to open its detail page.
• Scroll down to the Endpoints section.

You should see three endpoints listed.

What are the three Aurora endpoints?

• Cluster endpoint (writer) always routes to the current writer instance. Use this for all write operations and reads that need the latest data.
• Reader endpoint load-balances connections across all available reader instances. Use this for read-heavy workloads to distribute the load.
• Instance endpoint connects directly to a specific instance. Useful for diagnostics but rarely used in application code.

Now verify your migrated data is intact on the writer endpoint.

• Connect to the cluster (writer) endpoint using CloudShell or the EC2 instance you used in the previous step.
• Run the following query to confirm your data migrated:

SELECT * FROM examdb.products;

You should see the same product rows you inserted in Step 1. This confirms the snapshot migration preserved your data.

Not seeing your data?

• Make sure the cluster status shows Available before attempting to connect.
• Confirm you are connecting to the Cluster endpoint (writer), not the instance endpoint.
• Check that your connection is using the same VPC and security group as the Aurora cluster.

Why can't I connect to my Aurora cluster?

Add a reader instance

Your cluster currently has one writer instance. Aurora's shared storage architecture means adding a reader does not copy any data. The new reader simply points at the same underlying storage volume.

• In the RDS Console, select your cluster aurora-exam-cluster.
• Click Actions, then select Add reader.
• For the instance class, choose Serverless v2.
• Set Minimum ACUs to 0.5 and Maximum ACUs to 2.
• Set the DB instance identifier to aurora-exam-reader-1.
• Click Add reader.

Why is adding a reader so fast?

In standard RDS, creating a read replica copies the entire dataset. Aurora uses a shared storage volume. All instances (writer and readers) access the same 6 copies of data across 3 AZs. Adding a reader only provisions new compute. No data copying needed.

• Wait for aurora-exam-reader-1 to show status Available.

What is the difference between Aurora Standard and I/O-Optimized?

Aurora offers two storage configurations. Aurora Standard charges per million I/O requests on top of instance and storage costs. Aurora I/O-Optimized eliminates I/O charges entirely but increases instance and storage prices.

The exam tests the cost threshold: if your I/O spending is 25% or more of your total Aurora database spending, I/O-Optimized saves up to 40% on costs. You can switch from Standard to I/O-Optimized once every 30 days. For this short project, Standard keeps costs minimal since your I/O volume is negligible.

Before you verify, predict: if you connect to the Reader endpoint and query the products table, will you see the same rows as the writer endpoint? Why or why not?

• Connect to the Reader endpoint (not the cluster endpoint).
• Run the same query:

SELECT * FROM examdb.products;

You see the exact same rows. Both endpoints read from the same shared storage volume, so the data is identical.

Reader endpoint returning an error?

• Confirm the reader instance status is Available before connecting.
• Make sure you are using the Reader endpoint from the cluster's Endpoints section, not the instance endpoint.
• Verify your security group allows inbound traffic from your connection source.

Why is my Aurora reader endpoint not responding?

What is Aurora backtracking?

Aurora MySQL supports backtracking, which rewinds your database to a specific point in time without restoring from a backup. Unlike point-in-time recovery (which creates a new cluster), backtracking operates on the existing cluster and completes in seconds.

The SAA-C03 tests backtracking as the answer for scenarios requiring fast recovery from human errors (accidental DELETE or DROP statements) without provisioning a new database. Backtracking is only available for Aurora MySQL, must be enabled when the cluster is created, and supports a maximum backtrack window of 72 hours.

Your data is now running on Aurora with shared storage and separate read/write endpoints. Next up, you will add RDS Proxy in front of your cluster to handle connection pooling and faster failover.

Add RDS Proxy for Connection Pooling

Your Aurora cluster is running with separate reader and writer endpoints. Direct connections work fine when you have one client, but production workloads look very different.

Imagine hundreds of Lambda functions or microservices, each opening its own database connection. You quickly exhaust the connection limit and your application starts failing. RDS Proxy solves this by sitting between your application and Aurora, pooling and reusing connections so the database never gets overwhelmed.

In this step, get ready to:

• Store your database credentials in AWS Secrets Manager.
• Create an RDS Proxy targeting your Aurora cluster.
• Verify the proxy is healthy and note its endpoint.

Store database credentials in Secrets Manager

RDS Proxy does not accept a username and password directly. Instead, it retrieves credentials from AWS Secrets Manager. You need to create a secret that stores your Aurora admin credentials before the proxy can authenticate on your behalf.

• Open the Secrets Manager console by searching for Secrets Manager in the AWS Console search bar and selecting it.
• Click Store a new secret.
• For Secret type, select Credentials for Amazon RDS database.
• For User name, enter admin.
• For Password, enter the master password you set when creating your RDS instance in Step 1.
• For Database, select your Aurora cluster aurora-exam-cluster from the dropdown.
• Click Next.
• For Secret name, enter aurora-exam-proxy-secret.
• Click Next on the Configure rotation page (leave rotation off for now).
• On the Review page, click Store.

You should see aurora-exam-proxy-secret appear in your secrets list with status showing it was stored successfully.

Why does RDS Proxy need Secrets Manager?

RDS Proxy manages a pool of persistent connections to your database. It needs credentials to establish those connections, but storing credentials in the proxy configuration directly would be a security risk. Secrets Manager provides encrypted storage and automatic rotation support.

The proxy retrieves the credentials from your secret at runtime and uses them to authenticate against Aurora on behalf of your application.

🙋‍♀️ Don't see your Aurora cluster in the Database dropdown?

Make sure you are in the us-east-1 region. Secrets Manager only shows databases in the same region. Also confirm your Aurora cluster status is Available in the RDS console.

help me find my Aurora cluster in the Secrets Manager database dropdown

Create the RDS Proxy

With your credentials stored, you can now create the proxy itself. The proxy will sit in front of your Aurora cluster and manage all incoming database connections.

• Return to the RDS console by searching for RDS in the AWS Console search bar.
• In the left navigation pane, click Proxies.
• Click Create proxy.
• For Proxy identifier, enter aurora-exam-proxy.
• For Engine family, select MySQL.
• Under Target group configuration, for Database, select your Aurora cluster aurora-exam-cluster.
• Under Authentication, for Secrets Manager secret(s), select aurora-exam-proxy-secret (the secret you just created).
• Leave Transport Layer Security set to Require TLS.
• Under Connectivity, select the same VPC and security group as your Aurora cluster (rds-migration-sg).
• Click Create proxy.

The proxy takes approximately 3 to 5 minutes to become available. You will see its status change from Creating to Available.

Why use the same security group?

RDS Proxy uses the security group for both ingress (applications connecting to the proxy) and egress (the proxy connecting to Aurora). By sharing the same security group as your Aurora cluster, resources within the group can communicate with each other without additional rules.

💡 What is connection pooling?

Connection pooling means the proxy maintains a set of persistent database connections. When your application connects, the proxy assigns an existing idle connection instead of opening a new one. When your application disconnects, the proxy returns that connection to the pool instead of closing it.

This dramatically reduces the load on Aurora. Instead of 500 Lambda functions each holding their own connection, the proxy might reuse just 10 to 20 connections across all of them.

Verify proxy health and note the endpoint

Before you move on, you need to confirm the proxy can actually reach your Aurora instances. The Target groups section shows the health of each registered database instance.

• In the RDS console, click Proxies in the left navigation, then click aurora-exam-proxy to open its detail page.
• At the top, confirm the Status shows Available.
• Locate the Proxy endpoint field. Copy this endpoint and save it somewhere accessible. This is the address your applications would connect to instead of the Aurora cluster endpoint directly.
• Scroll down to the Target groups section and click the default target group link.
• In the Targets section, confirm that both your writer instance and aurora-exam-reader-1 show a state of Available.

What do you expect to see in the target group? Before you check, predict whether both instances will show as healthy or whether one might lag behind.

Both targets should show state Available. This confirms the proxy can successfully authenticate against Aurora using your Secrets Manager credentials and reach both the writer and reader instances.

What does the proxy endpoint replace?

In production, your application would connect to the proxy endpoint instead of the Aurora cluster endpoint. The proxy handles connection pooling (reuses idle connections), multiplexing (shares backend connections across clients), and failover (automatically pins connections to the new writer within seconds if a failover occurs).

The SAA-C03 exam tests this pattern specifically for Lambda functions and connection-heavy microservices. If a question mentions exhausting database connections, RDS Proxy is the answer.

🙋‍♀️ Targets showing Unavailable?

If a target shows state Unavailable with reason AUTH_FAILURE, the credentials in your Secrets Manager secret do not match the database password. Go to Secrets Manager, select your secret, and verify the username and password match your Aurora master credentials.

If the reason shows UNREACHABLE, your security group is not allowing traffic between the proxy and Aurora. Confirm both use the same security group and that the group allows inbound traffic from itself.

help me troubleshoot my RDS Proxy target health

Your Aurora cluster now has a connection management layer in front of it. Applications connect to the proxy endpoint, the proxy handles pooling and failover routing, and Aurora handles the actual queries. Next up, you will extend this architecture across regions with Aurora Global Database.

Create a Global Database (Secondary Region)

Your Aurora cluster is resilient within a single region. It stores 6 copies of your data across 3 Availability Zones. But what happens if the entire us-east-1 region goes down?

Aurora Global Database solves this by replicating your data to secondary regions using dedicated infrastructure with typical latency under one second. The SAA-C03 heavily tests this pattern: "how do you achieve cross-region disaster recovery with RPO near zero?" In this step, you will extend your cluster to a second region and observe the replication in real time.

In this step, get ready to:

• Add a secondary region (us-west-2) to create a Global Database.
• Verify the secondary cluster topology and endpoints.
• Monitor the replication lag metric in CloudWatch.

Add a secondary region to your Aurora cluster

You will use the Add AWS Region action on your existing cluster. This converts your standalone Aurora cluster into a Global Database with a primary in us-east-1 and a secondary in us-west-2.

• In the RDS Console (us-east-1), click Databases in the left navigation pane.
• Select your cluster aurora-exam-cluster.
• Click Actions, then choose Add AWS Region.
• On the Add a region page, choose US West (Oregon) us-west-2 as the secondary AWS Region.
• For Global database identifier, enter aurora-exam-global.
• For DB cluster identifier (the secondary cluster), enter aurora-exam-cluster-west.
• For the instance class, select Serverless v2. Set Minimum ACUs to 0.5 and Maximum ACUs to 2.
• Leave one reader instance to be created in us-west-2 (the default).
• Click Add Region.

What happens behind the scenes?

Aurora creates a Global Database container (aurora-exam-global) that groups your primary cluster in us-east-1 and the new secondary cluster in us-west-2. The secondary cluster shares no storage with the primary. Instead, Aurora uses dedicated replication infrastructure to stream committed changes from the primary to the secondary with typical latency under one second.

The secondary cluster receives its own Reader endpoint, but it has no writer endpoint. All writes must go through the primary cluster in us-east-1.

💡 What is the difference between Aurora Global Database and standard read replicas?

Standard Aurora read replicas live in the same region and share the same cluster storage volume. A Global Database replicates entire committed transactions to a separate storage volume in another region using physical replication.

This gives you an entire independent copy of your data that can be promoted to a standalone cluster if the primary region fails.

The secondary cluster takes approximately 10-15 minutes to become Available. You can watch the status change from Creating to Available in the Databases list.

Don't see the Add AWS Region option?

Make sure you selected the cluster itself (not an individual instance) in the Databases list. The Add AWS Region action only appears for the cluster-level item. Also confirm the cluster status is Available before attempting the action.

Help me troubleshoot this issue.

Verify the secondary cluster in us-west-2

Once the secondary cluster shows Available, you need to confirm it has the correct role and endpoint configuration.

• Switch to the RDS Console in us-west-2 by selecting US West (Oregon) from the Region selector in the top-right corner of the console.
• Click Databases in the left navigation pane.
• Confirm you see aurora-exam-cluster-west with status Available and role Secondary.
• Click on the cluster name to open the detail page.
• Note the Reader endpoint listed under Connectivity & security. This is the endpoint applications in us-west-2 would connect to for read traffic.
• Confirm there is no Cluster (writer) endpoint for this secondary cluster. All writes go through the primary in us-east-1.

Why no writer endpoint on the secondary?

In an Aurora Global Database, the primary cluster owns all write operations. The secondary cluster is read-only. This guarantees a single source of truth and avoids split-brain scenarios.

If you need the secondary to accept writes, you enable write forwarding (covered in the next step) or perform a switchover to promote it.

• Click on aurora-exam-global in the Databases list to view the Global Database topology. You should see the primary cluster in us-east-1 and the secondary cluster in us-west-2 listed together.

Monitor replication lag in CloudWatch

The exam tests the AuroraGlobalDBReplicationLag metric when asking about RPO for Global Database failover scenarios. This metric is available only in secondary AWS Regions and measures the average time elapsed (in milliseconds) replicating updates between the primary and secondary clusters.

• While still in us-west-2, open the CloudWatch console by searching for CloudWatch in the AWS search bar and selecting it.
• In the left navigation pane, click Metrics, then All metrics.
• Choose the RDS metric namespace.
• Select the Per-Database Metrics dimension (or search for AuroraGlobalDBReplicationLag in the search bar).
• Find and select the AuroraGlobalDBReplicationLag metric for your aurora-exam-cluster-west cluster.
• Observe the graph. With typical workloads, this value should show sub-second values (often under 100ms).

What does AuroraGlobalDBReplicationLag tell you?

This metric measures the average time elapsed replicating updates between the primary cluster's replication server and the secondary cluster's replication server. A lower value means less data would be lost in an unplanned failover.

The exam expects you to know this metric is directly proportional to potential data loss (RPO) during a region outage. Aurora Global Database supports up to 10 read-only secondary AWS Regions. For production systems, you would set a CloudWatch alarm on this metric to alert you if lag exceeds your RPO target.

Before you move on, what do you expect to see if you check the cluster role back in us-east-1? Think about whether it has changed from a standalone cluster to something new.

• Switch back to the RDS Console in us-east-1 using the Region selector.
• Click Databases and confirm that aurora-exam-cluster now shows role Primary (previously it had no global role).

Your cluster in us-east-1 is now labeled Primary because it is part of the Global Database. In us-west-2, your secondary cluster shows role Secondary with sub-second replication lag confirmed in CloudWatch.

Not seeing the AuroraGlobalDBReplicationLag metric?

Make sure you are viewing CloudWatch in us-west-2 (not us-east-1). This metric is only available in secondary AWS Regions. Also allow a few minutes after the secondary cluster becomes Available for CloudWatch to start collecting data points.

Help me find this metric.

Your database is now globally distributed. Data written in us-east-1 replicates to us-west-2 in under a second using dedicated infrastructure. Next up, you will enable write forwarding so your secondary region can issue writes without requiring separate connections to the primary.

Enable Write Forwarding and Test Cross-Region Writes

Your Aurora Global Database is replicating data from us-east-1 to us-west-2 in under a second. But what about applications in the secondary region that need to write data?

Without write forwarding, those applications must maintain separate connections to the primary cluster in us-east-1 for any write operations. Aurora's write forwarding feature eliminates this complexity. The secondary cluster automatically forwards write statements to the primary, which commits them and replicates the changes back to all secondary regions.

In this step, get ready to:

• Enable write forwarding on the secondary cluster in us-west-2.
• Execute a write from a reader instance in us-west-2 and confirm it reaches the primary.
• Verify the new row appears on both the writer and reader endpoints across regions.

Enable write forwarding on the secondary cluster

Write forwarding is configured on the secondary cluster, not the primary. You modify the secondary to tell it to forward any write statements it receives to the primary cluster in us-east-1.

• Switch to the RDS Console in us-west-2.
• In the navigation pane, click Databases.
• Select the secondary cluster aurora-exam-cluster-west.
• Click Modify.
• Scroll to the Read replica write forwarding section.
• Check the Turn on global write forwarding checkbox.
• Click Continue.
• Select Apply immediately, then click Modify cluster.

Why no reboot?

Enabling or disabling write forwarding does not cause downtime or a reboot. The secondary cluster begins accepting forwarded writes within seconds of the modification completing.

• Wait about 30 seconds, then refresh the cluster detail page.
• Click the Configuration tab.
• Look for Global write forwarding and confirm the status shows Enabled.

Still seeing Enabling or Requested?

Write forwarding can take up to a minute to propagate. Refresh the page after another 30 seconds. If the status remains stuck, confirm you selected Apply immediately rather than scheduling the change for the next maintenance window.

Help me troubleshoot write forwarding not enabling on my secondary cluster

Insert a row from us-west-2 using write forwarding

Now you will connect to a reader instance in us-west-2 and issue a write. Normally, a reader cannot process writes. With write forwarding enabled, the secondary forwards the statement to the primary in us-east-1.

• Open CloudShell in the us-west-2 region (check the region selector in the top-right corner of the console).
• Find the reader endpoint for aurora-exam-cluster-west on the cluster detail page under Endpoints. It will look like aurora-exam-cluster-west.cluster-ro-xxxxxxxx.us-west-2.rds.amazonaws.com.
• Connect to the reader endpoint by running this command (replace the endpoint with yours):

mysql -h aurora-exam-cluster-west.cluster-ro-[[READER_ENDPOINT="xxxxxxxx.us-west-2.rds.amazonaws.com"]] -P 3306 -u admin -p

• Enter your master password when prompted.

Before you can issue a write, you must set the read consistency mode for this session. This tells Aurora how to handle reads after a forwarded write.

• Set the session variable for read consistency by running:

SET aurora_replica_read_consistency = 'SESSION';

What are the three consistency modes?

The aurora_replica_read_consistency parameter accepts three values:

• EVENTUAL returns results immediately, even if forwarded writes have not replicated back yet.
• SESSION waits until all writes from THIS session replicate back before returning reads. Best balance of consistency and performance.
• GLOBAL waits until ALL committed writes (from any session) replicate back. Strongest guarantee but highest latency.

The SAA-C03 exam tests your understanding of when to recommend each mode. SESSION is most commonly recommended because it ensures a session sees its own writes without waiting for unrelated transactions.

Before you run the INSERT, think about what you expect to happen. Will it succeed on a reader instance?

• Insert a test row by running:

INSERT INTO examdb.products (name, price) VALUES ('Global Widget', 29.99);

The INSERT succeeds. The secondary forwarded it to the primary in us-east-1, which committed the row and began replicating it back.

• Verify the row is visible in this session (SESSION consistency ensures it waits for replication) by running:

SELECT * FROM examdb.products WHERE name = 'Global Widget';

You should see a row with Global Widget and price 29.99 returned. This proves your write was forwarded and the replicated result is already visible in the same session.

INSERT failed with an access denied error?

Confirm you connected to the reader endpoint (contains cluster-ro in the hostname), not an instance endpoint. Write forwarding routes from the cluster reader endpoint.

Also verify the Configuration tab shows Global write forwarding as Enabled. If it still shows Enabling, wait another minute and retry.

Help me fix my INSERT failing with write forwarding enabled

Verify the write reached us-east-1

The secondary forwarded the write, and you confirmed it locally with SESSION consistency. Now you will connect directly to the primary writer in us-east-1 to prove the row exists at the source of truth.

• Exit the current MySQL session in us-west-2:

EXIT;

• Switch CloudShell to the us-east-1 region, or open a new CloudShell tab in us-east-1.
• Find the cluster (writer) endpoint for aurora-exam-cluster on the cluster detail page in us-east-1. It will look like aurora-exam-cluster.cluster-xxxxxxxx.us-east-1.rds.amazonaws.com.
• Connect to the writer endpoint by running:

mysql -h aurora-exam-cluster.cluster-[[WRITER_ENDPOINT="xxxxxxxx.us-east-1.rds.amazonaws.com"]] -P 3306 -u admin -p

Before you query, predict: do you expect the row to be here? Remember, write forwarding sends the INSERT to the primary. It was committed here first, then replicated back to us-west-2.

• Run the same SELECT query to check for the forwarded row:

SELECT * FROM examdb.products WHERE name = 'Global Widget';

You should see the Global Widget row with price 29.99. This confirms write forwarding works end-to-end. The secondary in us-west-2 forwarded the INSERT to the primary in us-east-1, the primary committed it, and it replicated back to the secondary.

What does this prove for the exam?

Write forwarding simplifies application architecture. Applications in secondary regions can issue writes without maintaining separate connections to the primary. The exam tests this as the answer to scenarios asking how to reduce endpoint management complexity in a Global Database.

Remember that write forwarding does not support DDL changes (like CREATE TABLE or ALTER TABLE) or SELECT FOR UPDATE statements. Those must still go directly to the primary writer.

🙋‍♀️ Row not showing up in us-east-1?

If the SELECT returns no rows on the primary, double-check you connected to the cluster endpoint (writer), not the reader endpoint. Also confirm you specified the database with USE examdb; before running the query.

Help me find my forwarded write on the primary cluster

Write forwarding is live and verified across both regions. Next up, you will use this Global Database to perform a managed switchover and relocate the primary to a different region.

Secret mission

Perform a Managed Switchover

Your Global Database replicates data across regions in under a second. But what happens when you need to relocate the entire primary to another region with zero data loss? In this secret mission, you will perform a managed switchover, promoting your secondary cluster to primary and proving the new topology works end-to-end.

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 AWS services across two regions, so leaving resources running will incur ongoing charges.

Cost warning

Your Aurora Global Database (Serverless v2 in two regions), RDS Proxy, and standard RDS instance are all billed hourly. The combined cost is approximately $0.15-0.25/hour while running. If you are not planning to continue experimenting immediately, choose Pause or Delete to avoid unexpected charges.

Resources you used:

• Aurora Global Database (aurora-exam-global) spanning us-east-1 and us-west-2.
• Aurora cluster in us-west-2 (aurora-exam-cluster-west) with Serverless v2 instances.
• Aurora cluster in us-east-1 (aurora-exam-cluster) with Serverless v2 instances.
• RDS Proxy (aurora-exam-proxy) in us-east-1.
• RDS MySQL instance (rds-source-db) in us-east-1.
• RDS snapshot (rds-pre-migration-snapshot).
• Secrets Manager secret (aurora-exam-proxy-secret) in us-east-1.
• Security group (rds-migration-sg) in us-east-1.

Keep everything running

No action needed. Choose this if you are still actively building or experimenting with Aurora features.

• Your Aurora Serverless v2 clusters will continue billing at the minimum 0.5 ACU rate per region (approximately $0.06/ACU-hour per region).
• The RDS Proxy bills at approximately $0.015/vCPU-hour.
• The RDS MySQL instance bills at approximately $0.017/hour (or is covered under Free Tier if eligible).
• The Secrets Manager secret bills at $0.40/month prorated.

Pause - I'll come back to this later

Shut down running processes to reduce costs while keeping your configuration intact. Storage charges continue, but compute charges can be minimized.

• Stop the RDS MySQL instance: In the RDS Console (us-east-1), select rds-source-db, choose Actions, then Stop temporarily. The instance will auto-restart after 7 days.
• Aurora Serverless v2 clusters cannot be manually stopped, but if you modify the minimum ACU capacity to 0, the cluster scales down when idle. Note that storage charges continue.
• The RDS Proxy remains active and continues billing. You cannot pause a proxy independently.
• Snapshots and Secrets Manager secrets continue to bill at storage rates while paused.

Delete - I don't want to use this again

Remove all project resources completely. Follow this order to avoid dependency errors.

Why does order matter?

You cannot delete the primary Aurora cluster while it is part of a Global Database. You must remove secondaries first, then delete clusters. The RDS Proxy must be deleted before its target cluster.

• Remove the secondary region from the Global Database: In the RDS Console (us-east-1), go to Databases. Select the aurora-exam-cluster cluster (currently role Secondary). Choose Actions, then Remove from Global. Click Remove and promote to confirm. This detaches us-east-1 and makes it a standalone cluster.
• Remove the primary from the Global Database: Once the secondary is removed, go to the RDS Console in us-west-2. Select aurora-exam-cluster-west. Choose Actions, then Remove from Global. Confirm removal. The Global Database aurora-exam-global is automatically deleted once all clusters are removed.
• Delete the RDS Proxy: In the RDS Console (us-east-1), go to Proxies. Select aurora-exam-proxy. Choose Actions, then Delete. Confirm the deletion.
• Delete the Aurora cluster in us-east-1: In the RDS Console (us-east-1), go to Databases. Delete each instance (reader first, then writer) by selecting the instance, choosing Actions, then Delete. Uncheck Create final snapshot and acknowledge the data loss warning. Once all instances are deleted, the cluster aurora-exam-cluster is removed automatically.
• Delete the Aurora cluster in us-west-2: In the RDS Console (us-west-2), repeat the same process for aurora-exam-cluster-west. Delete each instance (reader first, then writer). Uncheck Create final snapshot to avoid ongoing snapshot charges.
• Delete the RDS MySQL source instance: In the RDS Console (us-east-1), select rds-source-db. Choose Actions, then Delete. Uncheck Create final snapshot and confirm.
• Delete the snapshot: In the RDS Console (us-east-1), go to Snapshots. Select rds-pre-migration-snapshot. Choose Actions, then Delete snapshot. Confirm.
• Delete the Secrets Manager secret: Open the Secrets Manager console in us-east-1. Select aurora-exam-proxy-secret. In the Secret details section, choose Actions, then Delete secret. Set the Waiting period to 7 days (the minimum). Choose Schedule deletion. The secret becomes inaccessible immediately and is permanently deleted after 7 days.
• Delete the security group: In the EC2 Console (us-east-1), go to Security Groups in the left navigation. Select rds-migration-sg. Choose Actions, then Delete security groups. Confirm deletion. If this fails, wait a few minutes for the RDS instance deletion to fully propagate.

That's a Wrap!

That's a Wrap!

Nice work. You just built a production-grade Aurora architecture from the ground up, starting with a standard RDS MySQL instance and ending with a multi-region Global Database capable of zero-data-loss region switching.

You've learned how to:

• Migrate a standard RDS MySQL database to Aurora using the snapshot restore method, and front your cluster with RDS Proxy for connection pooling and failover routing.
• Build an Aurora Global Database spanning two regions with sub-second replication, backed by 6 copies of your data across 3 AZs per region.
• Enable write forwarding with SESSION consistency so a secondary region can issue writes without application code changes, and explain the trade-offs between EVENTUAL, SESSION, and GLOBAL modes.
• Secret Mission: Performed a managed switchover relocating the primary cluster to another region with zero data loss (RPO=0), and verified the new topology functions correctly.

Ready to quiz yourself?