ASEv3 VS ASEv2 - Difference Overview

Published Apr 07 2022 02:21 AM 3,567 Views
Microsoft

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:

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

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

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

(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:

  1. You'll have fine-grained control over inbound and outbound application network traffic as always.
  2. High scale/Isolation and secure network access/High memory utilization/High requests per second (RPS)
  3. 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.
  4. App Service managed certificates aren't supported on apps that are hosted in an App Service Environment.
  5. External VIP ASE's DNS will be automatically put into public DNS. Internal VIP ASE's DNS needs your manual configuration.
  6. ……

 

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

XinyuShan_0-1649147379514.png

 

XinyuShan_1-1649147379518.png

 

 

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.

 

XinyuShan_0-1649149510892.png

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.

 

 

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.

 

 

If you have any other questions, feel free to comment below!

Co-Authors
Version history
Last update:
‎Aug 09 2022 07:12 AM
Updated by: