ASEv3 VS ASEv2 - Difference Overview

Microsoft

Apr 07, 2022

The App Service Environment v3 (ASEv3) has become GA since 2021/07. Both ASEv1 and ASEv2 will be retired on 2024/08/31.

App Service Environment v3 provides advantages and feature differences over earlier versions. We suggest to review the supported features of App Service Environment v3 before migrating to reduce the risk of an unexpected application issue.

We've received several customers feedback and questions regarding ASEv3's changes. This blog will focus on the difference between ASE different versions.

Migration:

ASEv2 -> ASEv3 automate migration(certain regions support): https://docs.microsoft.com/en-us/azure/app-service/environment/migrate

ASEv1 -> ASEv3 manual migration: manual migration options documentation

Update: As of September 2022, the automated migration feature supports ASEv1 -> ASEv3 as long as a classic virtual network in not being used - https://aka.ms/asemigration

Public documentation:

ASEv1: https://docs.microsoft.com/en-us/azure/app-service/environment/app-service-app-service-environment-intro

ASEv2: https://docs.microsoft.com/en-us/azure/app-service/environment/intro

ASEv3(latest): https://docs.microsoft.com/en-us/azure/app-service/environment/overview

Official Version Comparison (latest) : App Service Environment version comparison - Azure App Service Environment | Microsoft Learn

Difference Overview:

Features	ASEv1	ASEv2 (If needed, search ASEv2 to create)	ASEv3 (Default ASE creation )
Mange resources manually (Frontend,workers, IP addresses for IP-based TLS/SSL bindings)	YES	NO	NO
Worker pool concept (Scale worker pool before scale ASP)	YES	NO	NO
NSG should allow network dependencies/management traffic	YES	YES	NO need
Manual Front-end scaling	YES	YES	NO need
Scaling blocks other scale operations	YES	YES	NO
Allow private endpoint for app services	NO	NO	YES
Availability Zone redundancy	NO	Zone pinning to one zone	Zone redundancy Spread instances to all three zones in that region (Set only during ASE creation, not for all the regions)
Deploy ASE on dedicated host group	NO	NO	YES (Not compatible with zone redundancy)
Reach apps in an ILB ASE v3 across global peering	NO	NO	YES
Faster scaling	Low	Medium	High

Limitations (Under developing)	ASEv1	ASEv2 (If needed, search ASEv2 to create)	ASEv3 (Default ASE creation )
FTP(S) (Need to enable)	YES	YES	YES
Remote debug (Need to enable)	YES	YES	YES
SMTP traffic	YES	YES	YES
Network watcher or NSG flow logs to monitor traffic	YES	YES	YES
IP-based Transport Layer Security (TLS) or Secure Sockets Layer (SSL) binding with your apps	YES	YES	NO
Configure a custom domain suffix	YES	NO	YES
Perform a backup and restore operation on a storage account behind a firewall	YES	YES	Not yet

Pricing changes (Under developing)	ASEv1	ASEv2 (If needed, search ASEv2 to create)	ASEv3 (Default ASE creation )
MAX ASE instance count	55 hosts (default front-ends+workers)	ASP: 100 Total(ASPs):200	ASP: 100 Total(ASPs):200
Pricing	Pay for each vCPU (including workers which that aren't hosting workloads)	Stamp fee + ASP fee	ASP fee (If empty ASE without ASP, pay for one instance)
Plan type	Pay for each vCPU (including workers which that aren't hosting workloads)	Isolated	Isolated v2
Stamp fee	YES	YES	NO
1-year/3-year reserved instance pricing	NA	NA	YES

What didn't get changed:

You'll have fine-grained control over inbound and outbound application network traffic as always.
High scale/Isolation and secure network access/High memory utilization/High requests per second (RPS)
We recommend to create ASE in /24 subnet with 256 address to ensure enough addresses to support production scale. /27 (32 addresses) is the minimal size.
App Service managed certificates aren't supported on apps that are hosted in an App Service Environment.
External VIP ASE's DNS will be automatically put into public DNS. Internal VIP ASE's DNS needs your manual configuration.
……

QnA:

1. What does it mean "no networking dependencies on customer's VNET"?

In ASEv3, you don't need to set inbound/outbound rules explicitly for management/dependency traffic. Profiting from the underlying infrastructure change, those traffic will go from Azure backbone network rather than your own VNET.

The minimum required rule you need to set will be for your application traffic.

Inbound

Allow /80,443 from VNET to ASE's subnet -> allow app traffic
Allow /80 from Azure Load balancer to ASE's subnet -> allow Internal health check ping

Outbound

Depending on which external resources your application will call

2. Why we could not perform a backup and restore operation on a storage account behind a firewall?

This is a result of the underlying infrastructure change. As we've isolated all the management traffic out of customer's VNET, they will go through Azure backbone network.

Backup is a management operation which will be performed by a internal controller role, which will use an IP of Azure infrastructure VNET to access your storage account, and whitelist the ASE subnet IP range will not help in this case.

3. Not supported to configure an IP-based Transport Layer Security (TLS) or Secure Sockets Layer (SSL) binding with your apps.
What does it mean ? I see that certificates are still supported. Does not being able to use IP-based binding prevent some common scenario?

SNI based binding is always supported. IP-based SSL binding is supported in ASEv1 ASEv2, not yet supported in ASEv3.

In multi-tenant env, we purchase IP-based SSL binding in order to have a dedicated inbound IP for app service which is not shared with other customers. But in ASE, it’s already a single tenant env with an unshared inbound IP.

In ASEv1, you need to manage all of the resources manually, and you could obtain several IP SSL address for apps in ASE. Changing the number of IP addresses in the ASE that are available for IP SSL usage is one of the scale operation.

In ASEv2, it's also supported but has some requirements to pay attention.

But in ASEv3, all the app’s inbound IP will be the same, one and only. So far we didn't have an ETA to get it supported in ASEv3.

ASEv1 multiple IP: https://docs.microsoft.com/en-us/azure/app-service/environment/app-service-web-configure-an-app-service-environment#settings
ASEv2 Assign IP to app: https://docs.microsoft.com/en-us/azure/app-service/environment/network-info#app-assigned-ip-addresses

4. Configure a custom domain suffix. We can configure custom domains for app service. What is the "custom domain suffix" feature referring to?

The custom domain suffix is for the ASE, different from custom domain binding on app service.

Custom domain suffix is supported on ASEv1 and as of August 2022 on ASEv3, but got removed on ASEv2.

The custom domain suffix defines a root domain that can be used by the App Service Environment. In the public variation of Azure App Service, the default root domain for all web apps is azurewebsites.net. For ILB App Service Environments, the default root domain is appserviceenvironment.net. However, since an ILB App Service Environment is internal to a customer's virtual network, customers can use a root domain in addition to the default one that makes sense for use within a company's internal virtual network. For example, a hypothetical Contoso Corporation might use a default root domain of internal-contoso.com for apps that are intended to only be resolvable and accessible within Contoso's virtual network. An app in this virtual network could be reached by accessing APP-NAME.internal-contoso.com.

The custom domain name works for app requests but doesn't for the scm site. The scm site is only available at APP-NAME.scm.ASE-NAME.appserviceenvironment.net.

The custom domain suffix is for the App Service Environment. This feature is different from a custom domain binding on an App Service. For more information on custom domain bindings, see Map an existing custom DNS name to Azure App Service.