Session Persistence

Session persistence in Azure Load Balancer (also called session affinity) controls how requests from the same client are routed to backend servers across multiple connections. Choosing the right persistence setting ensures the load balancer aligns with your application’s statefulness and performance needs. In this article we cover the session persistence options available in Azure Load Balancer, show when to use each, and demonstrate them with a small test deployment.

Session persistence options

When configuring an Azure Load Balancer rule you can choose one of three session persistence modes:

None (default)
Client IP
Client IP and protocol

None — five-tuple hash

Uses a five-tuple hash: source IP, source port, destination IP, destination port, and protocol.
Because the source port is included, different connections from the same client (different source ports) can be distributed to different backend servers.
Best for stateless applications or when strict affinity is not required.

Client IP — two-tuple hash

Uses a two-tuple hash: source IP and destination IP.
All requests originating from the same client IP are directed to the same backend instance (assuming the destination is the load balancer frontend IP).
Useful for simple session affinity (e.g., in-memory cache or basic shopping-cart scenarios).

If clients are behind a NAT or forward proxy, many users may appear to share a single source IP. In that case, Client IP persistence will route all those users to the same backend instance, which can lead to uneven load distribution.

Client IP and protocol — three-tuple hash

Uses a three-tuple hash: source IP, destination IP, and protocol.
Applies when you need affinity per protocol (for example, separate affinity for secure vs non-secure sessions from the same client IP).

A slide titled "Session Persistence" showing three option cards — None (default), Client IP, and Client IP and protocol — alongside a dropdown menu with the same choices. The image appears to be a UI/configuration screenshot from KodeKloud.

Quick comparison

Option	Hash tuple	Behavior	Typical use case
None	five-tuple (`srcIP`, `srcPort`, `dstIP`, `dstPort`, `protocol`)	Requests may hit different backends even from same client	Stateless services, best-effort distribution
Client IP	two-tuple (`srcIP`, `dstIP`)	All requests from same client IP go to same backend	Simple session affinity (shopping cart, local cache)
Client IP and protocol	three-tuple (`srcIP`, `dstIP`, `protocol`)	Affinity per protocol per client IP	Different protocol behavior per client (HTTP vs HTTPS)

Choosing the correct setting is a balance between session affinity and even resource utilization — align your choice with how stateful your application is.

Demo: deploy a small test environment

This demo deploys three small webserver VMs, each serving a simple web page with a distinct background color so you can identify which backend served the request. The repository contains a deployment script:

070-loadbalancer-prep-infra.ps1

Running the script will provision the VMs and install a simple web page on each. Example output after the script completes:

Setting OS Profile
Creating VM webserver-03

RequestId                :
IsSuccessStatusCode      : True
StatusCode               : OK
ReasonPhrase             :

Creating jumpbox VM
Configuring VM

RequestId                :
IsSuccessStatusCode      : True
StatusCode               : OK
ReasonPhrase             :

Deployment Completed

Jumpbox VM DNS name       : jumpbox-vm-168e36.eastus.cloudapp.azure.com
Private IP (webserver-01): 10.0.2.4
Private IP (webserver-02): 10.0.2.5
Private IP (webserver-03): 10.0.2.6

PS C:\Users\RithinSkaria\Documents\kodekloud-az104>

SSH into the jumpbox and verify each VM returns the expected page (each uses a different background color):

kodekloud@jumpbox-vm:~$ curl 10.0.2.4
<html>
  <body style="background-color:red;">
    <h1 style="color:white;">Hello world</h1>
  </body>
</html>

kodekloud@jumpbox-vm:~$ curl 10.0.2.5
<html>
  <body style="background-color:green;">
    <h1 style="color:white;">Hello world</h1>
  </body>
</html>

kodekloud@jumpbox-vm:~$ curl 10.0.2.6
<html>
  <body style="background-color:blue;">
    <h1 style="color:white;">Hello world</h1>
  </body>
</html>

These VMs are only accessible on the private network; we will expose them using an Azure Public Load Balancer.

Create the load balancer (Azure portal steps)

In the Azure portal, create a new Load Balancer in the same resource group and region as the VMs.
- Example name: ACLBWEB01
- SKU: Standard (recommended for production). Basic is available for development/test.
- Type: Public (regional)
Add a frontend IP configuration:
- Create a Public IP resource (for example aclbpip) and assign it to the frontend (e.g., FE).
Create a backend pool:
- Example: ACLBBE
- Add the three webserver VMs to the backend pool by selecting the appropriate virtual network and the NICs or IP addresses of each VM.

A screenshot of the Microsoft Azure portal on the "Create load balancer" page showing the Backend pools tab. It lists a backend pool named "azlb-be-pool" with three webserver resources (webserver-01 to webserver-03) and their IP addresses.

Create a load balancing rule

A load balancing rule maps the frontend IP and port to the backend pool and defines the protocol and health probe. When you add a load balancing rule (for example HCLB-LBHTTP) configure:

Protocol: TCP
Frontend IP: the public IP you created
Backend pool: the three webservers
Frontend port: 80
Backend port: 80
Health probe: create an HTTP probe on port 80 (probe interval ~5s)
Session persistence: choose one of None, Client IP, or Client IP and protocol

The portal shows the session persistence options while adding the rule. For this demo keep the default None (five-tuple hash) and save the rule.

A screenshot of the Microsoft Azure portal on the "Create load balancer" page showing the Inbound rules tab and a right-hand "Add load balancing rule" pane with settings (IPv4, backend pool, TCP port 80, health probe, session persistence). A cursor is hovering over the Save button at the bottom of the pane.

Finish deployment and test

Complete the create operation and note the public IP assigned to the load balancer frontend.
Browse to that public IP. The load balancer will forward requests to healthy backend VMs according to the selected hashing algorithm.
With the default None (five-tuple) you may observe that requests from the same browser session could hit different backends because the source port can change between requests. Refresh the page several times to observe variations.
Use the background color of each response (red, green, blue) to identify which backend served a request.

After confirming basic behavior, try switching the session persistence setting:

Change to Client IP and observe that requests from the same client IP consistently hit the same backend.
Change to Client IP and protocol and observe affinity is maintained per-protocol.

Additional tips

Use health probes to ensure only healthy backends receive traffic.
If your clients are behind NAT/load balancer or you rely on cookies/session storage, consider application-level sticky sessions or centralized session stores (Redis) instead of relying solely on LB affinity.
For production workloads prefer Standard SKU for predictable performance and features.

Introduction

Administer Identity

Administer Governance and Compliance

Administer Azure Resources

Administer Virtual Networking

Administer Intersite Connectivity

Administer Network Traffic

Administer Azure Storage

Administer Azure Virtual Machines

Administer PaaS Compute Options

Administer Data Protection

Administer Monitoring

Session Persistence