RDS: Managed Databases

Running databases in the cloud can be complex - you need to handle installation, patching, backups, scaling, and high availability. Amazon RDS (Relational Database Service) handles all of this for you, letting you focus on your data and applications. In this lesson, we'll explore managed databases with RDS.

What You'll Learn

By the end of this lesson, you'll understand how RDS works, the supported database engines, Multi-AZ deployments for high availability, and how to create and connect to an RDS database.

What is Amazon RDS?

Amazon RDS is a managed database service that makes it easy to set up, operate, and scale relational databases in the cloud.

What RDS Manages For You

Task	Self-Managed EC2	RDS Managed
Hardware provisioning	You	AWS
Database setup	You	AWS
Patching	You	AWS
Backups	You	AWS
High availability	You	AWS
Scaling	You	AWS (with a click)
Your data and queries	You	You

Supported Database Engines

RDS supports six popular database engines:

Engine	Description
Amazon Aurora	AWS-built, MySQL/PostgreSQL compatible, highest performance
MySQL	Popular open-source database
PostgreSQL	Advanced open-source database
MariaDB	MySQL fork with additional features
Oracle	Enterprise database (requires license)
SQL Server	Microsoft's database (requires license)

For new projects, PostgreSQL or Aurora are popular choices. Aurora offers up to 5x the performance of MySQL at a similar price point.

RDS Architecture

DB Instances

An RDS database runs on a DB instance - a virtual server in the cloud dedicated to running your database engine.

Instance classes:

• Standard (db.m6g, db.m5) - General purpose, balanced compute/memory
• Memory Optimized (db.r6g, db.r5) - Memory-intensive workloads
• Burstable (db.t3, db.t4g) - Variable workloads, cost-effective

Storage

RDS uses EBS for storage with three options:

Storage Type	IOPS	Use Case
General Purpose SSD (gp2/gp3)	Up to 16,000	Most workloads
Provisioned IOPS SSD (io1/io2)	Up to 256,000	High I/O, large databases
Magnetic	Low	Backwards compatibility only

VPC Integration

RDS instances run inside a VPC (Virtual Private Cloud):

• Place in private subnets for security
• Use security groups to control access
• Access from EC2 instances in the same VPC
• Optionally enable public access for external connections

Creating an RDS Database

Let's create a PostgreSQL database step by step.

Step 1: Open RDS Console

1. Go to AWS Console
2. Search for "RDS"
3. Click "Create database"

Step 2: Choose Creation Method

• Standard create - Full configuration options
• Easy create - Simplified setup with defaults

Choose "Standard create" for learning.

Step 3: Engine Options

1. Engine type: PostgreSQL
2. Version: Choose the latest available version
3. Templates: Choose "Free tier" for learning

Step 4: Settings

1. DB instance identifier: my-postgres-db
2. Master username: postgres (or your preferred username)
3. Master password: Create a strong password

Step 5: Instance Configuration

For Free Tier:

• Instance class: db.t3.micro or db.t4g.micro
• Storage: 20 GB gp2

Step 6: Connectivity

1. VPC: Default VPC (for learning)
2. Public access: Yes (for testing; No for production)
3. VPC security group: Create new
4. Database port: 5432 (PostgreSQL default)

Step 7: Additional Configuration

• Initial database name: myappdb
• Backup retention: 7 days (Free Tier)
• Enable deletion protection: No (for learning only)

Step 8: Create Database

Click "Create database" - provisioning takes 5-10 minutes.

Connecting to Your Database

Get Connection Details

From the RDS console, click your database and find:

• Endpoint: my-postgres-db.abc123.us-east-1.rds.amazonaws.com
• Port: 5432

Configure Security Group

Ensure your security group allows inbound traffic on port 5432 from your IP or EC2 instances.

Connect Using psql

psql -h my-postgres-db.abc123.us-east-1.rds.amazonaws.com \
     -U postgres \
     -d myappdb

Connect From Application Code

Python example using psycopg2:

import psycopg2

conn = psycopg2.connect(
    host="my-postgres-db.abc123.us-east-1.rds.amazonaws.com",
    database="myappdb",
    user="postgres",
    password="your-password"
)

cursor = conn.cursor()
cursor.execute("SELECT version();")
print(cursor.fetchone())

High Availability with Multi-AZ

Multi-AZ deployment creates a standby replica in a different Availability Zone for automatic failover.

How It Works

                    ┌──────────────┐
                    │   Primary    │
