AWS Databases: RDS, Aurora, ElastiCache

Deploy a secured RDS MySQL instance and master AWS database architecture.

Introduction

30 Second Summary

Every app you use stores data somewhere. When that "somewhere" is the cloud, choosing the right database setup can mean the difference between a seamless user experience and a crashed application during peak traffic.

In this project, you will deploy a real RDS MySQL instance on AWS free tier, explore the architectural options behind Aurora and ElastiCache, and practice the database design decisions that the SAA-C03 exam tests.

What You'll Build

An architectural lab combining a live RDS MySQL deployment with deep exploration of AWS database services from the console.

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

A secured RDS MySQL instance configured with encryption at rest, restrictive Security Groups, and IAM Authentication.
Verified understanding of Multi-AZ vs Read Replicas, Aurora architecture, RDS Proxy use cases, and ElastiCache patterns.
A complete architectural design solving an enterprise scenario using Aurora Global Database and ElastiCache.
Secret Mission: Design and justify a multi-region architecture with Aurora Global Database, ElastiCache, and RDS Proxy for a global application.

Are there any prerequisites?

You need an active AWS account with legacy free tier (created before July 2025). Basic experience navigating the AWS Management Console is helpful but not required.

Launch RDS MySQL with Free Tier

The SAA-C03 exam dedicates roughly 26% of questions to resilient architectures and 24% to high-performing architectures. Databases sit at the center of both domains.

In this step, you'll deploy a real Amazon RDS MySQL instance using the free tier. This gives you a hands-on environment to explore the configuration options that directly map to exam questions.

In this step, get ready to:

Create a MySQL RDS instance with free tier settings.
Review Storage Autoscaling configuration.
Verify the instance is running and note its endpoint.

Create a MySQL RDS instance

On EC2, you would manage the operating system, database engine, patching, high availability, backups, and scaling entirely by yourself. Amazon RDS handles all of that for you as a managed service.

In the AWS Management Console, type RDS in the top search bar and select RDS from the results.
In the left navigation pane, click Databases.
Click Create database.
Select Standard create as the database creation method.

Now configure the engine and template:

Under Engine options, select MySQL as the engine type.
Under Templates, select Free tier.

Why Free tier template?

The Free tier template automatically disables Multi-AZ and selects cost-appropriate defaults. Your legacy free tier account includes 750 hours per month of Single-AZ db.t3.micro usage and 20 GB of gp2 storage for 12 months from account creation.

Configure the instance settings:

Under Settings, enter saa-lab-db for the DB instance identifier.
For Master username, leave the default value admin.
Enter a password you can remember in Master password and Confirm password.

Configure instance size and storage:

Under Instance configuration, confirm db.t3.micro is selected under Burstable classes.
Under Storage, confirm General Purpose SSD (gp2) is selected with 20 GiB allocated storage.
In the Storage autoscaling section, check that Enable storage autoscaling is enabled.
Set the Maximum storage threshold to 22 GiB.

Configure connectivity:

Under Connectivity, leave the default VPC selected.
For VPC security group (firewall), select Create new.

Configure backups:

Expand Additional configuration at the bottom of the page.
Under Backup, confirm automated backups are enabled with a retention period of 7 days.
Click Create database.

Why RDS instead of running MySQL on EC2?

RDS is a managed service that handles OS patching, automated backups, Multi-AZ failover, read replicas, and monitoring out of the box. On EC2, you would configure and maintain all of these manually.

On the exam, "managed database" and "reduce operational overhead" are signals pointing to RDS over a self-managed EC2 database.

Understand Storage Autoscaling

You just set a Maximum storage threshold of 22 GiB. This means RDS can automatically expand your storage up to that limit without downtime.

When does Storage Autoscaling trigger?

RDS auto-expands storage when all three conditions are met:

Free storage is less than 10% of allocated storage.
The low-storage condition lasts at least 5 minutes.
At least 6 hours have passed since the last storage modification.

This is a common SAA-C03 question pattern. If you see "application is running out of storage" in a scenario, the answer is often to enable Storage Autoscaling.

Verify the instance is running

