[This is part 3 of 4 in this series about securing a load-balanced API hosted on Azure VMs with Azure API Management and an Azure Virtual Network. You’ll find the table of contents at the bottom of this post.]
Let’s create an internal load-balancer that will distribute workloads across our VMs. The reason why we are creating an internal load-balancer (and not an external) – is because of the fact that we wish to keep this connection tight and secure.
Our Azure API Management service will need to access the internal load-balancer through a VPN connection. This is how we’re going to make sure that our backend API hosted on our VMs is never called (as it simply can’t be reached externally). Our only external connectivity with the backend API will be through the Azure API Management proxy.
To set this up we will use PowerShell, you’ll need to get the Azure cmdlets to do this with PowerShell (get it at http://azure.microsoft.com/sv-se/documentation/articles/powershell-install-configure/). Obviously this could also be done using Azure xplat-cli.
Pop up Azure PowerShell and run the following command:
Add-AzureInternalLoadBalancer -ServiceName “[cloud service name]” -SubnetName “[subnet name]” -InternalLoadBalancerName “[load-balancer name]” -StaticVNetIPAddress “[IP within subnet]”
Specify the domain name (the name of your cloud service), the subnet name (where your VMs are located), a name for the load-balancer and finally a static internal IP address within the subnet. This IP address is where your internal load-balancer will be located, and ultimately the IP address to where you’ll route workloads.
To verify that the internal load-balancer was added successfully, run:
Get-AzureInternalLoadBalancer -ServiceName “[cloud service name]”
Next up we’ll need to add the VMs to this internal load-balancer. To do this I’ll run the following script for each VM:
Get-AzureVM -ServiceName “[cloud service name]” -Name “[name of the VM]” | Add-AzureEndpoint -Name “[load-balancer name]” -LBSetName “[load-balancing set name]” -Protocol tcp -LocalPort 80 -PublicPort 80 -ProbePort 80 -ProbeProtocol tcp -ProbeIntervalInSeconds 10 -InternalLoadBalancerName “[internal load-balancer name]” | Update-AzureVM
So this script is pretty large, let’s go through it. First off we get the VM object using the Get-AzureVM cmdlet. Then we add an endpoint to it as a load-balanced set, configure health probes and set the InternalLoadBalancerName to what we named our internal load-balancer in Add-AzureInternalLoadBalancer. You should keep the Name and LBSetName parameters consistent across your VMs.
Lastly we need to call Update-AzureVM on the VMs to apply the changes that we’ve made. Again, repeat this for each of your VMs.
Notice that I’m using 80 as the LocalPort and PublicPort parameters – this is because my IIS configuration listens to HTTP traffic on port 80. Configure this port as you’d like in the load-balancer and IIS.
Let’s move on and configure the Azure API Management proxy with a VPN connection and call the internal load-balancer!
You can navigate within the entries of this series here:
- Creating the services and networking
- Installing IIS and Web Deploy
- Setting up the internal load-balancer
- Configuring the proxy and tightening up