Cloud / Azure Load Balancer Interview questions

Azure Load Balancer is a built-in Azure service that spreads incoming network traffic across healthy virtual machines or scale set instances. It works at Layer 4 of the OSI model, so it decides using IP address, port and protocol (TCP or UDP), not HTTP content.

It is a managed, software-defined service rather than a VM you size and patch. You define a frontend IP, a backend pool, health probes and rules, and Azure sends new flows only to instances that pass the probe.

Common uses are making a web or app tier highly available, balancing traffic between internal tiers, and giving private VMs outbound internet access.

Azure Load Balancer can be classified by where its frontend lives and by its tier. The two basic exposure types are public and internal, and on top of those there are the Gateway and Global (cross-region) variants.

The old Basic SKU also existed but has been retired, so new designs use Standard.

It means the load balancer only inspects transport-level details of each packet: source and destination IP, source and destination port, and protocol. It never opens the payload, so it has no idea whether the traffic is HTTP, SQL or something else.

The connection is effectively passed through to the chosen VM. The client's TCP session ends on the backend instance, not on the load balancer, and the original client IP is preserved.

• Can do: any TCP or UDP workload, very low latency, millions of flows
• Cannot do: URL path routing, cookie affinity, host-header routing, TLS offload, WAF

When you need those Layer 7 features, use Application Gateway or Azure Front Door instead.

Azure Load Balancer has three SKUs: Standard, Gateway and Basic. Standard is the general-purpose choice and the only one recommended for new deployments.

• Standard: zone-redundant, 99.99% SLA, secure by default, up to 1,000 backend instances.
• Gateway: a specialised SKU used to chain network virtual appliances in front of other load balancers.
• Basic: a limited, free tier with no SLA and no availability zone support. It was retired on 30 September 2025.

Standard also has a Global tier, used for cross-region load balancing.

A frontend IP configuration is the address that clients actually connect to. It is the entry point of the load balancer, and every load balancing rule, inbound NAT rule or outbound rule is tied to one.

For a public load balancer it holds a public IP address (Standard SKU, static). For an internal load balancer it holds a private IP from a chosen subnet, either static or dynamic.

One load balancer can have several frontend configurations, which is how you serve multiple IPs or publish the same port on different addresses. With a Standard SKU the frontend can also be set as zone-redundant or zonal.

The backend pool is the group of resources that receive the traffic. It normally contains the network interfaces of virtual machines or the instances of a Virtual Machine Scale Set in a single virtual network.

Members can be added by NIC or by IP address. Adding by IP is handy for containers or resources that do not have a standard NIC association. A Standard load balancer supports up to 1,000 instances in the pool.

Only pool members that pass the health probe are eligible for new flows, so scaling the pool in or out is just a matter of adding or removing members.

A health probe is a recurring check the load balancer sends to each backend instance to decide whether it can take new connections. Instances that respond correctly are considered healthy, and the rest are taken out of rotation for new flows.

You configure the protocol, port, interval and unhealthy threshold. Probes originate from the platform address 168.63.129.16, so the VM firewall and NSG must allow it.

Once a failed instance starts passing the probe again, it is added back automatically.

Standard Azure Load Balancer supports TCP, HTTP and HTTPS probes. The old Basic SKU did not support HTTPS.

A TCP probe only proves that something is listening. An HTTP or HTTPS probe pointed at a /health endpoint tells you whether the application itself is working, so it is usually the better choice.

A load balancing rule tells the load balancer how to turn incoming traffic into a backend decision. It maps a frontend IP and port to a backend pool and port for a given protocol, and it names the health probe to use.

Other settings on the rule include the distribution mode (session persistence), idle timeout, TCP reset, Floating IP, and whether the rule provides outbound SNAT.

For example, a rule can accept TCP 443 on the public frontend and forward it to TCP 8443 on the web pool, using an HTTPS probe on port 8443.

By default the load balancer uses a 5-tuple hash: source IP, source port, destination IP, destination port and protocol. The hash picks a backend for each new flow, and every packet of that flow then goes to the same instance.

