Hands-On Lab: Implementing High-Performing Database Solutions

This lab is designed to align with Task 3.3: Determine high-performing database solutions from the AWS Certified Solutions Architect - Associate (SAA-C03) exam guide. In this 30-minute guided lab, you will deploy a managed Amazon Relational Database Service (RDS) instance and configure a Read Replica to horizontally scale your read operations.

We will also conceptually explore how this compares to caching strategies like Amazon ElastiCache, fulfilling the requirement to understand high-performing, decoupled data access patterns.

---

Prerequisites

Before starting this lab, ensure you have the following:

• AWS Account: An active AWS account (Free Tier eligible is sufficient).
• AWS CLI Installed: The aws command-line interface installed and configured with your credentials.
• IAM Permissions: AdministratorAccess or sufficient permissions to create and manage RDS databases and EC2 Security Groups.
• Prior Knowledge: Basic understanding of relational databases and the difference between managed RDS vs. self-managed EC2 databases.

[!WARNING] Cost Estimation: This lab uses db.t3.micro instances. If your account is outside the AWS Free Tier, running these instances will incur a small hourly charge (approx. $0.017/hr per instance). Remember to run the teardown commands to avoid ongoing charges.

---

Learning Objectives

By the end of this lab, you will be able to:

1. Provision a Managed Database: Deploy a primary Amazon RDS MySQL instance, offloading infrastructure management from EC2.
2. Scale Read Performance: Create a Read Replica to offload read-intensive queries from the primary database.
3. Understand Endpoints: Differentiate between primary (writer) and replica (reader) endpoints for application integration.
4. Visualize Caching: Understand where an ElastiCache layer would fit to further reduce latency.

---

Architecture Overview

Below are two diagrams illustrating the high-performing architecture we are building, as well as an advanced caching pattern you should know for the SAA-C03 exam.

1. Read Replica Architecture (Active Lab)

We are building a primary DB for writes and a replica for reads. This mitigates performance bottlenecks for read-heavy workloads.

2. Caching Strategy Integration (Concept)

For extreme performance (sub-millisecond latency), a caching service like ElastiCache is placed in front of the database. This is a "Look-aside" caching pattern.

---

Step-by-Step Instructions

Step 1: Create a Security Group for the Database

First, we need a security group that allows our application to communicate with the database over the standard MySQL port (3306).

[!TIP] We are using 0.0.0.0/0 for lab simplicity. In a production environment, you should restrict the CIDR block to your application's specific Security Group or IP range.

▶Console alternative

1. Navigate to EC2 > Security Groups in the AWS Console.
2. Click Create security group.
3. Enter brainybee-rds-sg as the name.
4. Under Inbound rules, click Add rule.
5. Set Type to MySQL/Aurora (3306) and Source to Anywhere-IPv4.
6. Click Create security group.

📸 Screenshot: The Security Group inbound rules configuration showing port 3306 open to 0.0.0.0/0.

Step 2: Provision the Primary RDS Instance

Now, we leave the heavy infrastructure lifting to AWS by opting for Amazon RDS instead of building our own platform on an EC2 instance.

[!NOTE] We enabled --backup-retention-period 1. Automatic backups must be enabled on the primary instance to create a Read Replica.

▶Console alternative

1. Navigate to RDS > Databases.
2. Click Create database.
3. Choose Standard create and MySQL.
4. Select the Free tier template.
5. DB instance identifier: brainybee-primary-db.
6. Master username: admin / Password: LabPassword123!.
7. Under Connectivity, select the brainybee-rds-sg security group.
8. Expand Additional configuration and ensure Backup retention period is set to at least 1 day.
9. Click Create database.

📸 Screenshot: The RDS configuration screen highlighting the automated backups setting required for replicas.

Step 3: Create a Read Replica

To meet high-performance read demands, we will configure a Read Replica. This decouples our workloads so that read requests do not compete with write requests for CPU and IOPS.

▶Console alternative

1. In the RDS Console, select your brainybee-primary-db instance.
2. Click the Actions dropdown menu in the top right.
3. Select Create read replica.
4. Enter brainybee-replica-db as the Replica DB instance identifier.
5. Leave other settings as default and click Create read replica.

📸 Screenshot: The Actions menu dropdown showing "Create read replica" for the primary database.

Step 4: Retrieve Database Endpoints

Your application requires specific endpoints to route writes to the primary DB and reads to the replica.

[!IMPORTANT] Notice that you receive two distinct URLs. Your application code must be configured to split SQL traffic (e.g., INSERT/UPDATE to the primary URL, SELECT to the replica URL).

---

Checkpoints

Verify your progress by checking the status of your databases. Provisioning can take 5-10 minutes.

Run the following verification command:

Expected Output:

If the status says creating, wait a few minutes and run the command again.

---

Clean-Up / Teardown

[!WARNING] Cost Warning: You MUST delete these resources to avoid ongoing AWS charges. RDS instances are billed per hour.

Execute the following commands in order to destroy the resources. We use --skip-final-snapshot to delete them quickly without backing up the empty lab data.

1. Delete the Read Replica:

2. Delete the Primary Database:

3. Delete the Security Group:

---

Troubleshooting