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
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 |
IN PROGRESS |
|
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 |
NO |
NO |
|
Configure a custom domain suffix |
YES |
NO |
NO
|
|
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-dependencies
- ASEv3 NSG: https://docs.microsoft.com/en-us/azure/app-service/environment/networking#ports-and-network-restrictions
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 only supported in ASEv1, got removed in ASEv2 and 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.
But in ASEv2 and v3, all the app’s inbound IP will be the same, one and only.
- ASEv1 multiple IP: https://docs.microsoft.com/en-us/azure/app-service/environment/app-service-web-configure-an-app-service-environment#settings
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 ASE, different from custom domain binding on app service.
Custom domain suffix is only supported in ASEv1, got removed in ASEv2 and ASEv3.
For example, in ASEv1 you could configure the ASE’s root domain to internal-contoso.com, SCM site could be <app>.scm.internal-contoso.com.
But in ASEv2 and v3, all ASE’s default root domain will be <XXX>.appserviceenvironment.net. The SCM site is only available at <APPNAME>.scm.<ASENAME>.appserviceenvironment.net.
But this is not a regression in ASEv2/v3:
“The DNS settings for the default domain suffix of your App Service Environment don't restrict your apps to only being accessible by those names. You can set a custom domain name without any validation on your apps in an App Service Environment. If you then want to create a zone named contoso.net, you can do so and point it to the inbound IP address. The custom domain name works for app requests, but doesn't work for the SCM site. The SCM site is only available at <APPNAME>.scm.<ASENAME>.appserviceenvironment.net.”
- ASEv1 custom DNS Suffix: https://docs.microsoft.com/en-us/azure/app-service/environment/app-service-app-service-environment-create-ilb-ase-resourcemanager#creating-the-base-ilb-ase
- ASEv2/v3 default domain suffix: https://docs.microsoft.com/en-us/azure/app-service/environment/using#app-access
If you have any other questions, feel free to comment below!
Posted at https://sl.advdat.com/3uZB4gGhttps://sl.advdat.com/3uZB4gG