Series: F5 Distributed Cloud Multi-Cloud Networking Lab
Previous: Hub - MCN Lab Overview
Next: Part 2: Hybrid - RE + CE Architecture
The Simplest Path to Application Delivery
Every distributed cloud platform needs a starting point - a model that delivers value without requiring you to deploy anything in your own environment. For F5 Distributed Cloud, that starting point is the SaaS model, also called the RE-Only architecture.
RE stands for Regional Edge - the nodes that make up F5’s global network of Points of Presence (PoPs). When you use the SaaS model, your application traffic flows entirely through this network. No Customer Edge. No on-premises deployment. No VPN tunnels.
It is the architecture most people associate with a cloud-based WAF or CDN provider. But within the xC platform, it is just one of three deployment models - and the one that everything else builds on.
How It Works
The traffic flow in the SaaS model is straightforward:
- A user makes a request to your application’s FQDN (e.g., echo-public.lab.example.com)
- DNS resolves to xC’s anycast IP - the user is automatically routed to the nearest Regional Edge
- The RE terminates TLS, applies the configured security policies (WAF, Bot Defense, DDoS mitigation), and inspects the request
- The RE forwards the request to the origin server over the public internet
- The origin responds, and the RE delivers the response back to the user
The key characteristic: both ingress and egress happen at the Regional Edge. The RE connects to your backend the same way any external client would: over the internet, typically via a public load balancer, a cloud NLB, or a direct public IP. Customers can than set up an ACL on their edge router to block everything not related to F5 XC and ensure no “non-xc-filtered” traffic cann access the application.
What the RE Provides
A Regional Edge is not a simple proxy. Each PoP is a full-stack application delivery node:
Global Anycast
Every HTTP load balancer you create on xC is automatically advertised on the platform’s anycast IP across all PoPs worldwide. Users connect to the geographically closest edge - no manual DNS configuration, no geo-routing rules, no latency-based health checks. The network handles it.
TLS Termination
The RE terminates TLS at the edge. You can use xC-managed certificates (automatic Let’s Encrypt), upload your own certificates, or, as this lab does, generate CA-signed certificates and upload them via the API. The backend connection can be re-encrypted (TLS to origin) or plain HTTP, depending on your requirements.
Web Application Firewall
The WAF runs at the RE, inspecting every request before it reaches your origin. In this lab, the WAF is configured in blocking mode with:
- OWASP Top 10 signature coverage
- Threat campaign detection (proactive zero-day protection)
- Custom blocking page
- Full request logging for visibility
The same WAF policy can later be applied to Hybrid and Multi-Site deployments without modification. Write it once, enforce it everywhere.
Origin Discovery
In the SaaS model, the RE needs to know where to send traffic. This is configured via Origin Pools - a list of backends identified by:
- FQDN (DNS name, e.g., an AWS NLB DNS name)
- IP address** (direct)
- Kubernetes service (for later models)
Since the RE connects over the internet, origins must be publicly reachable. This is the primary constraint of the SaaS model and the reason the Hybrid model exists.
When to Use the SaaS Model
The SaaS model is the right choice when:
- Your application has a publicly reachable origin (behind a cloud LB, CDN, or public IP)
- You want WAF, DDoS, and bot protection without deploying any infrastructure
- You need to be live in minutes - create a load balancer, point DNS, done
- You’re looking for a quick proof-of-concept before committing to a deeper integration
It is also the natural first step in a progressive adoption: start with SaaS for public-facing applications, then extend to Hybrid for private backends, and Multi-Site for cross-region east-west traffic. Same console, same policies, no re-architecture required.
When NOT to Use It
The SaaS model has one fundamental limitation: the origin must be internet-reachable. If your backend runs in a private subnet, behind a firewall, or in a data center without public exposure, the RE cannot reach it. That is where the Hybrid model with Customer Edge comes in.
How This Looks in the Lab (later chapter)
In the lab environment, the SaaS model maps to the RE-Only use case:
- Origin: AWS Network Load Balancers (NLBs) fronting Ubuntu echo servers in two regions
- Discovery: The origin pool uses the NLB FQDN - the RE resolves it and connects over the internet
- Security: WAF in blocking mode, CA-signed TLS certificate
- Result: A globally available HTTPS endpoint with full WAF protection, deployed in seconds
The traffic path: User → Nearest RE (PoP) → WAF inspection → Internet → AWS NLB → Ubuntu echo server
No CE nodes are involved. The RE handles everything.
The Foundation for Everything Else
Understanding the SaaS model is important because every other model builds on top of it:
- The Hybrid model replaces the internet egress with a private path through the Customer Edge - but the RE ingress and WAF inspection work exactly the same way
- The Multi-Site model moves the load balancer onto the CE itself - but the origin pool concepts, certificate management, and policy engine remain identical
The building blocks are consistent. Once you understand how an origin pool, a load balancer, and a WAF policy work in the SaaS model, you understand them everywhere.
Key Takeaways
| Aspect | SaaS / RE-Only |
|---|---|
| Ingress | Regional Edge (anycast) |
| Egress | Internet (to public origin) |
| CE Required | No |
| Origin Visibility | Must be publicly reachable |
| WAF Location | RE (edge) |
| Deployment Time | Minutes |
| Best For | Public apps, quick wins, PoC |
Up Next
Part 2: Hybrid — RE + CE Architecture - What happens when your backend is not on the public internet? The Customer Edge extends the platform into your private environment.