Skip to content
Calcrivo

Aurora Replica Calculator

Size Aurora read replicas for a target query rate and utilisation, check the 15-replica limit and price the reader fleet.

Inputs

queries/s
queries/s
%

A spare absorbs the load when one reader is lost or restarting.

$/hour
hours
MB/s

Drives the redo volume replicas must apply, which sets replica lag.

Read Replicas Needed

7replicas

Fleet Read Capacity

21,000queries/s

Resulting Utilisation

57.1%

Estimated Replica Lag

116ms

Monthly Reader Fleet Cost

$1,481.90

Cluster Limit Check

Fits — 7 of the 15 replicas an Aurora cluster allows

Step by step

  1. Values used

    Peak read queries = 12,000 queries/s; Read capacity of one instance = 3,000 queries/s; Target utilisation per replica = 70 %; Keep one spare replica for failover = Yes; Replica instance price = 0.2900 $/hour; Billed hours per month = 730 hours; Writer change rate = 12 MB/s

  2. Aurora Replica

    replicas = ceil(read QPS ÷ (per-instance QPS × target utilisation)) + failover spare, capped at the 15-replica cluster limit.

  3. Read Replicas Needed

    = 7 replicas

  4. Fleet Read Capacity

    = 21,000 queries/s

  5. Resulting Utilisation

    = 57.1

  6. Estimated Replica Lag

    = 116 ms

  7. Monthly Reader Fleet Cost

    = 1,481.90

  8. Cluster Limit Check

    = Fits — 7 of the 15 replicas an Aurora cluster allows

How it works

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

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.

You might also need