Filter concepts by levelShowing all levels.

AWS · Section 23

Aurora — Working Knowledge

Level
intermediate
Read
20 min
Concepts
3

Aurora separates compute from storage — one cluster volume spans multiple AZs and is shared by the one writer and up to 15 readers, so a reader is genuinely different from a standard RDS read replica's full separate copy. This section covers that architecture and its cluster/reader/instance endpoints, the two separate PostgreSQL- and MySQL-Compatible offerings (chosen at creation, not switchable), and when Aurora's read-scaling, auto-scaling storage, and fast-failover advantages actually justify it over a simpler standard RDS deployment.

What is true here

  1. A cluster volume spans multiple AZs and is shared by every instance — even a single-instance Aurora setup is technically a cluster.
  2. The cluster endpoint always follows the current writer; the reader endpoint load-balances across readers — both automatically re-point on failover, unlike instance endpoints.
  3. Aurora PostgreSQL-Compatible and Aurora MySQL-Compatible are separate, non-interchangeable offerings chosen at cluster creation.
  4. Aurora does not support SQL Server, Oracle, or Db2 — those require standard RDS regardless of any other consideration.
  5. Aurora fits workloads needing many low-lag readers, auto-scaling storage, or fast failover; standard RDS is often simpler/cheaper for steady, smaller workloads.

What you will be able to do

  • Explain how Aurora's shared cluster volume differs architecturally from standard RDS's per-instance storage
  • Use the cluster and reader endpoints for application traffic so failover is transparent
  • Choose the correct Aurora compatibility flavor based on existing extensions, drivers, and engine requirements
  • Decide between Aurora and standard RDS for a given workload's read-scaling and engine requirements
From Aurora's architecture to when it fits
offered asweighedagainst

Shared storage, cluster/reader endpoints

PostgreSQL- or MySQL-Compatible

Aurora vs standard RDS

  • Shared storage, cluster/reader endpoints
    • leads to PostgreSQL- or MySQL-Compatible (offered as)
  • PostgreSQL- or MySQL-Compatible
    • leads to Aurora vs standard RDS (weighed against)
  • Aurora vs standard RDS

Aurora — Working Knowledge

Aurora's shared-storage architecture and endpoints, PostgreSQL/MySQL compatibility, and when it fits over standard RDS.

Aurora Architecture and Endpoints

coreintermediate

An Aurora DB cluster separates compute from storage — one shared cluster volume spans multiple AZs, and every instance (the one writer, up to 15 readers) reads from that same volume rather than each holding its own copy. The cluster endpoint always points at the current writer; the reader endpoint load-balances across all readers and automatically re-points on failover.

Think of it as

Standard RDS Multi-AZ is separate houses each keeping their own furniture in sync. Aurora is many people sharing access to one central warehouse (the cluster volume) — a reader doesn't need its own copy of the furniture, it just has a key to the same warehouse the writer uses.

What we're doing: See why connecting to an instance endpoint directly is riskier than using the cluster/reader endpoints.

endpoint-choice.txttext
App hardcodes the current writer's instance endpoint directly
Failover promotes a different instance to writer
→ App keeps connecting to the OLD instance, which is now a reader or gone —
  the cluster endpoint would have automatically followed the new writer
1
An instance endpoint always points at one specific physical instance, regardless of its current role in the cluster.
3
The cluster endpoint is specifically designed to always resolve to whichever instance is currently the writer — an instance endpoint has no such guarantee and does not follow failover.

Why this works: The cluster and reader endpoints exist precisely to abstract away which physical instance currently holds which role — bypassing them by hardcoding an instance endpoint reintroduces the exact fragility they were designed to remove.

Using instance endpoints for general application traffic instead of the cluster/reader endpoints

Wrong

text
# Connect application writes directly to a specific instance endpoint
# "because it's currently the writer"

Better

text
# Use the cluster endpoint for writes and the reader endpoint for reads —
# both automatically follow role changes during failover

What you see: A failover event breaks application connectivity even though Aurora itself completed the failover successfully, because the app was connected to a specific instance rather than a role-following endpoint.

Why: Instance endpoints are meant for diagnosis and tuning of one specific instance, not general application traffic — only the cluster and reader endpoints automatically track which physical instance currently holds the writer or reader role.

Aurora: compute separated from shared storage

Writer instance

cluster endpoint — all writes

Reader instances (up to 15)

reader endpoint — load-balanced reads

