Outbound Connectivity of Virtual Machines behind a Standard Load Balancer

Scenario:
We have an application that is to be scalable, load balanced and highly resilient even in the event of a Datacentre failure. The Application should not be accessible from the internet but the applciations must be able to make outbound connections to the internet on demand. Business wants to go for the cheapest possible solution and be made aware of the options and the flexibility to make changes if required a few months/years down the line.

Solution:
The use of Availability Sets and Basic Load Balancer was not an option as these specific application environments had to be resilient in the event of a Datacentre failure as well. So you can provision Application Virtual Machines (VMs) and deploy them in Availability Zones for Data centre level resiliency and load balanced using Standard load balancer with internal IP addresses for high availability and scalability.

However point to be understood here is that Standard Load Balancers (SLB) are secure by default as opposed to a Basic Load Balancer which is open to the internet by default. So any VMs in the backend pool of a SLB are unable to establish outbound connectivity.

So what are the options Azure gives us to allow outbound connectivity for VMs load balanced by Standard Load Balancer:

  • Option 1: Create a public IP address and associate to the VMs
  • Option 2: Route the traffic through a firewall either via Azure Firewall or a network virtual appliance
  • Option 3: Use a Standard Public Load Balancer with outbound NAT rules only
  • Option 4: Use an Azure NAT Gateway and associate with a subnet

Chosen Design and Reasons for doing so:

  • Option 1: Not feasible as we don’t want to allow the VMs to be accesible from the internet
  • Option 2: Costlier in terms of setting up and running also requires a detailed platform evaluation and design
  • Option 3: Chose to use a Standard Public Load Balancer with outbound NAT rules only as it gave you more control per VM and worked out to be cheaper than NAT gateway in my particular scenario
  • Option 4: Feasible but works out to be costlier than Option 3 (see indicative cost calculation below). Resource cost rate is £0.03354 per hour & data processed rate is £0.03354 per GB.

So to retierate Option 3 design to add an additional Standard tier Public Outbound only load balancer was the selected option. You can configure it to use only 1 outbound rule and added required VMs. You do need to configure the inbound rules nor the load balancing rule for this Standard tier Public load balancer. Finally you can also configured the NSG rules for the subnet that those VMs were part of to allow traffic out. So this design is secure and no one can reach the backend VMs via the Standard tier Public load balancer and you pay the costs for 1 rule only.

This design option also works out to be cheaper than a NAT gateway for the same amount of data processed.
For example: for 1000 GB data processed at 730 hours, including one public IP address per device, the indicative monthly cost for:

  • Option 3: Standard Load Balancer (resource cost with 1 rule + data processing cost) is approx. £17.33 per month + one public IP address £2.72 = ~ £20.05 per month
  • Option 4: NAT Gateway (resource cost + data processing cost) is approx. £59.03 per month + one public IP address £2.72 = ~ £61.75 per month
Azure NAT Gateway would work out to be cost effective over outbound-only Public Standard Load Balancer when you had a requirement for 4 or more outbound-only Public Standard Load Balancer per virtual network.

On a side note: It would have been nice to have the Azure NAT Gateway pricing integrated in the Pricing calculator.