Edit

Share via

Introduction to App Service Environment v1

  • Article

Important

This article is about App Service Environment v1. App Service Environment v1 and v2 are retired as of 31 August 2024. There's a new version of App Service Environment that is easier to use and runs on more powerful infrastructure. To learn more about the new version, start with the Introduction to the App Service Environment. If you're currently using App Service Environment v1, please follow the steps in this article to migrate to the new version.

As of 31 August 2024, Service Level Agreement (SLA) and Service Credits no longer apply for App Service Environment v1 and v2 workloads that continue to be in production since they are retired products. Decommissioning of the App Service Environment v1 and v2 hardware has begun, and this may affect the availability and performance of your apps and data.

You must complete migration to App Service Environment v3 immediately or your apps and resources may be deleted. We will attempt to auto-migrate any remaining App Service Environment v1 and v2 on a best-effort basis using the in-place migration feature, but Microsoft makes no claim or guarantees about application availability after auto-migration. You may need to perform manual configuration to complete the migration and to optimize your App Service plan SKU choice to meet your needs. If auto-migration isn't feasible, your resources and associated app data will be deleted. We strongly urge you to act now to avoid either of these extreme scenarios.

If you need additional time, we can offer a one-time 30-day grace period for you to complete your migration. For more information and to request this grace period, review the grace period overview, and then go to Azure portal and visit the Migration blade for each of your App Service Environments.

For the most up-to-date information on the App Service Environment v1/v2 retirement, see the App Service Environment v1 and v2 retirement update.

Overview

An App Service Environment is a Premium service plan option of Azure App Service that provides a fully isolated and dedicated environment for securely running Azure App Service apps at high scale.

App Service Environments are ideal for application workloads requiring:

  • Very high scale
  • Isolation and secure network access

Customers can create multiple App Service Environments within a single Azure region, as well as across multiple Azure regions. This makes App Service Environments ideal for horizontally scaling state-less application tiers in support of high RPS workloads.

App Service Environments are isolated to running only a single customer's applications, and are always deployed into a virtual network. Customers have fine-grained control over both inbound and outbound application network traffic, and applications can establish high-speed secure connections over virtual networks to on-premises corporate resources.

For an overview of how App Service Environments enable high scale and secure network access, see the AzureCon Deep Dive on App Service Environments!

For a deep-dive on horizontally scaling using multiple App Service Environments see the article on how to setup a geo-distributed app footprint.

To see how the security architecture shown in the AzureCon Deep Dive was configured, see the article on implementing a layered security architecture with App Service Environments.

Apps running on App Service Environments can have their access gated by upstream devices such as web application firewalls (WAF). The article on configuring a WAF for App Service Environments covers this scenario.

Note

Although this article refers to web apps, it also applies to API apps and mobile apps.

Dedicated Compute Resources

All of the compute resources in an App Service Environment are dedicated exclusively to a single subscription, and an App Service Environment can be configured with up to fifty (50) compute resources for exclusive use by a single application.

An App Service Environment is composed of a front-end compute resource pool, as well as one to three worker compute resource pools.

The front-end pool contains compute resources responsible for TLS termination as well automatic load balancing of app requests within an App Service Environment.

Each worker pool contains compute resources allocated to App Service Plans, which in turn contain one or more Azure App Service apps. Since there can be up to three different worker pools in an App Service Environment, you have the flexibility to choose different compute resources for each worker pool.

For example, this allows you to create one worker pool with less powerful compute resources for App Service Plans intended for development or test apps. A second (or even third) worker pool could use more powerful compute resources intended for App Service Plans running production apps.

For more details on the quantity of compute resources available to the front-end and worker pools, see How To Configure an App Service Environment.

For details on the available compute resource sizes supported in an App Service Environment, consult the App Service Pricing page and review the available options for App Service Environments in the Premium pricing tier.

Virtual Network Support

An App Service Environment can be created in either an Azure Resource Manager virtual network, or a classic deployment model virtual network (more info on virtual networks). Since an App Service Environment always exists in a virtual network, and more precisely within a subnet of a virtual network, you can leverage the security features of virtual networks to control both inbound and outbound network communications.

An App Service Environment can be either Internet facing with a public IP address, or internal facing with only an Azure Internal Load Balancer (ILB) address.

You can use network security groups to restrict inbound network communications to the subnet where an App Service Environment resides. This allows you to run apps behind upstream devices and services such as web application firewalls, and network SaaS providers.

Apps also frequently need to access corporate resources such as internal databases and web services. A common approach is to make these endpoints available only to internal network traffic flowing within an Azure virtual network. Once an App Service Environment is joined to the same virtual network as the internal services, apps running in the environment can access them, including endpoints reachable via Site-to-Site and Azure ExpressRoute connections.

For more details on how App Service Environments work with virtual networks and on-premises networks consult the following articles on Network Architecture, Controlling Inbound Traffic, and Securely Connecting to Backends.

Getting started

To get started with App Service Environments, see How to Create an ASEv1 from template

For an overview of the App Service Environment network architecture, see the Network Architecture Overview article.

For details on using an App Service Environment with ExpressRoute, see the following article on Express Route and App Service Environments.

Note

If you want to get started with Azure App Service before signing up for an Azure account, go to Try App Service, where you can immediately create a short-lived starter web app in App Service. No credit cards required; no commitments.