---
cuppy_hub: azure
cuppy_path: reference/app-service/app-service-environment.md
cuppy_section: docs
cuppy_doc: T50Y-P0H6
cuppy_doc_uuid: f93187da-c91f-4116-8531-0db60e9d05d3
cuppy_permalink: https://cuppy.io/azure/d/T50Y-P0H6
cuppy_version: 1
cuppy_updated: 2026-10-23T16:16:52.575Z
cuppy_canonical: https://cuppy.io/azure/docs/reference/app-service/app-service-environment
cuppy_mcp: https://cuppy.io/mcp
cuppy_body_sha256: a29e77eec0a78e7c2ccc83741bf86a8b4b5c6a3c95de609a02e96b27a31f349a
# cuppy_body_sha256 is over the document body ALONE, excluding both generated blocks.
---


# App Service Environment v3

An ASE v3 runs App Service plans (web, API, function, logic and container apps) for **one customer inside one subnet of their VNet**. Pick it for network isolation without per-app VNet features, more than 30 instances per plan, or single-tenant compliance; otherwise multitenant App Service with VNet integration and private endpoints is cheaper (`reference/app-service/configuration-and-networking.md`).

## Subnet

- **Delegated to `Microsoft.Web/hostingEnvironments`, empty**, and `addressPrefix` as a string (not `addressPrefixes`).
- **`/24` is recommended**, and needed to scale near the maximum (100 instances per plan, 200 across the ASE). Addresses go to: the five Azure reserves, 7–27 for supporting infrastructure, one per plan instance, one standby per 20 instances per OS/SKU combination, **double during scale up or down**, spare for platform upgrades, and for Windows containers **one per app per instance**. Running out blocks scale-out.
- Moving an ASE to another subnet takes a support ticket.

## Deploy (internal VIP)

```bicep
// Internal (ILB) App Service Environment v3 in a delegated, empty /24 subnet, with its private DNS zone
param location string = resourceGroup().location
param aseName string
param vnetName string
param subnetName string = 'snet-ase'

resource vnet 'Microsoft.Network/virtualNetworks@2026-01-01' existing = {
  name: vnetName
}

resource subnet 'Microsoft.Network/virtualNetworks/subnets@2026-01-01' existing = {
  parent: vnet
  name: subnetName // delegated to Microsoft.Web/hostingEnvironments, empty, /24 recommended
}

resource ase 'Microsoft.Web/hostingEnvironments@2025-03-01' = {
  name: aseName
  location: location
  kind: 'ASEV3'
  properties: {
    virtualNetwork: {
      id: subnet.id
    }
    internalLoadBalancingMode: 'Web, Publishing'
    zoneRedundant: true
  }
}

resource aseConfig 'Microsoft.Web/hostingEnvironments/configurations@2025-03-01' existing = {
  parent: ase
  name: 'networking'
}

resource zone 'Microsoft.Network/privateDnsZones@2024-06-01' = {
  name: '${aseName}.appserviceenvironment.net'
  location: 'global'
}

resource link 'Microsoft.Network/privateDnsZones/virtualNetworkLinks@2024-06-01' = {
  parent: zone
  name: 'link-${vnetName}'
  location: 'global'
  properties: {
    virtualNetwork: {
      id: vnet.id
    }
    registrationEnabled: false
  }
}

resource records 'Microsoft.Network/privateDnsZones/A@2024-06-01' = [for name in ['*', '@', '*.scm']: {
  parent: zone
  name: name
  properties: {
    ttl: 3600
    aRecords: [
      {
        ipv4Address: aseConfig.properties.internalInboundIpAddresses[0]
      }
    ]
  }
}]
```

- `internalLoadBalancingMode`: `Web, Publishing` puts HTTP(S) and FTP on an internal VIP in the subnet; `None` is an external ASE with a public VIP.
- **An internal ASE needs DNS**: the zone `<ase>.appserviceenvironment.net` with `*`, `@` and `*.scm` A records to the inbound IP, linked to every client VNet (or the same records on your DNS servers).
- `zoneRedundant` (where the region supports it) needs **at least two instances per plan**, and per-app scaling of one still leaves an app with a single replica. `dedicatedHostCount: 2` gives hardware isolation (Isolated v2 I1v2–I3v2 only). `upgradePreference`: `None` (default), `Early`, `Late` or `Manual`.

## Network rules

- **Inbound NSG:** at minimum allow `AzureLoadBalancer` → subnet on port **80** (internal health pings); usually `VirtualNetwork` → subnet on 80 and 443, plus your app and deployment ports. NSG changes can take **up to 14 days** to show, because of HTTP connection persistence.
- **Outbound:** route tables are unrestricted; you can force-tunnel through Azure Firewall as long as app dependencies (Entra ID, CRL endpoints, deployment sources) stay reachable. A NAT gateway on the subnet sets the egress address. ASE v3 has no networking dependencies on your VNet.
- **Outbound network segmentation** (apps joining other subnets for egress) must be enabled at creation; it can't be added later.

## SKUs

**Isolated v2** (I1v2–I6v2) is standard. **Isolated v4** (I1V4–I6V4 and memory-optimized I1mV4–I5mV4) uses Premium v4 hardware, runs in select regions and only on ASE deployments that support it: check with `az appservice list-locations --sku I1V4`. Iv4 capacity is constrained at launch; scale-outs can fail with quota or SKU-availability errors.

## Errors

| Message | Cause → fix |
|---|---|
| `Operation not supported for resource type Microsoft.Web/hostingEnvironments with kind ASEV3` (400) | `inboundNetworkDependenciesEndpoints` / `outboundNetworkDependenciesEndpoints` are ASE v2 APIs; v3 doesn't need them |
| Deployment rejects the subnet | Not delegated, not empty, or `addressPrefixes` used instead of `addressPrefix` |
| Apps resolve to nothing, or to public App Service | The `appserviceenvironment.net` zone or its VNet link is missing (internal ASE) |
| `The specified App Service Environment is in a subnet that is almost out of space. There are {0} remaining addresses. Once these addresses are exhausted, the App Service Environment will not be able to scale.` | Subnet sizing (see the list above). Plan scale-ups temporarily double addresses |
| `An App Service plan ({0}) creation has failed. This may be due to the App Service Environment operating at peak number of instances, or run out of subnet addresses.` | The 200-instance ASE limit or the subnet is exhausted; for Iv4, also regional capacity |
| `The specified App Service Environment is suspended. …` | Account shortfall or an invalid VNet configuration: fix the cause, then resume the ASE |
| Iv4 sizes missing or greyed out | The ASE's underlying deployment doesn't support Isolated v4 |

These messages come from the `AppServiceEnvironmentPlatformLogs` category: send it to Log Analytics with a diagnostic setting (`reference/monitor/diagnostic-settings-and-data-collection.md`).


---
<!-- cuppy -->
You are reading one file. The same content is free over MCP at https://cuppy.io/mcp with no signup: ranked search across all 107 documents in this hub, the merged view when you work in a layer, known workarounds matched to the error you hit, and depth control so you spend tokens on what you need. Start with the `_hello` tool. How to connect: https://cuppy.io/azure/ Something wrong in this document? Report it with the `session feedback` tool on the same endpoint.
<!-- /cuppy -->