When to use an Azure App Service Environment?
Rate this post

Introduction

An Azure App Service Environment (ASE) is a premium Azure App Service hosting environment which is dedicated, fully isolated, and highly scalable. It clearly brings advanced features for hosting Azure App Services which might be required in different enterprise scenarios. But being this a premium service, it comes with a premium price tag. Due to its cost, a proper business case and justification are to be prepared before architecting a solution based on this interesting PaaS offering on Azure.

When planning to deploy Azure App Services, an organisation has the option of creating an Azure Service Plan and hosting them there. This might be good enough for most of the cases. However, when higher demands of scalability and security are present, a dedicated and fully isolated App Service Environment might be necessary.

Below, I will summarise the information required to make a decision regarding the need of using an App Service Environment for hosting App Services. Please, when reading this post, consider that facts and data provided are based on Microsoft documentation at the time of writing, which will eventually change.

App Service Environment Pricing.

To calculate the cost of an App Service Environment, we have to consider its architecture. An Azure App Service Environment is composed of two layers of dedicated compute resources and a reserved static IP. Additionally, it requires a Virtual Network. The Virtual Network is free of charge and reserved IP Addresses carry a nominal charge. So the cost is mostly related to the compute resources. The ASE is composed of one front-end compute resource pool, as well as one to three worker compute resource pools.

The minimum implementation of an App Service Environment requires 2 x Premium P2 instances for the Front-End Pool and 2 x Premium P1 instances for the Worker Pool 1, with a total cost per annum superior to $ 20,000 AUD. This cost can easily escalate by scaling up or scaling out the ASE.

Having said that, the value and benefits must be clear enough so that the business can justify this investment.

The benefits of an Azure App Service Environment.

To understand the benefits and advance features of an App Service Environment, we can compare what we get by deploying our Azure App Services on or without an App Service Environment, as show in the table below.

Without an App Service EnvironmentOn an App Service Environment
Isolation LevelCompute resources are hosted on a multitenant environment.All compute resources are fully isolated and dedicated exclusively to a single subscription.
Compute resources specialisationThere is no out-of-the-box compute resource layer specialisation.Compute resources on an ASE are grouped in 2 different layers: Front-End Pool and Worker Pools (up to 3).

The Front-End Pool is in charge of SSL termination and load balancing of app requests for the corresponding Worker Pools. Once the SSL has been off-loaded and the load balanced, the Worker Pool is in charge of processing all the logic of the App Services. The Front-End Pool is shared by all Worker Pools.

Virtual Network (VNET) IntegrationA Virtual Network can be created and App Services can be integrated to it.

The Virtual Network provides full control over IP address blocks, DNS settings, security policies, and route tables within the network.

Classic “v1” and Resource Manager “v2” Virtual Networks can be used.

An ASE is always deployed in a regional Virtual Network. This provides the ability to have access to resources in a VNET without any additional configuration required.

[UPDATE] Starting from mid-July 2016, ASEs now support “v2” ARM based virtual networks.

[UPDATE July 2016] Accessible only via Site-to-Site or ExpressRoute VPNApp Services are accessible via public Internet. [UPDATE July 2016] ASEs support an Internal Load Balancer (ILB) which allows you to host your intranet or LOB applications on Azure and access them only via a Site-to-Site or ExpressRoute VPN. 
 
 Control over inbound and outbound trafficInbound and outbound traffic control is not currently supported.An ASE is always deployed in a regional Virtual Network, thus inbound and outbound network traffic can be controlled using a network security group.

[UPDATE] With updates of mid-July 2016, now ASEs can be deployed into VNETs which use private address ranges.

Connection to On-Prem ResourcesAzure App Service Virtual Network integration provides the capability to access on-prem resources via a VPN over public Internet.In addition to Azure App Service Virtual Network integration, the ASE provides the ability to connect to on-prem resources via ExpressRoute, which provides a faster and more reliable and secure connectivity without going over public Internet.

Note: ExpressRoute has its own pricing model.

Inspecting inbound web traffic and blocking potential attacks[UPDATE Sept – 2016] A Web Application Firewall (WAF) service is available to App Services through Application Gateway.

