On the Advantages of App Service Environment (ASE) for Government Web Apps

Azure App Service Environment (ASE) is now available in Azure Government. For most Government web applications, it offers many advantages compared to the standard Azure Web App Service. In this blog post, the requirements for Government web applications are reviewed and we will explore how these requirements can be met with either Azure Web Apps or Azure App Service Environment.

Background

Government web applications need to comply with traffic routing rules in addition to standard user authentication and access restriction. Traffic is required to flow through a Trusted Internet Connection (TIC) unless the web site is serving unrestricted information to the public. Consequently, most Government web applications moving from on-premises hosting to cloud hosting should still be considered internal. Even if they can be accessed from the public Internet, they should not be directly accessible via a public endpoint in the cloud. Traffic should come from the TIC and/or agency internal networks via Express Route or VPN to the cloud. The web applications may also need access to resources in on-premises or virtual networks in the cloud.

The requirements are challenging when using a multi-tenant environment such as Azure Web Apps. A new solution in Azure Government called App Service Environment (ASE) enables a more seamless solution to compliance with TIC regulations while enabling access to on-premises resources.

This blog post reviews use cases that Government web applications may need to support, and configurations steps needed ensure TIC compliance in those cases. To set the stage for the discussion, we start with a brief overview of Azure Web Apps and App Service Environment.

Azure Web Apps

