Keyboard shortcuts

Press ← or → to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

🏠 Back to Blog

Azure Load Balancer

Backend Pools

  • Backend pools contain resources for the load balancer to distribute traffic to
  • Resources can be VMs, VMSS, or IP addresses

Health Probes

  • You can configure Health Probes so that the load balancer only sends traffic to a healthy instance of the backend pool

SKUs

  • Standard

    • Charge per hour
    • The machines in the backend pool can be in an Availability Set, VMSS, or stand-alone VMs
    • Health Probes can be TCP, HTTP, or HTTPS
    • Supports Availability Zones
    • 99.99% SLA
    • Requires that the public IP address also be in the Standard SKU
    • Can be implemented as a public or internal load balancer
    • Supports a global deployment option, but you must choose a ‘home’ region. The backend pool will then have one or more regional load balancers. The frontend IP must be static and is advertised to other Azure regions via Anycast.;;;;
    • The standard load balancer has 3 availability zone configuration options: zonal, zone-redundant, and non-zonal.
      • a zonal configuration allows the load balancer to distribute requests to resources in a single zone
      • a non-zonal configuration is relatively uncommon and is generally used to distribute requests to workloads that have not been pinned to a specific zone.
      • a zone-redundant configuration allows the load balancer to distribute requests to resources in any zone the load balancer is deployed in.

  • Basic (Retiring soon)

    • Free
    • The machines in the backend pool need to be part of an availability set or VMSS
    • Health probes can be TCP or HTTP
    • No support for Availability Zones
    • No SLA

  • Gateway

    • Catered for high performance and HA scenarios with third party NVA’s (Network Virtual Appliances)

NAT

  • You can use NAT rules to translate a single public IP address into multiple backend resources with private IP addresses

Outbound Rules

Azure Load Balancer outbound rules define how outbound connections from your virtual machines (VMs) are handled. These rules determine the allocation and management of public IP addresses for outbound traffic from VMs within a virtual network. Here are the key points about Azure Load Balancer outbound rules:

  1. Outbound Connectivity: Outbound rules provide connectivity for VMs to the internet by assigning a public IP address to the outbound traffic, ensuring VMs can initiate connections to external resources.
  2. SNAT (Source Network Address Translation): Outbound rules use SNAT to translate private IP addresses of VMs to a public IP address for outbound traffic. This allows multiple VMs to share the same public IP for outbound connections.
  3. Public IP Allocation: You can associate a public IP address or a pool of public IP addresses with the load balancer to manage outbound connectivity. This provides control over the IP addresses used for outbound traffic.
  4. Port Management: Outbound rules manage the available ports for outbound connections. By default, Azure Load Balancer uses ephemeral ports for SNAT, but you can configure custom port ranges to optimize the use of available ports.
  5. Idle Timeout: Outbound rules include an idle timeout setting that defines the duration a connection can remain idle before being closed. This helps manage and free up unused connections.
  6. Scaling: Outbound rules support scaling scenarios where you can distribute outbound traffic across multiple public IP addresses to handle high traffic volumes and ensure availability.
  7. Configuration: Outbound rules can be configured in the Azure portal, through Azure PowerShell, or using Azure CLI. You can specify parameters such as the public IP address, port ranges, and idle timeout settings.
  8. Security: By controlling outbound traffic through outbound rules, you can enhance the security of your VMs by ensuring that only allowed outbound connections are established.

By configuring Azure Load Balancer outbound rules, you can effectively manage and optimize the outbound connectivity of your virtual machines, ensuring reliable and controlled access to external resources.

Internal Azure Load Balancer

An Internal Azure Load Balancer (ILB) is a load balancing service that distributes network traffic across virtual machines (VMs) within a virtual network (VNet) without exposing them to the internet. It is designed for private, internal applications and services. Here are the key points about an Internal Azure Load Balancer:

  1. Private IP Address: The ILB operates using a private IP address within your VNet, ensuring that traffic is only accessible internally and not exposed to the internet.
  2. Load Balancing Algorithms: ILB distributes incoming traffic across multiple VMs using various load balancing algorithms, such as round-robin and hash-based distribution, to optimize resource usage and performance.
  3. High Availability: By distributing traffic across multiple VMs, ILB enhances the availability and reliability of your internal applications and services, ensuring they remain accessible even if individual VMs fail.
  4. Health Probes: ILB uses health probes to monitor the status of VMs and ensure traffic is only directed to healthy instances. This helps maintain the stability and performance of your applications.
  5. Configuration Flexibility: You can configure ILB to balance traffic for different types of services, such as TCP, UDP, HTTP, and HTTPS, allowing for a wide range of internal application scenarios.
  6. Integration with Network Security: ILB can be integrated with Azure Network Security Groups (NSGs) and Azure Firewall;jjj to enhance the security of your internal network traffic.
  7. Scalability: ILB supports scaling out by adding more VMs to the backend pool, ensuring that your internal applications can handle increased traffic and load.
  8. Use Cases: Common use cases for ILB include load balancing for internal line-of-business applications, databases, private APIs, and microservices within a VNet.
  9. Configuration Management: ILB can be configured and managed using the Azure portal, Azure PowerShell, Azure CLI, and Azure Resource Manager (ARM) templates.

By using an Internal Azure Load Balancer, you can efficiently manage and distribute internal network traffic, ensuring high availability, performance, and security for your private applications and services.

Cross Region (Global) Load Balancer

  • Cross region load balancer is a global load balancer that can distribute traffic across multiple regions
  • You must still create a load balancer in each region
  • The global load balancer must be deployed in a ‘home region’
  • A global load balancer must be a public, Standard SKU load balancer
  • The global load balancer uses the geo-proximity load-balancing algorithm to determine the optimal routing path for network traffic. This algorithm directs requests to the nearest “participating” region based on the geographic location of the client creating the request.