The isolated tenant: App Service Environment, read as code.

When you deploy a normal Azure Web App, it lands on shared infrastructure: your app and thousands of strangers' apps run on the same pool of front ends and workers, walled off from each other by the platform. That is the right default — it is cheap, it scales, and the isolation is real. But some workloads carry a requirement that "walled off by the platform" does not satisfy: a regulator who wants the compute physically dedicated, a security posture where the app must have no public endpoint at all, or a network design where the app must sit inside a private VNet and be reachable only from there.

That is what an App Service Environment (ASE) is — the same App Service you already know, but deployed as a single-tenant stamp injected into a subnet of your own virtual network. Same apps, same deployment slots, same scaling — different tenancy and different network position. This lab is about understanding that difference precisely enough to know when to reach for it, and reading the exact Bicep that builds one.

You don't rent a floor. You buy the building.

Everything below is still hands-on — you clone nothing you have to pay for, you read a real template, and you compile it locally to prove it is valid. You just stop one step short of az deployment group create, on purpose.

Open Azure Cloud Shell (Bash) — az and the Bicep CLI are already installed and signed in, and reading and compiling a template costs nothing. Create the file below with a here-doc (or paste it into the Cloud Shell editor with code ase.bicep):

cat > ase.bicep <<'EOF'
// (paste the template from the next section here)
EOF

An isolated App Service is really four resources stacked in order: a network with a subnet handed over to the platform, the environment itself, an Isolated v2 plan placed inside it, and an app on that plan. Read it top to bottom — the comments are the lesson.

// ase.bicep — App Service Environment v3, read-only reference template.
// Illustrative: read it and compile it; this lab does not deploy it.

@description('Azure region for every resource.')
param location string = resourceGroup().location

@description('Globally unique name stem for the environment.')
param aseName string = 'campux-ase'

@description('Isolated v2 plan size. I1v2 is the smallest; I2v2 / I3v2 scale up.')
@allowed([ 'I1v2', 'I2v2', 'I3v2' ])
param planSku string = 'I1v2'

// 1 · The network. The ASE is injected into ONE subnet, which must be
//     delegated to the App Service platform — that delegation is what lets
//     Azure inject the environment's infrastructure. Nothing else may share
//     this subnet; the environment owns the whole /24.
resource vnet 'Microsoft.Network/virtualNetworks@2023-11-01' = {
  name: '${aseName}-vnet'
  location: location
  properties: {
    addressSpace: { addressPrefixes: [ '10.0.0.0/16' ] }
    subnets: [
      {
        name: 'ase-subnet'
        properties: {
          addressPrefix: '10.0.1.0/24'
          delegations: [
            {
              name: 'Microsoft.Web.hostingEnvironments'
              properties: { serviceName: 'Microsoft.Web/hostingEnvironments' }
            }
          ]
        }
      }
    ]
  }
}

// 2 · The environment. kind 'ASEV3' selects v3 (no stamp fee).
//     internalLoadBalancingMode 3 = fully internal (ILB): apps get PRIVATE
//     IPs only, reachable inside the VNet, never from the public internet.
//     Mode 0 would publish an external VIP instead. Private is the whole
//     point of most ASE deployments.
resource ase 'Microsoft.Web/hostingEnvironments@2024-04-01' = {
  name: aseName
  location: location
  kind: 'ASEV3'
  properties: {
    internalLoadBalancingMode: 3
    virtualNetwork: {
      id: resourceId('Microsoft.Network/virtualNetworks/subnets', vnet.name, 'ase-subnet')
    }
    zoneRedundant: false
  }
}

// 3 · An Isolated v2 App Service plan, placed INSIDE the environment via
//     hostingEnvironmentProfile. This is the only place Isolated v2 SKUs
//     run. You pay the Isolated v2 instance rate — and an empty ASE still
//     bills as one I1v2, which is why this template stays on the page.
resource plan 'Microsoft.Web/serverfarms@2024-04-01' = {
  name: '${aseName}-plan'
  location: location
  sku: {
    name: planSku
    tier: 'IsolatedV2'
  }
  properties: {
    hostingEnvironmentProfile: {
      id: ase.id
    }
  }
}

// 4 · A web app on that plan. Because the plan lives in an internal ASE,
//     this app has no public endpoint — it answers only inside the VNet.
resource site 'Microsoft.Web/sites@2024-04-01' = {
  name: '${aseName}-app'
  location: location
  properties: {
    serverFarmId: plan.id
    hostingEnvironmentProfile: {
      id: ase.id
    }
    httpsOnly: true
  }
}

output aseId string = ase.id
output appPrivateHostName string = site.properties.defaultHostName

You cannot cheaply deploy this, but you can compile it. az bicep build type-checks the whole template against Azure's resource schemas and emits the ARM JSON it would submit — entirely offline, no subscription touched, $0. It is the same check that runs before every real deploy, and it is how you prove a template is valid without spending a cent.

az bicep build --file ase.bicep --stdout | head -40
# or lint it for style + correctness warnings:
az bicep lint --file ase.bicep

The single most useful thing to carry out of this lab is an accurate mental model of ASE pricing, because it is where people get surprised.

Put together: an ASE is a standing monthly commitment, not a pennies-and-teardown experiment. That single fact is why regular App Service is the default answer and an ASE is the deliberate exception.

The interview-grade version of this knowledge is not "I can deploy an ASE." It is knowing when you would, and — more often — when you wouldn't.

You can explain the difference between multitenant App Service and a single-tenant App Service Environment, read the four resources that compose an ASE v3 in Bicep — the delegated subnet, the ASEV3 environment, the IsolatedV2 plan pinned by hostingEnvironmentProfile, and the app that inherits its privacy — and you compiled that template to valid ARM for free. Most usefully, you can say when an ASE is warranted and when a private endpoint on a regular Web App is the cheaper, correct answer. That last judgement is what separates someone who has heard of ASEs from someone who can be trusted to spend the budget on one.