Load Balancing in Microsoft Azure

Chapter 4. NGINX Plus and Microsoft Azure Load Balancers

Microsoft Azure has three options for load balancing: NGINX Plus, the Azure load balancing services, or NGINX Plus in conjunction with the Azure load balancing services.¹ The following aims to give you enough information to decide which best works for you and shows you how using NGINX Plus with Azure Load Balancer can give you a highly available HTTP load balancer with rich Layer 7 (L7) functionality.

Azure gives its users two choices for a load balancer: Azure Load Balancer for basic TCP/UDP load balancing (at Layer 4 [L4], the network layer) and Azure Application Gateway for HTTP/HTTPS load balancing (at L7, the application layer). Although these solutions work for simple use cases, they do not provide many features that come standard with NGINX Plus.

Table 4-1 provides a comparison of NGINX features with Azure options.

Table 4-1. Comparisons of NGINX features with Azure options (from nginx.com)

Feature	Azure Application Gateway	Azure Load Balancer	NGINX Plus	Both Plus & Load Balancer
Mitigation capability	Application layer (Layer 7)		Application layer (Layer 7)
HTTP-aware	✓	—	✓	✓
HTTP/2-aware	—	—	✓	✓
WebSocket-aware	—	—	✓	✓
TCP/UDP	—	✓	✓	✓
Load balancing methods	Simple	Simple	Advanced	Advanced
SSL/TLS termination	✓	—	✓	✓
SSL offloading	✓	—	✓
URL request mapping	✓	—	✓	✓
URL rewriting and redirecting	—	—	✓	✓
HTTP health checks	Simple	Simple	Advanced	Advanced
TCP/UDP health checks	—	Simple	Advanced	Advanced
Session persistence	Simple	Simple	Advanced	Advanced
Active-active NGINX Plus cluster	—	—	—	✓
Limits	—	—	✓	✓
Routing capabilities	Simple decision based on request URL or cookie‑based session affinity		Advanced routing capabilities
IP address-based access control lists	— (must be defined at the web-app level in Azure)		✓
Endpoints	Any Azure internal IP address, public internet IP address, Azure VM, or Azure Cloud Service		Any Azure internal IP address, public internet IP address, Azure VM, or Azure Cloud Service
Azure VNet support	Both internet-facing and internal (VNet) applications		Both internet‑facing and internal (VNet) applications
WAF	✓		✓
Volumetric attacks	Partial		Partial
Protocol attacks	Partial		Partial
Application-layer attacks	✓		✓
HTTP Basic Authentication	—		✓
JWT authentication	—		✓
OpenID Connect SSO	—		✓

Comparing NGINX Plus and Azure Load Balancing Services

NGINX Plus offers a choice of several load-balancing methods. In addition to the default round-robin method there are the following:

Least connections

A request is sent to the server with the lowest number of active connections.

Least time

A request is sent to the server with the lowest average latency and the lowest number of active connections.

IP hash

A request is sent to the server determined by the source IP address of the request.

Generic hash

A request is sent to the server determined from a user‑defined key, which can contain any combination of text and NGINX variables, for example, the variables corresponding to the Source IP Address and Source Port header fields, or the URI.

You can extend all of the methods by adding different weight values to each backend server.

Azure Load Balancer offers one load-balancing method, Hash, which by default uses a key based on the 5-tuple of the header along with other information. The 5-tuple comprises the IP packets Source IP Address, Source Port, Destination IP Address, Destination Port, and Protocol. Customers can restrict the 5-tuple to a 3- or 2-tuple to enable source IP affinity.

Azure Application Gateway provides only a round-robin method.

Session persistence, also known as sticky sessions or session affinity, is needed when an application requires that all requests from a specific client continue to be sent to the same backend server because client state is not shared across backend servers. NGINX Plus supports three advanced session-persistence methods:

Sticky Cookie

NGINX Plus adds a session cookie to the first response from the upstream group for a given client. This cookie identities the backend server that was used to process the request. The client includes this cookie in subsequent requests and NGINX Plus uses it to direct the client request to the same backend server.

Sticky Learn

NGINX Plus monitors requests and responses to locate session identifiers (usually cookies) and uses them to determine the server for subsequent requests in a session.

Sticky Route

You can configure a mapping between route values and backend servers so that NGINX Plus monitors requests for a route value and chooses the matching backend server.

NGINX Plus also offers two basic session-persistence methods, implemented as two of the aforementioned load-balancing methods:

IP Hash

The backend server is determined by the IP address of the request.

Hash

The backend server is determined from a user-defined key, for example Source IP Address and Source Port, or the URI.

Azure Load Balancer supports the equivalent of the NGINX Plus Hash method, although it is limited to 3- or 2-tuple for source IP affinity.

Azure Application Gateway supports the equivalent of the NGINX Plus Sticky Cookie method with the following limitations: you cannot configure the name of the cookie, when the cookie expires, the domain, the path, or the HttpOnly or Secure cookie attribute.

¹ Further reading: “NGINX Plus and Microsoft Azure Load Balancers”