Optimize Resource Utilization

Connect to both hosts and configure the CLI

Connected via SSH to CafeInstance (the web tier) and to the CLI Host (the operator bastion) using the lab's labsuser.pem private key. The key was first locked down with chmod 400 — required for SSH to accept it.

On the CLI Host, ran aws configure with the lab credentials, the region read from the instance metadata service (IMDS), and JSON output. IMDS is the right answer for "what region am I in?" — it doesn't require AWS credentials and works from inside the EC2:

# Discover the region from inside the EC2 (no credentials needed)
curl http://169.254.169.254/latest/dynamic/instance-identity/document | grep region

# Then configure the AWS CLI with the lab keys + that region
aws configure
# AWS Access Key ID:     <AccessKey from lab credentials>
# AWS Secret Access Key: <SecretKey from lab credentials>
# Default region name:   us-west-2
# Default output format: json

Uninstall the decommissioned MariaDB server

The local MariaDB was already stopped after the RDS migration, but the package was still installed and pulling ~137 MB of disk and a chunk of memory at boot. Stopped the service to be safe, then removed the package with -y to skip interactive prompts. yum resolved six dependencies and dropped them in the same transaction.

# On CafeInstance — make sure nothing is using the local DB
sudo systemctl stop mariadb

# Remove the package; yum pulls 6 dependencies with it
sudo yum -y remove mariadb-server

The transaction summary shows the six co-removed packages, the total 137 MB reclaimed, and the standard yum lifecycle (Erasing → Verifying → Complete!):

Downsize the instance from t3.small to t3.micro (CLI)

Driven entirely from the CLI Host. Four aws ec2 calls do the work, but the order is non-negotiable: describe → stop → modify → start → poll. modify-instance-attribute rejects the change unless the instance state is stopped.

3.1 — Find the instance by tag

Filtering by tag:Name=CafeInstance instead of hard-coding the ID makes the script portable across lab sessions, since the instance ID changes every time the environment is recreated.

aws ec2 describe-instances \
  --filters "Name=tag:Name,Values=CafeInstance" \
  --query "Reservations[*].Instances[*].[InstanceId,InstanceType,State.Name,PublicDnsName,PublicIpAddress]"

3.2 — Stop, modify, start

The --instance-type argument takes the structured form {"Value":"t3.micro"} — this is the only field on modify-instance-attribute that uses that shape, a quirk of the underlying API. stop-instances returns immediately but the state transition (running → stopping → stopped) takes ~30–60 seconds.

# Stop the instance — required before changing the type
aws ec2 stop-instances --instance-ids <CafeInstance-ID>

# Wait until State.Name == "stopped" (poll describe-instances or use the waiter)
aws ec2 wait instance-stopped --instance-ids <CafeInstance-ID>

# Swap the instance type
aws ec2 modify-instance-attribute \
  --instance-id <CafeInstance-ID> \
  --instance-type "{\"Value\": \"t3.micro\"}"

# Bring it back up
aws ec2 start-instances --instance-ids <CafeInstance-ID>

3.3 — Verify the new type and the new endpoint

Polled describe-instances with a tight --query projection. The four fields that matter post-restart are the type (must be t3.micro), the new public DNS, the new public IP, and the state (running).

aws ec2 describe-instances \
  --instance-ids <CafeInstance-ID> \
  --query "Reservations[*].Instances[*].[InstanceType,PublicDnsName,PublicIpAddress,State.Name]"

# Expected output after the restart:
# [
#   [
#     [ "t3.micro",
#       "ec2-54-184-228-111.us-west-2.compute.amazonaws.com",
#       "54.184.228.111",
#       "running" ]
#   ]
# ]

Hit http://ec2-54-184-228-111.us-west-2.compute.amazonaws.com/cafe/ in a browser — the café homepage rendered cleanly, the navbar (Home / About Us / Contact Us / Menu / Order History) was intact, and the catalog photos loaded. t3.micro is enough for this workload now that MariaDB isn't co-located.