Add read capacity without slowing down writes

A dedicated writer, with read replicas for customers with heavy load

Database capacity follows the size of the deployment. Small and Medium deployments use one cost-efficient writer. Large and Extra Large deployments add physical Aurora read replicas inside the regional database cluster. Managed connection pooling provides separate addresses for writes and reads, so queries that can use a replica get more capacity and do not compete with writes or with reads that need the latest data.

Regional database topology

One write path. Dedicated read capacity.

Large · 1 readerExtra Large · 2 readers

Writer endpoint

Writes + consistent reads

Mutations, transactions, locks and read-after-write flows remain on the writer.

Read endpoint · Replica-safe reads

physical replication

Physical reader 1

Reporting + search

Read-heavy work uses capacity that does not compete with the write path.

Physical reader 2

Extra Large headroom

A second reader expands eligible read capacity for the largest deployments.

Built in

What you get

Small and Medium deployments use a single writer
Physical read replicas: one for Large deployments and two for Extra Large
Separate addresses for writes and reads, so the application chooses which one each query uses
Managed connection pooling absorbs bursts of connections before they reach the database
Writes, transactions and reads that must see a change just written stay on the writer
Reports, search and list queries that can use a replica run on read capacity
The platform’s provisioning creates and updates the whole regional cluster as infrastructure-as-code
Large and Extra Large deployments can add an asynchronous Aurora Global Database secondary in another onboarded region

Under the hood

How it works

Larger deployments add read replicas

Smaller deployments keep the lower-cost single writer. Large adds one physical read replica and Extra Large adds two, all managed in the same way by the platform’s provisioning. A customer can grow into dedicated read capacity, and your application team does not run a second database system.

Connection pooling protects the database

Applications connect through managed pooled addresses and do not open an unlimited number of sessions directly on the database. The writer pool handles writes and reads that need the latest data. The read pool sends suitable queries to the read replicas of the regional database cluster.

The application chooses where each read goes

The delay before a replica has the latest data is small, but it is never assumed to be zero. Transactions, locks and reads that follow a write stay on the writer. Reports, search and other work that can accept a short delay can choose the read address. The rule for each query is visible in application code and is not hidden in an automatic router.

Regional scaling, with an optional copy in another region

Read replicas inside the deployment region provide normal read capacity and a standby for database failover. For eligible Large and Extra Large deployments, operators can also add an asynchronous, read-only Aurora Global Database secondary in another onboarded region. Promoting it and redirecting writes are deliberate recovery actions taken by an operator. Automated failover and regular drills are separate operating work.

Further additions

Additions that extend the capability described above.

Automated failover to another region and regular recovery drills

Pairs well with

Want a deeper walkthrough of Database Scaling & Resilience?

A solution architect will demo the live service against your domain model.

Get a deployment assessment