The Café Database Migration

---

The café currently operates on a “Monolithic” architecture where the web server, the application code, and the MariaDB database all reside on a single Amazon EC2 instance. While this worked for a startup phase, the growth of the business now requires a more robust, durable, and scalable solution.

The Objectives

1. Provisioning: Launch a MariaDB instance on Amazon RDS.
2. Security: Configure VPC Security Groups to allow specific traffic.
3. Data Extraction: Use mysqldump to create a logical backup of the existing order history.
4. Migration: Inject the data into the RDS instance.
5. Reconfiguration: Update the application to point to the new endpoint via AWS Secrets Manager.

---

Phase 1: Provisioning the Managed Infrastructure

The first step is moving away from the “server” mindset to the “service” mindset. Instead of installing MariaDB on an OS, we request a managed instance from AWS.

RDS Configuration Details

In the RDS Console, create a new database with these specific parameters:

• Engine & Version: Select MariaDB. This ensures compatibility with the existing application code.
• Template: Choose Dev/Test. This disables high-availability features (like Multi-AZ) to save costs during the migration testing phase.
• Instance Identifier: Name it CafeDatabase.
• Credentials: Set the Master Username to admin. For the password, use Caf3DbPassw0rd!. Note that in a production environment, you would use a randomly generated secret.
• Hardware Scaling: Choose Burstable Classes (db.t3.micro). This is sufficient for the café’s current traffic while allowing for “bursts” of CPU activity during peak ordering hours.
• Connectivity:
  • VPC: Select Lab VPC.
  • Subnet Group: Select lab-db-subnet-group. This ensures the database is placed in a private network segment.
  • Public Access: Select No. This is a critical security best practice; your database should never be directly accessible from the internet.

---

Phase 2: Establishing the Security Handshake

In AWS, resources are “secure by default.” Even though your EC2 web server and RDS database are in the same VPC, they cannot communicate until you explicitly open a “door” in the Security Group.

Updating Inbound Rules

1. Locate the Security Group assigned to the RDS instance (e.g., dbSG).
2. Add an Inbound Rule:
   • Type: MySQL/Aurora (Port 3306).
   • Source: Do not use 0.0.0.0/0. Instead, search for the Security Group ID of your CafeServer EC2 instance.
   • Result: This creates a “Least Privilege” environment where only the web server has the “key” to talk to the database.

---

Phase 3: Data Extraction (The Logical Dump)

Before we switch over, we must preserve the “Order History” that Martha and Frank rely on for business intelligence. We perform a “Logical Migration” using the mysqldump utility.

The Execution

Connect to the CafeServer via Session Manager. This allows terminal access directly through your browser without needing SSH keys.

1. Switch Users: sudo su - ec2-user to ensure you are operating with the correct permissions.
2. Locate the Secret: The café uses AWS Secrets Manager. Retrieve the current local password:Bash# Command to view secrets (simplified) aws secretsmanager get-secret-value --secret-id /cafe/dbPassword
3. Perform the Dump:Bashmysqldump --databases cafe_db -u root -p > CafeDbDump.sql This command freezes the state of the cafe_db and writes all table structures and row data into a single text file (.sql).

---

Phase 4: Data Injection into Amazon RDS

With the data “packaged” in the CafeDbDump.sql file, we now push it to the remote RDS instance.

The Migration Command

You need the RDS Endpoint (found in the RDS Connectivity tab).

Bash

mysql -u admin -p --host <RDS-ENDPOINT-URL> < CafeDbDump.sql

This command tells the MySQL client: “Connect to the RDS host as admin, prompt me for the password, and then execute all the SQL commands inside the dump file.” Once finished, the RDS instance is a perfect clone of the local database.

---

Phase 5: Cutover and Secrets Management

The final phase is the “Cutover.” We must tell the PHP application to stop looking at localhost and start looking at the Amazon RDS Endpoint.

Updating AWS Secrets Manager

The café application is modern; it doesn’t hard-code credentials. It fetches them from Secrets Manager. You must update three specific keys:

1. /cafe/dbUser: Change from root to admin.
2. /cafe/dbPassword: Change to Caf3DbPassw0rd!.
3. /cafe/dbUrl: Replace localhost or the old IP with the RDS Endpoint.

Validation (The “Moment of Truth”)

To ensure the application is truly using RDS, stop the local MariaDB service on the EC2 instance:

Bash

sudo service mariadb stop

Now, refresh the café website. If the Order History loads, you have successfully decoupled your data layer from your application layer.

---

Challenge Lab Quiz: Answer Key

Question	Correct Answer	Explanation
1. Where is the RDS instance running?	At the Availability Zone level	RDS instances are physically located in one AZ (unless Multi-AZ is enabled).
2. Does it have an IPv4 Public IP?	No	For security, RDS instances in a private subnet do not get public IPs.
3. What is the Subnet Name tag?	Private Subnet 1 (or 2)	Databases belong in private subnets to prevent external attacks.
4. How many SG rules are defined?	1	Only one inbound rule for Port 3306 is required for the EC2-to-RDS link.

---

Final Reflection

By migrating to Amazon RDS, the café has achieved Operational Excellence. Sofía no longer needs to manually patch the OS, and Martha’s order history is now backed up automatically by AWS’s managed snapshot system.

Er. Bikash Subedi