DEV Community

Cover image for AWS RDS Explained: Launch, Secure, and Scale a Managed Database
Vishal Patil
Vishal Patil

Posted on

AWS RDS Explained: Launch, Secure, and Scale a Managed Database


By Vishal Patil | #vishalcloudjourney

Running a database on your own EC2 instance means you are also the DBA. You patch the OS, schedule backups, set up replication, and wake up when the disk fills. Amazon RDS (Relational Database Service) takes that operational work off your plate so you can focus on your application. In this hands-on guide, you'll launch a MySQL database on RDS, lock it down, connect from EC2, test automatic failover, and learn how to scale reads.

What Is Amazon RDS?

Amazon RDS is a managed service for relational databases. You choose the engine and size, and AWS handles the heavy lifting.

Supported engines: Amazon Aurora (MySQL and PostgreSQL compatible), MySQL, PostgreSQL, MariaDB, Oracle, SQL Server, and Db2.

What AWS manages for you

  • Hardware provisioning and OS patching
  • Automated backups and point-in-time recovery
  • Database software patching during a maintenance window
  • Multi-AZ failover
  • Monitoring through CloudWatch

What you still manage

  • Schema design, queries, and indexes
  • Security groups, network placement, and user access
  • Choosing instance size and storage
  • Cost control

Note: With standard RDS you don't get SSH or OS-level access to the underlying host. That's the trade-off for a managed service.

What You Will Build

  • A security group setup where only your EC2 app server can reach the database
  • A private MySQL RDS instance with encryption and automated backups
  • A connection from EC2 to the database
  • A Multi-AZ standby and a failover test
  • (Optional) A read replica

Architecture:

EC2 app server (ec2-app-sg) → RDS MySQL primary (rds-sg, AZ-a)
                                  ↓ synchronous replication
                              RDS standby (AZ-b), takes over on failure
Enter fullscreen mode Exit fullscreen mode

Key Concepts in 60 Seconds

  • DB instance: The managed database server you pay for.
  • DB subnet group: The subnets (in at least two AZs) where RDS is allowed to place your database.
  • Multi-AZ: A standby copy in another AZ, kept in sync, that takes over automatically if the primary fails. It's for availability, not for read scaling.
  • Read replica: An asynchronously updated copy used to scale read traffic.
  • Automated backups: Daily backups plus transaction logs, kept for 1 to 35 days, enabling point-in-time restore.
  • Snapshot: A manual backup that stays until you delete it.
  • Endpoint: The DNS name your application uses to connect. Always use the endpoint, never an IP.

Prerequisites

  • An AWS account with permissions for RDS, EC2, and VPC
  • A VPC with subnets in at least two AZs (the default VPC works)
  • A running EC2 instance (Amazon Linux 2023) to act as your app server, or you can launch one in Step 4

Cost note: RDS bills while the instance is running, and Multi-AZ roughly doubles the instance cost. Check the current Free Tier terms for your account and follow the cleanup section at the end.

Step 1: Create the Security Groups

Use two security groups so the database is reachable only from your app server.

App security group (ec2-app-sg) attached to your EC2 instance

  • Inbound: SSH (22) from your IP, or use EC2 Instance Connect or Session Manager

Database security group (rds-sg)

  • Inbound: MySQL/Aurora (3306) from ec2-app-sg (select the security group as the source, not 0.0.0.0/0)

This is the single most important RDS security habit: never open your database port to the internet.

Step 2: Check the DB Subnet Group

  1. Go to RDS → Subnet groups.
  2. The default VPC already has a default subnet group covering its subnets.
  3. For your own VPC, create a subnet group and add subnets from at least two AZs.

Step 3: Create the Database

  1. Go to RDS → Databases → Create database.
  2. Choose Standard create and engine MySQL.
  3. Template: Free tier or Dev/Test, depending on what your account shows.
  4. Settings:
    • DB instance identifier: mydb-rds
    • Master username: admin
    • Credentials: choose Managed in AWS Secrets Manager (recommended), or set a strong password yourself
  5. Instance configuration: a small burstable class such as db.t4g.micro or db.t3.micro.
  6. Storage:
    • Type: General Purpose SSD (gp3), 20 GiB
    • Enable storage autoscaling with a sensible maximum
  7. Connectivity:
    • VPC and subnet group: your chosen ones
    • Public access: No
    • VPC security group: rds-sg
  8. Additional configuration:
    • Initial database name: appdb
    • Automated backups: enabled, retention 7 days
    • Encryption: enabled (this must be chosen at creation)
    • Deletion protection: on for anything important
  9. Click Create database. It takes a few minutes to reach Available.
  10. Open the database and copy its Endpoint.

