How many replicas a target takes
A service with several replicas is up while enough of them are. With k of n needed, it is down only when more than n − k fail at once, so its availability is the chance that at least k of the n are up: the sum of C(n, i) × ai × (1 − a)n − i for i from k to n. The AWS whitepaper on availability with redundancy uses the same idea: a workload with s spares fails only when s + 1 subsystems fail. The calculator sums the exact probabilities rather than AWS's approximation, counts up from k and stops at the first count that meets your target. k is the number of replicas that carry the load, and the answer is that number plus the spares.
The default is replicas at 99.9% where 2 must be up, aiming for 99.99%. Two replicas give 99.8001%, which misses. Three give 99.9997%, which meets it, so the answer is 3: the two that carry the load and one spare.
Count what carries the load
Needed is not always 1. Two nodes running at 60% each cannot lose one without overload: the survivor would have to run at 120%. The Azure reliability guidance on redundancy gives this example, and it is the default here, with 2 needed. Count the replicas that must be up to carry the load. For an autoscaled service, run the calculator twice: with the replicas needed at peak and with those needed off-peak. It does not weight the two by the time spent at each.
Pitfall: one spare is not always enough
One spare (N+1) covers less as the group grows. With 1 replica needed at 99.9%, 2 replicas give 99.9999%. With 10 needed, 11 give only 99.9945%. That meets 99.99%, but 99.999% takes 12. The more replicas you need, the more failures one spare has to cover.
The figure also assumes the replicas fail independently. Replicas that share a node, a zone or a deployment fail together, and spreading them across failure domains is what makes the assumption true: see topology spread constraints in the Kubernetes docs. To combine the replicas with a load balancer and a database, use the composite SLA calculator, and to see what a figure allows per day or quarter, the uptime calculator.
FAQ
How many replicas do I need for 99.99% availability?
It depends on how available one replica is and how many must be up to carry the load. If 2 must be up and each replica is 99.9%, you need 3: 2 of 3 gives 99.9997%, and 2 of 2 only 99.8001%. If one replica can carry the load, 2 replicas at 99% reach 99.99% (1 − 0.01² = 99.99%), and 2 at 99.9% reach 99.9999%.
Is three replicas enough?
Three replicas at 99.9% where 2 must be up give 99.9997%, which is about 1m 35s of downtime a year. That holds only if the three fail independently. Three replicas on one node or in one zone all go down if that node or zone fails, so the figure no longer holds. Spread them across failure domains.
Where do I get the availability of one replica?
You supply it. One way to estimate it is MTBF ÷ (MTBF + MTTR): the mean time between failures over that plus the mean time to recover. The AWS Reliability Pillar gives 150 days between failures and a 1 hour recovery as 99.97%. You can also measure it from your own uptime data. A cloud provider's SLA for one instance is another source, but check the current figure, because this page has no presets.
Do autoscaling or pod disruption budgets change the result?
Not in this calculator. Something has to start a replacement for a failed replica, such as a Kubernetes controller or an auto scaling group, and that takes time. Recovery time is not an availability percentage, so it is not modelled here. A pod disruption budget limits voluntary disruptions such as node drains. It cannot prevent involuntary ones, such as a node failing. For an autoscaled service, run the calculator twice: with the replicas that must be up at peak and with those that must be up off-peak.
Why does each extra replica add less?
Each extra replica cuts the chance that too few are up by a large factor, so the downtime shrinks fast and then stops mattering. At 99.9% with one needed, a second replica takes the downtime from about 8h 46m a year to about 32 seconds. A third takes it to a fraction of a second. The AWS whitepaper on redundancy makes the same point: past about three spares the gain is not worth the cost. Once the replicas are better than the rest of the system, improve the rest.