Shared cluster volume

spans multiple AZs, one copy of the data

  1. Writer instance — cluster endpoint — all writes
  2. Reader instances (up to 15) — reader endpoint — load-balanced reads
  3. Shared cluster volume — spans multiple AZs, one copy of the data

Remember: Aurora separates compute from storage — one shared cluster volume across AZs, up to 15 readers sharing it with the one writer. Use the cluster endpoint (always the writer) and reader endpoint (load-balanced readers) — both automatically follow failover; instance endpoints do not.

See also: postgresql mysql compatibility · multi az vs read replicas

Aurora PostgreSQL/MySQL Compatibility

standardintermediate

Aurora is offered as two separate, engine-compatible flavors — Aurora PostgreSQL-Compatible and Aurora MySQL-Compatible — each targeting wire/SQL compatibility with a specific upstream version of that engine. They are not one universal database; picking one is picking which engine's ecosystem, extensions, and version support you get.

Think of it as

Aurora is the same underlying storage-and-compute architecture wearing two different, mutually exclusive costumes — choosing Aurora PostgreSQL vs Aurora MySQL is choosing which engine's driver compatibility, extensions, and tooling ecosystem you get, not a setting you can change after the fact.

text
Aurora PostgreSQL-Compatible ≠ Aurora MySQL-Compatible — chosen at cluster creation, not switchable

What we're doing: See why choosing an Aurora flavor is a real engine decision, not a minor configuration knob.

engine-choice.txttext
Team already uses PostgreSQL-specific extensions (PostGIS, pg_trgm)
→ Aurora PostgreSQL-Compatible — those extensions carry over

Switching to Aurora MySQL-Compatible later would mean re-architecting
around those extensions' absence, same as any PostgreSQL → MySQL migration
1
PostgreSQL-specific extensions have no MySQL equivalent — this dependency alone determines the correct Aurora flavor.
3
There is no lightweight path between the two flavors — it is a genuine cross-engine migration with the same scope as migrating standalone PostgreSQL to standalone MySQL.

Why this works: Because Aurora's two flavors are compatibility layers over genuinely different underlying engines, a choice driven by existing extensions, drivers, or team expertise is effectively permanent without a full migration effort.

Remember: Aurora PostgreSQL-Compatible and Aurora MySQL-Compatible are separate, non-interchangeable offerings chosen at cluster creation — switching later is a full cross-engine migration, not a configuration change.

See also: aurora architecture and endpoints · postgresql as rdbms

When Aurora Fits Over Standard RDS

standardintermediate

Aurora's shared-storage architecture pays off when read scaling (up to 15 low-lag readers), storage auto-scaling, or fast failover matter most. Standard RDS is often simpler and cheaper for smaller, steady workloads, or when a specific engine (SQL Server, Oracle, Db2 — none of which Aurora supports) is required.

Think of it as

Aurora is a more sophisticated (and pricier) architecture that pays for itself once you actually need what it's built for — many low-lag read replicas, storage that grows without a resize operation, fast failover. For a small, steady workload that never approaches those needs, standard RDS is simpler and cheaper for the same result.

text
Need many low-lag readers, auto-scaling storage, fast failover, PostgreSQL/MySQL compatible → Aurora
Small/steady workload, or need SQL Server/Oracle/Db2 → standard RDS

What we're doing: Choose between Aurora and standard RDS for two different workloads.

decision.txttext
Read-heavy SaaS app, PostgreSQL, needs several low-lag read replicas
→ Aurora PostgreSQL-Compatible: shared storage keeps reader lag low

Small internal tool, steady light load, must use SQL Server
→ Standard RDS for SQL Server: Aurora does not support this engine at all
1
Multiple low-lag readers is exactly the scenario Aurora's shared-storage architecture is built to serve well.
3
The engine requirement alone rules out Aurora entirely — SQL Server is only available on standard RDS.

Why this works: The decision is rarely close once either the engine requirement or the read-scaling/failover profile is clear — Aurora is a genuine architectural upgrade for the cases it targets, and unnecessary complexity/cost for the cases it doesn't.

Remember: Choose Aurora for PostgreSQL/MySQL workloads needing many low-lag readers, auto-scaling storage, or fast failover. Choose standard RDS for other engines (SQL Server, Oracle, Db2) or small, steady workloads where Aurora's advantages go unused.

See also: aurora architecture and endpoints · rds core vocabulary

Advertisement