Aurora vs standard RDS: a practical guide for developers

Aurora vs standard RDS: a practical guide for developers

You're scaling a transactional platform and your single RDS instance is starting to strain. Your team debates whether to stick with standard RDS or migrate to Aurora. Both run MySQL or PostgreSQL, but the architecture and economics differ fundamentally. This guide cuts through the marketing to help you decide when Aurora actually saves you money and when it's overkill.

Understanding the fundamental difference

Standard RDS is familiar: a single database engine running on one EC2 instance (or an HA pair with synchronous replication). You pay per instance size, per backup storage, and per data transfer. Aurora is architecturally different—it decouples compute from storage. Your database engine connects to a shared storage layer that handles all the replication and durability concerns. This separation lets Aurora do things standard RDS can't, but it also changes the cost calculus.

Think of standard RDS as renting a self-contained apartment; think of Aurora as renting compute from a shared building with managed infrastructure. The building handles the plumbing and electricity, but you pay per room and per utility consumed.

Aurora storage: distributed replicas across three availability zones

Aurora's storage engine replicates your data across six copies distributed over three availability zones automatically. You don't configure this—it happens behind the scenes. Each write is acknowledged only when quorum (four of six copies) have durably stored it.

For standard RDS, you get two replicas: your primary instance and a synchronous standby in another AZ. If you want read replicas, those are asynchronous and you create them explicitly as separate instances, each consuming compute resources you pay for.

Here's the practical implication: if you run a standard RDS db.r6i.xlarge primary with two read replicas (also db.r6i.xlarge), you're paying for three instances. With Aurora, you'd create one db.r6i.xlarge primary and add replicas as pure read-only endpoints that share the same storage layer. The compute cost is lower, and you don't pay separately for storage duplication—it's baked in.

A real scenario: you're building a reporting system that hammers your production database with analytic queries. Standard RDS forces you to create read replicas as full instances. Aurora lets you spin up lightweight read-only endpoints that use the same nine-copy storage. You still pay for compute, but you avoid the storage multiplier.

# Standard RDS: create read replica as a full instance
aws rds create-db-instance-read-replica \
  --db-instance-identifier prod-db-replica-1 \
  --source-db-instance-identifier prod-db \
  --db-instance-class db.r6i.xlarge

# Aurora: add read replica to cluster (shares storage)
aws rds create-db-instance \
  --db-cluster-identifier prod-cluster \
  --db-instance-identifier prod-cluster-replica-1 \
  --db-instance-class db.r6i.xlarge

One caveat: Aurora storage is priced per GB-month. If your data is tiny (under 10 GB), the per-GB fee can exceed what you'd pay for a small RDS instance's attached storage. Do the math before migrating small databases.

Fast failover and up to 15 low-lag replicas

Standard RDS failover to the synchronous standby takes 1–3 minutes. During that window, your application is down (assuming no read-replica fallback logic). Aurora failover is typically 30 seconds or less because the storage layer is already consistent; the engine just reconnects.

The replica story is even more dramatic. Standard RDS read replicas are true separate instances with their own compute—if you have 15 of them, you're paying for 16 instances. Aurora gives you up to 15 read-only replicas in the same cluster, and they all lag behind the primary by single-digit milliseconds because they're reading from the same distributed storage.

Scenario: you're running a SaaS product with multiple customer regions. A standard RDS setup would require read replicas in each region as full instances. With Aurora Global Database, you have one primary cluster in one region and read-only clusters in others. Failover between regions is automatic and fast. The trade-off is higher cost and Aurora-only features.

For a transactional system with moderate concurrency (100–500 connections), standard RDS is fine. For a platform that needs to serve thousands of concurrent readers from multiple geographies, Aurora's replica architecture pays for itself in operational simplicity and lower failover blast radius.

Serverless v2: fine-grained scaling without capacity planning