Because the source port is part of the hash, two connections from the same client usually have different source ports and can land on different VMs. This gives a fairly even spread but no client affinity.

If you need the same client to keep hitting the same VM, switch the rule to a source IP affinity mode.

Session persistence, also called source IP affinity or client IP affinity, makes the load balancer send requests from the same client to the same backend instance, instead of using the default 5-tuple hash.

Watch out for clients behind a shared proxy or NAT: they all present one source IP, so they all stick to one VM and the load becomes uneven.

An inbound NAT rule forwards traffic arriving on a specific frontend IP and port to one specific backend instance and port. Unlike a load balancing rule, nothing is balanced; it is plain port forwarding.

A classic use is reaching individual VMs for administration, for example frontend port 50001 to VM1 on 22 and 50002 to VM2 on 22. In production, Azure Bastion is usually a safer way to do this.

Inbound NAT rules can be created for a single VM, or for scale set instances using NAT rule V2.

An outbound rule lets you explicitly configure SNAT for backend VMs that go out to the internet through a Standard public load balancer. You choose which frontend IPs to use, which backend pool it applies to, and how many SNAT ports each instance gets.

It also lets you set the outbound idle timeout and enable TCP reset. This is useful when the default port allocation is too small and you see connection failures from busy VMs.

Outbound rules are a Standard SKU feature. For most new designs Microsoft recommends a NAT Gateway for outbound instead, because it scales better.

SNAT (source network address translation) lets backend VMs that have only private IPs reach the internet. The load balancer rewrites each outgoing connection's source address to one of its public frontend IPs and picks a source port.

Each public frontend IP offers about 64,000 ports, and they are shared among the backend instances. The default allocation depends on pool size:

If an instance runs out of ports, new outbound connections fail. That is called SNAT port exhaustion.

A public load balancer has a public IP address as its frontend and accepts traffic from the internet. It then forwards flows to the private IPs of backend VMs.

It does two jobs at once: inbound balancing for services such as web or game servers, and outbound SNAT for VMs that have no public IP of their own.

A Standard public load balancer is closed by default, so you must add an NSG rule allowing the inbound ports you publish.

An internal (private) load balancer uses a private IP address from a subnet as its frontend, so it is reachable only from inside a virtual network or from connected networks such as on-premises over VPN or ExpressRoute.

It is typically used between tiers, for example web servers calling an app tier, or an application connecting to a database cluster. Nothing is exposed to the internet.

One known limitation: a backend VM cannot connect to the frontend IP of the same internal load balancer it belongs to, because the flow can be sent back to the originating VM.

A zone-redundant frontend is a frontend IP that is served from all availability zones of a region at the same time. If one zone goes down, the frontend keeps working through the others, and no IP change is needed.

It is the default for Standard public IPs created in zone-enabled regions. The alternative is a zonal frontend, which is pinned to a single zone and fails with it.

Zone redundancy only protects you fully if your backend VMs are also spread across zones.

A Standard Azure Load Balancer carries a 99.99% availability SLA for the data path, provided that at least two healthy virtual machine instances are in the backend pool.

The retired Basic SKU had no SLA. That alone was a good reason to move off it. Microsoft publishes the SLA as a percentage of monthly uptime, and service credits apply if it is missed, so check the current Azure SLA document for the exact credit tiers.

Keep in mind the SLA covers the load balancer's own data path. Your application's real availability also depends on the backend VMs, their zones and your health probes.

Gateway Load Balancer is a SKU built to insert third-party network virtual appliances (NVAs), such as firewalls, deep packet inspection or DDoS appliances, into the traffic path without changing your applications or routes.

You deploy the NVAs behind a Gateway Load Balancer, then chain its frontend to the frontend of a Standard public or internal load balancer. Traffic is transparently sent through the appliances and returned, with the original source and destination preserved.

The appliances are reached over VXLAN tunnels, so the NVA image must support that encapsulation.

