Amazon RDS

Definition

Amazon Relational Database Service (RDS) is a fully managed database service that automates time-consuming administration tasks — provisioning, patching, backup, recovery, failure detection, and repair. RDS supports six database engines: MySQL, PostgreSQL, MariaDB, Oracle, SQL Server, and Amazon Aurora. It lets development teams focus on query optimization and schema design instead of database infrastructure.

Supported Engines

Key Features

Multi-AZ Deployment

RDS automatically replicates your database to a standby instance in a different Availability Zone:

• Synchronous replication — standby is always up to date
• Automatic failover in 60–120 seconds if primary fails
• No data loss (RPO = 0) with synchronous replication
• Failover is transparent to the application (DNS failover)

Read Replicas

• Asynchronous copies of the primary database for read-heavy workloads
• Up to 15 read replicas per cluster (Aurora); 5 per instance (MySQL/PostgreSQL)
• Can be in the same region or cross-region for geographic distribution
• Can be promoted to standalone database for disaster recovery

Automated Backups

• Daily automated snapshots + continuous transaction log backup
• Point-in-time recovery (PITR) to any second within your retention window (1–35 days)
• Manual snapshots retained indefinitely

RDS Proxy

• Connection pooler between your application and RDS
• Essential for Lambda-to-RDS connections (Lambda can open thousands of connections)
• Reduces failover impact from 60+ seconds to under 5 seconds
• Supports IAM authentication for database credentials

RDS vs Aurora vs Self-Managed

Compliance and Security

• Encryption at rest with AWS KMS; encryption in transit with TLS
• VPC isolation — RDS runs in private subnets by default
• IAM database authentication (MySQL, PostgreSQL) — no passwords in code
• CloudTrail logs all API actions; RDS supports audit logging per engine
• HIPAA-eligible, PCI DSS-compliant, SOC 2 audited (when configured correctly)

Common Mistakes

Mistake 1: Using db.t3.micro for production. Burstable T-class instances are CPU-credit based — sustained load exhausts credits and degrades performance. Use M or R class for production.

Mistake 2: Enabling Multi-AZ without testing failover. Failover takes 60–120 seconds; test that your application handles it gracefully before relying on it for HA.

Mistake 3: Not using RDS Proxy for Lambda. Lambda-to-RDS without a proxy exhausts database connections under load. RDS Proxy is nearly always required for serverless-to-RDS architectures.

Related AWS Services

• Amazon Aurora: Higher-performance MySQL/PostgreSQL-compatible managed database
• RDS Proxy: Connection pooling for serverless and high-connection workloads
• AWS Secrets Manager: Rotate database credentials automatically
• AWS DMS: Migrate existing databases to RDS with minimal downtime

Related FactualMinds Content

• AWS RDS Consulting
• AWS Cloud Migration Services — DMS-based database migrations into RDS with parallel-run validation
• Cloud Compliance Services
• Cloud Cost Optimization