Visual overview
Aurora DB compute instances attach to a shared distributed cluster volume and expose writer/read connection roles.
Technical reference
Aurora architecture questions usually turn on the role of an instance, the shared cluster volume, the endpoint selected by the application, and failover eligibility.
The writer accepts database changes; cluster-aware endpoints let applications target the role rather than a fixed host.
Readers share the cluster volume, serve read traffic, and can be eligible for promotion during failover.
It balances new connections across replicas; it is not a per-query SQL load balancer.
Aurora maintains six copies of data across three Availability Zones for the cluster volume.
Eligible Aurora Replicas can be assigned failover priorities that influence promotion order.
Service limits and capabilities can change. Values shown here reflect the current AWS documentation; use the linked official sources below as the source of truth.
Aurora separates relational compute from distributed storage
Amazon Aurora is a relational database service compatible with MySQL and PostgreSQL. Its distinguishing architecture is the Aurora cluster: DB instances provide database compute while a shared cluster volume provides distributed storage. The writer instance handles changes to the database, and Aurora Replicas can attach to the same cluster volume to serve reads. This differs from thinking of each replica as a completely separate database copy with its own independent volume.
Aurora's storage subsystem maintains multiple copies of data across Availability Zones and automatically grows as the cluster's data increases within supported limits. Because compute and storage have distinct roles, scaling a read tier can involve adding or changing reader instances without duplicating a conventional storage stack for each reader. The architecture also underpins Aurora's automated failover behavior.
Endpoints express connection intent
An Aurora cluster endpoint directs connections to the current writer and is the normal target for write-capable application traffic. The reader endpoint provides connection balancing across available Aurora Replicas for read-only connections. It balances new connections, not individual SQL queries inside a persistent connection, so connection management influences how evenly an application uses the reader fleet.
Aurora also supports instance endpoints and custom endpoints for workloads that need more explicit routing. Most applications should prefer cluster-aware endpoints because the endpoint can follow role changes during failover. Hard-coding an individual writer instance endpoint can work against that design by coupling the application to a specific instance rather than the writer role.
- Cluster endpoint: connect to the current writer role.
- Reader endpoint: connection-balances read-only connections across Aurora Replicas.
- Instance endpoint: targets one specific DB instance and is useful only when that specificity is intentional.
- Custom endpoint: defines a chosen group of instances for specialized connection routing.
Key takeaways
- 01
Aurora is MySQL- and PostgreSQL-compatible but uses an AWS-designed distributed storage architecture.
- 02
Writer and reader DB instances share the cluster volume; readers are not independent application databases.
- 03
Use the cluster endpoint for the writer role and the reader endpoint for connection-balanced read traffic.
- 04
Aurora Replicas can provide read scaling and can also serve as failover targets when designed appropriately.
- 05
Provisioned versus serverless capacity is a compute choice, not a change to Aurora's relational model.
Official AWS sources
Use these primary AWS resources for the source material behind this article and for deeper reference.