A cross-region (global) load balancer is the Global tier of Standard Load Balancer. It gives you a single anycast global public IP that fronts several regional public load balancers, and it still operates at Layer 4.

Traffic enters at the Microsoft edge closest to the client and is sent to the closest healthy region. If a regional load balancer fails its health check, the global one stops sending traffic there.

It preserves the client IP and is useful for non-HTTP workloads that need geo-proximity routing and regional failover.

An HA ports rule is a load balancing rule with protocol set to All and port 0. It balances every TCP and UDP flow on every port through a single rule, instead of listing ports one by one.

It is available on an internal Standard load balancer and is designed mainly for network virtual appliances, where all traffic must reach a healthy appliance regardless of port.

Because flows are still spread by the usual hash, the NVAs must handle asymmetric or symmetric paths as designed, and you size the pool for the full traffic volume.

Floating IP is Azure's name for Direct Server Return. When it is on, the load balancer forwards packets to the backend without rewriting the destination IP, so the VM receives them still addressed to the frontend IP.

The VM must have that frontend IP configured on a loopback or guest interface to accept the traffic. You turn it on per rule.

The usual reasons are SQL Server Always On availability group listeners and reusing the same backend port for several frontend IPs.

The idle timeout is how long the load balancer keeps a TCP flow in its state table when no packets are exchanged. When the timer expires, the flow is dropped and later packets on it fail.

For TCP rules it is configurable from 4 to 30 minutes, with 4 minutes as the default. Long-lived but quiet connections such as database sessions or SSH can silently die if the timer is too short.

Fix it by raising the timeout, enabling TCP keepalives on the client or server with an interval below the timeout, or by turning on TCP reset so both ends learn about the drop.

TCP Reset on idle makes the load balancer send a TCP RST packet to both the client and the server when a flow times out from inactivity. It is enabled per rule.

Without it, an expired flow is dropped silently and each side keeps believing the connection is open until its own retry or timeout fires, which looks like a hang.

With TCP reset, applications fail fast and can reconnect straight away. It is a Standard SKU setting and is recommended for most TCP workloads.

Standard Azure Load Balancer publishes multi-dimensional metrics to Azure Monitor. The ones you will use most often are:

• Data path availability: whether the frontend is reachable end to end.
• Health probe status: percentage of backend instances passing probes.
• SYN count: new connection attempts, useful to spot spikes or SYN floods.
• SNAT connection count, allocated SNAT ports and used SNAT ports: outbound health.
• Byte count and packet count: traffic volume per frontend or backend.

You can split most of them by frontend IP, backend IP and port, and use them for dashboards and alerts.

Standard is the production-grade SKU with zones, an SLA, bigger limits and a closed-by-default security model. Basic was a free, limited tier and has been retired since 30 September 2025, so any remaining Basic instance should be migrated.

Standard also adds TCP reset, cross-region and Gateway variants, and Private Link service support.

Azure Load Balancer is a Layer 4 service for any TCP or UDP traffic. Application Gateway is a Layer 7 web traffic load balancer that understands HTTP, HTTPS, HTTP/2 and WebSockets, and can make routing decisions from the request itself.

Many designs use both: Application Gateway for the web front end, and internal load balancers between the other tiers.

Traffic Manager works at the DNS level. It answers a DNS query with the address of a healthy endpoint, and then the client connects to that endpoint directly. Azure Load Balancer sits in the data path and forwards every packet flow itself.

Because Traffic Manager never sees the traffic, it cannot do per-connection balancing and failover depends on DNS caching. It is often placed in front of regional load balancers for multi-region apps.

Azure Front Door is a global Layer 7 entry point built on Microsoft's edge network. It terminates TLS at the edge, offers WAF, caching and URL-based routing, and sends only HTTP and HTTPS to public origins. Azure Load Balancer is a regional Layer 4 service for any TCP or UDP flow to Azure VMs.

