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
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, not0.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
- Go to RDS → Subnet groups.
- The default VPC already has a
defaultsubnet group covering its subnets. - For your own VPC, create a subnet group and add subnets from at least two AZs.
Step 3: Create the Database
- Go to RDS → Databases → Create database.
- Choose Standard create and engine MySQL.
- Template: Free tier or Dev/Test, depending on what your account shows.
- Settings:
- DB instance identifier:
mydb-rds - Master username:
admin - Credentials: choose Managed in AWS Secrets Manager (recommended), or set a strong password yourself
- DB instance identifier:
- Instance configuration: a small burstable class such as
db.t4g.microordb.t3.micro. - Storage:
- Type: General Purpose SSD (gp3), 20 GiB
- Enable storage autoscaling with a sensible maximum
- Connectivity:
- VPC and subnet group: your chosen ones
- Public access: No
- VPC security group:
rds-sg
- 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
- Initial database name:
- Click Create database. It takes a few minutes to reach Available.
- Open the database and copy its Endpoint.
Step 4: Connect from EC2
- Connect to your EC2 instance (launch one with
ec2-app-sgin the same VPC if you don't have one). - Install a MySQL client:
sudo dnf install -y mariadb105
- Connect using the RDS endpoint:
mysql -h <your-rds-endpoint> -u admin -p
If you used Secrets Manager, open the secret in the console and choose Retrieve secret value to get the password.
- 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;
You now have a working managed database that only your app server can reach.
Step 5: Turn On Multi-AZ
- Select your database and click Modify.
- Under Availability, choose Create a standby instance (Multi-AZ).
- 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
- Select the database, then Actions → Reboot.
- Check Reboot with failover? and confirm.
- Watch the Events tab and the database's AZ. The standby is promoted, and the AZ changes.
- 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
- Select the database and choose Actions → Create read replica.
- Give it an identifier such as
mydb-rds-replica. - 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:
- Delete the read replica first (if you created one)
- Turn off deletion protection, then delete the DB instance
- Decide whether to keep a final snapshot (it costs storage) and whether to delete automated backups
- Delete leftover manual snapshots
- Delete the security groups and the EC2 instance if no longer needed
- 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
- LinkedIn: vishalpatil-devops-aws
- dev.to: @vishal_patil_aws
- GitHub: VishalPatil-DevOps-AWS
Top comments (0)