Amazon RDS
Managed databases. AWS handles backups, patching, and failover.
What is RDS?
Managed relational databases. Pick MySQL, PostgreSQL, or 6 other engines. AWS handles the rest. Automatic backups, patching, and failover. Focus on your app, not database ops.
Think of it like renting a managed apartment
You get the database (apartment), but AWS handles maintenance, backups, and repairs. You just use it - no DBA required for routine tasks.
Key Features
8 Database Engines
MySQL, PostgreSQL, MariaDB, Oracle, SQL Server, Aurora.
Multi-AZ
Automatic failover. Standby in another zone. 99.95% SLA.
Read Replicas
Scale reads. Up to 15 replicas with Aurora.
Automated Backups
Daily snapshots. Point-in-time recovery up to 35 days.
Performance Insights
See slow queries. Find bottlenecks fast.
Aurora Serverless
Auto-scales capacity. Pay per second of use.
When to Use
- Need relational database (SQL)
- Want managed backups and patching
- Require Multi-AZ failover
- Running standard MySQL/PostgreSQL
- Need read replicas for scaling
- Oracle/SQL Server licensing
When Not to Use
- NoSQL/key-value needs → DynamoDB
- Need custom DB config → EC2
- Graph databases → Neptune
- Time-series data → Timestream
- Data warehouse → Redshift
- Document store → DocumentDB
Prerequisites
- An AWS account (free tier eligible)
- VPC with subnets in multiple AZs
- Security group for database access
AWS Console Steps
Open RDS Dashboard
Navigate to RDS in the AWS Console and click 'Create database'
Choose Engine
Select your database engine (MySQL, PostgreSQL, etc.)
Select Template
Choose Production, Dev/Test, or Free tier template
Configure Instance
Set DB identifier, master username, and password
Choose Instance Class
Select db.t3.micro for free tier or larger for production
Configure Connectivity
Select VPC, subnet group, and security group
AWS CLI Quickstart
Create RDS instance with AWS CLI
Create a MySQL RDS instance using the AWS CLI
# Create DB subnet group
aws rds create-db-subnet-group \
--db-subnet-group-name my-subnet-group \
--db-subnet-group-description "My DB subnet group" \
--subnet-ids subnet-xxx subnet-yyy
# Create RDS instance
aws rds create-db-instance \
--db-instance-identifier mydb \
--db-instance-class db.t3.micro \
--engine mysql \
--master-username admin \
# ...Creates a MySQL RDS instance with 20GB storage. Takes 5-10 minutes to become available.
First Project Ideas
- Create a MySQL database for a web application
- Set up Multi-AZ for high availability
- Create a read replica for reporting queries
- Enable automated backups and test restore
- Connect from an EC2 instance in the same VPC
Pro Tips8
Multi-AZ vs Read Replicas
reliabilityMulti-AZ = high availability (auto failover). Read Replicas = read scaling (manual promotion).
Use Multi-AZ for HA. Add replicas for read-heavy apps.Don't rely on replicas for HA. They have lag.Use gp3 storage by default
performancegp3 gives 3,000 IOPS baseline. Scale IOPS independently. Cheaper than io1.
Start with gp3. Only use io1/io2 for extreme workloads.Don't over-provision io1 upfront. gp3 handles most cases.Enable Performance Insights
operationalSee slow queries without enabling logs. 7 days free. Essential for debugging.
Enable on all databases. Check it first when slow.Don't rely only on CloudWatch. It misses query details.Use RDS Proxy for Lambda
performanceLambda creates new connections per call. Proxy pools them. 97% fewer connections.
Always use Proxy for Lambda apps. Enable IAM auth.Don't connect Lambda directly. Connection storms crash DBs.Set 35-day backup retention
reliabilityEnables point-in-time recovery. Transaction logs every 5 min. Minimal cost.
Set max retention (35 days). Test PITR regularly.Don't set to 0. This disables ALL backups.Enable encryption at creation
securityCannot add encryption later. Must snapshot and restore to encrypt existing DBs.
Always enable encryption for new databases.Don't skip encryption. Migration requires downtime.Aurora Serverless v2 for variable traffic
costScales in seconds. Pay per ACU-hour. Great for dev/test and unpredictable loads.
Use for variable workloads. Set min ACU for baseline.Don't use for steady high traffic. Provisioned is cheaper.Create custom parameter groups
performanceDefault groups can't be modified. Create custom ones before you need tuning.
Create custom groups at setup. Test changes in dev.Don't wait for issues. Changes may need reboots.Key Facts8
Max storage: 64 TiB for most engines, 128 TiB for Aurora
SQL Server: 16 TiB. Aurora auto-scales storage.
limitRead replicas: 5 for most engines, 15 for Aurora
SQL Server has no read replicas.
limitBackup retention: 0-35 days. 0 = backups disabled
PITR requires retention > 0. Manual snapshots never expire.
limitMulti-AZ failover: 60-120 seconds
Automatic DNS switch. Standby does NOT serve reads.
behaviorMulti-AZ uses synchronous replication. Zero data loss.
Read Replicas use async. Some lag expected.
behaviorAurora: 128 TiB auto-scaling, 6 copies across 3 AZs
Self-healing storage. Continuous backup to S3.
behaviorDefault: 40 DB instances per region
max_connections depends on instance class memory.
limitMaintenance window: 30 min weekly, cannot disable
Multi-AZ fails over during maintenance. Minimal impact.
behavior