# Using F5 Distributed Cloud to solve cloud-native multi-regional application challenges **URL:** \ **Category:** F5 Technical Articles\ **Tags:** distributed-cloud, high-availability\ **Created:** [July 15, 2026, 7:15pm UTC](https://community.f5.com/t/using-f5-distributed-cloud-to-solve-cloud-native-multi-regional-application-challenges/77229 "2026-07-15T19:15:00Z")\ **Posts on this page:** 1\ **Page:** 1
**Author:** ![Preston\_Ashworth](https://d1p9zq3aats0t8.cloudfront.net/user_avatar/community.f5.com/preston_ashworth/32/3624_2.png) [@Preston\_Ashworth](https://community.f5.com/u/Preston_Ashworth)\ **Post date:** [July 15, 2026, 7:15pm UTC](https://community.f5.com/t/using-f5-distributed-cloud-to-solve-cloud-native-multi-regional-application-challenges/77229/1 "2026-07-15T19:15:00Z")
There are less-than-obvious costs to traditional multi-regional application availability, especially in micro-service or service-oriented architectures where regional failover has to be considered at a per-service level and not just in the context of the entire region. This can lead to significant transit charges with the cloud-native required approach. F5 Distributed Cloud is uniquely capable of solving these problems thanks to our combination of both network overlay and application-networking capabilities. ## This gets a little detailed, so here is a TL;DR version: Cloud-native architectures end up getting really expensive for service-level multi-regional failover because they require those services to be exposed on the internet for multi-regional failover. F5 Distributed Cloud (F5 XC) is a software defined network with embedded application load-balancing that  makes service-level high-availability trivial. ## Details: Cloud-native multi-region redundancy strategies rely exclusively on DNS load-balancing solutions. Cloud applications that are hosted in multiple regions are advertised to the world with a DNS load-balancer resolving clients to healthy applications in different regions. Typically they send health-check probes to each service in each reason, and can either resolve these services/regions based on their availability, the IP geography of the requesting LDNS or DNS client, in an active-standby or active-active fashion. This has been known as Global Server Load Balancing (GSLB) and F5 pioneered this approach to build on the frailty of the Round-Robin DNS server approach that had been in place since the mid 90s. ![image_346936.png](https://d20hrnpixdzcsd.cloudfront.net/original/2X/1/1ca1e67d540847cd2467add03cefc8167e4ef300.png) Figure A: Simplified Cloud-Native GSLB GSLB is a well-known pattern, but it does have its own challenges that must be considered: 1. **Failover times depend on the Time-To-Live (TTL) value that every DNS request supplies in its response. There is no control over what downstream resolvers rewrite this value to:**  The TTL value tells the DNS client (or intermediate LDNS recursive resolver) how long to cache the resolution response before sending a fresh query for the latest record of a hostname. In the case of GSLB for highly-available applications, a short TTL is desired because clients with existing cached resolution values will not resolve to the healthy server in a failover event until the cached value expires. The challenge is that a DNS administrator can’t control any downstream rewrites of TTL values that ISPs might do to lower the load on their DNS infrastructure. Lower TTLs mean increased resolution queries from clients, which increases their infrastructure requirements; rewriting this value to an hour or even a day lowers the load on their servers. 2. **Routing decisions based on HTTP request parameters are impossible with DNS because it operates completely independently of the HTTP protocol,** and is therefore completely independent of application requests in general. This means that first, DNS must distribute traffic via record resolution with total ignorance of the requests and that the request-routing logic must be duplicated locally across all regions the application is deployed in. 3. Specific to cloud-based, multi-regional, service-specific high-availability applications, **DNS load-balancing requires that the services are exposed on the public internet**. What makes this so painful is that often cloud architectures aren’t as simple as a VPC/VNET/VCN with application servers/pods behind a public-facing native load balancer that directly proxies to applications in their native subnet (ex. Figure A); rather cloud-native transitive-routing services are often used to pass requests/responses through intermediate security inspection networks. _This is becoming especially true in the era of agentic AI with its rapidly-growing sprawl of MCP services, agents, and agent harnesses along with local and third-party inference._ ![image_346936.png](https://d20hrnpixdzcsd.cloudfront.net/original/1X/1a25499272ee642f302c2eeceb9042663ef7aa92.png) Figure B: Multi-service Cloud-Native High Availability. Note the x^2 scaling of connections hair-pinning between internet-exposed services. The multiple transits through advanced enterprise cloud architectures add up exponentially thanks to the need to hairpin everything through the internet edge--even between local services--to facilitate GSLB-based multi-regional per-service high-availability, compounding transit costs. ## How does F5 Distributed Cloud address this problem? F5 XC moves multi-regional load-balancing back into the data-path by incorporating a software-defined network overlay into its capabilities. The F5 XC Customer Edge (CE) node is a local instantiation of the same software running in our Global Regional Edges (RE)--see [Platform Overview](https://docs.cloud.f5.com/docs-v2/platform/concepts/system-overview) for more information--and acts as both a proxy/load-balancer and a cloud router. This means on each CE, a VIP can be advertised for each service, while being able to discover and connect to origins in each cloud region, regardless of whether or not they are in the same cloud provider, private data center, or edge location. A service can reach other services advertised on these CEs, and in the event of a local failure of one service, F5 XC automatically routes to the other cloud region where another CE is located that has been actively health-checking its local instance of that service. This works even with IP overlap in one or more regions/clouds. F5 XC can even provide internet-facing VIPs that load-balance across these regions, including advanced request-based conditional routing. ![image_346936.png](https://d20hrnpixdzcsd.cloudfront.net/original/2X/a/a4764a868dab4054a4aa066eab7d1bda363ef353.png) With the F5 XC secure mesh overlay, ordinarily difficult multi-regional/cloud networking becomes shockingly simple application networking. The complexity of networking and firewalling between locations is reduced to defining application VIPs in the desired sites on CEs, their application/service origins discovered by CEs, and any special conditional routing that is required as needed for that application. Instead of building interstate systems, application-specific teleportation portals handle inter-location communications and failovers automatically. This approach applies a minimal effort up front to implement an application-networking framework architecture (F5 XC) to rapidly reduce future application deployment time, failover time, and latency while increasing security by hiding services from the internet behind the F5 XC platform. It does all this while logging all requests and flows that traverse the platform by default, and provides advanced web application security and modern application discovery in Kubernetes along with traditional services running in IaaS services like cloud VMs or private cloud virtualization platforms.