# F5 Distributed Cloud Multi-Cloud Networking Lab - Part 2: Hybrid

**URL:** <https://community.f5.com/t/f5-distributed-cloud-multi-cloud-networking-lab-part-2-hybrid/77331>\
**Category:** F5 Technical Articles\
**Tags:** f5-distributed-cloud, waf\
**Created:** [September 1, 2026, 12:00pm UTC](https://community.f5.com/t/f5-distributed-cloud-multi-cloud-networking-lab-part-2-hybrid/77331 "2026-09-01T12:00:00Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![Martin\_Petersen](https://d1p9zq3aats0t8.cloudfront.net/user_avatar/community.f5.com/martin_petersen/32/18608_2.png) [@Martin\_Petersen](https://community.f5.com/u/Martin_Petersen)\
**Post date:** [September 1, 2026, 12:00pm UTC](https://community.f5.com/t/f5-distributed-cloud-multi-cloud-networking-lab-part-2-hybrid/77331/1 "2026-09-01T12:00:00Z")

</div>

**Series:** [F5 Distributed Cloud Multi-Cloud Networking Lab](https://community.f5.com/topic/347317)

**Previous:** [Part 1: SaaS - RE-Only Architecture](https://community.f5.com/topic/347319)

**Next:** [Part 3: Multi-Site - CE-Only Architecture](https://community.f5.com/topic/347321)

## When Public Is Not an Option

The SaaS model works well for applications with publicly reachable backends. But in practice, many workloads run in private subnets - behind firewalls, in VPCs without internet-facing load balancers, or in on-premises data centers that are deliberately isolated from the internet.

These applications still need global load balancing, WAF protection, and DDoS mitigation. They just cannot expose their origins publicly.

This is the problem the _ **Hybrid model** _ solves. It keeps everything that makes the SaaS model effective - global anycast ingress, WAF at the edge, centralized policy management; and adds a private path from the F5 Global Network into your environment.

That private path is the _**Customer Edge (CE)**_.

## The Customer Edge

A Customer Edge is a lightweight node, a virtual machine or bare-metal appliance, that you deploy in your own environment. It runs wherever your applications run: in an AWS VPC, an Azure VNet, a GCP project, or an on-premises data center.

What makes the CE different from a traditional reverse proxy or VPN gateway:

- _ **Outbound-only connectivity:** &nbsp;_The CE initiates connections to the F5 Global Network. No inbound firewall rules required. No public IPs on the CE. No VPN configuration.
- _ **Automatic mesh:** &nbsp;_Once registered, the CE joins the xC fabric - an encrypted overlay network that connects all REs and CEs. Traffic between any two points in the fabric is encrypted and optimized.
- _ **Full proxy capabilities:** &nbsp;_The CE can terminate TLS, apply WAF policies, discover local services, and forward traffic to private backends. It is not just a tunnel endpoint - it is a complete application delivery node.

In the Hybrid model, the CE acts as the _ **egress point:** _ traffic enters via the RE (global anycast), traverses the xC fabric, and exits through the CE into your private network.

## How It Works

 ![image_347320.png](https://d20hrnpixdzcsd.cloudfront.net/original/3X/3/d/3d47e15f4671c892893ff1d4765fb469a4df7c26.png)

1. _ **A user makes a request** _ to the application’s FQDN
2. _ **DNS resolves to xC’s anycast IP** _ - the user connects to the nearest Regional Edge
3. _ **The RE terminates TLS** _ and applies WAF, Bot, and DDoS policies - identical to the SaaS model
4. _ **The RE forwards the request through the xC fabric** _ to the Customer Edge in the target region
5. _ **The CE receives the request** _ and forwards it to the private backend (e.g., a server in a VPC private subnet)
6. _ **The response travels back** _ through the CE → xC fabric → RE → user

The critical difference from SaaS: **step 4 and 5 replace the internet egress**. Instead of the RE connecting to a public origin over the internet, it routes through the private xC fabric to a CE that has local network access to the backend.

## Why This Matters

### No Public Exposure

The backend never needs a public IP, a public load balancer, or an internet-facing security group. The CE connects to backends using private IPs on the local network. From the backend’s perspective, traffic comes from the CE — a trusted, local source.

### No Inbound Firewall Rules

Traditional hybrid architectures require opening inbound ports for VPN tunnels or reverse proxy connections. The CE reverses this: it initiates outbound connections to the xC fabric. Your firewall only needs to allow outbound HTTPS (port 443) and IPSec/IPSEC-NAT-T (ports 500, 4500). No inbound rules, no NAT hairpinning, no DMZ configurations.

### Consistent Security

The WAF policy you apply in the SaaS model works identically in the Hybrid model. The RE still inspects traffic at the edge. The only difference is where the traffic goes after inspection. This means you can start with SaaS for a public-facing application and later move it behind a CE without changing your security configuration.

### Origin Discovery via CE

In the Hybrid model, origin pools reference backends that are only reachable from the CE’s local network. Discovery methods include:

- **Private IP** - direct IP address of the backend server
- **Private DNS** - hostname resolved by the CE on the local network (e.g., Route53 private hosted zone)
- **Kubernetes service** - service name in a local k8s cluster (later use case)

The CE acts as the resolver and forwarder. The RE does not need to know the backend’s IP - it only needs to know which CE site to route to.

## Multi-NIC: Inside and Outside

In many environments, the CE is deployed with two network interfaces:

| Interface | Name | Connected To | Purpose |
| --- | --- | --- | --- |
| _ **SLo** _ (Site Local Outside) | Public / Internet-facing | Public subnet, Internet Gateway, (application servers) | Connects to the xC fabric, receives management traffic |
| _ **SLi** _ (Site Local Inside) | Private / Backend-facing | Private subnet, application servers | Forwards traffic to local backends |

This dual-NIC architecture provides network segmentation: the SLo interface faces the internet (for fabric connectivity), while the SLi interface faces the private network (for backend access). Traffic from the xC fabric arrives on SLo and exits to the backend via SLi.

In the lab environment, the CE’s SLo interface sits in the public subnet with an Elastic IP, and the SLi interface sits in the private subnet alongside the Ubuntu servers and BIG-IP appliances. A Transit Gateway connects the Main VPC to the App VPC, extending the CE’s reach to application workloads in a separate network segment.

For a more simplistic set up, or a Proof of Concecpt, the _ **SLo can be used for inside and outside traffic** _ (Single-NIC).

## How This Looks in the Lab\*\*

The Hybrid model maps to several lab use cases, but the most direct demonstration is the **RE-to-CE** use case:

- _ **Ingress:** _ RE (global anycast)
- _ **Egress:** _ CE in `eu-central-1` and/or `eu-west-1`
- _ **Backends:** _ Ubuntu echo servers on private IPs, discovered via origin pools created during infrastructure provisioning
- _ **Configuration:** _ Three load balancers demonstrate different routing strategies:

| Load Balancer | Origin Pool | Behavior |
| --- | --- | --- |
| lb-echo-hybrid | Both regions | Multi-region - xC routes to the app defined as lb-logic (e.g. round robin) |
| lb-echo-hybrid-central | eu-central-1 only | Regional pinning - all traffic exits in Frankfurt |
| lb-echo-hybrid-west | eu-west-1 only | Regional pinning - all traffic exits in Ireland |

\*\* This is a preview to the use case later in the lab

_ **The traffic path:** _ User → Nearest RE → WAF → xC Fabric → CE (eu-central or eu-west) → Private subnet → Echo server

### Regional Pinning vs. Multi-Region

This is a practical consideration that comes up in real deployments. The multi-region LB lets xC decide which CE to use based on proximity, health, and load. It supports migration and scale out scenarios. With policies, admins can control who access which region (A/B Testing/Canary Releases by ratio, cookie or header; access policy by Source IP, …).

The pinned LBs force all traffic to a specific region - useful when data residency requirements mandate that traffic exits in a particular geography.

Both configurations use the same WAF policy, the same certificate management, and the same origin pool structure. The only difference is the _ **origin\_servers\_subset** _ in the load balancer configuration.

## The BIG-IP Extension

The lab includes a second Hybrid use case: _ **RE-to-CE via BIG-IP** _. This extends the traffic path by one hop: User → RE → WAF → xC Fabric → CE → BIG-IP → Echo server

This is the “better together” scenario - xC handles global ingress, anycast, and WAF at the edge. The CE provides private network access. And BIG-IP adds local traffic management capabilities: iRules, advanced health monitors, connection persistence, or APM policies.

In the lab, the BIG-IP is configured with an AS3 virtual server that accepts TLS traffic from the CE and applies an iRule injecting custom headers. It demonstrates that xC does not replace BIG-IP - it extends it with a global front door.

This set up (as we chain services) would also work in a SaaS only set up. But in many environments it invoilved the CE to build a “private switch” to access private apps directly or go via a BIG-IP.

## When to Use the Hybrid Model

The Hybrid model is the right choice when:

- Your application runs in a _ **private subnet** _ without public internet access
- _ **Compliance requirements** _ prevent exposing backend servers to the internet
- You want _ **consistent WAF policies** _ across public and private applications
- You need to _ **consolidate multiple tools** _ (external LB + WAF + VPN) into one platform
- You are integrating _ **existing BIG-IP deployments** _ with a modern global delivery layer

### When to Consider Multi-Site Instead

If your use case involves _ **east-west traffic between sites** _ (not just north-south from users to backends), or if you want the _ **load balancer to run directly on the CE** _ without RE involvement, the [Multi-Site model](https://community.f5.com/topic/347321) is the next step.

## Key Takeaways

| **Aspect** | Hybrid / RE + CE |
| --- | --- |
| **Ingress** | Regional Edge (anycast) |
| **Egress** | Customer Edge (private network) |
| **CE Required** | Yes |
| **Origin Visibility** | Private — only CE needs local access |
| **WAF Location** | RE (edge) |
| **Fabric** | Encrypted overlay (RE → CE) |
| **Best For** | Private backends, compliance, hybrid environments |

## Up Next

[Part 3: Multi-Site - CE-Only Architecture](https://community.f5.com/topic/347321) - What happens when you remove the RE from the equation entirely? Customer Edges become full application delivery nodes - with local WAF, east-west routing, and edge compute.