Primary, Secondary, or Active-Active at the Edge?

TL;DR

When it comes to public traffic ingress, choosing between primary-secondary, cold standby, and active-active is not just a matter of availability. Key factors include failover time, utilization, operational effort, state management, and the manageability of failure scenarios. Active-active utilizes resources better but requires a consistent architecture and robust operational processes.

Introduction

A standby system that does not process traffic during normal operations is not automatically the safest architecture. While it reduces complexity during regular operations, it introduces its own risks: unknown errors in the backup path, outdated configurations, and a failover that is only validated during disruptions. For public traffic ingress, it is essential to separately consider how routing, state changes, capacity, and operations interact. A primary-secondary model can be sensible for certain requirements. A cold standby architecture fits other conditions. Active-active offers a different balance between utilization and resilience. The right decision does not depend on a generic architectural ideal.

1. Primary-Secondary: Clear Roles, Controlled Failover

In the primary-secondary model, an active instance processes regular traffic. The secondary instance remains available but only takes over after a detected failure. This clear role distribution simplifies configuration, troubleshooting, and responsibilities. Especially when applications or network paths cannot be easily operated in parallel, primary-secondary can be a pragmatic solution.

The cost lies in unused capacity and failover risk. The secondary environment must be regularly synchronized with configurations, certificates, routing information, and security rules. Otherwise, a backup path exists technically but not reliably equivalent. Additionally, it must be defined who triggers the switch, how DNS or routing changes are propagated, and how a rollback occurs. A primary-secondary model is robust only if the failover strategy and rollback are treated as repeatable operational processes.

2. Cold Standby: Low Ongoing Costs, High Switch Dependency

In cold standby, the backup is not or only partially active. Resources are only started, scaled up, or brought into the traffic path in case of a disruption. This can be economically attractive if failures are rare and the requirements for restart time are limited. This model can also be understandable for systems with high capacity costs.

For public ingress, however, cold standby is particularly critical. The failure encompasses not just a single component but potentially provisioning, configuration, routing, TLS termination, security functions, and backend reachability. Each additional activation step prolongs recovery and increases the number of potential error sources. Moreover, the backup is not fully loaded during regular operations. Defective or outdated dependencies thus remain more easily undetected. Cold standby is therefore mainly suitable where a longer failover is tolerated, the activation process is automated, and regularly tested.

3. Active-Active: Planning Utilization and Resilience Together

Active-active means that multiple edge paths process productive traffic simultaneously. If one path fails, the remaining part can continue to operate. In normal operations, the available capacity is utilized, making investments in backup systems economically better utilized. In distributed edge architectures, Anycast can direct traffic to accessible locations or network points, while health checks and routing logic consider backend reachability.

However, active-active is not an automatic security gain. Configurations must be consistently distributed, certificates and policies synchronized, and states correctly handled. Stateful applications, session bindings, or asymmetric network paths can complicate the architecture. Additionally, overload scenarios must be considered: If one part fails, the remaining capacity must be able to handle the additional traffic. Active-active shifts the effort from manual switching to design, automation, monitoring, and capacity planning.

4. Decision Criteria for Public Traffic Ingress

The central question is not “Active-Active versus Active-Passive?” but rather: What failures can occur, how quickly must traffic continue, and which operational processes are manageable? Relevant criteria include Recovery Time Objective, expected failure patterns, capacity reserves, configuration consistency, and the ability to regularly test failover. The separation of edge and compute is also important: An active edge path can continue to accept traffic even if a single backend has failed. Backend health checks and failover are therefore not the same as switching between two edge installations.

For companies with multiple providers or Kubernetes clusters, decoupling also gains importance. The edge should control public ingress, TLS termination, protection, and distribution independently of the location of workloads. The ayedo Edge Cloud is designed for this as a distributed multi-PoP platform with its own Autonomous System and active-active principle. It can direct traffic to ayedo Managed Kubernetes as well as to self-managed or externally operated Kubernetes clusters. This means the operational model of the edge is not tied to a single compute location.

Practical and Operational Scenario

A company operates an API in two Kubernetes clusters with different providers. In the primary-secondary model, normal traffic is directed exclusively to the first cluster. The second cluster must be kept synchronized and activated via routing or DNS in case of a disruption. In cold standby, start and provisioning times are also added.

In an active-active architecture, both paths accept traffic. Health checks remove unreachable backends from distribution, while the edge centrally maintains public access and protection functions. For this, both clusters must meet the same API contracts, security rules, and capacity assumptions. The comparison shows: Active-active reduces switch dependencies but increases the requirements for consistency and operations.

FAQ

Is Active-Active always more available than Primary-Secondary?

No. Active-active reduces certain failover dependencies but can fail due to inconsistent configurations or insufficient remaining capacity. The quality of operational processes is crucial.

When is Cold Standby justifiable?

When longer restart times are acceptable, the activation process is automated, and the backup is regularly tested. For time-critical public APIs, the model is often too slow.

Does Active-Active also apply to the backends?

No. Edge and compute can be operated differently. The edge can work actively redundant, while backends are prioritized, distributed, or removed from the traffic path in case of failure via health checks.

Conclusion

The choice of operational model is a decision about failure behavior, capacity utilization, and organizational discipline. Primary-secondary creates clear roles, cold standby reduces ongoing backup costs, active-active reduces switch dependencies, and continuously utilizes infrastructure. For public traffic ingress, it is crucial whether routing, protection, TLS, health checks, and backend connectivity can be operated as a coherent process. The ayedo Edge Cloud integrates these tasks into its own distributed active-active edge without dictating the choice of compute platform.