• Pick Front Door for global web apps needing acceleration, WAF and routing across regions.
• Pick Load Balancer for non-HTTP protocols, internal tiers, or very low-latency pass-through traffic.
• Use them together by pointing Front Door at an Application Gateway or at an origin that sits behind a load balancer.

They do not compete so much as cover different layers and scopes.

Both forward a frontend port to a backend instance without balancing, but they are built for different scales. An inbound NAT rule maps one frontend port to one backend instance. An inbound NAT pool is the older mechanism for scale sets, mapping a range of frontend ports onto instances as they are created.

NAT rule V2 is the newer model. It attaches a rule to a backend pool and allocates frontend ports from a configured range automatically, so it handles both standalone VMs and scale sets with the same object.

For new builds, prefer V2 and consider Azure Bastion instead of exposing SSH or RDP ports at all.

For TCP, established connections to that instance are not torn down by the load balancer. They continue until the application or the idle timeout ends them. What changes is that new flows are no longer sent to the instance.

That means a VM that is half-broken can still hold on to its current clients, and they may keep seeing errors until they reconnect. If the VM truly dies, the client sees the connection break and the next attempt is hashed to a healthy VM.

For UDP, there is no connection state to preserve, so datagrams from a flow can be redistributed to another healthy instance.

When the instance passes the probe again it simply rejoins the rotation for new flows.

The load balancer sends a probe to the instance on the configured port every interval seconds. If the number of consecutive failures reaches the unhealthy threshold, the instance is marked down. A single success marks it up again.

A probe counts as a failure when a TCP handshake does not complete, an HTTP or HTTPS probe returns anything other than 200, or the response times out. The rough detection time is the interval multiplied by the threshold.

flowchart LR
    A["Probe sent every interval"] --> B{Response OK?}
    B -- Yes --> C["Reset failure count, instance healthy"]
    B -- No --> D["Increase failure count"]
    D --> E{Count reaches threshold?}
    E -- Yes --> F["Instance marked unhealthy"]
    E -- No --> A
    C --> A

Tune both values to balance quick failover against flapping from short blips. A short interval with a low threshold fails over fast but may pull healthy VMs out during a brief GC pause or deployment, while a longer setup is calmer but keeps sending users to a dead VM for longer.

A Standard load balancer and its Standard public IP follow a closed-by-default model. Inbound traffic is blocked until a network security group (NSG) on the subnet or NIC explicitly allows it, so a misconfigured rule set does not accidentally expose a VM.

The older Basic SKU was the opposite: it was open to inbound traffic unless an NSG blocked it, and NSGs were optional.

• You must create an NSG rule for each published port.
• Allow the AzureLoadBalancer service tag so health probes are not blocked.
• Outbound access is no longer implicit for new virtual networks; plan it with NAT Gateway or an outbound rule.

The result is a smaller attack surface and fewer surprises, at the cost of one extra configuration step.

When every instance in the pool is probed down, Standard Load Balancer stops sending new flows to the pool. Clients trying to connect will time out because there is nowhere healthy to send them.

Already established TCP flows are allowed to continue, which is a difference from the retired Basic SKU that terminated all TCP flows in this situation.

This is why a bad health probe design is dangerous. A probe that checks a dependency such as the database can mark every web VM as unhealthy at once when the database blips, turning a partial problem into a full outage.

Keep probes focused on the instance's own ability to serve, and use a lightweight endpoint.

Start by confirming the probe is reaching the VM and the application is answering. Work through the usual causes in order:

1. Check the Health probe status metric split by backend IP to find which instances are affected.
2. Make sure the application is listening on the probe port. Test from the VM itself with curl http://localhost:PORT/health.
3. For HTTP or HTTPS probes, confirm the path returns exactly 200, not a redirect or 401.
4. Allow 168.63.129.16 (the AzureLoadBalancer tag) in the NSG and in the guest OS firewall.
5. Check route tables or UDRs on the subnet that could send the probe reply somewhere else.
6. Verify the probe port matches the one in the rule and that the NIC is really in the backend pool.
7. Use Network Watcher IP flow verify to confirm no NSG is denying the probe.

