Outbound Load Balancers for Azure VM Scale-Sets

Background

I recently setup automation for an Outbound Load Balancers in Azure .

Up until this point, I had used Inbound Loadbalancer architecture to distribute incoming network traffic to backend compute workloads to handle consumer demand.

An Inbound Load Balancer (LB) configuration typically has static ingress IPs (either public/private) that serve as an entry point to spread traffic to VMs/VMSS workloads. The only outbound is the return traffic (TCP) for from the source of the original incoming traffic communication.

An Outbound Load Balancer isn’t much different except serves as an outbound exit-point which helps protect internal vm-scalesets (VMSS) from being exposed to with IPs or if you want to use public-IP prefixes. It doesn’t replace an internal load balancer. In fact, you can have a loadbalancer configured to do handle special rules for inbound/outbound routing; but I prefer having a loadbalancer on potential on an dedicated external subnet.

The outbound lb configuration can be configured in one loadbalancer that handles inbound and outbound rules. IMHO that configuration reduces control of outgoing traffic and opens more exposure to your network

Reasons to Use a Outbound Load Balancer

So why would you do want to do this?
There are a few benefits to come to mine.

✅ Avoids the need to assign public IP/prefixes to VM/VMSS

  • Outbound Load Balancer offer a more secure solution egress traffic without assigning a public IP address to your instances exposing them unnecessarily

✅ Supports PublicIP Prefix with a Multi-Zone VM Scaleset Configuration

  • If you’re solution only consist of virtual machines this is not an issue for you; you can easily carve out publicipprefixes in each zone you want redundancy in and assign them to virtual machine its respective zone
  • However associating publicipprefixes in Azure with VM ScaleSets specifically provisioned across multiple zones you will get the following message

Deployment failed. Correlation ID: xxx. {
“status”: “Failed”,
“error”: {
“code”: “ResourceDeploymentFailure”,
“message”: “The resource operation completed with terminal provisioning state ‘Failed’.”,
“details”: [
{
“code”: “CannotSpecifyBothTagsAndPublicIpPrefixForPublicIpAddress”,

  • Loadbalancers multiple regional properties along with being able to assign publicipprefix in different zones is a viable workaround

✅ Transient VNETs (Hub/Spoke)

  • Ideally, If you’re leveraging an hub/spoke configuration in Azure having outgoing loadbalancers are handy particular for hub vnet solution where are egress traffic passes through exiting some virtual appliance running on the azure workload then out to the Internet

✅ Azure Firewall Might Not Be a Good Fit

Deploying the resources (Example)

Provided below is ARM to deploy an outgoing loadbalancer. This is pretty much automated route that I went. If you would like to automate feel free to use the ARM as starting point to bootstrap your setup.

The ARM Template will create a vmscaleset in multi-az, a publicipprefix, and outboundload balancer

External References

MS-Docs: Configuring an outbound LoadBalancer in the Azure Portal

https://docs.microsoft.com/en-us/azure/load-balancer/configure-load-balancer-outbound-portal