Edit

Cross-region load balancer (Preview)

  • Article

Azure Standard Load Balancer supports cross-region load balancing enabling geo-redundant High Availability scenarios such as:

Important

Cross-region load balancer is currently in preview. This preview version is provided without a service level agreement, and it's not recommended for production workloads. Certain features might not be supported or might have constrained capabilities. For more information, see Supplemental Terms of Use for Microsoft Azure Previews.

The frontend IP configuration of your cross-region load balancer is static and advertised across most Azure regions.

Diagram of cross-region load balancer.

Note

The backend port of your load balancing rule on cross-region load balancer should match the frontend port of the load balancing rule/inbound nat rule on regional standard load balancer.

Regional redundancy

Configure regional redundancy by adding a global frontend public IP address to your existing load balancers.

If one region fails, the traffic is routed to the next closest healthy regional load balancer.

The health probe of the cross-region load balancer gathers information about availability of each regional load balancer every 20 seconds. If one regional load balancer drops its availability to 0, cross-region load balancer will detect the failure. The regional load balancer is then taken out of rotation.

Diagram of global region traffic view.

Ultra-low latency

The geo-proximity load-balancing algorithm is based on the geographic location of your users and your regional deployments.

Traffic started from a client will hit the closest participating region and travel through the Microsoft global network backbone to arrive at the closest regional deployment.

For example, you have a cross-region load balancer with standard load balancers in Azure regions:

  • West US
  • North Europe

If a flow is started from Seattle, traffic enters West US. This region is the closest participating region from Seattle. The traffic is routed to the closest region load balancer, which is West US.

Azure cross-region load balancer uses geo-proximity load-balancing algorithm for the routing decision.

The configured load distribution mode of the regional load balancers is used for making the final routing decision when multiple regional load balancers are used for geo-proximity.

For more information, see Configure the distribution mode for Azure Load Balancer.

Egress traffic will follow the routing preference set on the regional load balancers.

Ability to scale up/down behind a single endpoint

When you expose the global endpoint of a cross-region load balancer to customers, you can add or remove regional deployments behind the global endpoint without interruption.

Static anycast global IP address

Cross-region load balancer comes with a static public IP, which ensures the IP address remains the same. To learn more about static IP, read more here

Client IP Preservation

Cross-region load balancer is a Layer-4 pass-through network load balancer. This pass-through preserves the original IP of the packet. The original IP is available to the code running on the virtual machine. This preservation allows you to apply logic that is specific to an IP address.

Floating IP

Floating IP can be configured at both the global IP level and regional IP level. For more information, visit Multiple frontends for Azure Load Balancer

Health Probes

Azure cross-region Load Balancer utilizes the health of the backend regional load balancers when deciding where to distribute traffic to. These health checks by the cross-region load balancer are done automatically every 20 seconds, given that a user has set up health probes on their regional load balancer.  

Build cross region solution on existing Azure Load Balancer

The backend pool of cross-region load balancer contains one or more regional load balancers.

Add your existing load balancer deployments to a cross-region load balancer for a highly available, cross-region deployment.

Home region is where the cross-region load balancer or Public IP Address of Global tier is deployed. This region doesn't affect how the traffic will be routed. If a home region goes down, traffic flow is unaffected.

Home regions

  • East US 2
  • West US
  • Southeast Asia
  • Central US
  • North Europe
  • East Asia
  • US Gov Virginia
  • UK South
  • West Europe

Note

You can only deploy your cross-region load balancer or Public IP in Global tier in one of the regions above.

A participating region is where the Global public IP of the load balancer is being advertised.

Traffic started by the user will travel to the closest participating region through the Microsoft core network.

Cross-region load balancer routes the traffic to the appropriate regional load balancer.

Diagram of multiple region global traffic.

Participating regions

  • East US
  • West Europe
  • Central US
  • East US 2
  • West US
  • North Europe
  • South Central US
  • West US 2
  • UK South
  • Southeast Asia
  • North Central US
  • Japan East
  • East Asia
  • West Central US
  • Australia Southeast
  • Australia East
  • Central India
  • US DoD Central
  • US DoD East
  • US Gov Arizona
  • US Gov Texas
  • US Gov Virginia

Note

The backend regional load balancers can be deployed in any publicly available Azure Region and is not limited to just participating regions.

Limitations

  • Cross-region frontend IP configurations are public only. An internal frontend is currently not supported.

  • Private or internal load balancer can't be added to the backend pool of a cross-region load balancer

  • NAT64 translation isn't supported at this time. The frontend and backend IPs must be of the same type (v4 or v6).

  • UDP traffic isn't supported on Cross-region Load Balancer.

Pricing and SLA

Cross-region load balancer, shares the SLA of standard load balancer.

Next steps