Announcing Public Preview: ASEv3 Outbound Network Segmentation

jordanselig

Microsoft

Oct 01, 2025

We’re excited to announce the public preview of Outbound Network Segmentation for App Service Environment v3 (ASEv3)—a long-awaited feature that brings enhanced control, security, and flexibility to outbound traffic management in isolated environments.

🔍 What Is Outbound Network Segmentation?

Outbound Network Segmentation allows you to define and control how outbound traffic is routed from your App Service Environment v3 apps. This means you can now segment outbound traffic at an app level, enabling fine-grained egress control that aligns with enterprise security policies and compliance requirements.

Previously, all outbound traffic from an App Service Environment v3 originated from the full subnet range hosting the App Service Environment, making it difficult for networking teams to apply per-app restrictions, like what is available with the multi-tenant App Service offering. With this new capability, you can now:

For each app, define the subnet all outbound traffic is routed through.
Assign dedicated outbound IPs per app via NAT Gateways.
Route traffic through custom firewalls or appliances.
Apply Network Security Groups (NSGs) with greater precision.
Improve auditability and compliance for regulated workloads.

In an App Service Environment, each worker is assigned an IP from the subnet, but there is no way to group IPs from various apps/plans to allow for routing/blocking/allowing specific app traffic from a networking perspective. With outbound network segmentation, you can now direct various app traffic to the same subnet/virtual network and gain this level of control.

For example, consider the following scenario where you would like to ensure that only App A is able to talk to Database A. To ensure only traffic from App A can reach Database A, you join App A to an alternate subnet (vnet-integration-subnet). The alternate subnet has network access to the private endpoint subnet via NSG. This means that only traffic from the virtual network integration subnet can reach the private endpoint subnet, which then gives access to the database.

🧪 What’s Included in the Public Preview?

This feature is currently available in all public Azure regions. If you're interested in trying it out, you will need to create a new App Service Environment and enable the following cluster setting during creation. Cluster settings can be configured using an ARM/Bicep template. For guidance on configuring cluster settings, see Custom configuration settings for App Service Environments.

"clusterSettings": [
    {
        "name": "MultipleSubnetJoinEnabled",
        "value": "true"
    }
]

Once the App Service Environment is created and this cluster setting is enabled, you will have access to join apps to alternate subnets at any time. However, if you don't set the cluster setting during creation, the App Service Environment will not support this feature. Enabling this feature on existing App Service Environments is not supported.

Portal support for enabling this cluster setting as well as joining alternate subnets is not available at this time. To configure the cluster setting, use an ARM/Bicep template to create the App Service Environment.

To join an alternate subnet, you can use the following Azure CLI command. The alternate subnet must be empty and be delegated to Microsoft.web/serverfarms prior to attempting to join it. Also ensure that application traffic routing is enabled for your app. This is key to ensure all traffic is routed through the alternate subnet and not the default route.

az webapp vnet-integration add --resource-group <APP-RESOURCE-GROUP> --name <APP-NAME> --vnet <VNET-NAME> --subnet <ALTERNATE-SUBNET-NAME>

If your alternate subnet is in a different resource group than your app, run "az webapp vnet-integration add -h" and see the help text to learn how to specify this resource id.

🔧 Tech Specs

If you're familiar with the multi-plan subnet join feature available in the multi-tenant App Service offering, unfortunately, App Service Environments and the alternate subnet join feature are incompatible with multi-plan subnet join. For App Service Environments, each app from a given plan can only integrate with 1 alternate subnet.

Similar to regular virtual network integration, however, a given plan can have multiple different connections and apps in the same plan can use either of the connections. For multi-tenant App Service, this is limited to 2 connections per plan. For App Service Environment v3, you can have up to 4 connections.

If you need to remove or change the alternate subnet join for a specific app, you can do this at any time. First remove the existing join, and then add a new one following the same process as you did previously.

💡 Why This Feature Matters

App Service Environment v3 has always been about isolation, scalability, and control. With outbound segmentation, we’re taking that control to the next level. Whether you're running high-scale web apps, handling sensitive data, or managing complex environments, this feature gives you the tools to secure outbound traffic without compromising performance.