Active-Active vs Active-Passive: What Your Uptime Target Buys You

A single application instance in a single region is the cheapest setup and the one most small teams start with. Its failure mode is total: if the instance, the availability zone, or the region has a problem, you're down until someone (or something) restarts service elsewhere. This is a reasonable choice when your users would forgive an hour of downtime a handful of times a year, and it's a poor choice once a customer contract includes an uptime commitment you haven't actually engineered for.

Even within "single-region," running multiple instances across separate availability zones in that region is a cheap, meaningful step up: it protects against a single machine or zone failing without the cost or complexity of a second region. Plenty of teams conflate "single-region" with "single point of failure" when the actual gap is just not having spread their existing instances across zones.

Active-passive keeps a standby copy of your infrastructure, often in a second availability zone or region, that takes over when the primary fails. The standby can be running and idle (faster failover, more cost) or provisioned on demand when a failure is detected (slower failover, less cost). Failover isn't instant: detecting the failure, promoting the standby, and redirecting traffic typically takes anywhere from under a minute to several minutes depending on how much of that process is automated versus manual.

The operational discipline this requires is easy to underestimate: a standby that's never actually been failed over to in a drill is a standby you don't really know works. Teams that skip failover drills often discover gaps (an expired credential, a config that only exists on the primary) during a real incident instead of a scheduled test.

Database replication is usually the hardest part to get right here. An asynchronous standby database can lag behind the primary by seconds or more, which means a failover under load can lose the most recent writes. Decide up front, and document, how much data loss is acceptable in a failover; that number should drive whether you need synchronous replication, which costs latency on every write, or asynchronous, which is cheaper but riskier during a failover.

Active-active runs full production capacity in two or more locations simultaneously, splitting real traffic across them, so there's no failover step at all: traffic just shifts away from a failed location. This buys the fastest recovery of the three approaches, but it requires your data layer to handle writes safely from multiple locations, which is a genuinely hard problem for most databases and often means real architectural changes, not just infrastructure changes.

Most teams that need this level of resilience are already operating at a scale, and with a contractual uptime commitment, that justifies the engineering investment. Adopting it earlier than that usually means solving a distributed-data problem you didn't need to solve yet.

For example, a team that adopts active-active before it's needed often discovers the hard requirement only once they hit a real conflict: two users in different regions edit the same record within seconds of each other, and now the application has to decide which write wins, or how to merge them. That's a product decision as much as an infrastructure one, and it's far cheaper to make deliberately, before it's forced by an incident, than to retrofit after.

A 99.9% target allows roughly 8.76 hours of downtime a year, while 99.99% shrinks that to about 53 minutes and 99.999% to roughly 5 minutes¹. Active-passive with a well-drilled runbook can realistically hit 99.9% to 99.95% uptime¹. Getting past that into 99.99% availability territory is where active-active, or at minimum a heavily automated active-passive setup with sub-minute detection, becomes necessary rather than aspirational¹.

Before committing to a target, check what your actual customer contracts require. Founders regularly find they've been designing for 99.99% uptime because it sounded appropriately serious, when their signed agreements only commit to 99.9%, a target that costs meaningfully less to operate¹.

Match the approach to your situation like this:

• Single-region fits when users would forgive an hour of downtime a handful of times a year, ideally with instances spread across availability zones.
• Active-passive fits once a customer contract includes an uptime commitment, provided you have a well-drilled failover runbook.
• Active-active fits only when your data layer can handle writes safely from several locations and the target justifies running everything twice.
• Whatever you choose, rehearse failover on a schedule so the first real test is not an actual incident.