Deploy Azure App Service Environment with Internal Load Balancer
In this article, I will show you how to deploy an internal Azure Service Environment (ASE), which will share its hosted app services via an internal load balancer.
Say Goodbye to Traditional PC Lifecycle Management
Traditional IT tools, including Microsoft SCCM, Ghost Solution Suite, and KACE, often require considerable custom configurations by T3 technicians (an expensive and often elusive IT resource) to enable management of a hybrid onsite + remote workforce. In many cases, even with the best resources, organizations are finding that these on-premise tools simply cannot support remote endpoints consistently and reliably due to infrastructure limitations.
Create A New ASE
Start the creation by clicking Create A Resource > Web + Mobile > App Service Environment. Enter the following details:
- Name: Enter a unique name in the .p.azurewebsites.net domain for your new ASE.
- Subscription: Specify the subscription you want to create the ASE in.
- Resource Group: Select an existing resource group or create a new one for the ASE resources.
The Virtual Network/Location setting is important because this is where you:
- Select/create a virtual network
- Specify the region
- Create the ASE as an internal one
Click Virtual Network/Location. Here you will enter:
- Virtual Network: Either select or create a virtual network. Note that the location of the virtual network will be the location of the ASE.
- VIP Type: Select Internal.
- Domain: Enter the domain name that will be used for all app services in the app services plan (instead of the usual .azurewebsites.net).
When you close the Virtual Network blade, you can click Create in the App Service Environment blade. The creation job might take around one and a half hours to complete.
Eventually, you will have a set of resources. Note that you cannot see an internal load balancer but here is one.
You can find the internal IP address (192.168.250.11, an IPv4 address from the virtual network, which we will use later) of the ASE by opening it and browsing to Settings > IP Addresses. There you will also find the outbound (NAT) address and the management IP address of the ASE.
Deploy an App Service / App Services Plan
You can add a new app service, running on an Isolated tier app services plan, to the internal ASE the same way as normal. In the Azure Portal, click Create A Resource > Web + Mobile > Web App. Enter the details for the web app:
- App Name: This prefix will form a unique .azurewebsites.net FQDN.
- Subscription: The name of the subscription that the app service and app service plan will be in.
- Resource Group: The new or existing resource group that the app service and app service plan will be deployed into.
- OS: Windows – Linux is not supported by ASE.
When you get to App Service/Location, click Create New. Enter the following information:
- App Service Plan: Give the plan a descriptive name.
- Location: Select the internal ASE that you just created.
- Pricing Tier: Choose one of the isolated tier instance sizes.
Click OK to save the settings in New App Service Plan. You are returned to Web App, where you can optionally enable Application Insights. Click Create and the new app service is deployed into a new app service plan in the internal ASE.
Testing the App Service
The only way to connect to the App Service is to connect to the virtual network because, by default, it is only available from the virtual network. Some connection methods will include:
- Virtual Network: Deploy a service, such as a virtual machine, on the same virtual network as the app service (but a different subnet), and access the app service.
- VNet Peering: You can peer the ASE virtual network with another virtual network and connect to the app service from the other virtual network.
- Virtual Network Gateway: Features such as point-to-site (P2S) VPN, site-to-site (S2S) VPN, or ExpressRoute will give remote users access to the ASE virtual network, and thus the app services hosted in it.
- Web Application Gateway (WAG): You can deploy a WAG in front of the ASE and use the private IP address of the ASE as a “backend pool” for the Azure layer-7 load balancer/firewall.
Note that in all cases, you must manage DNS to resolve a domain name to the virtual network IP address of the ASE. In my example, I created an ASE with the joeelway.com domain name, so the app service (called petriapp) is called petriapp.joeelway.com and should resolve to the public IP address of the ASE (192.168.250.11).
In my example, I did the following:
- Added a subnet to the ASE virtual network.
- Deployed a virtual machine to the new subnet.
- Added a hosts file entry to the guest OS of the Azure virtual machine to resolve petriapp.joeelway.com to 192.168.250.11.
- Browsed from the Azure virtual machine to http://petriapp.joeelway.com.
The internal ASE is what I think of when I think of isolated app services. The private virtual network connection makes for an interesting deployment that brings the power of the cloud to truly private but still flexible deployments.