Step 4: Connect from EC2

  1. Connect to your EC2 instance (launch one with ec2-app-sg in the same VPC if you don't have one).
  2. Install a MySQL client:
   sudo dnf install -y mariadb105
Enter fullscreen mode Exit fullscreen mode
  1. Connect using the RDS endpoint:
   mysql -h <your-rds-endpoint> -u admin -p
Enter fullscreen mode Exit fullscreen mode

If you used Secrets Manager, open the secret in the console and choose Retrieve secret value to get the password.

  1. Create a table and add data:
   USE appdb;
   CREATE TABLE visitors (id INT AUTO_INCREMENT PRIMARY KEY, name VARCHAR(50));
   INSERT INTO visitors (name) VALUES ('Vishal'), ('AWS Builder');
   SELECT * FROM visitors;
Enter fullscreen mode Exit fullscreen mode

You now have a working managed database that only your app server can reach.

Step 5: Turn On Multi-AZ

  1. Select your database and click Modify.
  2. Under Availability, choose Create a standby instance (Multi-AZ).
  3. Choose Apply immediately and confirm.

RDS creates a standby in another AZ and keeps it synchronized. Your endpoint stays the same.

Step 6: Test Failover

  1. Select the database, then Actions → Reboot.
  2. Check Reboot with failover? and confirm.
  3. Watch the Events tab and the database's AZ. The standby is promoted, and the AZ changes.
  4. Re-run your SQL query. Your data is still there, and the same endpoint works.

Expect a short interruption (typically a minute or two) while DNS flips to the new primary. Your application should retry failed connections.

Step 7 (Optional): Add a Read Replica

  1. Select the database and choose Actions → Create read replica.
  2. Give it an identifier such as mydb-rds-replica.
  3. Once available, point read-heavy queries at the replica's endpoint and keep writes on the primary.

Replication is asynchronous, so replicas can lag slightly behind the primary.

Multi-AZ vs Read Replica

Multi-AZ Read Replica
Purpose High availability and failover Read scaling
Replication Synchronous Asynchronous
Takes traffic normally No (standby only) Yes (reads)
Automatic failover Yes No (manual promotion)

Security Best Practices

  • Keep Public access set to No and place the DB in private subnets.
  • Allow access only from application security groups.
  • Use Secrets Manager for credentials and rotate them.
  • Enable encryption at rest (KMS) and enforce SSL/TLS connections.
  • Turn on deletion protection and automated backups.
  • Use IAM to control who can modify or delete DB instances.

Cost Tips

  • Pick the smallest instance that meets your needs and resize later.
  • Use Multi-AZ for production, but not for throwaway labs.
  • Stop or delete dev databases you aren't using. (A stopped RDS instance is automatically started again after 7 days.)
  • Delete old manual snapshots you no longer need.
  • Consider Reserved Instances for steady, long-running databases.

Common Issues and Fixes

Problem Likely cause Fix
Connection times out rds-sg doesn't allow 3306 from your app's SG Add the inbound rule with ec2-app-sg as source
Can't connect from your laptop Database is private (public access: No) Connect through EC2, a bastion, or Session Manager
Access denied for user Wrong username or password Re-check credentials or the Secrets Manager value
Unknown database Initial DB name wasn't set Run CREATE DATABASE appdb;
Storage full warnings Autoscaling off or limit reached Enable storage autoscaling or increase size

Clean Up

To avoid charges:

  1. Delete the read replica first (if you created one)
  2. Turn off deletion protection, then delete the DB instance
  3. Decide whether to keep a final snapshot (it costs storage) and whether to delete automated backups
  4. Delete leftover manual snapshots
  5. Delete the security groups and the EC2 instance if no longer needed
  6. Delete the Secrets Manager secret if you created one just for this lab

Conclusion

Amazon RDS lets you run production-grade relational databases without managing servers, patches, or backups by hand. With private networking, Multi-AZ, and automated backups, you get a secure and resilient foundation in minutes. Next, try adding a read replica, enabling Performance Insights, or moving to Aurora to see how far managed databases can go.

If you found this helpful, let's connect and keep learning together.

Connect with me

vishalcloudjourney

Top comments (0)