Your instance will take a few minutes to launch. The status starts as Creating and transitions to Available when ready.

On the Databases page, wait for the Status of saa-lab-db to show Available.
Click the instance name saa-lab-db to open its details.
In the Connectivity & security tab, note the Endpoint URL and Port (3306).

What are these console tabs?

The RDS instance detail page has several tabs: Connectivity & security, Monitoring, Configuration, Maintenance & backups. Each maps directly to exam topic areas: networking, performance metrics, instance settings, and backup/recovery.

Instance stuck on Creating?

RDS instances can take 5 to 20 minutes to become available depending on configuration. If it remains in Creating for more than 20 minutes, check the Events section in the left navigation for error messages.

help me troubleshoot my RDS instance that is stuck in Creating status

Your RDS MySQL instance is live. Next up, you'll lock it down with encryption, Security Groups, and IAM Authentication.

Secure Your RDS Instance

Your RDS MySQL instance is live and accepting connections. A running database is only half the story. A misconfigured database is one of the most common security risks in cloud environments.

In this step, you'll lock down your instance with three layers of protection: encryption, network access controls, and token-based authentication. These map directly to the SAA-C03's "Design Secure Architectures" domain, which accounts for 30% of the exam.

In this step, get ready to:

Verify encryption at rest is enabled on your RDS instance.
Configure restrictive Security Group rules to limit database access.
Enable IAM database authentication for token-based access.

Verify encryption at rest and in transit

Your data needs to be protected both when it's stored on disk (at rest) and when it travels between your application and the database (in transit). Let's verify that both are covered.

In the RDS console, click on your saa-lab-db instance to open its details page.
Select the Configuration tab.
Scroll down to the Storage section and look for Encryption. It should show Enabled.
Note the KMS key listed. By default, new RDS instances use the AWS-managed key aws/rds.

What is encryption at rest?

Encryption at rest means your data is encrypted on the physical storage disks using AWS KMS (Key Management Service). This protects against unauthorized access to the underlying hardware.

A critical exam fact: you cannot encrypt an existing unencrypted RDS database directly. The process is: create a snapshot, copy the snapshot with encryption enabled, then restore from the encrypted snapshot. This always creates a new DB instance with a new endpoint.

What about encryption in transit?

Encryption in transit uses SSL/TLS to protect data traveling between your application and the database. For MySQL, clients connect with --ssl-mode=REQUIRED to enforce encrypted connections.

You won't configure SSL in this project since you're not connecting a client application. The key exam takeaway is that both at-rest and in-transit encryption are available for RDS.

Configure restrictive Security Group rules

Right now, your RDS instance's Security Group may have a default rule that's too permissive. In production, you should restrict database access to only the application tier or your specific IP address.

On your saa-lab-db details page, select the Connectivity & security tab.
Under Security, find the VPC security groups section and click on the linked Security Group name to open it in the EC2 console.
Select the Inbound rules tab.
Click Edit inbound rules.
Delete any existing inbound rules by clicking the Delete button next to each rule.
Click Add rule.
For Type, select MYSQL/Aurora. This automatically sets the port to 3306.
For Source, select My IP. This restricts access to only your current IP address.
Click Save rules.

Why My IP instead of Anywhere?