If the probe passes locally and the NSG is fine, the cause is nearly always the guest firewall or a path that returns non-200.

SNAT exhaustion shows up as intermittent outbound failures or timeouts, often under load, while inbound traffic works fine. First confirm it with metrics.

1. Open the SNAT Connection Count metric and filter by connection state Failed.
2. Compare Used SNAT Ports with Allocated SNAT Ports per backend instance. Values near the allocation are the proof.
3. Reduce port churn in the application: reuse connections, use connection pooling and keep-alive.
4. Add retries with exponential backoff so brief shortages do not become failures.
5. Increase supply by adding frontend IPs and raising ports per instance through an outbound rule.
6. Better still, move outbound traffic to a NAT Gateway, or use Private Link or service endpoints for Azure services so they need no SNAT.

Remember that ports are held per destination IP and port, so many connections to one endpoint burn through allocation fastest.

For most new designs NAT Gateway is the better choice for outbound internet access. It gives far more SNAT capacity with much less tuning, while outbound rules remain useful when you already depend on the load balancer's frontend IPs.

When a subnet has a NAT Gateway, it takes precedence over outbound rules and default outbound access for that subnet. Choose outbound rules only when you need a specific legacy arrangement, such as allow-listing the load balancer's existing IPs.

When a backend VM calls the frontend IP of the internal load balancer it belongs to, the load balancer can pick that same VM as the target. The packet then arrives with the same source and destination VM, the two legs of the flow do not match, and the connection fails.

It does not happen every time, only when the hash selects the originating VM. That makes it an intermittent failure that is confusing to debug.

• Call a different tier's load balancer, so the caller is not in the target pool.
• Put a second internal load balancer in front of a separate pool for the service being called.
• Use a design where clients sit outside the backend pool, such as dedicated client or proxy VMs.

This restriction applies to internal load balancers; public load balancers are not affected in the same way.

Use Floating IP when the backend needs to receive packets still addressed to the frontend IP, instead of having the destination rewritten to its own NIC address.

The main case is a SQL Server Always On availability group listener. The listener IP lives on whichever replica is primary, so the VM must accept traffic for the frontend address itself. Another case is running several services on the same backend port, each behind a different frontend IP.

Setup requirements to remember:

• Enable Floating IP on the rule.
• Configure the frontend IP on the VM, usually as a loopback or secondary address, so the OS accepts it.
• Keep the probe aligned with the service that owns the address, so only the active node passes.

Skip it for ordinary web farms, where default behaviour is simpler.

An HA ports rule balances all ports and protocols across a pool of NVAs through one internal Standard load balancer. A health probe on a port the appliance exposes removes a failed NVA, and flows are then hashed to the surviving ones.

Routing is steered by a user-defined route whose next hop type is virtual appliance and whose next hop IP is the load balancer's private frontend IP. Traffic from spoke subnets therefore reaches whichever NVA is alive.

flowchart LR
    S["Spoke subnet UDR 0.0.0.0/0"] --> L["Internal LB HA ports frontend"]
    L --> N1["NVA 1"]
    L --> N2["NVA 2"]
    N1 --> I["Internet or other spokes"]
    N2 --> I

Two cautions: keep flows symmetric so request and reply pass through the same NVA (or SNAT on the appliance), and size every NVA to take the load if the other fails.

A Gateway Load Balancer has its own frontend and a backend pool of NVAs. A Standard public or internal load balancer, or a VM's public IP, is chained to that frontend. Traffic reaching the chained frontend is automatically diverted to the NVAs before it goes on.

Packets are wrapped in VXLAN and carried over an internal tunnel and an external tunnel (ports 10800 and 10801 by default), so the NVA can tell traffic coming from the outside from traffic going back in. The original source and destination IPs are preserved, so applications and routes do not change.

sequenceDiagram
    participant C as Client
    participant L as Consumer Standard LB
    participant G as Gateway LB
    participant N as NVA
    participant V as App VM
    C->>L: Request to frontend
    L->>G: Chained frontend diverts packet
    G->>N: VXLAN encapsulated flow
    N-->>G: Inspected packet returned
    G-->>L: Back to consumer LB
    L->>V: Delivered to backend