Azure Web Apps is a multi-tenant platform for hosting web applications using a variety of environments and programming languages. It is a managed environment - all patching, updating, etc. is handled by the platform. Developers are only responsible for maintaining application code. In the standard offering, all web applications instantiated in the environment will have a public endpoint (e.g., https://MYWEBSITE.azurewebsites.us or https://MYWEBSITE.azurewebsites.net). Unless specific steps are taken to block access to this endpoint, users will be able to access the service through that route (if they can authenticate), which may be a TIC violation. The web applications in the multi-tenant environment will need to configure point-to-site VPN connections to access private resources in virtual or on-premises networks.

App Service Environment (ASE)

The App Service Environment (ASE) can be thought of as a private deployment of an Azure Web Apps in a customer controlled virtual network. The Web App instances in the ASE have private IP addresses and they have access to virtual network resources. All traffic to these applications arrive from the virtual network where the ASE is deployed - there is no direct access through a public endpoint unless a reverse proxy (e.g., Azure Application Gateway) is used. It is also possible to configure forced tunneling to route traffic from the ASE through an on-premises network to the internet. ASE is inherently more TIC compliant and offers a much stronger security posture for sensitive workloads. But it is still a managed environment where patching and updating is handled by the platform and users only need to maintain the application code running in the environment.

The isolated, private environment does come at some additional cost. Specifically, there is a monthly flat fee for running an ASE (regardless of the instance scaling in the environment) and the instance scale units are more expensive in ASE. Due to the flat fee for running ASE, the relative cost difference is greater when considering a single website as opposed to a group of web sites sharing the same ASE.

Use cases

An environment for Government web applications may need to support the following use cases:

Internal Access Only

As outlined above, traffic to government web applications must come through the TIC. There are some exceptions for web sites that provide unrestricted access to public information, but in many (if not most) cases, traffic to the web application must come from an on-premises network. If the Web App environment exposes a public endpoint, there must be away to block it. The ASE solution does that out of the box while the multi-tenant Web App Service will require some configuration to ensure compliance (see below).

Access to Email and/or Messaging Services

Web applications often need to notify users via email or other messaging services. In an on-premises network, SMTP relays are frequently used to send such emails. In Azure, an ASE would be able to reach the same on-premises SMTP relay. The multi-tenant Web App Service would, however, reach the SMTP service via the internet (if it is even reachable). This is potentially a TIC violation. Furthermore, it would also prevent the application from relaying email to external users. Use of third party email distribution services (e.g., SendGrid) may also be a TIC violation. There are ways to connect the multi-tenant Web App Service to virtual network resources via a point-to-site VPN connection, but additional configuration is needed, and it may not be compatible with existing network configurations (see below).

Access to On-Prem Resources (Databases, etc.)

In addition to email or messaging services, the web application may need to access on-premises resources that are only accessible through the on-premises private network IP space. There are many examples of such services, but legacy on-premises databases and CRM systems are common examples. The ASE would be able to access such resources provided that the virtual network is connected to the on-premises network and existing routing rules permit the traffic.

Controlling SSL Policies

Government must comply with current guidelines for SSL configurations. Specifically, current rules require agencies to disable TLS 1.0. Since the ASE is a private environment, users can configure the SSL policies on Web Apps to follow existing rules, but the multi-tenant Web App Service does not allow the users to make changes to the default configuration. It is necessary to use a virtual network appliance (Application Gateway) to ensure compliance in the shared environment.

App Service Environment (ASE) Configuration

The ASE will be able to support the required use cases with little or no additional configuration. A typical ASE deployment for a Government web application would look like the diagram below:

 

Notice that the web app itself is deployed within the virtual network boundary and through standard techniques for connecting to on-premises networks it would be able to reach an SMTP relay or database in the on-premises network. It would also have access to any resources (virtual machines, databases, etc.) deployed in the virtual network. There is no public endpoint on the Web App and the only way to reach it from a public IP address would be through the TIC, which makes it inherently compliant with TIC rules. If an agency should choose to host a web application with direct public access is allowed, this can be achieved by connecting an Application Gateway (with a public IP address) to the Web App. Finally, the ASE allows configuration of the SSL policy on the Web App.

Multi-Tenant Web App Configuration

As indicated above, the multi-tenant environment will not be able to provide all the needed use cases without some additional configuration. Specifically, it is necessary to block direct access to the public endpoint of the Web App and use virtual network appliances (e.g., Application Gateway) to direct traffic from a virtual network to the web app. A configuration of the multi-tenant Web App Service could look like the diagram below:

 

 

There are multiple custom configurations in this setup. The Web App is not deployed in the virtual network. It is equipped with a public IP address, but the IP security restrictions have been configured such that there is only access from a single public IP address. The only public IP address allowed to access the Web App is the IP address of the App Gateway. The App Gateway is deployed in the virtual network and configured to reverse proxy web request from the virtual network to the Web App. No traffic is routed from the public IP of the App Gateway to anywhere in the virtual network. The details of this configuration and scripts for setting it up are provided in a previous blog post. To provide the Web App with access to virtual network or on-premises resources, virtual network integration can be configured. Under the hood, the virtual network integration is a point-to-site VPN connection to a Gateway in the virtual network. This an important limitation of this feature, since such a Gateway may not be compatible with existing network configurations. If the Web App only needs access to the virtual network in order to relay email, there are other solutions such as using message queues to relay the message.

Virtual Network Service Endpoints

Other PaaS services such as Azure Storage and Azure SQL can also be secured to a virtual network using Virtual Network Service Endpoints. Using this feature, the public endpoints on these storage services will be completely removed and they can only be access from the virtual network. When combined with ASE, it forms a complete ecosystem of PaaS services for hosting private web applications.

Conclusions

It should be evident from the analysis above that ASE is the technology of choice for Government web applications in Azure. It provides compliance with TIC rules out of the box and enables integration with virtual network and on-premises resources if needed. With ASE being available in Azure Government, the remaining issue is that of cost. ASE is more expensive, especially when considering a single website running on a single core. However, the cost should be considered in the context of running multiple applications and the operational complexity of securing a public Web App for Government agencies. The cost consists of a flat hourly fee per ASE environment plus a per core cost. Operating a multi-tenant Web App Service with the controls above (Application Gateway and VPN Gateway) will also incur additional costs, but they are lower than the ASE environment costs and the per core cost is lower for the multi-tenant environment. In environments with many websites (and thus many cores) the cost of ASE is asymptotically 50% higher than the multi-tenant environment (when comparing Premium plan to Isolated plan), but for a single core environment it can be more than 3 times as expensive due to the ASE environment cost. Considering that typical web applications will also have costs from databases and other resources, the increased premium for the ASE may well be marginal for organizations with many web applications sharing the app service environment. Moreover, administrative costs associated documenting and monitoring the additional controls for the multi-tenant environment may well outweigh the lowered environment costs. ASE will be the preferred platform for Government web applications in most cases.