Azure ASE to secure tiers
Using multiple Azure App Service Environment instances (ASE or Azure App Service “Isolated” tier) to secure multiple tiers of your applications.
Background
While it is possible to secure Azure App Service in multiple ways, from a networking perspective, only the Isolated tier lets you deploy applications into an instance of ASE running in a VNET.
We discuss a way you can secure multiple tiers of your application (web frontends, API apps, etc.) from a networking standpoint.
See Resources section below for additional references.
What about costs?
While the Isolated tier does cost significantly more than other App Service plans, there are some cases for ASE:
- You require the network isolation provided by ASE. That is, whitelisting access on other App Service plans doesn’t comply with requirements and/or regulation — and more strict network isolation is required.
- On-premises connectivity via ExpressRoute is required.
- Costs can be shared by multiple apps. That is, multiple apps can be deployed on the same App Service Plan thereby maximizing resource usage and thus dividing up the costs over multiple applications.
- As a variation to the above point, the same (secure) network access pattern is applied to the design & deployment of future applications.
Solution architecture
In a multi-tier application where tiers can also be deployed and scaled independently, multiple instances of the App Service plan host the distinct tiers.
In the above diagram:
- The frontend tier hosts typically the presentation tier applications (e.g. ASP.NET (Core), Java, Ruby, Node.js, PHP or Python).
- The backend tier hosts the APIs and logic (.NET, Java, etc.).
- The access to the frontend tier is secured by an application gateway, Network Security Groups (NSGs) secure access from a networking perspective. Traffic Manager or Front Door — depending on whether just DNS based routing is sufficient or Layer 7 is required — is used for additional high availability/global presence and disaster recovery.
- The frontend tier accesses the backend tier. The two VNETs are peered (not shown in diagram) and access is secured by NSGs. The backend VNET has on-premises connectivity by being peered with a HUB VNET.
- With this architecture setup, the frontend web applications have no direct connectivity to an on-premises environment. Only the backend tier has network connectivity to an on-premises environment.
- Though not shown in the diagram, both the frontend as well as backend tiers can securely connect to databases (or Azure Storage) from a networking standpoint using Azure Private Link (or VNET Service Endpoints).
When no on-premises connectivity is required, a variation of this architecture setup is to deploy the backend App Service in another subnet of the frontend VNET instead of its own VNET.
