Active-Active or Active-Passive: Choosing a DNS Failover Setup

DNS failover solves the case where an entire region, data center, or point of presence becomes unreachable: a cloud provider outage, a network partition, a catastrophic failure at one location. It does not solve a partial degradation where the service is technically reachable but slow or returning errors for some requests, since a basic health check often still reports that endpoint as healthy.

It also doesn't fail over instantly. DNS resolvers and clients cache responses for the duration of your TTL, and some resolvers or clients cache longer than they should regardless of what you set. Plan around a failover window measured in minutes at best, not the instant cutover a load balancer in front of a single region can offer within that region.

Active-passive keeps one region serving all traffic while a second stands ready but idle. It's simpler to reason about: only one region is actively serving requests at any time, so there's no need to worry about data consistency or session handling across two live regions simultaneously. The cost is failover time: detecting the failure, updating DNS, and waiting for caches to expire all happen after the primary region is already down, during which real users are affected.

This fits services where a failover delay of several minutes is acceptable and where running a second region hot, actively serving traffic, adds cost or complexity, data replication, session affinity, that isn't worth it for your actual availability requirements.

Active-active serves traffic from multiple regions simultaneously, so when one fails, DNS failover just stops sending new traffic there while existing capacity in the other region absorbs the load, rather than needing to spin up or warm a passive region from a cold start. This is meaningfully faster in practice, since the failover mechanism doesn't have to wait for a standby region to actually be ready to serve traffic.

The cost is real operational complexity: your data layer needs a strategy for consistency across regions, whether that's a globally distributed database, regional read replicas with careful write routing, or eventual consistency your application can tolerate. Don't take on active-active for the failover speed benefit alone if your data architecture isn't already built for multi-region operation, since retrofitting that afterward is a much larger project than the DNS configuration itself.

A health check that only confirms the server responds to a ping or returns a healthy status on a static endpoint will report healthy right up until a downstream dependency, a database, a critical internal API, fails and takes the actual user-facing functionality down with it. Build the health check to exercise a real, representative path: a lightweight version of the actual critical transaction, not just process liveness.

Balance this against false positives: a health check that's too strict, failing on a slow but not actually broken downstream dependency, triggers unnecessary failovers that add their own risk and confusion. Tune the check to fail on things that genuinely indicate the region can't serve real traffic, and let genuinely transient slowness recover on its own without triggering a full regional failover.

Your DNS record's TTL directly trades off two things, and most teams pick one value and never revisit it:

• A short TTL means failover propagates faster once triggered, since clients and resolvers stop trusting the old answer sooner.
• A short TTL also means more DNS query volume and, for a paid DNS provider, higher cost, along with slightly higher latency on every fresh resolution.
• A long TTL reduces query volume and cost but extends how long some fraction of clients keep hitting the failed endpoint after failover has already been triggered.
• Some resolvers and clients ignore or override your TTL entirely, which is a real limitation of DNS failover, not a configuration mistake you can fully engineer around.

Set the TTL short enough to matter for your actual failover time requirements, and treat DNS failover as one layer of a broader resilience strategy, not the only mechanism standing between an outage and your users.