AWS RDS vs Aurora: architecture, scaling, and cost trade-offs

2026-09-21 · aws databases rds aurora

Amazon RDS and Amazon Aurora are both managed relational database services, but they make different architectural bets. RDS gives you familiar managed engines (including MySQL, PostgreSQL, MariaDB, Oracle, SQL Server, and Db2), while Aurora reimplements MySQL-, PostgreSQL-, and DSQL-compatible databases on a cloud-native storage layer. The right choice depends less on the AWS console and more on storage behavior, read scaling, failover mechanics, engine compatibility, and how you pay for I/O.

Storage architecture

Standard Amazon RDS engines run on database instances backed by storage managed through the RDS service (often EBS-backed in practice, with engine- and configuration-specific details). Aurora separates compute from a shared cluster volume. AWS documentation describes that cluster volume as a single virtual SSD-backed volume whose data is replicated across three Availability Zones in a Region. The same logical volume is shared by the writer and reader instances in the cluster.

That shared-volume design changes several operational details. Adding or removing an Aurora reader does not require copying a full new data set, because the instance attaches to the existing cluster volume. Aurora storage grows automatically as data increases; AWS states that Aurora cluster volumes can grow up to 256 TiB for supported engine versions, and that storage space can be reduced when data is removed. Aurora also offers two storage configurations: Aurora Standard, which charges for storage and I/O requests, and Aurora I/O-Optimized, which removes separate read/write I/O charges but has different instance and storage pricing.

Replication, failover, and endpoints

Aurora uses a cluster model with one primary (writer) instance and up to 15 Aurora Replicas (reader instances). Because replicas read from the shared cluster volume, AWS states that replicas typically return the same data with minimal replica lag, often much less than 100 milliseconds after a write, though lag can vary with workload. Aurora exposes a cluster endpoint for read/write traffic, a reader endpoint that load-balances read-only connections across replicas, and instance endpoints for direct connections. AWS recommends cluster and reader endpoints for high-availability applications because they handle failover better than hard-coding instance endpoints.

Standard RDS replication is engine-specific. For RDS MySQL, PostgreSQL, MariaDB, Oracle, and SQL Server, read replicas are typically implemented with engine-native replication and separate replica instances. RDS Multi-AZ is primarily a high-availability feature; in Aurora, all cluster instances are active participants in the cluster's read/write and read-scaling model. Cross-Region options also differ: Aurora Global Database replicates across Regions using Aurora's storage infrastructure, while Aurora PostgreSQL does not support cross-Region Aurora Replicas in the same way as Aurora MySQL's binlog-based cross-Region replicas.

Failover timing should be treated as workload-dependent, not as a guaranteed number. AWS documentation and database engineering posts describe Aurora failover as typically faster than traditional instance-plus-storage failover because replicas already share the storage volume; RDS Multi-AZ failover behavior depends on engine and deployment type (for example, Multi-AZ with one standby versus Multi-AZ DB cluster with readable standbys for RDS PostgreSQL). Applications should use endpoint-based connections, DNS-aware retry logic, and, where appropriate, RDS Proxy.

Compatibility and operational trade-offs

The clearest boundary is engine choice. AWS states that RDS supports managed MySQL, PostgreSQL, MariaDB, Oracle, SQL Server, and Db2 engines, while Aurora supports MySQL-, PostgreSQL-, and DSQL-compatible workloads. If you need Oracle, SQL Server, or Db2, Aurora is not a drop-in option.

Aurora can be attractive when you want Aurora-specific features: a shared distributed storage volume, fast reader scaling inside a cluster, Global Database, serverless capacity options, and (for PostgreSQL/MySQL families where available) features such as Aurora I/O-Optimized, Aurora PostgreSQL Limitless Database, or other engine-specific capabilities. But Aurora is not "RDS with a different checkbox" - it has its own cluster concepts, endpoint model, replica behavior, and feature/version matrix. Standard RDS can be simpler when you need the broadest engine compatibility or when the workload does not justify Aurora's baseline cost and operational model.

Cost considerations

Cost comparisons are easy to get wrong because Aurora and RDS bill different components. For Aurora, AWS pricing distinguishes between database instances, storage, and (for Aurora Standard) I/O requests; Aurora I/O-Optimized removes separate read/write I/O charges and changes instance/storage rates. AWS also notes that Aurora Global Database includes replicated write I/O charges between Regions. For standard RDS, pricing depends on engine, instance class, storage type (such as General Purpose SSD or Provisioned IOPS), Multi-AZ configuration, backup storage, and read replicas.

AWS's product comparison page says Aurora is designed for up to 6x the throughput of standard MySQL and PostgreSQL, and it highlights automatic storage scaling and faster failover as reasons to choose Aurora. Treat those as vendor performance and capability claims, not as a substitute for workload-specific testing. A practical evaluation should model instance hours, storage growth, read/write I/O patterns, replica count, Multi-AZ or cluster topology, backup retention, and cross-Region replication before assuming Aurora is cheaper or faster for a particular application.

Conclusion

Choose standard RDS when engine compatibility, familiar instance-level behavior, or a smaller steady workload matters most. Choose Aurora when its cluster volume, reader scaling, endpoint model, or cross-Region/global capabilities match the workload and the pricing model fits your I/O pattern. The safe path is to verify the exact engine, version, Region, and deployment option in AWS documentation, then test with representative queries and failover scenarios rather than relying on generic comparisons.

Sources

← back to posts