Active-Active vs Cold Standby: Edge-HA Explained

TL;DR

In an active-active setup, multiple edge instances continuously handle production traffic. If a location or processing path fails, traffic is distributed across remaining resources. Cold standby activates a reserve only in case of failure, requiring additional management of switchover, capacity, and operational state.

A cold standby model may initially seem efficient: a reserve infrastructure is on standby, causing minimal effort during normal operations. However, for high availability at the public application entry point, this creates an additional operational process. The reserve must be reachable, adequately sized, correctly configured, and quickly activatable in case of failure. Simultaneously, routing must detect the failure and redirect traffic.

Active-active takes a different approach. Multiple edge resources are simultaneously active and share incoming traffic. High availability is achieved not through an unused backup environment but through distributed processing capacity and the ability to redistribute traffic in case of failures.

Comparing Active-Active and Cold Standby Architectures

In cold standby, a primary environment processes the traffic. The reserve is either turned off or not integrated into the active data path during normal operations. A failover must therefore coordinate several steps: error detection, reserve activation, routing update, and possibly providing current configurations.

In active-active operations, multiple edge resources are already part of the productive architecture. Anycast can direct requests to available edge locations, while load balancing manages distribution within the platform. The individual resources are not merely backups but continuously contribute to processing.

The difference lies not only in the switchover logic. Cold standby shifts part of the risk to the failure event. Active-active distributes operational effort over normal operations and reduces dependency on a single activation procedure. However, states, configurations, and capacity limits must be consistently managed across active paths.

Traffic Distribution and Failover at the Edge

Edge high availability begins with the question of how a failure is detected. Backend health checks verify whether downstream applications are reachable and functional. For the edge itself, available processing paths, routing information, and the reachability of respective resources are crucial. If a path fails, traffic must not continue to be distributed there.

In an anycast architecture, multiple edge locations announce the same public reachability. This allows routing to direct requests to another available location if a site or network path becomes unreachable. Within the edge, Layer 4 and Layer 7 load balancing handle further distribution.

Cold standby, on the other hand, requires explicit activation or switchover. Depending on the mechanism, DNS TTLs, routing convergence, or reserve initialization can influence recovery time. Failover then becomes a process with multiple dependencies. Active-active does not eliminate every error but shortens the path between error detection and continued processing because target resources are already active.

Utilization, Capacity, and Operational Costs

The most significant economic difference concerns the use of provided resources. In the cold standby model, part of the infrastructure remains unused during normal operations. This can be sensible if the reserve is only needed for rare failures. At the same time, the company pays for redundancy without gaining ongoing throughput from it.

Active-active distributes productive traffic across multiple resources. This better utilizes existing capacity, and load peaks can be spread across multiple processing paths. However, the sizing must cover not only normal operations. If a location fails, remaining resources must handle the additional traffic at least within planned limits.

This also changes operational tasks. Instead of regularly testing a reserve for functionality, an active-active system must primarily monitor distribution, capacity reserves, health checks, and failure scenarios. Traffic and usage statistics help assess real load distributions. The operational effort does not disappear; it shifts from activating a reserve to continuous monitoring of a distributed system.

Security and Architectural Implications of Active-Active Operations

The edge is the public entry point before applications and APIs. Therefore, security functions must not be loaded or reactivated during a failover. TLS termination, web application firewall, and DDoS protection should be consistently available on active edge paths. Otherwise, the switchover may technically work but alter security or routing properties.

Backend cloaking further limits the direct visibility of actual backends. Traffic is processed at the edge and then forwarded via defined paths. For Kubernetes , the edge cloud can connect with ayedo Managed Kubernetes or with own clusters and clusters of other providers. Thus, the high availability of the edge remains separate from the specific compute provider.

The ayedo Edge Cloud combines anycast, its own network infrastructure, its own autonomous system, and a distributed multi-PoP architecture with an active-active principle. This is not synonymous with a specific Kubernetes deployment. The edge handles public traffic entry, protection, termination, and distribution; the compute infrastructure executes the workloads. This separation prevents a single cluster or provider from automatically becoming the benchmark for edge high availability.

Practical Scenario: Failure of an Edge Location

A company operates an API on Kubernetes , with clusters running at an external provider. The public endpoint is at the edge. In a cold standby model, a primary edge path would process the traffic. If it fails, a reserve would need to be activated and then made reachable via DNS or routing. Recovery thus depends on several sequential steps.

In an active-active model, multiple edge locations already process productive requests. If one fails, traffic is distributed to available locations. The backends remain unchanged in reachability; only the public processing path changes. It is crucial that remaining resources have sufficient capacity and that security and routing configurations are consistent.

FAQ

Is active-active automatically fail-safe?

No. Active-active reduces dependency on a single resource. It still requires correct health checks, sufficient remaining capacity, consistent configurations, and tested failure assumptions.

What is the main disadvantage of cold standby?

The reserve must first be activated and made reachable in case of failure. This creates additional dependencies in routing, initialization, configuration state, and restart.

Does active-active need to be operated on the same provider?

No. The edge can be operated independently of the compute platform. Kubernetes clusters can run at ayedo, in-house data centers, or with other providers.

Conclusion

Active-active is not merely a distribution model but an operational decision: redundant edge resources are continuously used, monitored, and included in capacity planning. Cold standby can conserve resources during normal operations but shifts significant risks to the failure event. For companies with distributed applications and APIs, it is crucial to consider edge and compute separately. The ayedo Edge Cloud implements this separation with a distributed active-active architecture, anycast, and its own network operations.