Creating the Load Balancer

In order to expose your Service with a Private Link Service you need to first put it behind a Load Balancer. Unfortunately this step cannot be skipped, even if you only want to expose a single server.

Setting up an Azure Load Balancer is relatively easy, however some care must be taken when doing so in order to properly integrate it with a Private Link Service

For example:

Let’s say you have a working SPSS License Server running in a VM inside a VNet in your azure tenant. This VM will most likely have security configured to only allow UDP traffic on port 5093 (SPSS’s License server default port).

(At the time of this writing) If you decide to create a Load Balancer through the Azure Portal you will soon run into a problem: Health Probes

Azure doesn’t let you create a Load Balancer without a Health Probe when using the Portal. This is a problem for most cases where we are not allowed to alter the targeted VM and expose other ports in order to facilitate a health probe. Thus, we need to find a way to create a Load Balancer without a health probe or find a way to ignore the health probe. Likely, we can create a Load Balancer through a Bicep template and deploy it which will allow us to not specify a health probe for it.

Caution

If you decide to setup a health probe for the load balancer you need to make sure it works. In case the configured health probe cannot reach the target VM all incoming connections will be dropped and your service will not be accessible.

Here’s a bicep configuration that you can use to deploy a Load Balancer in Azure without a configured Health probe with High Availability Ports meaning it will Forward and Load-Balance traffic for all ports.

You can narrow down the forwarded ports by specifying the port number for frontendPort & backendPort

param location string
param lbName string
param vnetName string
param subnetName string

resource lb 'Microsoft.Network/loadBalancers@2024-05-01' = {
name: lbName
location: location
sku: {
  name: 'Standard'
}

properties: {
  frontendIPConfigurations: [
    {
      name: 'front'
      properties: {
        subnet: {
          id: resourceId('Microsoft.Network/virtualNetworks/subnets', vnetName, subnetName)
        }
      }
    }
  ]

  backendAddressPools: [
    {
      name: 'back'
      properties: {
        loadBalancerBackendAddresses: [
          {
            name: 'backpool-addresses'
            properties: {
              subnet: {
                id: resourceId('Microsoft.Network/virtualNetworks/subnets', vnetName, subnetName)
              }
              loadBalancerFrontendIPConfiguration: {
                id: resourceId('Microsoft.Network/loadBalancers/frontendIPConfigurations', lbName, 'front')
              }
            }
          }
        ]
      }
    }
  ]

  loadBalancingRules: [
    {
      name: 'lb-all'
       properties: {
        backendAddressPool: {
          id: resourceId('Microsoft.Network/loadBalancers/backendAddressPools', lbName, 'back')
        }
        frontendIPConfiguration: {
          id: resourceId('Microsoft.Network/loadBalancers/frontendIPConfigurations', lbName, 'front')
        }
        frontendPort: 0
        backendPort: 0
        protocol: 'All'
       }
    }
  ]
}
}

You can deploy the Bicep template from command line: Replace the <resourceGroup> with the resource group in which your VNet resides and the <bicepFile> with a .bicep file containing the code for the Load Balancer.

az deployment group create --resource-group <resourceGroup> --template-file <bicepFile>

When deployment finishes you must setup your backend pool to include the IP Configurations of the VMs to which traffic will be forwarded.

Specifying the VM Network Interfaces

Danger

Azure gives you 2 options to attach VMs to a backend pool.

1. Directly specifying the VM’s private ip address.
2. Attaching the Network Interface (NIC) of the VM to the backend pool.

Directly attaching VM’s by private ip address does not work for our use case. You cannot create a Private Link Service from a Load Balancer that has an IP-based attached VM. Thus we only mention the second method in our guide.

Attaching a VM’s Network Interface to the backend pool depents on how you created your Load Balancer & VMs. If you VM is already created, you can go ahead and through the Azure Portal select:

Load Balancer -> Backend Pools -> IP Configurations -> Add -> Add the NIC of the VM you want to route traffic to

In case you’re creating this for the first time and you’re using a Bicep template you need to specify the loadBalancerBackendAddressPools property of the Network Interface to point to the Backend Pool ID of the Load Balancer. There is no way to specify which VM you want to attach from the Load Balancer declaration, you have to do this on the VM’s Network Interface resource.

resource nic 'Microsoft.Network/networkInterfaces@2024-05-01' = {
name: 'vm-nic'
location: location

properties: {
  ipConfigurations: [
    {
      name: 'vm-ipconfig'
      properties: {
        privateIPAllocationMethod: 'Dynamic'
        publicIPAddress: {
          id: ip.id
        }
        subnet: {
          id: resourceId('Microsoft.Network/virtualNetworks/subnets', vnetName, subnetName)
        }
        loadBalancerBackendAddressPools: [
          {
            id: resourceId('Microsoft.Network/loadBalancers/backendAddressPools', lbName, 'back')
          }
        ]
      }
    }
  ]
  networkSecurityGroup: {
    id: nsg.id
  }
}
}

When deployment finishes you should have a properly configured Load Balancer that you can use.

We can now move on and expose our Load Balancer with a Private Link Service.