How to build highly resilient applications with Azure Load Balancer

Microsoft

Dec 19, 2024

As customers move workloads to the cloud, designing their applications for high resiliency becomes a key consideration. This blog will highlight how Azure Load Balancer enables highly resilient applications across multiple resiliency categories.

How to approach resiliency with Azure Load Balancer?

When it comes to designing highly resilient applications, there are multiple types of design patterns that should be considered.

Zone-redundancy

Customers want to ensure that their deployments in an Azure region are resilient to any data center failures. Azure provides within-region resiliency via Azure Availability Zones. Availability Zones are separated groups of datacenters within a region. Customers can deploy their applications and Azure Load Balancer in a zone-redundant deployment method.

A zone-redundant load balancer is replicated across all available zones. If one of the zones fails, then all incoming traffic will be sent to the other two zones, ensuring high availability.

Global resiliency

For mission critical applications or applications that need a global presence, replicating them across multiple Azure regions will ensure the application is globally resilient. This design pattern will ensure that no single region or geography becomes a single point of failure. In case a region goes offline, traffic will failover to the next available region, ensuring high availability of the application.

Azure global Load Balancer can then be used to distribute traffic to these multi-region applications. Azure global Load Balancer is a globally distributed layer-4 load balancing solution. Global load balancer provides features such as a globally static IP address, geo-proximity routing, and automatic failover to the next available region.

Subscription resiliency

The last two categories of resiliency focused on ensuring the infrastructure itself is resilient. A third bucket focuses on resource management and isolation. Deploying resources and applications into multiple subscriptions can ensure that they are resilient to any subscription-level events. For example, if someone accidentally deletes a subscription or changes permissions, the overall application will still be available due to the replicated instances in the other subscriptions.

To support multi-subscription workloads, Azure now supports cross-subscription load balancing. Now, the load balancer’s frontend IP address or backend pool can be located in a subscription that is different than the load balancer.

An example of a real world customer

To better understand how all the categories of resiliency can be combined, let’s explore an example customer scenario. In this scenario, we will walk through the customer’s use-case and how Azure Load Balancer helped them deploy a highly resilient application.

Who is the customer?

In this scenario we will be learning about an example customer called Contoso. Contoso is a large retail company based in Europe, and they have a global presence. Contoso is moving off their on-prem environment and onto Azure to support their high-scale needs.

What are the application requirements?

As the team at Contoso is looking at moving their application to the cloud, they have strict requirements around resiliency that need to be addressed.

As mentioned above, Contoso has a global presence and most of their applications need to be globally available. With that, Contoso will deploy replicas of an application across multiple Azure regions to ensure high-availability and resiliency for their global user base.
Second, given the criticality of some applications (e.g., inventory manager), these applications need to be deployed in a redundant manner. As mentioned earlier, these applications will be replicated across multiple Azure regions, but Contoso needs these applications to also be replicated within a single Azure region.
Third, each application deployment should be isolated from each other, and shouldn’t share a single resource (virtual machine, IP address, etc.). This requirement also extends to subscriptions, where each application replica will be isolated in its own subscription.

In addition to the requirements outlined above, Contoso decided that Azure Load Balancer would be a perfect fit for their ingress needs, given its ultra-low latency capabilities. However, Contoso wanted to ensure that Azure Load Balancer would be able to meet their strict resiliency requirements.

How did Azure Load Balancer help?

To address Contoso’s resiliency requirements, they deployed Azure Load Balancer in a multi-tier architecture.

To support their multi-region requirement, an Azure global load balancer was deployed. The global load balancer would then be the gateway into the overall application. Whenever traffic would be sent to the global endpoint, Azure would route it to the closest deployment to that user. In addition, global load balancer’s automatic health probes and failover capabilities gave Contoso peace of mind, knowing that in the off chance of a regional failure, traffic would be automatically routed to the other geos.
To support their in-region redundancy requirements, Contoso adopted a zone-redundant architecture for all of their in-region infrastructure (virtual machines, IP addresses, load balancers, etc.).
Finally, Contoso adopted the new cross-subscription load balancing feature. With this feature, Contoso can deploy each application replica in its own subscription and then link them to their Azure global Load Balancer. This allows each deployment to be independent and avoid a common failure point.

Contoso, after adopting Azure Load Balancer, has developed an architecture that addresses resiliency across the stack. Furthermore, Contoso’s application is now resilient globally, regionally, and at the subscription layer.