Bad Request: Internal Load Balancer usage not allowed for this deployment

Microsoft released a number of new networking features for the Azure platform this week:

• Multiple Site-to-Site VPNs
• VNET-to-VNET Secure Connectivity
• Reserved IPs
• Instance level Public IPs
• Internal Load Balancing

Announcement details can be found on Scott Gu’s blog post

Internal load balancing (ILB) was a much needed networking feature that will enable the design of highly available environments in hybrid infrastructure scenarios. Until now, 3rd party solutions were required to load balance workloads in IaaS virtual machines when accessed by on-premise (internal) clients across the site-to-site VPN. Using the existing public load balancer and exposing public endpoints was not a palatable option for many organisations even when hardened using network ACL’s.

ILB now provides a highly available load balancing solution using an internally addressable endpoint within your cloud service or VNET. However, the ILB feature will not work out-of-the-box for you. Like most new features in preview, documentation is sparse and spread out across a number of locations. I have pulled together a list of considerations you’ll need to address before using this feature:

1. ILB is not available from the Portal (Scott Gu’s post), you must use PowerShell or REST API
2. You cannot create an ILB instance for a cloud service or virtual network if there are no external endpoints configured on any of the resident virtual machines. (MSDN)
3. ILB is available only with new deployments and new virtual networks. (Scott Gu’s post)

After installing the latest PS Azure cmdlets you will have a number of cmdlets used to manage ILBs in Azure:

• Get-AzureInternalLoadBalancer
• Add-AzureInternalLoadBalancer
• Remove-AzureInternalLoadBalancer
• Add-AzureEndpoint (now includes the –InternalLoadBalancerName parameter)

However, you may receive the following error when trying to provision a new instance of the ILB despite redeploying virtual machines into a new VNET and cloud service:

Add-AzureInternalLoadBalancer : BadRequest: Internal Load Balancer usage not allowed for this deployment.
At line:1 char:1
+ Add-AzureInternalLoadBalancer -ServiceName $svc -InternalLoadBalancerName $ilb – …
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo          : CloseError: (:) [Add-AzureInternalLoadBalancer], CloudException
+ FullyQualifiedErrorId : Microsoft.WindowsAzure.Commands.ServiceManagement.IaaS.AddAzureInternalLoadBalancer

The solution lies in the definition of “…new virtual network” (from point 3 above). Re-creating the VNET using the portal provisions the “old” type of VNET. As part of this release, a new type of VNET was introduced, Regional Virtual Network. Regional VNETs span the entire regional data centre instead of being pinned to an Affinity Group. This is a good thing for a number of reasons well documented in this post by Narayan Annamalai. Also mentioned in the post was the key to unlocking this:

Following are the key scenarios enabled by Regional Virtual Networks:

• New VM Sizes like A8 and A9 can be deployed into a virtual network which can also contain other sizes.
• New features like Reserved IPs, Internal load balancing, Instance level Public IPs
• The Virtual Network can scale seamlessly to use the capacity in the entire region, but we still restrict to maximum of 2048 virtual machines in a VNet.
• You are not required to create an affinity group before creating a virtual network.
• Deployments going into a VNet does not have to be in the same affinity group.

To provision an ILB instance we need to create a Regional Virtual Network. Again this is not currently supported in the Portal (either version). Fortunately, creating this new type of VNET is just a matter of changing our exported VNET configuration file as follows:

Original VNET config:

<VirtualNetworkSite name="lab-vnet" AffinityGroup="lab-ag">

New VNET config

<VirtualNetworkSite name="lab-vnet" Location="Southeast Asia">

Important: You will need to un-deploy all resources in the current VNET before you can upgrade to the new regional VNET as the old VNET is deleted and the new VNET created. Not an insignificant task for those looking to take advantage of this new feature in existing DEV/TEST environments. I can’t stress enough the importance of automating your cloud provisioning and deployment operations. It will save you many days of Click > Click > Next’ing

After the VNET is upgraded and environment re-provisioned the ILB feature can be provisioned as follows:

1. Create the ILB instance using the Add-AzureInternalLoadBalancer cmdlet

   Add-AzureInternalLoadBalancer -ServiceName $svc -InternalLoadBalancerName $ilb –SubnetName $subnet –StaticVNetIPAddress $IP

2. Add internal endpoints to the ILB instance on each VM to be load balanced using the Add-AzureEndpoint cmdlet

   Get-AzureVM –ServiceName $svc –Name $vmname | `
   	Add-AzureEndpoint -Name $epname -Protocol $prot -LocalPort $locport -PublicPort $pubport –DefaultProbe -InternalLoadBalancerName $ilb | `
   	Update-AzureVM
   

   Note: the InternalLoadBalancerName parameter.

3. Create an DNS A record that points to ILB virtual IP (VIP) that clients will use to communicate with the ILB instance. Use the Get-AzureInternalLoadBalancer cmdlet to get the ILB instance VIP

   Get-AzureService -ServiceName $svc | `
   	Get-AzureInternalLoadBalancer
   

With the new Internal Load Balancer feature we can now achieve a highly available, load balancing solution that clients on-premise can access across the site-to-site VPN.