Introduction to App Service Environment v1

Important

This article is about App Service Environment v1. App Service Environment v1 will be retired on 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 29 January 2024, you can no longer create new App Service Environment v1 resources using any of the available methods including ARM/Bicep templates, Azure Portal, Azure CLI, or REST API. You must migrate to App Service Environment v3 before 31 August 2024 to prevent resource deletion and data loss.

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.