Ravindra BagaleCourses & study guides Track your progress

Labs · Cyber Security

Lab: Make an Amazon RDS MySQL Database Private – No Public Access, App-Server-Only Security Group and Automated Backups On

Intermediate50 minAWS account (Free Tier) · RDS · EC2 (Lab 4) · MariaDB client

Course: Cyber Security · Chapter 15: Amazon RDS for MySQL: Create, Connect, Back Up and Keep It Private

Chapter 15 creates, connects and backs up RDS and keeps it private; this lab proves the private part.

Chala mitrano! A database should never be reachable from the whole internet. Only the app server needs to talk to it. Today we build exactly that with RDS, then we test it from both sides: the app server can connect, our laptop cannot. Proof, not hope!

Suppose we are…

Suppose we are a cloud intern at Swiggy building a small internal tool. The developer asks for "a MySQL database with a public endpoint so I can connect from home". Our answer: no. We create an Amazon RDS (managed database) instance with Public access: No, a security group that allows port 3306 only from the app server's security group, and automated backups switched on.

Goal of this lab

By the end you will have:

  • A free-tier RDS MySQL database that is not publicly accessible.
  • A database security group whose only inbound rule allows MySQL from the EC2 server's security group.
  • Connected from EC2, failed from your laptop, checked the backup settings, and deleted everything.

What you need (all free)

  • Your AWS account (Free Tier) and a running free-tier EC2 Amazon Linux 2023 server in the same Region (Lab 4).
  • 45–50 minutes (RDS takes about 10 minutes to create).

Safety and ethics

Pick only the Free tier template and a micro instance class. Use a practice password. Delete the database at the end, without a final snapshot, so nothing keeps costing money.

Steps

  1. Open RDS → Databases → Create database.
  2. Choose Standard create, engine MySQL, and under Templates choose Free tier.
  3. DB instance identifier: lab-private-db. Master username: admin. Credentials management: Self managed; type a practice password twice.
  4. Instance configuration: the free-tier template selects a db.t3.micro or db.t4g.micro class. Keep 20 GiB gp2/gp3 storage and switch off storage autoscaling.
  5. Connectivity: choose Connect to an EC2 compute resource and select your EC2 server. AWS will create two security groups that allow MySQL only between this server and this database.

    What you should see: Public access: No is selected and cannot be changed while this option is on.

  6. Under Additional configuration, check Enable automated backups is ticked and set Backup retention period to 1 day. Click Create database. Wait until Status is Available.

  7. Open the database → Connectivity & security. Copy the Endpoint (like lab-private-db.abc123xyz.ap-south-1.rds.amazonaws.com). Note Publicly accessible: No.
  8. Click the VPC security group named rds-ec2-1 → Inbound rules.

    What you should see: one rule: MYSQL/Aurora, TCP 3306, source = a security group (sg-..., the ec2-rds-1 group), not an IP and not 0.0.0.0/0.

  9. SSH to your EC2 server, install the client and connect (replace the endpoint):

    sudo dnf install -y mariadb105
    mysql -h lab-private-db.abc123xyz.ap-south-1.rds.amazonaws.com -u admin -p
    

    What you should see: the MySQL [(none)]> prompt. Run SELECT VERSION(); then EXIT;.

  10. From your laptop, test the same endpoint (PowerShell):

    Test-NetConnection lab-private-db.abc123xyz.ap-south-1.rds.amazonaws.com -Port 3306
    

    On Mac/Linux use nc -vz -w 5 <endpoint> 3306.

    What you should see: TcpTestSucceeded : False (or a timeout). The name may resolve to a private 172.31.x.x address, which your laptop cannot reach. That is the goal.

  11. Back in RDS → your database → Maintenance & backups: confirm Automated backups: Enabled (1 Day) and note the backup window.

Ravindra Bagale's Tip

Allowing "security group to security group" is better than allowing an IP address. If the app server gets a new IP or you add a second app server in the same group, it still works, and nothing else can connect. Developers want to connect from home? Give them a bastion host or SSM, never a public database.

Common mistakes

Mistake What happens Fix
Template Production or Dev/Test Multi-AZ or bigger class, real charges Choose Free tier
Public access Yes "just for testing" Database endpoint reachable from the internet Keep No; connect from EC2
Inbound rule 3306 from 0.0.0.0/0 Bots can try passwords on your database Source must be the app server's security group
EC2 and RDS in different Regions or VPCs Connection times out from EC2 too Create RDS in the same Region and VPC as the server
Deleting the DB with a final snapshot "just in case" The snapshot keeps costing storage Untick final snapshot for practice databases

Self-check checklist

0 of 6 done

Try-at-home challenge

Using AWS CloudShell, write one command that lists every RDS database in the Region with its name and whether it is publicly accessible. Why is this a useful weekly check?

Check your answer
aws rds describe-db-instances --query "DBInstances[].[DBInstanceIdentifier,PubliclyAccessible]" --output table

It shows every database and True/False. A weekly look (or an AWS Config rule) catches a database someone made public by mistake before an attacker finds it.

Clean up to avoid charges

  1. RDS → Databases → select lab-private-db → Actions → Delete.
  2. Untick Create final snapshot and Retain automated backups, tick the acknowledgement, type delete me → Delete.
  3. After it is gone, check RDS → Snapshots (manual and system) shows nothing for this database.
  4. EC2 → Security Groups: delete rds-ec2-1 and ec2-rds-1 (first remove ec2-rds-1 from the EC2 server under Actions → Security → Change security groups if the server is still running).
  5. Terminate the EC2 server if you no longer need it.

Samjla ka? Public access No, security group to security group, backups On, delete after practice. Aata pudhe jaauya: Chapter 16 joins EC2, S3 and RDS in one project.