Selecting My IP restricts access to your current public IP address only. In a real production environment, you would reference another Security Group (for example, the application server's SG) instead of an IP address. This way, only instances in that group can reach the database.

On the SAA-C03, the exam signal "restrict database access to only the application tier" means creating an inbound rule where the source is the app server Security Group.

Don't see any Security Group link?

Make sure you're on the Connectivity & security tab of your RDS instance, not the Configuration tab. The VPC security groups are listed under the Security heading on that tab.

If you accidentally removed all inbound rules without adding a new one, go back to Edit inbound rules and add a MYSQL/Aurora rule with My IP as the source.

Help me configure my RDS Security Group inbound rules

Enable IAM database authentication

By default, RDS uses password-based authentication. IAM database authentication replaces stored passwords with short-lived tokens generated through the AWS API. This is more secure because no credentials are stored in your application code.

Return to the RDS console and select your saa-lab-db instance.
Click Modify.
Scroll down to the Database authentication section.
Select Password and IAM database authentication.
Click Continue.
In the Scheduling of modifications section, select Immediately.
Click Modify DB instance.

The modification applies with no downtime. After a few moments, your instance will show IAM authentication as enabled.

Why use IAM database authentication?

IAM authentication tokens are valid for 15 minutes and generated via the AWS API. This means no database passwords are stored in your application code. Access is centralized through IAM policies instead.

On the SAA-C03, the exam signals for IAM authentication are: "centralized authentication", "no database passwords in application code", or "manage database access through IAM policies". IAM database authentication works with MySQL, PostgreSQL, and MariaDB.

What about audit logging?

You can also publish IAM database authentication logs to CloudWatch Logs for auditing purposes. This helps track who is authenticating to your database and when. For this lab, you can skip enabling log exports to avoid storage charges.

Verify your changes by clicking on your saa-lab-db instance and selecting the Configuration tab.
Confirm that IAM DB authentication shows Enabled.
Confirm that Encryption shows Enabled.

IAM DB authentication still showing Disabled?

If you selected Apply during the next maintenance window instead of Immediately, the change won't take effect until the scheduled maintenance window. Go back to Modify, re-select Password and IAM database authentication, and this time choose Immediately in the scheduling section.

Help me enable IAM authentication on my RDS instance

Your database is now locked down with encryption at rest, a restrictive Security Group, and IAM-based authentication. Next up, you'll explore the high availability and read scalability patterns that are central to the SAA-C03 exam.

Explore High Availability and Read Scalability

Your RDS instance is now locked down with encryption, restrictive Security Groups, and IAM Authentication. Security is only one part of a production database architecture.

The SAA-C03 dedicates approximately 26% of questions to resilient architectures and 24% to high-performing architectures. Databases sit at the center of both domains. In this step, you will explore the two most critical architectural decisions for RDS: Multi-AZ deployments for high availability and Read Replicas for read scalability.

In this step, get ready to:

Compare Multi-AZ (high availability) with Read Replicas (read scalability) using the RDS console.
Understand the network cost rules for same-Region and cross-Region replication.
Review disaster recovery patterns including automated backups, manual snapshots, and cross-Region replicas.

Explore Multi-AZ vs Read Replicas from the console

Multi-AZ and Read Replicas solve different problems. The exam frequently tests whether you can pick the right one for a given scenario.

In the RDS console, click on your saa-lab-db instance.
Click the Modify button in the top right corner.
Scroll down to the Availability & durability section.
Observe the Multi-AZ deployment option. DO NOT enable it. Multi-AZ is not eligible for the free tier and would incur charges.
Click Cancel to exit the Modify screen without saving changes.

Now that you have seen where Multi-AZ lives in the console, let's compare the two architectures side by side.

What is Multi-AZ?

Multi-AZ creates a synchronous standby replica in a different Availability Zone. The standby is NOT accessible for reads. Its only purpose is high availability.

Purpose: High availability and disaster recovery.
Replication: Synchronous. Every write is confirmed on both instances before returning success.
Failover: Automatic, typically 60-120 seconds. The DNS CNAME endpoint updates to point to the new primary.
RPO: Zero data loss (synchronous replication guarantees this).
Data transfer cost: No charge for replication between primary and standby.

What are Read Replicas?

Read Replicas are asynchronous copies of your database that you CAN read from. They offload read traffic from the primary instance.

Purpose: Read scalability. Offload analytics, reporting, or heavy read workloads.
Replication: Asynchronous. There may be slight replication lag.
Failover: Manual promotion required. Not automatic.
Scaling: Up to 5 replicas for standard RDS MySQL. Can be same AZ, cross-AZ, or cross-Region.
Auto-scaling: RDS does NOT auto-scale read replicas. You must manually create or delete them.

Exam decision pattern

When the question says "automatic failover", "survive AZ failure", or "zero data loss", the answer is Multi-AZ. When the question says "offload read traffic", "analytics workload", or "reporting", the answer is Read Replicas.

Understand Read Replica network costs

Cost-optimization questions on the SAA-C03 frequently test your knowledge of data transfer charges. The rules for Read Replica replication are straightforward but easy to confuse.

What are the network cost rules for Read Replicas?

Same Region (same or cross-AZ): No charge for data replication between the source DB instance and the read replica.
Cross-Region: $0.02/GB out from the source Region for replication traffic.

For comparison, EC2 to RDS in different AZs within the same Region costs $0.01/GB in and $0.01/GB out.

Cross-Region replica cost optimization

For MySQL and MariaDB, you can create one replica from the source in the target Region. Then chain additional replicas from that first replica. Since intra-Region replication is free, you only pay the cross-Region transfer cost once.

Review disaster recovery patterns

The SAA-C03 tests multiple DR patterns for RDS. Each pattern has a different RPO and RTO tradeoff.

Return to your saa-lab-db instance details page in the RDS console.
Click the Maintenance & backups tab.
Observe the automated backup configuration: daily full backup with transaction logs captured every 5 minutes.

What are the RDS backup and restore patterns?

RDS offers two backup mechanisms, each with different retention and use cases.

Automated backups: Daily full backup plus transaction logs every 5 minutes. Enables point-in-time restore to any moment within the retention window. Retention: 1-35 days.
Manual snapshots: User-initiated. Retained until you explicitly delete them. No automatic expiration.
Restore behavior: Restoring a backup or snapshot ALWAYS creates a new DB instance with a new endpoint. You cannot restore into an existing instance.

How does cross-Region DR work with Read Replicas?

A cross-Region Read Replica can be promoted to a standalone database for disaster recovery. Because replication is asynchronous, there is potential data loss (the RPO is not zero).

Promotion is manual and creates a new independent database. For the exam: "RPO = 0 with automatic failover" means Multi-AZ. "Cross-Region DR with some data loss tolerance" means cross-Region Read Replica promotion.

You now understand the two pillars of RDS architecture: Multi-AZ for surviving failures and Read Replicas for scaling reads. Next up, you will dive into Amazon Aurora, which takes these same concepts and pushes them further with 6 copies of data across 3 AZs, auto-scaling replicas, and sub-30-second failover.

Explore Amazon Aurora Architecture

You now understand the critical distinction between Multi-AZ (high availability) and Read Replicas (read scalability) for standard RDS. But AWS offers something more powerful for workloads that need both.

Amazon Aurora is AWS's cloud-native relational database. It separates compute from storage, replicates data six times across three Availability Zones, and fails over in under 30 seconds. In this step, you'll explore Aurora's architecture from the console without creating any paid resources.

In this step, get ready to:

Explore the Aurora cluster architecture and understand how it differs from standard RDS.
Review Aurora Serverless, Global Database, and Custom Endpoints use cases.
Understand Aurora ML, backup behavior, and database cloning.

Explore the Aurora cluster architecture

Aurora uses a fundamentally different architecture from standard RDS. Instead of attaching storage to each instance, Aurora separates compute from storage entirely. All replicas in a cluster share the same underlying storage layer.

In the AWS Console, navigate to RDS (search for it in the top search bar if needed).
Click Create database in the Databases section.
Under Engine options, select Aurora (MySQL Compatible).
Scroll through the configuration options to see the Aurora-specific settings. Do NOT click Create database at the bottom. You are only exploring.

How does Aurora's storage work?

Aurora stores 6 copies of your data across 3 Availability Zones. It needs 4 copies out of 6 to process writes, and 3 copies out of 6 to process reads. This means Aurora can tolerate losing an entire AZ (2 copies) and still handle both reads and writes.

Storage auto-scales up to 128 TiB without any manual intervention. The storage layer uses self-healing peer-to-peer replication across hundreds of volumes. If a segment becomes corrupted, Aurora repairs it automatically from the other copies.

What makes Aurora different from standard RDS?

Up to 15 Aurora Replicas (standard RDS MySQL supports only 5 read replicas).
Failover to a new writer takes under 30 seconds (standard RDS Multi-AZ takes 60-120 seconds).
Aurora supports auto-scaling of read replicas based on CPU or connections. Standard RDS does not auto-scale replicas.
Compatible with MySQL and PostgreSQL.

What is RDS Custom?

RDS Custom gives you access to the underlying operating system and database engine. It is available only for Oracle and SQL Server. Use it when you need custom patches, third-party software on the DB host, or specific OS-level configurations that standard RDS does not allow.

Review Aurora Serverless, Global Database, and Custom Endpoints

Aurora offers several deployment options beyond the standard provisioned cluster. Each one solves a specific architectural problem that appears frequently on the SAA-C03.

In the Aurora creation wizard, look for the DB cluster storage configuration section. Notice the Aurora Serverless option if available.
Observe the instance configuration options. These map directly to Aurora's compute/storage separation model.
Click Cancel to exit the creation wizard without creating anything.

What is Aurora Serverless?

Aurora Serverless is an on-demand, auto-scaling configuration that scales compute capacity in increments of 0.5 Aurora Capacity Units (ACUs). It can scale all the way to zero when idle, meaning you pay nothing during periods of no activity.

Exam signal: when you see "unpredictable workload", "development/test environment", or "scales to zero", think Aurora Serverless.

What is Aurora Global Database?

Aurora Global Database spans multiple AWS Regions. It supports 1 primary Region for read/write operations and up to 10 secondary Regions for read-only access. Replication uses dedicated infrastructure with latency typically under 1 second.

A secondary Region can be promoted to full read/write in less than 1 minute.
Write forwarding allows secondary clusters to forward write requests to the primary Region.
Use case: global low-latency reads and cross-Region disaster recovery with RPO under 1 second.

What are Custom Endpoints?

Custom Endpoints let you route traffic to specific subsets of Aurora Replicas. For example, you can direct analytics queries to higher-memory instances while keeping OLTP traffic on standard instances. All instances share the same storage, but each endpoint targets a different compute tier.

Exam signal: "different instance types for different workloads in the same cluster" points to Custom Endpoints.

Understand Aurora ML, backups, and cloning

Aurora includes features that are not available in standard RDS. These come up on the SAA-C03 when the question requires capabilities beyond what a basic managed database provides.

What is Aurora Machine Learning?

Aurora ML exposes machine learning models as SQL functions. It integrates with SageMaker and Amazon Bedrock, allowing you to add predictions or sentiment analysis directly in SQL queries without moving data out of the database.

How do Aurora backups differ from RDS?

Aurora backups are continuous and incremental. Point-in-time restore goes back up to 5 minutes ago.
Automated backups cannot be disabled in Aurora (retention is always 1-35 days). In standard RDS, you can set retention to 0 to disable them.
Manual snapshots have no expiration in both Aurora and RDS.
Restoring a backup or snapshot always creates a NEW database cluster. You cannot restore into an existing cluster.

What is Aurora Database Cloning?

Aurora Cloning creates a new cluster from existing data using a copy-on-write protocol. The clone shares the same storage pages as the source until data diverges. This makes it fast and cost-efficient.

Exam signal: "test against production data without affecting production performance" points to Aurora Database Cloning.

Aurora-only features to remember

Aurora Serverless, Aurora Global Database, and Aurora ML integration are not available in standard Amazon RDS. If an exam question requires any of these capabilities, the answer must involve Aurora.

You've now mapped out Aurora's entire architecture. Next up, you'll explore RDS Proxy and ElastiCache to complete the database toolkit the SAA-C03 tests you on.

Explore RDS Proxy and ElastiCache

You now have a solid grasp of Aurora's architecture, from its 6-copy storage layer to Serverless scaling and Global Database replication.

But there's a gap between your application and the database that the SAA-C03 loves to test. What happens when hundreds of Lambda functions simultaneously open connections to your database? How do you serve repeated reads without hammering your database on every request? RDS Proxy and ElastiCache solve these problems.

In this step, get ready to:

Explore RDS Proxy and understand when it solves connection pooling problems.
Learn the three ElastiCache architecture patterns tested on the SAA-C03.
Differentiate Redis vs Memcached for exam decision questions.

Review RDS Proxy in the console

RDS Proxy sits between your application and database, pooling and reusing connections so your database never gets overwhelmed. This is especially critical for serverless architectures where each Lambda invocation opens a new connection.

In the RDS console, click Proxies in the left navigation panel.
Observe the empty proxies list. You won't create one today (it requires a target database group configuration), but review the information on this page.

The proxy page shows where you would configure target groups, IAM roles, and Secrets Manager associations. Here's what RDS Proxy provides:

What does RDS Proxy do?

RDS Proxy is a fully managed database proxy that pools and shares database connections. Your application connects to the proxy, and the proxy manages a pool of reusable connections to the actual database.

Connection pooling: reduces the number of open connections to your DB by sharing them across application instances.
Faster failover: reduces Multi-AZ failover time by up to 66%.
Security: enforces IAM authentication and integrates with Secrets Manager for credential rotation.
No code changes: your application connects to the proxy endpoint instead of the DB endpoint. That's the only change.

When does the SAA-C03 expect you to choose RDS Proxy?

Look for these signals in exam questions:

"Lambda functions exhausting database connections" = RDS Proxy.
"Too many connections to database" = RDS Proxy.
"Reduce failover time" = RDS Proxy.
"Serverless application + relational database" = RDS Proxy.

RDS Proxy supports RDS (MySQL, PostgreSQL, MariaDB, SQL Server) and Aurora (MySQL, PostgreSQL).

Why a proxy instead of increasing max connections?

Lambda functions are ephemeral. Each invocation opens a new connection, uses it briefly, then the connection hangs idle. With bursty traffic, hundreds of connections open simultaneously but most sit unused.

RDS Proxy caps the actual connections to the database and multiplexes application requests over that smaller pool. The database stays healthy even during traffic spikes.

Understand ElastiCache architecture patterns

ElastiCache is a managed in-memory caching service that delivers sub-millisecond reads. The SAA-C03 tests three specific patterns for how applications use a cache alongside a relational database.

What is the DB Cache (Lazy Loading) pattern?

Application queries ElastiCache first.
Cache hit: data returned immediately (sub-millisecond).
Cache miss: application queries RDS, stores the result in ElastiCache, then returns it.

Benefit: dramatically reduces load on RDS for repeated reads. Challenge: cached data can become stale if the underlying database changes.

What is the Write-Through pattern?

The application writes to both the database AND the cache simultaneously on every write operation. Reads always find fresh data in the cache, eliminating stale data. The trade-off is slower writes because every write operation hits two destinations.

What is the Session Store pattern?

Instead of storing user session data on the application server, store it in ElastiCache with a TTL (time-to-live). Any application instance can retrieve the session, making your application stateless.

Exam signal: "user loses session after failover" or "make application stateless" = ElastiCache Session Store.

ElastiCache requires code changes

Unlike RDS Proxy (which only changes the connection endpoint), using ElastiCache requires application code changes. Your application must implement the cache-check logic, cache-write logic, or session storage logic. This is a common exam distractor.

Differentiate Redis vs Memcached

ElastiCache supports two engines. The SAA-C03 frequently asks you to pick the right one based on requirements. Here's the breakdown:

When should you choose Redis?

Multi-AZ with automatic failover.
Read Replicas for high availability.
Data durability with AOF (Append Only File) persistence.
Backup and restore capabilities.
Supports complex data types like Sets and Sorted Sets (great for leaderboards and unique data).

Choose Redis when you need persistence, high availability, or complex data types.

When should you choose Memcached?

Multi-node data partitioning (sharding) for horizontal scaling.
No high availability or replication.
Non-persistent. Data is lost on restart.
Multi-threaded architecture for maximum raw performance.

Choose Memcached when you need simple key-value caching at maximum speed and don't care about persistence or HA.

How does ElastiCache security work?

ElastiCache does NOT support IAM authentication for the data plane. IAM only controls AWS API-level actions like creating or deleting clusters.

Redis authentication: Redis AUTH (password/token).
Memcached authentication: SASL-based.
Both support in-transit encryption (TLS) and at-rest encryption.

Exam trap: if a question says "use IAM to authenticate to ElastiCache", that answer is wrong. IAM works for RDS and Aurora authentication, but not for ElastiCache data access.

Quick exam decision patterns

"Need persistence + HA + complex data types" = Redis.
"Simple caching + maximum performance + multi-threaded" = Memcached.
"Reduce database load from repeated reads" = ElastiCache (either engine).
"Session store + stateless application" = ElastiCache Redis.

You now have the full picture of AWS database services. RDS Proxy handles connection management. ElastiCache accelerates reads and enables stateless applications. Next up, you'll put all of these concepts together in a real SAA-C03 architecture design challenge.

Secret mission

Design a Global Architecture

You've mastered each AWS database service individually. Now put them all together. Design a production-grade multi-region architecture for a global e-commerce company, solving a scenario exactly like the ones you'll face on the SAA-C03 exam.

Clean Up Your Resources

This project used a single RDS MySQL instance running on the AWS free tier. As long as your legacy free tier is active (12 months from account creation), the instance costs nothing within 750 hours per month. If your free tier has expired, leaving the instance running will incur charges.

Cost warning

If your AWS free tier has expired, the db.t3.micro instance will begin accruing charges immediately. Delete the instance after completing the project to guarantee $0 ongoing cost.

Resources you used:

RDS MySQL instance saa-lab-db (db.t3.micro, 20 GiB gp2, Single-AZ).
Security Group saa-lab-db-sg (inbound rule on port 3306).

Decide whether to keep your resources running, pause them to come back later, or delete them entirely.

Keep everything running

No action needed. Choose this if you are still actively reviewing the concepts or plan to revisit the RDS console soon.

Your instance remains free as long as you stay within 750 hours per month on your legacy free tier (12 months from account creation).
Monitor usage in the AWS Billing dashboard to confirm no unexpected charges.

Pause - I'll come back to this later

RDS allows you to temporarily stop an instance to save on compute costs. However, a stopped instance automatically restarts after 7 days to receive required maintenance updates.

In the RDS console, select saa-lab-db.
Choose Actions, then Stop temporarily.
Acknowledge the 7-day auto-restart warning and choose Stop temporarily.

Why does it restart after 7 days?

AWS restarts stopped instances automatically so they do not fall behind on required maintenance patches. If you do not need the instance after 7 days, delete it instead.

Delete - I don't want to use this again

Remove all project resources permanently. This ensures $0 ongoing cost regardless of your free tier status.

In the RDS console, choose Databases in the left navigation pane.
Select the saa-lab-db instance.
Choose Actions, then Delete.
Uncheck Create final snapshot? (you do not need a snapshot for this lab).
Uncheck Retain automated backups.
Type delete me in the confirmation box.
Choose Delete.

After the instance is deleted, remove the Security Group:

Navigate to the EC2 console, then choose Security Groups in the left navigation pane.
Search for the Security Group associated with saa-lab-db.
Select the Security Group, choose Actions, then Delete security groups.
Confirm the deletion.

Why delete the Security Group separately?

Deleting an RDS instance does not automatically remove its associated Security Group. The Security Group remains in your account until you delete it manually.

Nice Work!

Nice work! You just deployed a production-secured RDS MySQL instance and explored the full spectrum of AWS database architecture decisions that the SAA-C03 exam tests.

You've learned how to:

Deploy and secure an RDS MySQL instance with encryption at rest, restrictive Security Groups, and IAM Authentication to demonstrate managed database best practices.
Distinguish Multi-AZ (high availability, synchronous replication, automatic failover) from Read Replicas (read scaling, asynchronous replication, manual promotion) and architect Aurora solutions including Serverless, Global Database, and Custom Endpoints.
Apply RDS Proxy for Lambda connection pooling and faster failover, and implement ElastiCache patterns including Lazy Loading, Write-Through, and Session Store while differentiating Redis from Memcached.
Secret Mission: Design a complete multi-region architecture solving a real SAA-C03 scenario with Aurora Global Database, RDS Proxy, ElastiCache Redis, and Custom Endpoints.

Ready to quiz yourself?