High availability is a critical requirement for mission-critical workloads running on Azure Virtual Machines. When deploying SQL Server Always On Availability Groups (AGs), the Availability Group listener provides a single, highly available endpoint that transparently redirects client connections to the current primary replica. To read more, take a look at this link and also see Azure Resource Inventory (ARI) for Engineers: Improving Control and Compliance.
In single-subnet deployments, an Azure Standard Load Balancer is required to expose the listener’s virtual IP address and ensure seamless failover between cluster nodes. Proper configuration of the load balancer including the frontend IP configuration, backend pool, health probe, and load-balancing rules is essential to maintain application connectivity during failover events.
This article walks through the end-to-end configuration of an Azure Standard Load Balancer using the Azure portal, covering its integration with Windows Server Failover Clustering (WSFC) and SQL Server Always On Availability Groups. The guide follows Microsoft recommended practices and highlights the key considerations for building a resilient and highly available SQL Server infrastructure on Azure.
While Azure now supports alternative approaches such as the Distributed Network Name (DNN) for certain multi-subnet scenarios, the Azure Standard Load Balancer remains the recommended solution for single-subnet deployments that require a traditional Availability Group listener.
Please see Azure Virtual Desktop: Build Custom Session Host Images Using Image Builder Templates [Part 07], and Veeam Agent for Windows: VSS Error Caused by Old SQL Server References.
Azure Load Balancer Overview
This overview page summarizes the complete configuration of an Azure Standard Load Balancer deployed in the North Europe region. The load balancer operates at the regional tier and provides high availability for a backend pool composed of four virtual machines.
The configuration includes a load-balancing rule on TCP port 1433, typically used for SQL Server traffic, together with a dedicated health probe on TCP port 59999 to continuously monitor backend node availability. No inbound NAT rules are configured, indicating that access is managed exclusively through the load-balancing mechanism.
Overall, this architecture delivers a resilient and scalable platform for business-critical database workloads, ensuring traffic is automatically directed only to healthy backend instances.
Please see Azure Virtual Desktop: Autoscaling Implementing and Monitoring Session Hosts [Part 05], and how to implement Azure Private Link for Azure Virtual Desktop [Part 06].
Azure Load Balancer: Static Frontend IP Configuration
The screenshot shows the configuration of a private Azure Load Balancer Frontend IP within a specific Virtual Network and subnet. The frontend IP is configured as Static, ensuring a fixed and predictable address for application access.
The backend pool is associated with virtual machine NICs, allowing incoming traffic to be distributed across backend resources according to the configured load-balancing rules and health probes.
This design is particularly useful for enterprise environments where applications require a stable internal endpoint and centralized traffic management. Using a static frontend IP simplifies DNS management, firewall configuration, and integration with other Azure or on-premises services, while ensuring high availability through the Load Balancer infrastructure.
- The Backend Pool and the Always On Availability Group Listener share the same IP address.
- The Backend Pool is associated with the virtual machine network interfaces (NICs).
Also, see Azure Virtual Desktop: Manage Azure Virtual Desktop host pools and session hosts using the Azure portal [Part 02], Azure Virtual Desktop: How to set Up Azure Virtual Desktop Insights Monitoring [Part 03], and Azure Virtual Desktop: Connect to Session Hosts Using Entra ID [Part 04].
Azure Load Balancer Health Probe Configuration
This screenshot highlights the Health Probe configuration of an Azure Load Balancer. The probe uses the TCP protocol on port 59999 with a 5-second interval to continuously verify the availability of backend instances.
Health probes are essential for high availability because Azure routes traffic only to healthy backend servers. If a probe fails, the affected instance is automatically removed from load balancing until it becomes responsive again.
This configuration demonstrates a proactive monitoring approach, ensuring service continuity and reducing the risk of sending traffic to unavailable backend resources.
Please see Azure Virtual Desktop: Deploy host pools and session hosts in the Azure [Part 01], Disaster Recovery Test Checklist: What to Capture Before You Start, and Upgrading Azure AD Connect to Microsoft Entra Connect Sync.
Azure Load Balancer Rule Configuration for SQL Workloads
This screenshot shows a Load Balancer rule configured to distribute SQL Server traffic on TCP port 1433. The rule maps the frontend and backend ports identically, ensuring transparent traffic forwarding to the backend pool.
A dedicated Health Probe (TCP 59999) continuously monitors backend availability, allowing Azure to route connections only to healthy instances. Notably, Floating IP (Direct Server Return) is enabled, a common requirement for SQL Server high-availability scenarios such as Failover Cluster Instances (FCI), where the same virtual IP must move seamlessly between cluster nodes.
This configuration provides high availability, automatic failover, and connection continuity, making it a robust design for mission-critical database services deployed on Azure.
Please see PCI Driver Error: Connection to Deployment Share could not be made, Steps to Fix the “Invalid OS GUID” Error in MDT, and Faulting SecHealthUI: Resolve Windows Defender Notification.
Conclusion
This configuration demonstrates a robust Azure networking design for SQL Server high availability. By combining a Standard Azure Load Balancer, a static private frontend IP, dedicated health probes, and Floating IP enabled on the load-balancing rule, the solution ensures seamless failover and continuous service availability.
The architecture allows client applications to connect through a single, stable endpoint while Azure automatically directs traffic to healthy backend nodes. This approach minimizes downtime, simplifies operational management, and aligns with Microsoft best practices for deploying mission-critical database workloads in Azure.
Ultimately, Azure Load Balancer provides a resilient, scalable, and cloud-native foundation for supporting highly available SQL Server environments in enterprise production scenarios.
Hello to all readers. Thank you for visiting the blog and for your interest in content about Azure and cloud architectures.
If you found the article useful, feel free to leave a comment below: feedback, questions, or even general thoughts are always welcome. If you’d like to explore other Azure topics (Load Balancer, SQL Server Always On, networking, security, VMs, or any other Microsoft Azure service), feel free to submit your requests. I can create tailored guides, practical examples, or troubleshooting content based on your needs. See you soon on the blog.
