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:
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
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 |
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 (since April) |
|
Remote debug (Need to enable) |
YES |
YES |
YES (since April) |
|
SMTP traffic |
YES |
YES |
YES |
|
Network watcher or NSG flow logs to monitor traffic |
YES |
YES |
IN PROGRESS
|
|
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
- ASEv2 NSG: https://docs.microsoft.com/en-us/azure/app-service/environment/network-info#inbound-and-outbound-dep...
- ASEv3 NSG: https://docs.microsoft.com/en-us/azure/app-service/environment/networking#ports-and-network-restrict...
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-serv...
- ASEv2 Assign IP to app: https://docs.microsoft.com/en-us/azure/app-service/environment/network-info#app-assigned-ip-addresse...
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.
- ASEv1 custom DNS Suffix: https://docs.microsoft.com/en-us/azure/app-service/environment/app-service-app-service-environment-c...
- ASEv2 default domain suffix: https://docs.microsoft.com/en-us/azure/app-service/environment/using#app-access
- ASEv3 custom domain suffix: Configure custom domain suffix for App Service Environment - Azure App Service Environment | Microso...
If you have any other questions, feel free to comment below!