Achieving Ultimate Application Resiliency: A Hybrid F5 Architecture Combining BIG-IP HA and Distributed Cloud WAAP
In today’s digital-first world, ensuring constant application availability and robust security is paramount for business success. Any performance degradation or downtime can lead to significant financial loss, damage to brand reputation, and a poor user experience. Enterprises face the dual challenge of protecting their applications from an ever-evolving threat landscape while guaranteeing seamless access for users, even in the face of infrastructure failures. Traditional disaster recovery (DR) solutions are often complex, slow, and require manual intervention, making them inadequate for modern, distributed applications.
This article presents a powerful, fault-tolerant architecture that combines the strengths of on-premises F5 BIG-IP Application Delivery Controllers (ADCs) with the cloud-native capabilities of F5 Distributed Cloud Web App and API Protection (WAAP). By integrating key F5 ADC use cases, local fault tolerance (ADC Use Case #2) and global load balancer failover (ADC Use Case #8), this hybrid solution delivers a multi-layered defense and automated disaster recovery, ensuring your applications remain secure, available, and performant.
Architecture Overview: The Best of Both Worlds
This solution establishes a relationship between a trusted, highly available on-premises ADC cluster and a flexible, scalable cloud-delivered security and application delivery service. This architecture specifically uses XC WAAP on F5’s Regional Edges (RE) and forwards traffic directly to the on-premises BIG-IP, without involving a Customer Edge (CE) node, per the user’s request.
-
On-Premises F5 BIG-IP Local Traffic Manager (LTM) deployed in a High Availability (HA) Cluster: The workhorse of the data center, the on-premises BIG-IP deployment consists of an active/standby LTM pair providing local fault tolerance. This cluster manages intelligent traffic management, persistence, and load balancing for the backend application servers residing in the primary data center. This configuration eliminates the BIG-IP itself as a single point of failure.
-
F5 Distributed Cloud WAAP on Regional Edge (RE): This is the application’s global front door. F5’s REs are globally distributed, high-capacity points of presence (PoPs) interconnected by a multi-terabit private backbone. All user traffic is first directed to the nearest RE via Anycast routing. Here, F5 XC WAAP provides a critical first line of defense, including Web Application Firewall (WAF), DDoS mitigation, and bot protection, before forwarding legitimate traffic to the on-premises environment.
-
F5 Distributed Cloud DNS and HTTP Load Balancers: These components work in concert to provide a powerful, SaaS-based Global Server Load Balancing (GSLB) capability. The DNS Load Balancer provides global traffic steering, while the HTTP Load Balancer manages application-level health checks and failover logic. It monitors the health of the entire primary data center (represented by the BIG-IP HA cluster’s public-facing floating IP) and a secondary disaster recovery (DR) site, enabling automated, policy-driven failover in the event of a complete site outage.
Architecture diagram
Deep Dive: The Three Pillars of Hybrid Resiliency
This architecture’s resilience stems from three integrated layers of protection, addressing security threats, local hardware failures, and global site outages.
Pillar 1: Resiliency Through Edge Security with F5 XC WAAP
Application downtime isn’t just caused by hardware failure; it’s often the result of overwhelming security attacks. By positioning F5 XC WAAP at the edge, this architecture builds resiliency by neutralizing threats before they can impact the core infrastructure.
-
Volumetric DDoS Mitigation: The F5 Global Network is built to absorb and scrub massive, multi-terabit DDoS attacks at the network edge across Layers 3-7. This ensures that such attacks never reach the on-premises data center’s internet circuit, preventing a common cause of widespread outages.
-
Advanced Web Application Firewall (WAF): The WAF at the edge shares the same proven core engine as the on-premises BIG-IP Advanced WAF (AWAF). It protects against the OWASP Top 10, zero-day exploits, and other application-layer attacks using a combination of signatures, behavioral analysis, and AI-powered machine learning. The WAF policy is applied directly to the HTTP Load Balancer in the F5 XC Console and can be set to “Monitoring” mode initially to prevent false positives before switching to “Blocking” mode for active protection.
-
Bot Defense: Integrating technology from F5’s acquisition of Shape Security, XC WAAP provides sophisticated bot protection that uses AI and machine learning to distinguish between human and automated traffic. This mitigates threats like credential stuffing, content scraping, and application-layer DDoS, ensuring that only legitimate user traffic is processed by the application infrastructure.
-
Threat Offloading: By filtering out malicious traffic at the global edge, F5 XC WAAP ensures the on-premises BIG-IP cluster and the applications behind it can dedicate their resources to serving valid users. This prevents security events from turning into availability incidents by conserving CPU, memory, and bandwidth on the origin infrastructure.
Together, these edge security controls turn the F5 Global Network into a protective buffer that absorbs attacks before they can degrade performance or take applications offline. By stopping threats at the edge, XC WAAP makes sure security incidents never become availability incidents, which is the first layer of true application resiliency.
Pillar 2: Local Fault Tolerance with BIG-IP High Availability (ADC Use Case #2)
The second pillar of resilience addresses single points of failure within the primary data center. Instead of relying on a single BIG-IP device, this architecture uses a high-availability (HA) cluster, a core tenet of F5’s ADC Modernization Use Case #2.
-
Active/Standby Model: Two BIG-IP systems are deployed as a redundant pair. One device is “active,” processing all live traffic, while the “standby” unit continuously monitors the active device’s health and maintains a synchronized configuration. If the active unit fails due to a hardware or software issue, the standby unit automatically and immediately takes over, ensuring service continuity with little to no user interruption.
-
Device and Traffic Groups: This HA functionality is managed through two key constructs:
-
Device Groups: A “Sync-Failover” device group is a collection of BIG-IP systems that trust each other and synchronize their configurations. This ensures the standby unit is always ready with an up-to-date configuration. A device can only belong to one Sync-Failover group, and all devices should run the same software version for reliable operation.
-
Traffic Groups: A traffic group is a collection of related configuration objects—most importantly, the “floating” virtual IP addresses that receive traffic from XC WAAP. These objects run on the active device and “float” as a single unit to the standby device during a failover. This ensures the application’s network identity seamlessly moves to the new active device.
-
-
Stateful Failover with Mirroring: To prevent the disruption of active user sessions during a failover, F5 provides stateful mirroring capabilities.
-
Connection Mirroring: This feature duplicates TCP/UDP connection information from the active to the standby BIG-IP in real-time. This is critical for long-lived connections, as it prevents them from being terminated during a failover.
-
Persistence Mirroring: This ensures that session affinity records (which “stick” a user to a specific backend server) are also replicated. After a failover, the new active BIG-IP knows exactly which server to send the user’s subsequent requests to, preserving the session and preventing data loss or the need to log in again.
-
By combining synchronized device groups, floating traffic groups, and stateful mirroring, the BIG-IP HA cluster makes sure a single device failure never becomes an application outage. This local fault tolerance keeps user sessions intact and the primary data center serving traffic, building resiliency directly into the core of the infrastructure.
Pillar 3: Automated Global Failover with F5 XC Load Balancers (ADC Use Case #8)
The final pillar provides a defense against a complete site-level disaster, replacing slow, error-prone manual failover processes with an automated, policy-driven framework. This is orchestrated by the F5 Distributed Cloud HTTP and DNS Load Balancers, which provide a powerful and flexible GSLB capability. The core of this capability is decoupling application health from DNS propagation delays, allowing for failover in seconds, not minutes.
Configuration Deep Dive: Implementing Global Failover in F5 Distributed Cloud
Achieving automated failover involves configuring several key components within the F5 XC Console’s “Multi-Cloud App Connect” service.
-
Create and Prioritize Origin Pools:
-
Origin Pools represent the backend endpoints that serve application content. You will configure two distinct pools.
-
Primary Pool: This pool is configured with the public floating VIP of the on-premises BIG-IP HA cluster, using its IP address or public DNS name. It is assigned a higher priority value (e.g., 10) to designate it as the active pool.
-
Secondary (DR) Pool: This pool contains the public IP or DNS name of the application endpoint in the disaster recovery site. It is assigned a lower priority value (e.g., 5 or 1) to designate it as the standby pool. With unequal priorities, F5 XC directs all traffic to the highest-priority pool that is healthy; the lower-priority pool only receives traffic if all higher-priority pools are down.
-
-
Configure Intelligent, Multi-Layered Health Checks:
-
F5 Distributed Cloud continuously runs highly configurable health checks from multiple RE locations to get a true picture of application health. F5 strongly recommends configuring health monitors for all production origins to improve resiliency.
-
L7 (HTTP/HTTPS) Check: This is the most effective check as it validates the entire application stack. It is configured to send a specific request (e.g., GET /healthz) and validate the response by checking for an expected status code (e.g., 200 OK) and optionally
a “Receive String” in the response body. This confirms the application logic is functioning correctly. -
L4 (TCP/UDP) and L3 (ICMP) Checks: These checks can also be configured to verify basic port availability and network reachability, respectively.
-
These health checks are then applied to their respective origin pools.
-
-
Tie it Together with an HTTP Load Balancer:
-
An HTTP Load Balancer is created in the F5 XC Console. You assign it a domain name (e.g., app.yourdomain.com) and attach the primary and DR origin pools you created.
-
This load balancer is the component that enforces the failover logic based on the health check results and origin pool priorities.
-
-
Secure the Origin with Firewall Rules:
-
A critical final step is to ensure attackers cannot bypass the F5 XC platform.
-
You must configure your on-premises firewall to create an allowlist, permitting inbound traffic on your application’s port (e.g., 443) only from F5’s published Regional Edge IP ranges.
-
The official list of IP addresses is available in the F5 documentation, often in a machine-readable JSON format for automation. It is a best practice to subscribe to notifications for changes to these IP ranges.
-
All other inbound traffic to the application port must be denied.
-
With prioritized origin pools, multi-layered health checks, and a locked-down origin, F5 Distributed Cloud can detect a site-wide outage and redirect users to the DR site in seconds, with no manual intervention. This automated global failover completes the resiliency model, so even the loss of an entire data center doesn’t take the application offline.
A Resilient Architecture in Action
Let’s walk through failure scenarios to see how the components work
together.
Scenario 1: On-Premises BIG-IP Device Failure (Local Failover)
-
The active BIG-IP device in the on-prem HA pair experiences a critical hardware or software failure.
-
The standby BIG-IP detects the failure via the HA heartbeat.
-
The standby unit immediately promotes itself to become the new active device.
-
The traffic group containing the floating VIP and related objects fails over to the new active unit.
-
Thanks to connection and persistence mirroring, existing user sessions are preserved and continue to be processed without interruption.
-
F5 XC continues to send traffic to the same floating VIP, which is now being served by the newly active BIG-IP. The failover is completely transparent to both F5 XC and the end-user.
Scenario 2: On-Premises Data Center Failure (Global Failover)
-
The primary data center experiences a complete network outage, making the BIG-IP cluster’s floating VIP unreachable.
-
The F5 XC health monitors, running from multiple global REs, fail multiple consecutive times, exceeding the configured unhealthy threshold.
-
The F5 XC HTTP Load Balancer automatically marks the primary origin pool (priority 10) as “down” based on the health check failures.
-
A new user requests the application. Their DNS lookup still resolves to the F5 XC Anycast VIP.
-
The user connects to the nearest F5 RE, and the traffic passes the WAAP inspection.
-
The HTTP Load Balancer, seeing the primary pool is down, automatically redirects the request to the next-highest-priority healthy pool—the DR site (priority 5).
-
The request is forwarded to the virtual server in the disaster recovery environment, and the application remains online for the user. This entire process is automated and requires no human intervention.
-
Once the primary data center is restored and consistently passes its health checks, the HTTP Load Balancer automatically marks the primary pool as “up” and, based on policy, will begin directing new traffic back to it.
Conclusion
In an era where application uptime is non-negotiable, organizations can no longer rely on single-site or single-layer protection strategies. The challenge is to build a fault-tolerant system that is resilient against both malicious attacks and the entire spectrum of infrastructure failures, from a single device to a complete data center.
By combining the robust on-premises high-availability capabilities of F5 BIG-IP with the global scale and SaaS-based security and delivery services of F5 Distributed Cloud, enterprises can create a superior hybrid architecture. This solution, managed through the unified F5 Distributed Cloud Console, establishes a multi-layered resiliency model:
-
Edge Security: F5 XC WAAP on the Regional Edge network provides a powerful security shield, stopping threats before they can cause an outage by offloading malicious traffic from the origin.
-
Local Fault Tolerance (Use Case #2): An on-premises active/standby BIG-IP cluster eliminates the local ADC as a single point of failure, using device groups, traffic groups, and stateful mirroring to provide seamless failover for individual device issues.
-
Global Disaster Recovery (Use Case #8): The F5 Distributed Cloud DNS and HTTP Load Balancers provide intelligent, automated GSLB failover between a primary on-premises site and a disaster recovery location. It uses prioritized origin pools and sophisticated, multi-layered health checks to detect site-wide outages and automatically redirect traffic in seconds, independent of DNS TTLs.
The result is a comprehensive, secure, and highly available application delivery framework. It protects against a wide range of disruptions, ensures a seamless user experience, and provides a simplified, centrally managed operational model for the modern hybrid enterprise.