Aurora Serverless v2 scales your database compute automatically based on demand. You set a minimum and maximum capacity (in ACUs—Aurora Compute Units), and Aurora scales in between without restarting the database. Each 0.5 ACU increment is granular enough that you're not over-provisioning between sizes.

Standard RDS has no auto-scaling for compute. You pick an instance size and live with it. If load spikes, you manually or scripted-ly resize, which causes a brief downtime (typically 1–3 minutes).

Practical example: your nightly batch ETL job requires 16 vCPUs for two hours, but your daytime transactional load needs only 4 vCPUs. With standard RDS, you provision for 16 and pay for idle time during the day, or you script resize operations and accept downtime. Aurora Serverless v2 scales down after the batch completes and scales up automatically when load returns, no downtime.

# Create Aurora Serverless v2 cluster
aws rds create-db-cluster \
  --db-cluster-identifier prod-serverless-v2 \
  --engine aurora-postgresql \
  --engine-version 15.2 \
  --database-name mydb

# Add a serverless v2 instance
aws rds create-db-instance \
  --db-instance-identifier prod-serverless-v2-instance \
  --db-cluster-identifier prod-serverless-v2 \
  --db-instance-class db.serverless \
  --engine aurora-postgresql

# Set scaling policy
aws rds modify-db-cluster \
  --db-cluster-identifier prod-serverless-v2 \
  --min-capacity 1 \
  --max-capacity 4

Caveat: Aurora Serverless v2 pricing is per-ACU-second, which sounds cheap but adds up fast under sustained high load. If your workload runs consistently at 8 ACUs 24/7, you'll pay more than provisioning a static db.r6i.2xlarge. Serverless v2 is best for bursty or variable workloads.

Cost: the decisive factor for most teams

Let's build a concrete comparison. Assume a production database in us-east-1 with 500 GB of data.

Key insight: Aurora saves money when you need read replicas or high availability. If you're running a single database instance, standard RDS is cheaper. Migration cost and operational learning curve also matter—moving a large database to Aurora involves downtime or complex migration strategies.

A startup with one database and a budget: stick with standard RDS until you need read replicas. A mature SaaS platform with distributed read traffic: Aurora probably pays for itself in replica cost reduction.

Common mistakes

• Comparing single instances head-to-head. It's unfair. Aurora shines when you need replicas or failover. A single standard RDS instance is cheaper than a single Aurora instance for the same compute.
• Forgetting about backups. Aurora backups are cheaper (stored in S3 behind the scenes). Standard RDS backups are straightforward but more expensive per GB for long retention. Factor this into your TCO.
• Assuming Serverless v2 is always cheaper. It's not. High sustained load makes Serverless v2 pricey. Use it for variable or bursty patterns, not for always-on production at steady-state.
• Ignoring migration complexity. Moving a live 5 TB database to Aurora takes careful planning. Don't assume a lift-and-shift is free. Budget for downtime or use DMS (AWS Database Migration Service) and plan for a multi-day cutover.
• Overlooking regional differences. Aurora pricing varies by region. us-east-1 is cheaper than eu-west-1. If cost is tight, geography matters.

Key takeaways

• Aurora decouples compute from storage and replicates across three AZs automatically. Standard RDS couples compute and storage on one instance.
• Aurora failover is ~30 seconds; standard RDS is 1–3 minutes. Aurora read replicas share storage; standard RDS replicas are full instances.
• Aurora Serverless v2 scales compute automatically without downtime. Standard RDS requires manual resize or scripted operations that cause brief downtime.
• For a single database with no replicas, standard RDS is cheaper. For workloads needing multiple read replicas, Aurora typically wins on cost and operability.
• Aurora Serverless v2 is ideal for bursty or variable workloads. Sustained high load makes it expensive compared to provisioned instances.
• Do a cost projection for your specific workload pattern before migrating. Migration itself takes effort and planning—don't assume it's trivial.
• Consider your team's operational maturity. Aurora has fewer knobs to turn, which is good for small teams but less flexible for teams that need tight control.