Azure Load Balancer

A load balancer resource is either a public load balancer or an internal load balancer within the context of the virtual network.¹ Azure load balancer has an inbound and an outbound feature set. The Load Balancer resource’s inbound load-balancing functions are expressed as a frontend, a rule, a health probe, and a backend pool definition. Azure load balancer maps new flows to healthy backend instances.

Azure load balancer is available in two different versions (SKUs). The Standard load balancer enables you to scale your applications and create high availability for small-scale deployments to large and complex multizone architectures. The Basic load balancer does not support HTTPS and other basic functionality and is not suitable for production workloads.

A public load balancer maps the frontend IP address and port number of incoming traffic to the private IP address and port number of the virtual machine (VM), and vice versa for the response traffic from the VM. By applying load-balancing rules, you can distribute specific types of traffic across multiple VMs or services. For example, you can spread the load of web request traffic across multiple web servers.

Resources within the virtual network are not directly reachable from the outside unless a customer takes specific steps to expose them through public endpoints or connects them to on-premises networks through a virtual private network (VPN) or Azure ExpressRoute. Azure internal load balancer uses a private IP address of the subnet of a virtual network as its frontend. It directs traffic from within the virtual network or from on-premises networks to VMs within the virtual network.

An internal load balancer enables the following types of load balancing:

Within a virtual network

Load balancing from VMs in the virtual network to a set of VMs that reside within the same virtual network.

For a cross-premises virtual network

Load balancing from on-premises computers to a set of VMs that reside within the same virtual network.

For multitier applications

Load balancing for internet-facing multitier applications where the backend tiers are not internet-facing. The backend tiers require traffic load balancing from the internet-facing tier.

For line-of-business (LoB) applications

Load balancing for LoB applications that are hosted in Azure without additional load balancer hardware or software. This scenario includes on-premises servers that are in the set of computers whose traffic is load-balanced.

Azure Application Gateway for Load Balancing

An application gateway serves as the single point of contact for clients.² It distributes incoming application traffic across multiple backend pools, such as Azure VMs, VM scale sets, App Services, or on-premises/external servers. It is an application delivery controller (ADC) as a service and provides per-HTTP-request load balancing.

Azure Application Gateway is a Layer 7 (L7) web traffic load balancer that enables you to manage traffic to your web applications. Traditional load balancers operate at the transport layer (OSI Layer 4 [L4]—TCP and UDP) and route traffic based on source IP address and port to a destination IP address and port.

Web Application Firewall (WAF) is a feature of Application Gateway that provides centralized protection of your web applications from common exploits and vulnerabilities. WAF is based on rules from the Open Web Application Security Project (OWASP) core rule sets.

Azure Traffic Manager for Cloud-Based DNS Load Balancing

Azure Traffic Manager is a DNS-based traffic load balancer that enables you to distribute traffic optimally to services across global Azure regions while providing high availability and responsiveness.³

Traffic Manager uses DNS to direct client requests to the most appropriate service endpoint based on a traffic-routing method and the health of the endpoints. An endpoint is any internet-facing service hosted within or outside of Azure. Traffic Manager provides a range of traffic-routing methods and endpoint monitoring options to suit different application needs and automatic failover models. It is resilient to failure, including the failure of an entire Azure region.