Chapter 46: AWS RDS

AWS RDS properly — like we’re sitting together in a Madhapur café with a whiteboard, a filter coffee, and no rush. I’ll explain it step-by-step, with real analogies, actual Hyderabad startup examples, the current 2026 reality (engines, pricing, features), when to use it vs DynamoDB/Aurora/DocumentDB, and a clear hands-on path you can follow today.

1. What is Amazon RDS? (Very Simple First)

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

AWS handles:

• Hardware provisioning
• OS patching
• Backups & point-in-time recovery
• Multi-AZ failover
• Monitoring & alarms
• Minor version upgrades

You just focus on:

• Your SQL queries
• Schema design
• Application logic

Supported engines (2026 – still the same core list):

• PostgreSQL
• MySQL
• MariaDB
• Oracle
• Microsoft SQL Server
• Amazon Aurora (PostgreSQL & MySQL compatible – more on this later)

Official short line (still accurate): “Amazon RDS makes it easy to set up, operate, and scale a relational database in the cloud. It provides cost-efficient and resizable capacity while automating time-consuming administration tasks.”

In plain Hyderabad language: Imagine you want to open a small biryani restaurant.

• Old way → rent a full kitchen, buy stoves, hire cooks, manage gas, clean every day, worry about power cuts
• RDS way → you rent a fully managed cloud kitchen (AWS provides stove, gas, cleaning staff, backup power, 24×7 guard) → you just bring your secret biryani masala & recipe → focus on cooking & serving customers

RDS = the managed cloud kitchen for relational databases.

2. Why Do So Many Hyderabad Companies Choose RDS? (Real 2026 Reasons)

• No sysadmin headaches — no need to manage OS patches, backups, replication, failover
• Production-ready in minutes — launch a PostgreSQL instance → get endpoint → connect
• Multi-AZ high availability — automatic failover to standby in another AZ (~60–120 seconds)
• Automated backups — point-in-time restore (up to 35 days retention)
• Scaling options — vertical (bigger instance), read replicas, storage auto-scaling
• Security defaults — encryption at rest (KMS), in-transit (TLS), VPC isolation, IAM auth
• Familiar engines — most Indian developers already know MySQL/PostgreSQL

Real Hyderabad examples (very common in 2026):

• E-commerce / food delivery → orders, users, restaurants, payments (PostgreSQL or Aurora)
• Edtech → student profiles, course progress, quiz scores (PostgreSQL)
• SaaS startups → tenant data, subscriptions, audit logs (MySQL / PostgreSQL)
• Fintech → transaction metadata, KYC data (Aurora PostgreSQL for strong consistency)
• Legacy migration → lift-and-shift Oracle / SQL Server apps

3. RDS Deployment Options – The Important Choices (2026)

2026 quick recommendation for Hyderabad teams:

• Development / testing → Single-AZ db.t4g.micro / db.t4g.small
• Production small–medium app → Multi-AZ db.t4g.medium / db.m6g.large
• Variable traffic (edtech during exams, e-commerce during sales) → Aurora Serverless v2 or RDS Proxy + Multi-AZ
• High read scale → Aurora with readable standbys or read replicas

4. Real Hyderabad Example – Full RDS Setup in a Startup

Your food discovery & delivery platform in Gachibowli:

Database needs:

• Users, restaurants, orders, ratings, payments
• Strong consistency (order amount must match payment)
• ~5,000–20,000 orders/day
• Some reporting queries

Chosen setup (very typical 2026):

• Engine: Aurora PostgreSQL (3–5× faster than standard RDS PostgreSQL)
• Instance class: db.t4g.large (2 vCPU, 8 GB RAM)
• Multi-AZ deployment (primary in ap-south-2a, standby in ap-south-2b)
• Storage: 200 GB gp3 (auto-scaling enabled)
• Backup retention: 7 days (point-in-time recovery)
• Performance Insights enabled → see slow queries
• RDS Proxy in front → Lambda functions connect via proxy (connection pooling)

What happens during Sankranti festival rush:

• Orders spike 5–8×
• Aurora auto-scales storage if needed
• CPU/memory spikes → you scale up instance class (or use Aurora Serverless v2 for auto-capacity)
• Standby takes over in ~60 seconds if primary AZ has issue
• No downtime → customers keep ordering biryani

Monthly cost example (moderate traffic):

• db.t4g.large Multi-AZ → ~₹8,000–12,000
• Storage 200 GB + IOPS → ~₹1,500
• Backups + data transfer → ~₹500
• Total: ₹10,000–15,000 (very reasonable)

5. Quick Hands-On – Launch Your First RDS Instance

1. RDS console → Create database
2. Engine: PostgreSQL (or Aurora PostgreSQL)
3. Template: Free tier (db.t4g.micro) or Dev/Test
4. DB instance identifier: “hyd-demo-db”
5. Master username/password
6. Instance configuration: db.t4g.micro (free tier eligible)
7. Storage: 20 GB gp3
8. Connectivity: Public access (for learning only!), VPC default
9. Create → wait 5–10 min → get endpoint
10. Connect with DBeaver / pgAdmin → run CREATE TABLE users (id SERIAL PRIMARY KEY, name TEXT);

Cost? Usually ₹0 first month (free tier: 750 hours db.t4g.micro + 20 GB storage)

Summary Table – RDS Cheat Sheet (2026 – India Focus)

Teacher’s final note: RDS is the “set it and forget it” relational database — perfect when you want MySQL/PostgreSQL behavior without hiring a DBA or worrying about backups & failover. In 2026, most Hyderabad web/mobile startups start with RDS PostgreSQL Multi-AZ or Aurora Serverless v2, and later add DynamoDB for high-scale parts and ElastiCache for speed.

Got it? This is the “how do I run a proper SQL database in the cloud without pain?” lesson.

Next?

• Deep comparison: RDS PostgreSQL vs Aurora PostgreSQL (why most teams switch)
• Step-by-step: Set up RDS Multi-AZ + read replica?
• Or RDS Proxy + Lambda connection pooling example?

Tell me — next whiteboard ready! 🚀🗄️