Introduction
Multi-Cloud Networking sounds straightforward until you try to build it. Connecting applications across regions, clouds, and on-premises environments while maintaining consistent security policies is one of those challenges that grows in complexity the deeper you go. VPN tunnels, Transit Gateways, firewall rules, certificate management, WAF policies - the list of moving parts never seems to end.
This article series introduces an open-source lab environment that provisions a fully functional F5 Distributed Cloud (xC) Multi-Cloud Networking setup on AWS (two regions, incl. Customer Edge nodes, BIG-IP appliances, Ubuntu application servers, Kubernetes workloads, …). All deployed with a single command and ready for hands-on experimentation within minutes.
The goal is not to replace official documentation, but to provide a practical, working reference that demonstrates how these components fit together in real deployment scenarios.
GIT Repository: Link
RTFM - Lab Guide: Link
What This Lab Covers
The lab spans two areas that build on each other:
(1) Architecture Patterns
F5 Distributed Cloud supports three fundamental deployment models SaaS, Hybrid, and Multi-Site/Cloud. Each model answers a different question about how traffic enters, traverses, and exits the platform. Before touching any use case, it helps to understand these patterns and when each one applies.
| Model | Traffic Flow | Best For |
|---|---|---|
| SaaS (RE-Only) | User → Regional Edge → Internet → Origin | Public-facing apps, quick deployment, no infrastructure to manage |
| Hybrid (RE + CE) | User → Regional Edge → xC Fabric → Customer Edge → Private Backend | Private subnets, compliance, hybrid environments |
| Multi-Site (CE-Only) | CE → xC Fabric → CE (or local) | East-west traffic, edge computing, cross-region services |
These are covered in detail in the Architecture series:
- Part 1: SaaS - RE-Only Architecture
- Part 2: Hybrid - RE + CE Architecture
- Part 3: Multi-Site - CE-Only Architecture
(2) Use Cases
Each use case is a self-contained deployment that demonstrates a specific traffic pattern. Every use case is fully automated - a shell script creates all required xC objects (certificates, origin pools, load balancers, service policies) via the xC API, and a corresponding delete script tears everything down cleanly.
| Use Case | Architecture | Direction | What It Demonstrates |
|---|---|---|---|
| RE Only | SaaS | North-South | Pure RE load balancing with WAF, DNS-based origin discovery |
| RE to CE | Hybrid | North-South | RE ingress to private backends via CE, regional pinning |
| RE to CE via BIG-IP | Hybrid | North-South | Three-tier F5 architecture (RE + CE + BIG-IP) |
| CE via CLB | Multi-Site | North-South | CE-direct with AWS NLB, WAF on CE, dual internal/external access |
| CE to CE | Multi-Site | East-West | Cross-region routing via xC fabric, no VPC peering required |
| k8s Service Discovery | Hybrid + Multi-Site | North-South + East-West | Kubernetes service discovery via kubeconfig registration |
| vk8s Edge Computing | Hybrid + Multi-Site | North-South + East-West | Container workloads running directly on CE nodes |
| mTLS Authentication | Hybrid | North-South | Client certificate validation, XFCC header injection, service policies |
| JWT Validation | Hybrid | North-South | RS256 token validation at the edge, inline JWKS embedding |
These are covered in the Use Case series:
- Part 4: North-South - RE-Only & RE-to-CE](link-to-article (T.B.D.)
- Part 5: North-South - BIG-IP Integration & CE-via-CLB](link-to-article (T.B.D.)
- Part 6: East-West - CE-to-CE](link-to-article (T.B.D.)
- Part 7: Kubernetes - Service Discovery & vk8s](link-to-article (T.B.D.)
- Part 8: Security Services - mTLS & JWT Validation](link-to-article (T.B.D.)
Lab Architecture
The infrastructure spans two AWS regions - “eu-central-1” (Frankfurt) and “eu-west-1” (Ireland) - each with an identical set of components.
You can either use the lab as “FYI” and just read the Labs, Use Cases - or build it on your own (requires a MAC or a Linux OS). To be able, you need certain tools and access requirements (see below). The lab uses terraform to deploy the infrastrucurre and uses the REST API to deploy services within the platform.
Access Requirements
- AWS Access Key + Secret (and STS Token if temporary)
- xC Tenant name and Namespace
- xC API certificate (.p12) and password
Series Overview
This series is structured in two parts:
Part 1: Architecture (conceptual): Explains the three deployment models - SaaS, Hybrid, and Multi-Site - with diagrams, traffic flow descriptions, and guidance on when to use each pattern
Part II: Use Cases (hands-on): Walks through each lab use case with deployment steps, API payloads, verification commands, and architectural diagrams showing the exact traffic path.
The architecture articles provide the foundation. The use case articles show it in practice. You can read them in order or jump directly to the pattern that interests you.
Up Next
Next three chapters focus on some architecture foundations of the XC platform. Beginning with part 4, the more practical hands-on part will begin.
Part 1: SaaS - The RE-Only Architecture - How traffic flows when everything runs through the F5 Global Network, no Customer Edge required.
Disclaimer
This is a personal project maintained in my own time. It is not affiliated with, endorsed by, or representative of any employer or organization. The lab is intended for demonstration and educational purposes only.