Amazon RDS

Definition

Amazon Relational Database Service (RDS) is AWS’s managed relational layer for MySQL, PostgreSQL, MariaDB, Oracle, SQL Server, and Aurora (as engine options). RDS automates provisioning, OS patching, backups, and Multi-AZ failover so teams focus on schema and queries instead of database VMs. Storage for non-Aurora engines lives on EBS; you choose instance class, allocate storage up to engine limits, and attach read replicas for read scaling and DR.

Multi-AZ synchronously replicates to a standby in another AZ — automatic failover typically in 60–120 seconds with RPO=0 for synchronous mode. RDS Proxy pools connections (critical for Lambda-heavy architectures), supports IAM auth, and reduces failover impact on connection storms. Standard RDS fits conventional OLTP with familiar SQL semantics; when throughput, storage autoscaling, or sub-30s failover matter more, Aurora on RDS is the upgrade path within the same console family.

When to use it

• Existing MySQL, PostgreSQL, Oracle, or SQL Server applications migrating to AWS with minimal code change.
• OLTP needing ACID transactions, joins, and ad hoc SQL that DynamoDB’s access-pattern model cannot express cleanly.
• Compliance workloads requiring encryption at rest (KMS), VPC isolation, audit logs, and HIPAA/PCI-eligible configurations.
• Read-heavy reporting off read replicas while keeping writes on the primary — not a substitute for Redshift, but fine for moderate analytics.

When not to use it

• Massive horizontal shard-by-tenant scale with only simple key lookups — DynamoDB or Aurora DSQL may fit better.
• Petabyte warehouse analytics — use Redshift, Athena on S3 Tables, or lakehouse patterns; do not hammer RDS with full-table scans.
• Sub-millisecond session caches — ElastiCache or MemoryDB, not RDS connection overhead.

Tips

• Front serverless and microservice fleets with RDS Proxy — without it, Lambda concurrency opens one connection per execution environment and exhausts max_connections.
• Use Graviton (db.m7g/r7g) for open-source engines after compatibility testing — meaningful savings over x86 at same memory tier.
• Enable Performance Insights and Enhanced Monitoring on production; right-size from wait events (IO:DataFileRead, Lock:transactionid) not CPU alone.
• Automate credential rotation with Secrets Manager integration — static passwords in Parameter Store rot less cleanly.
• Test Multi-AZ failover in staging quarterly: DNS TTL and connection retry logic in apps cause most “HA did not work” incidents, not RDS itself.

Gotchas

• Serious: Production on burstable T-class without Unlimited mode — CPU credit exhaustion throttles writes during traffic spikes with no obvious “database down” alarm.
• Serious: Lambda → RDS without Proxy under load causes too many connections outages that look like application bugs.
• Regular: Failover changes the endpoint IP behind the DNS name — clients that cache DNS too aggressively hang until TTL expires.
• Regular: Storage autoscaling max cap misconfigured — disk-full still stops writes even when autoscaling is “enabled.”
• Regular: Major version upgrades are one-way — snapshot before upgrade and validate extension compatibility (PostGIS, pg_cron, etc.).

Official references

• RDS Proxy — pooling, IAM auth, and failover behavior.
• Best practices for Amazon RDS PostgreSQL — parameter groups and monitoring.

Related FactualMinds content

• AWS RDS Consulting
• Amazon Aurora — cloud-native engine on RDS
• Cloud Compliance Services
• AWS Cloud Migration
• Cloud Cost Optimization