RDS vs Aurora

AWS DB.

Overview

RDS and Aurora are both managed Postgres or MySQL on AWS, but the storage layer underneath is the entire conversation. RDS uses EBS volumes attached to a single primary; Aurora replaces that with a distributed log-structured storage service replicated across three AZs. The choice shapes failover behaviour, read scaling, and bill shape.

• Standard RDS. Predictable pricing, mature feature set, full control over engine version and parameters, single-writer with replica failover measured in tens of seconds.
• Aurora distributed storage. Six-way replicated storage, sub-10s failover, up to 15 read replicas sharing the same storage volume, faster crash recovery.
• Operational fit. RDS suits steady workloads with known IOPS budgets; Aurora suits read-heavy workloads, multi-AZ reliability targets, and apps that benefit from fast clones.
• Per-database decision and cost shape. Aurora's storage I/O is metered per request, so chatty workloads can cost more than provisioned EBS; model the bill before committing.

The approach

Match the engine to the workload's read pattern, RTO requirement, and cost ceiling. Treat the choice per database, not per AWS account, and re-evaluate when usage patterns change.

• Workload classification. Read-heavy with replica fan-out leans Aurora; write-heavy with predictable IOPS leans RDS where you control the EBS volume directly.
• Failover and RTO target. If recovery objective is under a minute, Aurora's storage-level replication wins; if you can absorb a longer Multi-AZ failover, RDS suffices.
• Cost modelling. Aurora I/O charges scale with request count; high-throughput log tables can balloon. Run a 30-day shadow before committing.
• Document the choice and the trigger to revisit. Capture the rationale and the metric (read replica count, RTO, cost variance) that would flip the decision.

Why this compounds

Database engine choice compounds because backup tooling, observability, IAM patterns, and on-call playbooks all anchor on the engine. Each new service that picks the same engine inherits the operational surface for free.

• Operational consolidation. Fewer engines means fewer parameter groups, fewer backup strategies, fewer failover drills to maintain.
• Cost predictability. A documented choice keeps surprise bills out of the next quarter and gives finance a model to forecast.
• Faster recovery posture. Aurora's storage-level replication and fast clones speed up disaster recovery exercises and PITR tests.
• Decision trail for the next database. Each documented choice teaches the next team which questions to ask, not which engine to default to.