User Request ──────►│   Instance   │
                    │    (AZ1)     │
                    └──────┬───────┘
                           │ Synchronous
                           │ Replication
                    ┌──────▼───────┐
                    │   Standby    │
                    │   Instance   │
                    │    (AZ2)     │
                    └──────────────┘

Automatic Failover

If the primary instance fails:

1. RDS detects the failure
2. DNS is updated to point to standby
3. Standby is promoted to primary
4. A new standby is created

Failover typically completes in 60-120 seconds.

When to Use Multi-AZ

• Production workloads - Where downtime is costly
• Critical applications - That need high availability
• Compliance requirements - That mandate redundancy

Note: Multi-AZ is for availability, not read scaling. Use Read Replicas for that.

Read Replicas

Read Replicas are read-only copies of your database for scaling read operations.

How They Work

                    ┌──────────────┐
Write Request ─────►│   Primary    │
                    │   Instance   │
                    └──────┬───────┘
                           │ Asynchronous
           ┌───────────────┼───────────────┐
           ▼               ▼               ▼
    ┌──────────┐    ┌──────────┐    ┌──────────┐
    │ Replica 1│    │ Replica 2│    │ Replica 3│
    └────▲─────┘    └────▲─────┘    └────▲─────┘
         │               │               │
         └───────────────┴───────────────┘
                Read Requests

Use Cases

• Read-heavy applications - Distribute read traffic across replicas
• Analytics - Run reports against replica without impacting primary
• Disaster recovery - Promote replica to standalone in another region

Creating a Read Replica

1. Select your database in RDS console
2. Actions → Create read replica
3. Configure replica settings
4. Create

Replicas can be in the same region or cross-region.

Automated Backups

RDS automatically backs up your database:

Automated Backups

• Daily full backup during backup window
• Transaction logs every 5 minutes
• Retention period: 1-35 days
• Point-in-time recovery to any second within retention

Manual Snapshots

Create snapshots anytime:

• Persist until you delete them
• Can be copied across regions
• Can be shared with other AWS accounts

Restoring from Backup

Restoring creates a NEW database instance - it doesn't overwrite the existing one.

1. Select snapshot or point-in-time
2. Configure new instance settings
3. Launch new instance
4. Update application to use new endpoint

Security Best Practices

Network Security

• Run in private subnets - No direct internet access
• Use security groups - Allow only necessary ports/sources
• Avoid public access in production

Encryption

At rest:

• Enable encryption when creating the database
• Uses AWS KMS for key management
• Encrypts storage, backups, snapshots, and replicas

In transit:

• Use SSL/TLS connections
• Most database drivers support this by default

IAM Authentication

Instead of passwords, authenticate using IAM:

import boto3

rds_client = boto3.client('rds')
token = rds_client.generate_db_auth_token(
    DBHostname='my-postgres-db.abc123.us-east-1.rds.amazonaws.com',
    Port=5432,
    DBUsername='iam_user'
)

Benefits: Centralized access management, no password rotation needed.

RDS vs Aurora

For production PostgreSQL/MySQL, consider Aurora:

Feature	RDS	Aurora
Performance	Standard	Up to 5x MySQL, 3x PostgreSQL
Storage scaling	Manual	Automatic (up to 128 TB)
Replicas	Up to 5	Up to 15
Failover time	60-120 seconds	Typically under 30 seconds
Pricing	Lower base	Higher base, but often better value at scale

Aurora is also available as Aurora Serverless - scales automatically to zero when not in use.

RDS Pricing

RDS pricing includes:

Component	What You Pay For
Instance hours	Time DB instance runs
Storage	GB provisioned per month
I/O requests	For Provisioned IOPS only
Backup storage	Beyond free allocation
Data transfer	Data transferred out

Free Tier

• 750 hours/month of db.t2.micro or db.t3.micro
• 20 GB storage
• 20 GB backup storage
• For 12 months

Cost Optimization

• Right-size instances
• Use Reserved Instances for steady workloads
• Stop dev/test instances when not in use
• Delete unused snapshots

Key Takeaways

• RDS manages database infrastructure - patching, backups, scaling
• Six engines supported: Aurora, MySQL, PostgreSQL, MariaDB, Oracle, SQL Server
• Multi-AZ provides high availability with automatic failover
• Read Replicas scale read traffic and enable cross-region replication
• Automated backups enable point-in-time recovery
• Security: Use private subnets, encryption, and IAM authentication
• Aurora offers higher performance for MySQL/PostgreSQL workloads

What's Next

Now that you understand both compute (EC2, Lambda) and data storage (S3, RDS), let's explore how to expose your applications to the internet. In the next lesson, we'll dive into API Gateway - building serverless APIs at scale.