Aurora Replica Calculator
Size Aurora read replicas for a target query rate and utilisation, check the 15-replica limit and price the reader fleet.
About Aurora Replica Calculator
Aurora replicas read the same shared storage volume as the writer, so read scaling is close to linear and the sizing is a capacity division rather than a replication-throughput problem. The spare matters because a fleet sized at exactly 100% of capacity is one failover away from overload, and lag is estimated from the writer's change rate since replicas apply redo from storage rather than replaying a binlog. The replica hourly rate is an editable input with a realistic us-east-1 default, so confirm the current price with AWS for your region and instance family. Aurora replica lag is typically well under a second, which makes the reader endpoint safe for most read traffic — but only if the fleet has enough headroom that one reader disappearing does not cascade.
Formula
Aurora Replica
replicas = ceil(read QPS ÷ (per-instance QPS × target utilisation)) + failover spare, capped at the 15-replica cluster limit.
- 15
- Maximum Aurora Replicas in one cluster
- target utilisation
- Headroom policy — 70% leaves room for spikes and vacuum
- spare
- Extra reader so losing one does not overload the rest
- replica lag
- Delay before a committed write is visible on a reader
Worked example
With the default values below, Aurora Replica Calculator returns Read Replicas Needed of 7. Change any input above and every figure here is recalculated in your browser.
Inputs used
- Peak read queriesaccepts 0–5,000,000 queries/s
- 12,000 queries/s
- Read capacity of one instanceaccepts 1–500,000 queries/s
- 3,000 queries/s
- Target utilisation per replicaaccepts 10–100 %
- 70 %
- Keep one spare replica for failover
- Yes
- Replica instance priceminimum 0 $/hour
- 0.29 $/hour
- Billed hours per monthaccepts 0–744 hours
- 730 hours
- Writer change rateaccepts 0–5,000 MB/s
- 12 MB/s
Results
- Read Replicas Needed
- 7 replicas
- Fleet Read Capacity
- 21,000 queries/s
- Resulting Utilisation
- 57.1%
- Estimated Replica Lag
- 116 ms
- Monthly Reader Fleet Cost
- $1,481.90
- Cluster Limit Check
- Fits — 7 of the 15 replicas an Aurora cluster allows
Step by step
- 1Values used
- 2Aurora Replica
- 3Read Replicas Needed= 7 replicas
- 4Fleet Read Capacity= 21,000 queries/s
- 5Resulting Utilisation= 57.1
- 6Estimated Replica Lag= 116 ms
- 7Monthly Reader Fleet Cost= 1,481.90
- 8Cluster Limit Check= Fits — 7 of the 15 replicas an Aurora cluster allows
Assumptions and limits
- The result is derived only from the 7 inputs listed above. Anything not among them is not part of the calculation.
- In particular, this calculator does not take inflation, tax or compounding frequency into account.
- Figures are rounded for display to 2 decimal places, so totals built from several rounded parts can differ slightly from the unrounded arithmetic.
How these calculators are built and tested is described on the Methodology page. If a figure looks wrong, please report it.
Frequently Asked Questions
How is Aurora Replica calculated?
replicas = ceil(read QPS ÷ (per-instance QPS × target utilisation)) + failover spare, capped at the 15-replica cluster limit. Aurora replicas read the same shared storage volume as the writer, so read scaling is close to linear and the sizing is a capacity division rather than a replication-throughput problem. The spare matters because a fleet sized at exactly 100% of capacity is one failover away from overload, and lag is estimated from the writer's change rate since replicas apply redo from storage rather than replaying a binlog. The replica hourly rate is an editable input with a realistic us-east-1 default, so confirm the current price with AWS for your region and instance family.
Why does Aurora Replica matter?
Aurora replica lag is typically well under a second, which makes the reader endpoint safe for most read traffic — but only if the fleet has enough headroom that one reader disappearing does not cascade.
What values do I need to enter?
This calculator takes 7 inputs: Peak read queries, Read capacity of one instance, Target utilisation per replica, Keep one spare replica for failover, Replica instance price, Billed hours per month, Writer change rate. The pre-filled defaults are a realistic starting point — replace them with figures from your own environment for a result you can act on.
Why is Aurora replica lag so much lower than RDS read replica lag?
RDS replicas replay the binary log, which is a single-threaded logical operation on the replica. Aurora replicas read the same storage volume as the writer and only apply redo to their buffer cache, so lag is usually tens of milliseconds rather than seconds.