Application Gateway WAF has its own pricing model.

ASEs provide the ability to configure a Web Application Firewall for inspecting inbound web traffic which can block SQL injections, cross-site scripting, malware uploads, application DDoS, and other attacks.

Note: Web Application Firewall has its own pricing model.

Static IP AddressBy default, Azure App Services get assigned virtual IP addresses. However, these are shared with other App Services in that region.

There is a way to give an Azure Web App a dedicated inbound static IP address.

Nevertheless, there is no way to get a dedicated static outbound IP. Thus, an Azure App Service outbound IP cannot be securely whitelisted on on-prem or third-party firewalls.

ASEs provides a static Inbound and Outbound IP Address for all resources contained within it.

App Services (Web App, Azure Web Jobs, API Apps, Mobile Apps and Logic Apps) can connect to third party application using a dedicated static outbound IP which can be whitelisted on on-prem or third-party firewalls.

SLAApp Services provide an SLA of 99.95%.App Services deployed on an ASE provide an SLA of 99.95%.
Scalability / Scale-UpApp Services can be deployed on almost the full range of pricing tiers from Free to Premium.

However, Premium P4 is not available for App Services without an ASE.

App Services deployed on an ASE can only be deployed on Premium instances, including Premium 4. (8 cores, 14 GB RAM, 500 GB Storage)
Scalability / Scale-OutApp Services provisioned on a Standard App Service Plan can Scale-Out with up to 10 instances.

App Services provisioned on a Premium App Service Plan can Scale-Out with up to 20 instances.

App Services deployed on an ASE can scale out with up to 50 instances.

An ASE can be configured to use up to 55 total compute resources. Of those 55, only 50 can be used to host workloads.

Scalability / Auto Scale-OutApp Services can be scaled-out automatically.App Services deployed on an ASE can be scaled-out automatically.

However an auto Scale-Out buffer is required. See section below.

Points to consider

As seen above, Azure App Service Environments provide advanced features which might be necessary in enterprise applications. However, there are some additional considerations to bear in mind when architecting solutions to be deployed on these environments.

Without an App Service EnvironmentOn an App Service Environment
Use of Front-End PoolAzure App Service provides load-balancing out-of-the-box.

Thus, there is no need to have a Front-End Pool for load balancing.

The Front-End Pool contains compute resources responsible for SSL termination and load balancing of app requests within an App Service Environment.

However, these compute resources cannot host workloads. So depending on your workload, the Front-End Pool, of at least 2 x Premium P2 instances, could be seen as an overhead.

Fault-tolerance overheadSLA is provided without requiring additional compute resources.To provide fault tolerance, one or more additional compute resources have to be allocated per Worker Pool. This compute resource is not available to be assigned a workload.
Auto Scale-Out bufferAuto Scale-Out does not require a buffer.Because Scale-Out operations in an App Service Environment take some time to apply, a buffer of compute resources is required to be able to respond to the demands of the App Service.

The size of the buffer is calculated using the Inflation Rate formula explained in detailed here.

This means that the compute resources of the buffer are idle until a Scale-Out operation happens. In many cases this could be considered as an overhead.

E.g. if auto Scale-Out is configured for an App Service (1 to 2 instances), when only one 1 instance is being used, there is an overhead of 2 compute resources. 1 for fault-tolerance (explained above) and 1 for Scale-Out buffer.

DeploymentApp Services can be deployed using Azure Resource Manager templates.App Service Environments can be deployed using Azure Resource Manager templates. [UPDATE July 2016] And after the update, ASEs now support ARM VNETs (v2).

In addition, deploying an App Service Environment usually takes more than 3 hours.

Conclusion

So coming back to original the question, when to use an App Service Environment? When is right to deploy App Services on an App Service Environment and to pay the premium price? In summary:

  • When higher scalability is required. E.g. more than 20 instances per App Service Plan or larger instances like Premium P4 OR
  • When inbound and outbound traffic control is required to secure the App Service OR
  • When connecting the App Service to on-prem resources via a secure channel (ExpressRoute) without going by public Internet is necessary OR
  • [Update July 2016] When access to the App Services has to be restricted to be only via a Site-to-Site or ExpressRoute VPN OR
  • [Update Sept 2016] When inspecting inbound web traffic and blocking potential attacks is needed without using Web Roles OR
  • When a static outbound IP Address for the App Service is required.

AND

  • Very important, when there is enough business justification to pay for it (including potential overheads like Front-End Pool, fault-tolerance overhead, and auto Scale-Out buffer)

What else would you consider when deciding whether to use an App Service Environment for your workload or not? Feel free to post your comments or feedback!

Thanks for reading! 🙂

Category:
Architecture, Azure Platform
Tags:
, ,

Leave a Reply

  Subscribe  
newest oldest most voted
Notify of
Pat
Guest
Pat

Great article, nice job explaining a complicated topic!

Miguel Angel Saez
Guest

Are you sure there’s no way to obtain an Static IP address for outbound traffic?

st
Guest
st

did you get any solution to this problem?

I am also interested in knowing if we have any option for an Azure App Service outbound IP to be securely whitelisted on on-prem or third-party firewalls? Or is it only viable through Premium App Service Environment?

Tony
Guest
Tony

Finally I could understand ASE clearly by reading your clear explanation.

I am still confused about how Front-End Pool works. I assume that there is a load balancer in the front of Front-End Pool because there are more than 1 instance in the Front-End Pool. Do you know if my understanding is correct or not?

And do you know what protocol is used between Front-End Pool and Worker Pool? HTTP/HTTPs or TCP? I did not find any docs talking about this.

Thanks,

Tony

Mahesh
Guest
Mahesh

Thanks .Very Good Article summarizes very well
Have couple of questions

1> Can ASE support DR when deployed inside Vnet .I think public AppService provides DR automatically .
2>If we are using dedicated DB for app within Public Appservice , how DR works for Database tier
3> Do they support availability zones/sets

Neil Correa
Guest
Neil Correa

Do you need an ASE to use NSGs or does an App Service have that capability? Haven’t been able to find that via the portal.

Bhavin Shah
Guest
Bhavin Shah

Very helpful article. Clear and concise !
Thanks.

Perter Woodland
Guest
Perter Woodland

Hi, Can I update my Web App on the ASE as updating Web App of App Service(without an ASE) with swapping between staging and product slots?

Perter Woodland
Guest
Perter Woodland

Thanks for your response!
Could you give me some Information about swapping steps and so on? Either formal or informal are good.

Perter Woodland
Guest
Perter Woodland

Thanks you very much!
The article is for App Service. But I will ask Official MS and have a try to swap on ASE.

Thanks again for your information!

ADBK
Guest
ADBK

Hi, regarding statement in column “Without an App Service Environment”, where Application Gateway and WAF is supported. Is this with this setuo: https://blogs.msdn.microsoft.com/benjaminperkins/2014/05/05/how-to-get-a-static-ip-address-for-your-microsoft-azure-web-site/

Or does it work with all 4 inbound ip-addresses?

Joshua Stern
Guest
Joshua Stern

I guess this must be obvious because it is not even mentioned, but I guess that an ASE can access an Azure SQL Database the same way a conventional app service does, but the ASE does not change the service level definitions or pricing of that database tier?

We are interested in Azure scalability and finding bottlnecks in the standard app services so I thought I’d like at the ASE, but we also have certain bottlenecks at the database level and sort of hoped ASE might address them too, but guess not.

Bryan Marks
Guest
Bryan Marks

Is an App Service Environment the only way to get a Web App or Mobile App to use a VNET associated to an Express route?

louisleong
Guest

Great article, though it is mentioned that the multi tenanted webapp supports WAF via Application Gateway. I believe that’s not the case as Application Gateway supports ASE only, not webapps. https://docs.microsoft.com/en-sg/azure/application-gateway/application-gateway-introduction

azuredev
Guest
azuredev

Very useful article. I also have a similar question related to the Front-End Pool and the Worker Pool. So if I take an example of publish one application to the ASE what components goes where? I think the incoming traffic will be handled by the traffic manager / ILB and not by front end pool.
This needs more clarity if you could help with it. Thanks.

Follow Us!

Kloud Solutions Blog - Follow Us!