In this post, I will explain how you can run Azure App Services in an isolated or virtual network-connected deployment and why, despite the price, it was the right choice for some projects I’ve been working on.
When you deploy an app services plan (a set of under-the-cover virtual machines) to host one or more app services in the Free, Shared, Basic, Standard, or Premium Tiers, then the infrastructure that your app services are deployed into are multi-tenant. This means that the virtual machines that make up your app services plan are in a shared pool. Those virtual machines might be dedicated to you, but they come from a shared environment. A set of transparent and hidden front-end servers (offering the load balancing functionality) are shared between all of the tenants (customers) using the virtual machines in this app services environment. And finally, because you are in a multi-tenant environment, the app service plan is not connected directly to a virtual network. Although, you can connect your app services to a virtual network via a P2V VPN connection and use this to route externally via a site-to-site VPN connection.
The goal of app services is to make things easy for you. But easy means making some small compromises. For a small number of customers, these compromises are too much. And it is because of this, that Microsoft launched the Isolated tier app services plan, which allows you to deploy your own app services environment (ASE).
The term ASE is normally used to describe a customer’s deployment of the isolated tier app services plan, but it’s something that I have also heard Microsoft use to describe the hidden pieces of the other tiers. Typically, if you hear ASE, then it’s a reference to the Isolated tier.
In short, the Isolated tier app services plan must be deployed into an ASE. The ASE provides a single customer with a completely private deployment of app services. There are a few traits to this:
As several other parts of the Azure PaaS catalogue, ASE is built on IaaS components. One will have to understand virtual networks, IP addresses, load balancers, Network Security Groups, and more. This is more evidence that, even with an advanced PaaS deployment, the future career of IT pros (that are willing to do continuous re-learning) are secure. Although, “disk monkeys” are probably still at great risk.
The first type of ASE deployment is an external ASE, using a PIP to make the web apps available to the Internet using a public IP (PIP) address. The first benefit of this approach is that you get a single-tenant (you) ASE but it’s still on the Internet. The second benefit of this approach is that the instances of the app service plan(s) that you deploy in the ASE are connected to a virtual network, just like virtual machines. Now some interesting architectural possibilities arise (more on this later).
The second type of ASE is an internal deployment, where the ASE is shared to the virtual network via an internal Azure load balancer with a private IP address from the virtual network. Note that with this deployment type, you have sole responsibility for managing the DNS of the app services.
It is up to you if you deploy the app service(s) on the Internet or not, and if you do, how you accomplish it. There are plenty of interesting ways to share a private IP address to the Internet in Azure, including the web application gateway, third-party firewall appliances, and more. The architectural possibilities are interesting!
The reason that ASE has popped up, unexpectedly, in proposals that I have written, is the connectivity to virtual networks. Don’t get me wrong, a more traditional app service plan does offer network connectivity:
The problem with both of those approaches is scale. In one of my proposals, the customer needed many connections to suppliers and partners without deploying any change-making software. If an ASE can be deployed into a virtual network, then a VPN gateway can enable those connections without deploying any software. The higher sizes of gateway support up to 30 site-to-site VPN tunnels.
The ASE also has the ability to talk directly to virtual machines on the virtual network. That works both ways. Another customer has a preference to use a certain brand of firewall for edge network security. That firewall can be run as a virtual appliance in Azure, so it can be deployed on an edge subnet in the virtual network and route to the private IP address of an internal ASE deployment (internal load balancer).
Or if a customer wishes, the ASE can be published to on-premises users via an ExpressRoute or VPN connection, with no Internet connection at all! The customer gets the cloud benefits of a PaaS deployment but with the security of an isolated installation.
When I saw the fixed cost of an ASE (~$1,043.82/month RRP in East US) plus the cost of the isolate tier instances (starting at ~$219/month RRP in East US), I thought I would never deploy ASE. However, when we compared the architectural, technical, and operational (developer) benefits with the alternatives, ASE with the Isolated app services tier was a no-brainer.