Deploying F5 BIG-IP with Azure Cross-region load balancer

Summary

Background

Recently I had a customer ask about when and why to consider Azure's Cross-region load balancer. Since this was announced as Generally Available in July 2023, it's still new to most customers. Here's a few notes about this Azure service and the advantages and limitations compared to other approaches.

An overview of Azure's Cross-region Load Balancer

This image tells you most of what you need to know about Azure's Cross-region load balancer

From here on out, I'll refer to Cross-region load balancer as CRLB for short. Obviously you should read Microsoft's overview, but here's what stood out to me as most important:

1. Anycast IP routing and the concept of a global backbone are pre-requisite knowledge. That's what makes this all work, so it's really nothing new in terms of technology. If you know what these 2 terms are, you can pretty much understand how a CRLB works.

2. Load balancer of load balancers. Basically, a CRLB is an LB in front of a regular Azure LB. These regular Azure LB's are referred to as 'backend regional load balancers' in the MS documentation.

3. Home Regions. The concept of Home Regions isn't the knowledge you need for most Azure deployments, and it really doesn't matter much. You choose a Home region to deploy your CRLB into, but it doesn't affect how traffic is routed. Still, you might have policies or other concerns about the logical home of your resources, so the supported Home regions are listed here.

4. Participating regions are where the Global Public IP is advertised. I think of these as my physical locations of my Anycast IP address. They are listed here, and include most Azure regions I can think of.

5. Other regions. Your 'backend regional load balancers' can live in any publicly available Azure region

Limitations

I'm generally a fan of Azure's load balancers, but there are some limitations documented and some things I think we should point out early.

1. Public Only. "Cross-region frontend IP configurations are public only. An internal frontend is currently not supported."
2. No outbound rules. "Outbound rules aren't supported on Cross-region Load Balancer. For outbound connections, utilize outbound rules on the regional load balancer or NAT gateway.

Here's some important limitations not documented as part of this announcement, and they apply to Azure load balancers generally:

1. Active/Standby is not supported. So if you have a Primary site and a DR site that only receives traffic when the Primary site is down, you'd need to find a workaround at time of disaster.
2. Even though you get a single public IP that is anycast globally and will not change, the public IP addresses that belong to your regional (backend) load balancers are still reachable. This means that your global website is reachable at your global IP address and each regional IP address. That's probably going to be a minor point of confusion for traditional network teams.

F5 BIG-IP deployments with Azure Cross-region load balancer

There isn't much change for the average customer. Most F5 + Azure customers have BIG-IP VM's running behind a regular Azure LB, but only public-facing LB's would consider adding CRLB.

I see 2 main reasons you would do this, both outlined below.

An alternative to Global Server Load Balancing (GSLB) and multiple IP addresses.

DNS failover has some disadvantages if you use it internally, for non-browser clients, or failover frequently. But for public websites and many internal use cases, I'd still use it over CRLB today in many scenarios. However, it's worth pointing out that in the example use case that Microsoft used in their announcement blog post, a global large-scale IOT use case would be a good candidate for this.

GSLB still works and is widely used today. Azure have their own offering and of course, F5 has an SaaS option with DNS LB on F5 Distributed Cloud, or VE's that can run BIG-IP DNS (formerly GTM).

Performance for websites used by a globally diverse user base

Why? Your public IP address will exist in many locations. Every user will be sent to the closest Azure participating region (that's how Anycast IP routing works), and from there, they will traverse the Microsoft's global network to the region where the 'regional load balancer' exists. It's a safe bet that traversing Microsoft's global backbone will be faster than traversing the public Internet.

You might think, "But with GSLB you can also send users to their closest site using geo topology!". True, but GSLB will only send users to sites where you have a public IP address configured. Most companies that I see use GSLB for HA between 2 regions. But Microsoft has 22 participating regions from which your public IP will be advertised!

An example of performance improvements traversing Microsoft's global backbone

GSLB is one alternative to a Cross-region load balancer, but if you are looking for the advantages of anycast IP routing, it's unlikely you would build your own global anycast network.

Other platforms can also provide you with an anycast globally advertised static IP address, and the one I know best is (of course) F5 Distributed Cloud. When you provision an HTTP or TCP LB using F5 XC and advertise your site from our Regional Edges, your single public IP address is static and advertised from multiple global sites.

There's a few advantages to a platform built for global application delivery (and this can include our competitors, too). For example, the limitations we outlined above don't exist with F5 XC. There's no concept of layering load balancers required. And importantly, you can natively apply things like security (L3/L4, WAF, DDos, bot protection, etc) with these global platforms. With F5 XC, you can do more than just security (TLS termination, HTTP manipulation, etc). You can even run your microservices directly in the SaaS platform!

Conclusion

Azure's Cross-region load balancer is a nice start for basic global use cases, but has some limitations for the average enterprise customer. GSLB works today in most uses cases, but I do like to use a global platform (I am biased and prefer F5 Distributed Cloud) to build new apps and achieve HA/failover/performance improvements using Anycast. If you're an Azure customer that currently uses GSLB between multiple existing public Azure load balancers purely for active/active HA, the Azure Cross-region load balancer could work for you.

Please reach out if you're interested in hearing more and thanks for reading.

Related Articles

Cross-region load balancer - Azure Load Balancer | Microsoft Learn

Azure cross-region Load Balancer is now generally available.