█
LastWrite
  • > Curriculum
  • > Pricing
  • > For Educators
  • > About
  • > Contact
Log InGet Started

Questions, concerns, bug reports, or suggestions? We read every message, write to us at [email protected].

More ways to reach us →
LastWrite

Structured computer science lessons for aspiring developers and security professionals.

[email protected]

(201) 785-7951

Mon–Fri, 9 AM–5 PM EST

Learn

  • Curriculum
  • Pricing

Company

  • About
  • For Educators & Schools
  • Contact Us

Legal

  • Terms of Service
  • Privacy Policy
© 2026 LastWrite. All rights reserved.
Curriculum/DevOps and Infrastructure/Cloud Platforms — AWS/RDS
45 minIntermediate

RDS

After this lesson, you will be able to: Use RDS managed databases: Multi-AZ, read replicas, automated backups, and connecting from an application securely.

RDS is the boring-but-essential managed DB service. Most production AWS apps end up with one. This lesson covers the must-know features.

Prerequisites:S3

Why RDS over EC2-hosted DB

AWS handles: provisioning, OS patching, DB engine patching, automated backups, point-in-time recovery (PITR), Multi-AZ failover, read replicas. You handle: schema design, queries, connection pooling, application logic. Trade-off: less control (can't tune kernel; can't install custom extensions). Cost ~30-50% more than self-hosted on equivalent hardware. Worth it almost always for small/mid teams.

Multi-AZ vs read replicas

Multi-AZ: a synchronous standby in a different availability zone. Failover in 60-120 seconds on primary failure. NOT readable; pure HA. Read replica: an asynchronous copy. Application reads from replica, writes to primary. Replication lag in seconds. For HA: Multi-AZ. For read scale: read replicas. For both: combine. Multi-AZ doubles cost; replicas add per-replica cost. Decide based on actual needs.

Connecting from an application

Networking: put RDS in PRIVATE subnets (no public IP). Allow security group to accept connections only from app SG. Credentials: use AWS Secrets Manager to store DB password; app fetches at boot. Auto-rotate via Secrets Manager + RDS integration. Alternative: IAM database authentication, connect with short-lived tokens from IAM, no password. Best practice for modern apps.

Connection pooling matters (RDS Proxy)

Without pooling, serverless / spiky apps exhaust DB connections.

tsx
# Problem: Lambda spawns N concurrent invocations.
# Each invocation opens a new Postgres connection.
# Postgres hits max_connections; new invocations fail.
# Solution: RDS Proxy
# - Sits between your app and RDS
# - Maintains a pool of warm connections
# - App connects to the proxy; proxy multiplexes onto few DB connections
# Cost: ~$0.015/hr per vCPU. Cheaper than a bigger DB.
# Alternative: PgBouncer on EC2 (free; you operate). Or Supabase's pooler.

💡 Backups: automated + manual snapshots

RDS takes daily automated backups + transaction logs every 5 min. Point-in-time recovery within the retention window (default 7 days, max 35). For longer retention, take manual snapshots periodically. Snapshots are cross-region-copyable for disaster recovery. Test the restore process at least quarterly. A backup you've never restored isn't a backup.

Common mistakes only experienced engineers avoid

Putting RDS in a public subnet with public IP. Direct internet exposure of your DB. Don't. Hardcoding DB password in source code. Use Secrets Manager or IAM database auth. Skipping Multi-AZ for production. Single-AZ = single point of failure. No connection pooler with Lambda. Connection exhaustion at scale. Retention = 7 days for compliance-relevant data. Set to 30+ days where required.

Quick Check

Your Lambda function intermittently fails with 'too many connections' to RDS Postgres. What's the fix?

Pick the canonical solution.

Sign in and purchase access to unlock this lesson.

Sign in to purchase
←S3
Back to Cloud Platforms — AWS
Lambda→