Azure Load Balancer distributes TCP and UDP traffic at Layer 4 between eligible backends. That is useful for a service that needs a stable frontend address, healthy target selection, and supported scaling, but it does not guarantee that the application responds correctly or that its data remains available. A sound Azure Load Balancer design begins with the traffic direction, the deployment’s supported SKU, a readiness probe, effective security policies, the outbound path and a failure rehearsal that tests the real user task.<\/p>\n
Consider an internal order-processing API running on three Azure VMs in a regional workload VNet. Its clients come from the corporate network, a database sits on a restricted subnet, and the VMs need controlled outbound access to retrieve updates. A functioning internal load-balancer frontend should help clients reach eligible VM backends, but a wrong NSG, failed backend probe, exhausted outbound ports or database failure could still break the system. Keep the network-level promise separate from the business-level recovery objective.<\/p>\n
Microsoft retired Basic Load Balancer on September 30, 2025. Existing Basic instances may continue to operate but are unsupported and lack the Standard SLA protection. Standard is the normal choice for production Layer 4 distribution with zone-aware features and explicit security configuration. Gateway Load Balancer serves supported traffic-inspection deployments with network virtual appliances; it is not a drop-in Basic replacement. The design decision must use the actual topology rather than the old assumption that Basic and Standard are the only meaningful categories.<\/p>\n
An internal Standard Load Balancer provides a private frontend reachable through the intended private network path. A public Standard Load Balancer uses a compatible Standard public IP and an explicitly permitted inbound path. For the order-processing application, a private frontend is appropriate if only corporate clients and authorized Azure workloads need access. Public exposure would increase security obligations without satisfying the stated business need. Frontend selection does not itself create a valid return route, application authorization or an outbound internet policy.<\/p>\n
Write down one traffic flow: client IP, frontend IP and port, backend pool, selected protocol, backend port, effective route and network policy. Separately document how the VM makes outbound API calls. Inbound load-balancing rules, inbound NAT rules and outbound rules solve different problems. A successful inbound request cannot be used as evidence that VM update downloads or other outbound dependencies will work.<\/p>\n
The backend pool identifies which VM or supported scale-set instances can receive flows through a configured rule. A frontend rule matches relevant protocol and port combinations and uses a health probe to determine eligibility. Decide whether source-IP affinity or session persistence is required by the workload; it is not a replacement for an application that stores shared or durable session state. Multiple frontend configurations may serve distinct workloads, but they do not remove the need for consistent policy and backend management.<\/p>\n
Standard Load Balancer supports TCP, HTTP and HTTPS health probes. The right choice depends on what \u201cready\u201d means. A TCP probe can succeed when a process accepts a connection even if database-backed requests return errors. An HTTP probe can test a more meaningful path, but a static \/health endpoint may still fail to check a critical dependency. Design the probe with the application’s owners, select a response that indicates usable readiness, and separately run a genuine user transaction as the acceptance test.<\/p>\n
For the order API, first run a controlled request and record its response. Then make one backend return an application error while its TCP port still accepts connections. Observe whether the configured probe marks it healthy or unhealthy. Switch to a suitable readiness probe or application repair as justified and repeat the test. Stop one backend entirely and verify new connections are sent to supported healthy instances. Do not claim that a health probe can detect every business logic or database fault without instrumenting what the probe actually measures.<\/p>\n
Microsoft documents specific Standard versus retired Basic behavior for failed health probes, including how existing TCP flows behave when probes become unhealthy. Avoid a simplistic statement that all established sessions are immediately dropped or all traffic will be routed to a backup. Verify the behavior of the selected SKU and protocol; a client may need retry logic and connection recovery even if the load balancer stops selecting an unhealthy backend for new connections.<\/p>\n
Microsoft publishes a 99.99% availability SLA for eligible Standard Load Balancer configurations, subject to documented conditions. Its published reliability guidance requires at least two healthy backend VMs for the relevant SLA, and excludes downtime caused by conditions such as SNAT port exhaustion and NSGs that block traffic. An SLA percentage is not proof that a one-VM application, misconfigured rule or failed database will achieve the same availability. The correct claim is about Microsoft’s defined service commitment under specified conditions, not a guarantee that the entire business application remains up.<\/p>\n
To evaluate resilience, list every component required for a successful order: client route, frontend, healthy backend VM, operating system, service process, database, identity, outbound dependency and monitoring. Each has its own failure modes and recovery ownership. Zone-redundant frontends and multiple backends can reduce certain single-instance risks, but they do not automatically protect a database deletion, schema regression or broken DNS configuration. Define an application recovery-time objective and, where data is involved, a recovery-point objective based on the business requirement, not the load-balancer service SLA.<\/p>\n
Run two different controlled tests. In the first, stop one backend while others remain ready and observe the new client response. In the second, leave all VMs accepting connections but make the database unavailable in a disposable environment. If the load balancer still considers the VMs healthy yet the order fails, the problem is in the application\/dependency chain and must not be recorded as a load-balancer platform outage. Capture failover behavior, user-visible errors and the operator’s recovery decision.<\/p>\n