Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
App Service Environment v3 provides a fully isolated and dedicated environment for running App Service apps. Multitenant App Service runs apps on dedicated workers while sharing the supporting platform infrastructure with other customers.
Both offerings support applications with no public inbound exposure. App Service Environment v3 can provide private ingress through an internal load balancer (ILB). Multitenant App Service can provide private ingress through a private endpoint with public network access disabled.
This article compares the capabilities and requirements that differentiate App Service Environment v3 from multitenant App Service.
Hosting
| Feature | App Service Environment v3 | App Service public multitenant |
|---|---|---|
| Hosting environment | Fully isolated and dedicated compute | Shared environment. Workers running your apps are dedicated, but the supporting infrastructure is shared with other customers. |
| Hardware | Virtual machine scale sets | Virtual machine scale sets |
| Pricing tiers | Isolated v2, Isolated v4 | Free, Basic, Standard, Premium v2, Premium v3, Premium v4 |
| Dedicated host group | Available | Not available |
| Remote file storage | Fully dedicated to the App Service Environment | Remote file storage for the application is dedicated, but the storage is hosted on a shared file server. |
| Private inbound configuration | Supported through an internal load balancer (ILB) App Service Environment or private endpoints. | Supported through a private endpoint. Disable public network access to eliminate public inbound exposure. |
| Planned maintenance | Manual upgrade preference is available | The platform handles maintenance |
| Aggregate storage limit for remote file shares | 1 TB for all apps in App Service Environment v3 | 250 GB for all apps in a single App Service plan. 500 GB for all apps across all App Service plans in a single resource group. |
Scaling
Both App Service Environment v3 and the public multitenant offering run on virtual machine scale sets. Both offerings benefit from the capabilities that scale sets provide.
However, App Service Environment v3 is a dedicated environment. Even though it can scale out to more instances than the public multitenant offering, scaling out to multiple instances can be slower than the public multitenant offering.
| Feature | App Service Environment v3 | App Service public multitenant |
|---|---|---|
| Maximum instance count | 100 instances per App Service plan. Maximum of 200 instances across all plans in a single App Service Environment v3. | 30 instances per App Service plan. This limit can't be raised. |
| Scaling speed | Slower scaling times due to the dedicated nature of the environment | Faster scaling times due to the shared nature of the environment |
Certificates and domains
| Feature | App Service Environment v3 | App Service public multitenant |
|---|---|---|
| Custom domains | A custom domain suffix can be added to the App Service Environment, and all apps inherit the domain suffix. Custom domains can also be added directly to the apps. | Custom domains can be added directly to the apps |
| Custom domain on private DNS (no domain verification required) | Supported on ILB App Service Environment | Not supported. The custom domain needs to resolve via public DNS. |
| Inbound TLS | Supported. You can manage SSL certificates directly within the environment, including the ability to upload and bind custom SSL certificates. | Supported. You can bring your own certificate or use an Azure-provided certificate. |
| Inbound TLS using certificates issued by private certificate authority (CA) | Supported | Not supported |
| Outbound calls using client certificates issued by private CA | Supported for both Windows and Linux apps. You can add root CA certificates environment-wide using the Root Certificate API or per-app using the private client certificate method (Windows code apps only). | Not supported for source-code based deployments. Supported if you deploy by using either Windows containers or Linux containers. (You can install arbitrary dependencies, including private CA-issued client certificates, inside a custom container for both platform variants.) |
| App Service managed certificates | Not supported | Supported |
| Certificates shared across apps | Yes. | No. You must upload the certificate to every app. |
| Public certificate limit | 1,000 public certificates per App Service plan | 1,000 public certificates per App Service plan |
| End-to-end TLS encryption for inbound calls | Supported | Supported on Premium App Service plans and existing Standard App Service deployments. For configuration details, see End-to-end TLS encryption. |
| Changing TLS cipher suite order | Supported | Supported with the minimum TLS cipher suite feature |
Networking
| Feature | App Service Environment v3 | App Service public multitenant |
|---|---|---|
| Virtual network integration | Supported. App Service Environment v3 is deployed into a subnet in your virtual network by default. | Supported, but must be explicitly enabled |
| Private endpoint support | Supported, but must be explicitly enabled in the App Service Environment | Supported, but must be explicitly enabled |
| IP access restrictions for inbound traffic | Supported, but must be explicitly enabled | Supported, but must be explicitly enabled |
| Network security group (NSG) integration | Supports inbound and outbound traffic control | Can use NSG for inbound traffic control via the subnet that sourced the IP of a private endpoint. (Note that the feature requires private endpoints.) Supports outbound network restrictions with NSG on the virtual network integration subnet. |
| User-defined route (UDR) integration | Supports outbound traffic routing, but must be explicitly enabled | Supports outbound traffic routing, but must be explicitly enabled |
| Routing outbound traffic over a virtual network | Yes. All apps are in the same subnet, and all outbound traffic is routed through the virtual network by default. | Supported. |
| Blocking inbound traffic to App Service functionality hosted on non-HTTP ports | Supported. NSG can be used to block inbound traffic to non-HTTP ports. | Not supported. In some cases (FTP and remote debugging), functionality can be explicitly disabled on a per-application basis. However, inbound network traffic can't be blocked via NSGs because the underlying App Service platform that hosts the infrastructure owns the listed ports. |
| Pulling Docker containers over a virtual network | Supported. Uses the subnet of the App Service Environment. | Supported |
| Azure Functions storage account access over a virtual network | Supported. Uses the subnet of the App Service Environment. | Supported |
| Backup/restore over a virtual network | Supported. Uses the subnet of the App Service Environment. | Supported |
| Maximum outbound TCP/IP connections per virtual machine instance | 16,000 | 1,920 per P1V3 instance. 3,968 per P2V3 instance. 8,064 per P3V3 instance. |
| Maximum source network address translation (SNAT) ports per virtual machine instance | Dynamic: 256 to 1,024, depending on the total instance count | 128 per instance |
Note
In multitenant App Service, private endpoints and virtual network integration serve separate traffic directions. A private endpoint provides private inbound access to the app. Virtual network integration routes application-initiated outbound traffic into a virtual network and must use a different subnet.
Route tables and network security groups on the virtual network integration subnet don't apply to replies for requests received through the app's private endpoint. For more information, see Virtual network integration routing.
If traffic destined for a private endpoint is routed through a network virtual appliance, ensure that the forward and return paths remain symmetric. Private Link generally recommends source network address translation (SNAT) for this topology unless the appliance uses the supported disableSnatOnPL configuration. For more information, see Private endpoint limitations.
Pricing
App Service Environment v3 tends to be more expensive than the public multitenant offering, due to the dedicated nature of the infrastructure. For both offerings, you pay for only the resources that you use. Reserved instances and savings plans are available for both offerings to save money on long-term commitments.
| Feature | App Service Environment v3 | App Service public multitenant |
|---|---|---|
| Pricing | Pay per instance | Pay per instance |
| Reserved instances | Available | Available |
| Savings plans | Available | Available |
| Availability zone pricing | Two-instance minimum enforced per App Service plan that has Availability Zones enabled | Two-instance minimum enforced per App Service plan |
Frequently asked questions
- How do I know which offering is right for me?
- Can I use App Service Environment v3 and the public multitenant offering together?
- Can I migrate from the public multitenant offering to App Service Environment v3?
- Can I use App Service Environment v3 for my development and testing environments?
- How do I get started with App Service Environment v3?
- How do I get started with the App Service public multitenant offering?
How do I know which offering is right for me?
Private inbound access or elimination of public exposure alone doesn't require App Service Environment v3. Both offerings support private application access. In multitenant App Service, configure a private endpoint and disable public network access.
Choose App Service Environment v3 when you require dedicated supporting infrastructure or App Service Environment-specific capabilities, such as environment-level networking, scale beyond multitenant plan limits, private certificate authority scenarios, or control of inbound traffic on non-HTTP platform ports.
Deciding between App Service Environment v3 and the public multitenant offering depends on your specific requirements. The following common scenarios can help you decide:
If you need a fully isolated and dedicated environment for running your apps, App Service Environment v3 is the right choice for you.
If you don't need a fully isolated environment and you're OK with sharing the supporting infrastructure with other customers, the public multitenant offering is the right choice for you.
If you need nearly instantaneous scaling times, the public multitenant offering is the right choice for you.
If you need to scale out to more than 30 instances, App Service Environment v3 is the right choice for you.
If you need to use client certificates issued by a private CA, App Service Environment v3 is the right choice for you.
If you need to use client certificates issued by a private CA and you're deploying by using either Windows containers or Linux containers, the public multitenant offering is also a possibility.
If you want to simplify your networking configuration and have all your apps in the same subnet, App Service Environment v3 is the right choice for you.
If you want to use virtual network integration, private endpoints, or IP access restrictions, then both offerings are right for you. But you need to enable these features on a per-app basis for the public multitenant offering.
Can I use App Service Environment v3 and the public multitenant offering together?
Yes, you can use App Service Environment v3 and the public multitenant offering together. You can use App Service Environment v3 for applications that require dedicated supporting infrastructure or App Service Environment-specific capabilities. You can use multitenant App Service for applications whose isolation and networking requirements can be met through per-app features such as private endpoints, public network access controls, virtual network integration, and access restrictions.
Can I migrate from the public multitenant offering to App Service Environment v3?
Yes. You can migrate from multitenant App Service to App Service Environment v3, but the process isn't an in-place conversion. You need to create the target App Service resources and redeploy or restore the application.
If you use App Service backup and restore, review the applicable limitations. Restore compatibility depends on factors including the backup type and operating system, and automatic and custom backups have different destination restrictions. For more information, see Back up and restore your app.
Can I use App Service Environment v3 for my development and testing environments?
Yes, you can use App Service Environment v3 for your development and testing environments. However, App Service Environment v3 is more expensive than the public multitenant offering. You might want to use the public multitenant offering for your development and testing environments to save money.
How do I get started with App Service Environment v3?
To get started with App Service Environment v3, see Azure App Service landing zone accelerator.
How do I get started with the App Service public multitenant offering?
To get started with the App Service public multitenant offering, see Getting started with Azure App Service.