The App Services in Azure is a PAAS offering that integrates Microsoft Azure Websites, Mobile Services, and other services into a single service. It is a fully managed platform allowing you to run ad scale your applications effortlessly. You can quickly build powerful web, mobile and API apps using the different programming language of your choice. It offers auto-scaling and high availability and enables automated deployments from multiple sources.
App Service Plan
App Service Plan represents the collection of physical resources for the App Service. An App Service Plan can have multiple web apps. In other words, we can have multiple web apps in an app service plan. We can consider an App Service Plan as a single compute resource, i.e., a Virtual Machine. Therefore, for the billing purposes, if we create more than one web apps in a single App Service Plan, we will be charged only once. On the other hand, there can be an adverse effect on the performance of an application if the applications are using the same App Service Plan because they will be competing for the same resources.
Below is a high-level comparison of the features as per the pricing tier for the App Service Plan.
|Disk space||1 GB||1 GB||10 GB||50 GB||250 GB|
|Max instances||Up to 3||Up to 10||Up to 20|
|Testing in Production||Available||Available||Available|
|Integrated Load Balancer||Available||Available||Available||Available||Available|
App Services Environment (ASEv1/ASEv2)
The App Service Environment, on the other hand, is a deployment of the Azure App Service into your own Azure Virtual Network as per the new capabilities of ASE and runs on a separate SKU, which is called Isolated SKU. This is the second generation of ASE generally referred to as ASEv2, whereas, the previous version was referred to as ASEv1. This enables your apps to have direct access to corporate resources over Site-to-site or ExpressRoute connections.
ASEs are isolated from running only a single customer’s applications and are always deployed into a virtual network. Customers have fine-grained control over inbound and outbound application network traffic. Applications can establish high-speed secure connections over VPNs to on-premises corporate resources.
Customers can create multiple ASEs within a single Azure region or across multiple Azure regions. This flexibility makes ASEs ideal for horizontally scaling stateless application tiers in support of high RPS workloads. App Service environments (ASEs) are appropriate for application workloads that require:
- Very high scale.
- Isolation and secure network access.
- High memory utilization.
|ASE v1||ASE v2|
|Resources are managed manually. This includes the Front Ends, Workers and IP based SSL||No manual intervention is required to scale out front ends and workers. All infrastructure is automatically added as customers scale out their App Service plans|
|Pay for each allocated vCPU, which includes both front ends and workers that are not hosting and workloads||There is a flat monthly rate for an ASE v2. There is an additional cost per App Services Plan vCPU|
|App Service Environment can be configured with up to fifty (50) compute resources for exclusive use by a single application||ASE v2 can host 100 App Service Plan instances. The range can span 100 instances in a single App Service plan to 100 single-instance App Service plans, and everything in between|
|ASE v1 can be deployed on both classic virtual network as well as Resource Manager virtual network||ASE v2 can be deployed only on the Resource Manager Virtual Network|
Refer to the below URL for the ASE Pricing details along with the App Services Plan.
Below is the pricing tier availability for the App Service Plan for ASE v2
An ASE can be either internet-facing with a public IP address or internal-facing with only an Azure internal load balancer (ILB) address.
If you deploy the ASE in a virtual network that has a VPN connection to the on-premises network, the apps in the ASE can access the on-premises resources, ad this can be done using either Site-to-site VPN or an Express Route. The best example would be in case you wish to leverage the on-premises databases with the application hosted on ASE.
An App Service Environment (v2) is a fully isolated and dedicated environment for running Azure App Service apps at high scale securely, which includes Web Apps, Mobile Apps, and API’s. It is the deployment of the Azure App Service into a subnet of your virtual network, and also allows your applications to interact with your corporate systems giving you more flexibility.
Thanks for this clear article and information. One question I have is how we can connect/associate existing resources like a WebApp or a FunctionApp (which are already linked to an App Service Plan), to an existing Azure Service Environment? Any information or recommendations in that area?
Hi, If I understand your question correctly, you want to create a Web App with an App Service Plan., and separately create the ASE, and then associate the App/ASP with the existing ASE. This is possible if the ASE V1/V2 has already been created and then you are creating the App Service Plan. In that case, the pricing tier is going to be only Isolated tier. It is NOT possible to modify the App Service Plan to change or associate with other ASE after it has been created. It is one of the drawbacks. I hope that explains.
Is it possible to create separate sunbet in an ASE to separate web app on DMZ network and route traffic through app gateway for DMZ to app services running on that subnet and second subnet on app service would receive traffic through ILB
What I understand from your question is that you wish to have your ASE mapped to two separate subnets, one for the DMZ and one for the app service that is not in DMZ and is load-balanced by the ILB. Am I right? If that is the question, then the answer is NO, what you are thinking of is not possible. However, I have a question. Why do you want to use the ASE? Is your application accessed from the public internet or is accessed over VPN? There could be other possible solutions as well. Also, need to understand the purpose of the Application Gateway. Is that for Layer 7 load-balancing or for WAF?
I’m sorry to be so blunt, but the fact that you don’t even know the correct name of the service makes your entire article highly questionable. It is “App Service” — not “App Services”. How can we trust anything else in your article when you don’t get this simple thing right?
Thank you for your feedback and comment, Frank. I sincerely apologize for this mistake and will keep this in mind the next time.
As far as trusting the article and content goes, it is completely up to you. You may be right as per your perception if you feel a spelling mistake puts the credibility of the content author questionable. You are judging the content by spelling and not the core concepts explained. BTW, my articles, specifically on Azure Data Explorer have been reviewed by Microsoft and have been listed in their reference study links.
I would suggest you to NOT refer to any of my articles as there may be more such questionable contents where trusting the concepts may be an issue.
Thank you again!