Flow hashing keeps both directions on the same appliance. Providers can publish the NVA service so consumers in other subscriptions chain to it.

A cross-region load balancer fronts several regional Standard public load balancers with one global anycast IP. Clients are routed to the closest healthy region using geo-proximity. It runs its own health checks against each regional load balancer's frontend.

If a region's load balancer becomes unhealthy, for example because every backend there is down, the global load balancer stops sending new flows to it and traffic goes to the next closest region. When it recovers it rejoins the rotation.

• The home region only hosts the resource. An outage there does not affect the data path.
• Backends must be regional Standard public load balancers, so internal ones cannot be added.
• Client IP is preserved, and it works at Layer 4 for TCP and UDP.

For HTTP workloads that need caching or WAF, Azure Front Door is usually the better global option.

The load balancer is a pass-through service. For inbound traffic it only rewrites the destination (to the backend VM's IP, unless Floating IP is on), and leaves the source IP untouched. The backend therefore sees the real client address directly.

This lets you use client IPs in application logs, NSG rules or IP-based access control without extra headers such as X-Forwarded-For.

The client IP can still be lost further along the path:

• A proxy, Application Gateway or NVA in the path that does its own SNAT shows its own address.
• On AKS, externalTrafficPolicy: Cluster may SNAT to a node address, while Local keeps the client IP.
• Outbound traffic is the other direction: SNAT replaces the VM's private IP with the frontend public IP.

Because Basic is retired, migration is a must. You cannot flip the SKU in place, so you either create a new Standard load balancer or use the upgrade module from Microsoft, which builds a Standard equivalent and moves the configuration.

1. Inventory your Basic load balancers and Basic public IPs, for example with Azure Resource Graph.
2. Upgrade or replace Basic public IPs with Standard static IPs, since the SKUs cannot be mixed.
3. Create or update NSGs, because Standard is closed to inbound by default.
4. Run the upgrade script, or recreate frontends, backend pools, probes and rules manually.
5. Plan outbound access explicitly with NAT Gateway or outbound rules.
6. Test probes, then cut over in a maintenance window, as short downtime is possible.

Install-Module -Name AzureBasicLoadBalancerUpgrade -Scope CurrentUser -Repository PSGallery -Force
Start-AzBasicLoadBalancerUpgrade -ResourceGroupName rg-web -BasicLoadBalancerName lb-basic-web

Validate the result against your old configuration before deleting the Basic resource.

You need a Standard static public IP first, then the load balancer with its frontend and backend pool, a probe and a rule. Here is a minimal web setup:

az network public-ip create -g rg-lb -n pip-web --sku Standard --allocation-method Static --zone 1 2 3

az network lb create -g rg-lb -n lb-web --sku Standard \
  --public-ip-address pip-web --frontend-ip-name fe-web --backend-pool-name be-web

az network lb probe create -g rg-lb --lb-name lb-web -n probe-http \
  --protocol http --port 80 --path /health

az network lb rule create -g rg-lb --lb-name lb-web -n rule-http \
  --protocol Tcp --frontend-port 80 --backend-port 80 \
  --frontend-ip-name fe-web --backend-pool-name be-web \
  --probe-name probe-http --idle-timeout 15 --enable-tcp-reset true

Then add VM NICs to the be-web pool and create an NSG rule that allows port 80, because Standard is closed by default. Do not forget outbound access if the VMs need the internet.

When you create a Kubernetes Service of type LoadBalancer in AKS, the cloud controller programs the cluster's Standard Azure Load Balancer for you. The node pool (a scale set) is the backend pool, and the service gets a frontend IP, a rule and a probe.

apiVersion: v1
kind: Service
metadata:
  name: web
  annotations:
    service.beta.kubernetes.io/azure-load-balancer-internal: "true"
spec:
  type: LoadBalancer
  externalTrafficPolicy: Local
  selector:
    app: web
  ports:
  - port: 80
    targetPort: 8080

• The annotation above makes it an internal load balancer with a private IP.
• externalTrafficPolicy: Local keeps the client IP and sends traffic only to nodes running the pod, using a health check node port for probes.
• The same load balancer also supplies outbound SNAT unless you pick another outbound type such as a NAT Gateway.

Each new service adds frontend rules, so watch rule limits and SNAT capacity on large clusters.

Use Azure Monitor metric alerts on the load balancer resource, and send them to an action group (email, SMS, webhook, ITSM). Good starting alerts are:

• Data path availability (VipAvailability) below 100% for several minutes.
• Health probe status (DipAvailability) below your expected percentage, split by backend IP.
• Used SNAT ports approaching the allocated SNAT ports, split by backend instance.
• SYN count far above its normal baseline, a sign of spikes or SYN floods.

az monitor metrics alert create -g rg-lb -n alert-lb-probes \
  --scopes <load-balancer-resource-id> \
  --condition "avg DipAvailability < 100" \
  --window-size 5m --evaluation-frequency 1m \
  --action <action-group-id>

Add a Resource Health alert for platform events, and use the Load Balancer Insights workbook to see topology and health at a glance.

The flow below assumes a public load balancer and a rule for TCP 443 with no Floating IP.

1. The client sends a packet to the frontend IP:443.
2. The platform matches it to a load balancing rule on that frontend and port.
3. A hash of the 5-tuple (or 2- or 3-tuple, if persistence is on) chooses one healthy backend instance.
4. The destination is rewritten (DNAT) to that instance's private IP and backend port, while the source stays the client's IP.
5. The VM replies. The host rewrites the reply's source back to the frontend IP and sends it straight to the client.
6. The load balancer keeps flow state, so later packets in the same flow follow the same path until it ends or times out.

sequenceDiagram
    participant C as Client
    participant L as Load Balancer frontend
    participant V as Backend VM
    C->>L: Packet to frontend IP port 443
    L->>L: Match rule, hash flow, pick healthy instance
    L->>V: Forward with destination set to VM IP
    V-->>C: Reply with source shown as frontend IP

Because the reply skips the load balancer, there is no bottleneck on the return path.

Place a load balancer at each tier boundary, spread every tier across availability zones, and keep the data tier on an internal load balancer. A common layout:

flowchart TD
    I[Internet] --> PL["Public Standard LB zone-redundant"]
    PL --> W1["Web VMs zone 1"]
    PL --> W2["Web VMs zone 2"]
    W1 --> IL["Internal LB for app tier"]
    W2 --> IL
    IL --> A1["App VMs zone 1"]
    IL --> A2["App VMs zone 2"]
    A1 --> DL["Internal LB with Floating IP for SQL listener"]
    A2 --> DL
    DL --> D1["SQL replica zone 1"]
    DL --> D2["SQL replica zone 2"]

• Use a zone-redundant frontend on the public load balancer and zonal spread for the VMs.
• Give each tier its own NSG and probe that checks only that tier's health endpoint.
• Use Floating IP on the database load balancer when SQL Always On owns the listener.
• Give outbound traffic a NAT Gateway rather than relying on load balancer SNAT.
• Do not call a tier's load balancer from inside the same pool, to avoid the hairpin issue.

If the web tier needs URL routing or WAF, swap the public load balancer for Application Gateway and keep internal load balancers below it.

The result depends on the frontend type and where your backends are. With a zone-redundant frontend, the IP is served from every zone, so the surviving zones keep accepting connections and sending them to healthy instances.

Backend instances in the failed zone fail their probes and are removed from rotation. Clients with connections to them see resets or timeouts and must reconnect. Because the load balancer uses cross-zone distribution, instances in other zones pick up the load.

To make this work, deploy at least two instances in different zones and size each zone to absorb the extra traffic. If all your VMs sit in one zone, a zone-redundant frontend alone will not save you.