Migrating to Amazon RDS

Seed the existing database with order data

Opened the café website at CafeInstanceURL, placed a few orders from the Menu, and noted the order count on the Order History tab. That number is the integrity check at the other end of the migration: same number of orders must show up after the cutover.

Build the network prerequisites for RDS (CLI)

Connected to the CLI Host via EC2 Instance Connect and ran aws configure with the lab's AccessKey, SecretKey, LabRegion and JSON output. All the following commands run from that host.

2.1 — Dedicated security group for the DB

CafeDatabaseSG protects the future RDS instance. The inbound rule allows TCP 3306, but instead of opening a CIDR range it uses another security group as the source — only instances attached to CafeSecurityGroup can reach the DB. Cleaner than CIDRs because it follows the workload, not the IP.

aws ec2 create-security-group \
  --group-name CafeDatabaseSG \
  --description "Security group for Cafe database" \
  --vpc-id <CafeVpcID>

aws ec2 authorize-security-group-ingress \
  --group-id <CafeDatabaseSG Group ID> \
  --protocol tcp --port 3306 \
  --source-group <CafeSecurityGroup Group ID>

aws ec2 describe-security-groups \
  --query "SecurityGroups[*].[GroupName,GroupId,IpPermissions]" \
  --filters "Name=group-name,Values='CafeDatabaseSG'"

2.2 — Two private subnets in different AZs

The VPC is 10.200.0.0/20 and the public subnet already occupies 10.200.0.0/24. RDS requires a DB subnet group with at least two subnets in different Availability Zones — even for a Single-AZ instance — so failover targets exist. Picked 10.200.2.0/23 in the same AZ as the app (for proximity) and 10.200.10.0/23 in a second AZ as the failover slot.

# Private subnet 1 — same AZ as CafeInstance
aws ec2 create-subnet \
  --vpc-id <CafeVpcID> \
  --cidr-block 10.200.2.0/23 \
  --availability-zone <CafeInstanceAZ>

# Private subnet 2 — a different AZ (e.g. us-west-2b)
aws ec2 create-subnet \
  --vpc-id <CafeVpcID> \
  --cidr-block 10.200.10.0/23 \
  --availability-zone <other-AZ>

aws rds create-db-subnet-group \
  --db-subnet-group-name "CafeDB Subnet Group" \
  --db-subnet-group-description "DB subnet group for Cafe" \
  --subnet-ids <PrivateSubnet1ID> <PrivateSubnet2ID> \
  --tags "Key=Name,Value=CafeDatabaseSubnetGroup"

Provision the RDS MariaDB instance with the CLI

One create-db-instance call with everything inlined: engine, version, size, storage, AZ, SG, subnet group, no public access, root credentials. The call returns immediately but the instance takes ~10 minutes to reach available.

aws rds create-db-instance \
  --db-instance-identifier CafeDBInstance \
  --engine mariadb \
  --engine-version 10.11.11 \
  --db-instance-class db.t3.micro \
  --allocated-storage 20 \
  --availability-zone <CafeInstanceAZ> \
  --db-subnet-group-name "CafeDB Subnet Group" \
  --vpc-security-group-ids <CafeDatabaseSG Group ID> \
  --no-publicly-accessible \
  --master-username root \
  --master-user-password 'Re:Start!9'

Polling the lifecycle

Used describe-db-instances with a --query projection so the output is a flat array of the five fields that actually matter while waiting: endpoint, AZ, backup window, retention, and status. The status walks through creating → modifying → backing-up → configuring-enhanced-monitoring → available, and the endpoint is null until very late in that chain.

aws rds describe-db-instances \
  --db-instance-identifier CafeDBInstance \
  --query "DBInstances[*].[Endpoint.Address,AvailabilityZone,PreferredBackupWindow,BackupRetentionPeriod,DBInstanceStatus]"

Migrate data: dump on the source, restore over TLS to RDS

Connected to the CafeInstance (web tier) via EC2 Instance Connect — this is the host that can reach the new SG because CafeSecurityGroup is the authorized source for CafeDatabaseSG.

4.1 — Dump the local database

--add-drop-database makes the dump self-contained: the restore drops cafe_db first if it exists, then recreates it. Safe to re-run.

mysqldump --user=root --password='Re:Start!9' \
  --databases cafe_db --add-drop-database > cafedb-backup.sql

less cafedb-backup.sql   # quick sanity check on schema + INSERTs

4.2 — Pull the RDS CA bundle

Modern RDS requires TLS by default. Without --ssl-ca the connection is refused. The CA bundle is a static URL — pulled once with curl to the local working directory.

curl -o global-bundle.pem \
  https://truststore.pki.rds.amazonaws.com/global/global-bundle.pem

4.3 — Restore the dump and verify

Same mysql binary, now pointed at the RDS endpoint with the CA bundle and the SQL file piped in via <. Then an interactive session against cafe_db and a SELECT * FROM product to confirm row integrity. The product table is the catalog the website displays, so if it's intact, the menu page will render correctly after the cutover.

# Restore (silent — no output on success)
mysql --user=root --password='Re:Start!9' \
  --host=<RDS-Endpoint> \
  --ssl-ca=./global-bundle.pem \
  < cafedb-backup.sql

# Verify
mysql --user=root --password='Re:Start!9' \
  --host=<RDS-Endpoint> \
  --ssl-ca=./global-bundle.pem \
  cafe_db
MariaDB [cafe_db]> select * from product;

Cut the app over via Parameter Store

The PHP café app doesn't hardcode its DB URL — it reads /cafe/dbUrl from AWS Systems Manager Parameter Store on each request. The cutover is therefore a single edit:

• Systems Manager → Parameter Store → /cafe/dbUrl → Edit.
• Replace the value (previously localhost or the EC2 private IP) with the RDS endpoint cafedbinstance.cfm9rpzhbev6.us-west-2.rds.amazonaws.com.
• Save. No restart, no redeploy.

Verification: reload CafeInstanceURL in the browser, open Order History, and confirm the order count matches what was recorded in Task 1. Same number → same data → migration succeeded.

Sanity-check monitoring in CloudWatch

RDS publishes a fixed set of instance metrics to CloudWatch every minute, no extra setup required. The Monitoring tab on the DB instance page exposes them as pre-built graphs.

Sanity-checked the live signal: opened an interactive mysql session from the CafeInstance to RDS and waited a minute — the DatabaseConnections graph went from 0 to 1. Ran exit, waited another minute, refreshed — back to 0. Confirms metrics are flowing on the standard 1-minute granularity.