Azure App Service – Consider Upgrading Isolated Service Plans to v2

The Azure App Service Isolated v2 upgrade policy flags App Service plans on an Isolated v1 SKU (I1, I2, or I3) and recommends the matching Isolated v2 SKU. Isolated v1 plans run in an App Service Environment v2, which charges a stamp fee of about $991 per month on top of instances, while App Service Environment v3 has none. Apply this policy to every azurerm_service_plan with an Isolated v1 sku_name, including plans in shared Terraform modules.

Why This Policy Matters

How It Helps Reduce Cloud Costs

Azure App Service Isolated plans run inside an App Service Environment, a single-tenant deployment of App Service in your own virtual network. The environment version decides how Isolated plans are billed.

App Service Environment v2 charges a stamp fee for the environment itself, plus a per-instance charge for each Isolated v1 instance. The stamp fee applies whether the environment runs one instance or forty.

App Service Environment v3 removes the stamp fee. You pay for the Isolated v2 instances you run, and an empty environment is billed as one Windows I1v2 instance.

Isolated v2 instances also carry more capacity per SKU. An I1v2 instance has 2 cores and 8 GB of memory, against 1 core and 3.5 GB on an I1 instance.

The stamp fee is the biggest line item for small Isolated estates. With one or two I2 instances, the App Service Environment v2 stamp fee costs more than the instances themselves.

Potential Savings

The Azure App Service Isolated v2 upgrade saves the most on small and mid-sized environments. The figures below are Microsoft's published 2023 Linux, East US, pay-as-you-go estimates from its App Service Environment v3 pricing guidance.

Moving that single I2 instance to I1v2 cuts the monthly cost by about 80%. Infracost's policy example, which prices I2 at $555 per month and I1v2 at $293 per month, shows a similar saving of about 81%.

Commitment pricing widens the gap. Microsoft lists a three-year reservation for Linux I1v2 at about $127 per month, and a three-year savings plan at about $155 per month.

Prices vary by region, operating system, and date. Confirm current list prices in the Azure Pricing Calculator before planning a migration.

Implementation Guide

Infrastructure-as-Code Example (Terraform)

The following examples show an Azure App Service plan on an Isolated v1 SKU, and the corrected Isolated v2 configuration in an App Service Environment v3.

Non-compliant configuration: Linux App Service plan on Isolated v1 I2 in App Service Environment v2

resource "azurerm_service_plan" "api" {
  name                       = "plan-api-prod"
  resource_group_name        = azurerm_resource_group.api.name
  location                   = azurerm_resource_group.api.location
  os_type                    = "Linux"
  sku_name                   = "I2"
  worker_count               = 2
  app_service_environment_id = var.ase_v2_id
}

resource "azurerm_service_plan" "api" {
  name                       = "plan-api-prod"
  resource_group_name        = azurerm_resource_group.api.name
  location                   = azurerm_resource_group.api.location
  os_type                    = "Linux"
  sku_name                   = "I2"
  worker_count               = 2
  app_service_environment_id = var.ase_v2_id
}

resource "azurerm_service_plan" "api" {
  name                       = "plan-api-prod"
  resource_group_name        = azurerm_resource_group.api.name
  location                   = azurerm_resource_group.api.location
  os_type                    = "Linux"
  sku_name                   = "I2"
  worker_count               = 2
  app_service_environment_id = var.ase_v2_id
}

This plan pays a per-instance charge for two I2 instances plus the App Service Environment v2 stamp fee. This configuration is a common source of wasted spend in Isolated estates built before App Service Environment v3 existed.

Compliant configuration: Linux App Service plan on Isolated v2 I1v2 in App Service Environment v3

resource "azurerm_app_service_environment_v3" "main" {
  name                         = "ase-prod-v3"
  resource_group_name          = azurerm_resource_group.api.name
  subnet_id                    = azurerm_subnet.ase.id
  internal_load_balancing_mode = "Web, Publishing"
}

resource "azurerm_service_plan" "api" {
  name                       = "plan-api-prod"
  resource_group_name        = azurerm_resource_group.api.name
  location                   = azurerm_resource_group.api.location
  os_type                    = "Linux"
  sku_name                   = "I1v2"
  worker_count               = 2
  app_service_environment_id = azurerm_app_service_environment_v3.main.id
}

resource "azurerm_app_service_environment_v3" "main" {
  name                         = "ase-prod-v3"
  resource_group_name          = azurerm_resource_group.api.name
  subnet_id                    = azurerm_subnet.ase.id
  internal_load_balancing_mode = "Web, Publishing"
}

resource "azurerm_service_plan" "api" {
  name                       = "plan-api-prod"
  resource_group_name        = azurerm_resource_group.api.name
  location                   = azurerm_resource_group.api.location
  os_type                    = "Linux"
  sku_name                   = "I1v2"
  worker_count               = 2
  app_service_environment_id = azurerm_app_service_environment_v3.main.id
}

resource "azurerm_app_service_environment_v3" "main" {
  name                         = "ase-prod-v3"
  resource_group_name          = azurerm_resource_group.api.name
  subnet_id                    = azurerm_subnet.ase.id
  internal_load_balancing_mode = "Web, Publishing"
}

resource "azurerm_service_plan" "api" {
  name                       = "plan-api-prod"
  resource_group_name        = azurerm_resource_group.api.name
  location                   = azurerm_resource_group.api.location
  os_type                    = "Linux"
  sku_name                   = "I1v2"
  worker_count               = 2
  app_service_environment_id = azurerm_app_service_environment_v3.main.id
}

The App Service plan now runs in an App Service Environment v3 with no stamp fee. Each I1v2 instance keeps the 2 cores of an I2 and adds 1 GB of memory.

The subnet for azurerm_app_service_environment_v3 must be /24 or larger and delegated to Microsoft.Web/hostingEnvironments. Changing subnet_id or internal_load_balancing_mode on an existing App Service Environment v3 forces a new resource, so set both deliberately.

If the codebase still uses the legacy azurerm_app_service_plan resource, the same change sits in the sku block: tier = "Isolated" with size = "I2" becomes tier = "IsolatedV2" with size = "I1v2". Plan a move to azurerm_service_plan at the same time.

Use this mapping to pick the Isolated v2 SKU for each Isolated v1 SKU.

Step-by-Step Fix Instructions

1. Search Terraform for sku_name values of I1, I2, or I3 on azurerm_service_plan, and for tier = "Isolated" in the sku block of the legacy azurerm_app_service_plan.

2. Check shared modules, .tfvars files, and variable defaults. Isolated SKUs and App Service Environment IDs often sit in module inputs rather than in the resource block.

3. Record the os_type, worker_count, and App Service Environment for each Isolated v1 plan.

4. Create an azurerm_app_service_environment_v3 in a delegated subnet, or confirm one already exists for the target virtual network.

5. Change sku_name to the mapped Isolated v2 SKU and point app_service_environment_id at the App Service Environment v3.

6. Run terraform plan and read whether it shows an in-place update or a replacement of the App Service plan. A replacement means apps must be redeployed into the new plan, so schedule it with the app owners.

7. Apply the change with the same worker_count, then watch response times, CPU, and memory in Azure Monitor.

8. Reduce worker_count in a later change only if metrics show headroom, then add Infracost to CI/CD so new Isolated v1 plans get flagged in pull requests before they merge.

Best Practices

• Default shared Terraform modules for App Service Environments to azurerm_app_service_environment_v3, and add a validation block that rejects I1, I2, and I3 values for sku_name.

• Move the SKU first and reduce the instance count in a separate change. This isolates any performance change to one variable at a time.

• Use a memory-optimized SKU such as I1mv2 when an app is memory-bound, rather than adding instances for memory alone.

• Buy reservations or an Azure savings plan for compute only after the Isolated v2 instance count has been stable for a few weeks.

• Delete any App Service Environment v3 that no longer hosts App Service plans. An empty App Service Environment v3 still bills as one Windows I1v2 instance.

Tools and Scripts

How does Infracost detect Isolated v1 App Service plans automatically?

The Azure App Service Isolated v2 upgrade policy is available in Infracost, including in the free trial. When Infracost runs in CI/CD, it checks App Service plan resources in each pull request and flags Isolated v1 SKUs in the PR comment.

The same Infracost pull request comment shows the estimated monthly cost of the resources in the change. Reviewers see the cost of a new I2 plan before it merges, not on next month's invoice.

Infracost also scans connected repositories for Isolated v1 App Service plans already in code. Platform and FinOps teams can burn down that backlog over time and measure progress, tracking new issues prevented separately from existing issues fixed.

To find Isolated v1 SKUs in a Terraform codebase:

grep -rnE 'sku_name\s*=\s*"I[123]"' --include="*.tf" --include="*.tfvars"

grep -rnE 'sku_name\s*=\s*"I[123]"' --include="*.tf" --include="*.tfvars"

grep -rnE 'sku_name\s*=\s*"I[123]"' --include="*.tf" --include="*.tfvars"

To list Azure App Service plans still on the Isolated v1 tier with the Azure CLI:

az appservice plan list \
  --query "[?sku.tier=='Isolated'].{name:name, rg:resourceGroup, sku:sku.name, workers:sku.capacity}" \
  --output

az appservice plan list \
  --query "[?sku.tier=='Isolated'].{name:name, rg:resourceGroup, sku:sku.name, workers:sku.capacity}" \
  --output

az appservice plan list \
  --query "[?sku.tier=='Isolated'].{name:name, rg:resourceGroup, sku:sku.name, workers:sku.capacity}" \
  --output

If an App Service plan is managed by Terraform, change sku_name in code rather than in the Azure portal. Otherwise the next terraform apply tries to set the Isolated v1 SKU again.

Examples of Impact

Savings from the Azure App Service Isolated v2 upgrade depend mostly on how many instances share one stamp fee.

Illustrative example: a single internal API. A platform team runs one Linux I2 instance in an App Service Environment v2. Moving to one I1v2 instance in an App Service Environment v3 drops the monthly cost from about $1,407 to about $282 at Microsoft's East US estimates. That is about $13,500 per year.

Illustrative example: a two-instance line-of-business app. A DevOps team runs two Linux I2 instances. Moving to two I1v2 instances cuts the monthly cost from about $1,824 to about $564, a 69% saving, before any reservation discount.

(These are illustrative scenarios based on Microsoft's published list price estimates, not specific customer accounts.)

Considerations and Caveats

The Azure App Service Isolated v2 upgrade removes the stamp fee, but the percentage saving shrinks as the environment grows.

• Large Isolated v1 estates. Microsoft's own analysis shows that above roughly 13 I1 instances, a one-for-one move to I1v2 can cost more on pay-as-you-go. Large estates should consolidate onto fewer Isolated v2 instances or use reservations to save.

• Environment migration. Isolated v2 plans require an App Service Environment v3. App Service Environment v1 and v2 were retired on 31 August 2024, so any remaining Isolated v1 code references a retired platform.

• Network changes. A new App Service Environment v3 needs its own delegated subnet and can change inbound and outbound IP addresses. Update firewall rules and DNS before cutover.

• Dedicated hosts. An App Service Environment v3 on dedicated hosts bills for two hosts plus a per-vCore Isolated v2 rate, and supports only I1v2, I2v2, and I3v2.

• Provider-specific. This policy targets Azure App Service through the azurerm Terraform provider. AWS and Google Cloud use different isolated hosting models, resources, and pricing.

Related Policies and Concepts

• Azure App Service - consider upgrading Premium service plans to v3: the same generation upgrade for multi-tenant App Service plans on Premium v2.

• Azure App Service - consider upgrading Standard service plans to Premium v3: a Compute-group policy that moves Standard tier App Service plans to Premium v3 for better price per core.

• App Service - consider using latest TLS version: a related Azure App Service policy covering security configuration on the apps that run inside these plans.

• Azure Virtual Machines - consider upgrading DS series machines to Dv5: the equivalent generation upgrade for Azure Virtual Machines in the Compute group.

• "How to Enforce Cloud Cost Policies in Your CI/CD Pipeline": a planned Infracost resource article covering how to catch cost policy violations like this one at the pull request stage.

Frequently Asked Questions (FAQs)

Is this policy supported in Infracost?

Yes. The Azure App Service Isolated v2 upgrade policy is supported in Infracost and available in the free trial. Infracost flags App Service plans that use an Isolated v1 SKU (I1, I2, or I3) in pull requests, so the team can plan the move to Isolated v2 before the change merges.

Can this policy be customized?

Yes. Teams can adjust how the Azure App Service Isolated v2 upgrade policy applies in Infracost rather than relying on the default configuration, for example by limiting the check to specific repositories or projects.

Does Infracost automatically fix violations?

No. Infracost reports each Isolated v1 App Service plan in the pull request. Moving a plan to Isolated v2 requires an App Service Environment v3, so the platform team chooses the target SKU, instance count, and migration path and applies the change.

Is this policy cloud-agnostic?

No. The Azure App Service Isolated v2 upgrade policy targets Azure App Service plans that run in an App Service Environment, through the azurerm Terraform provider. Other clouds use different isolated hosting models, resources, and pricing.

Which Isolated v2 SKU replaces an I2 App Service plan?

I1v2 is the usual replacement for an I2 App Service plan. Both have 2 cores, and I1v2 has 8 GB of memory against 7 GB on I2. An I1 plan also maps to I1v2, and an I3 plan maps to I2v2.

Does an App Service Environment v3 charge a stamp fee?

No. App Service Environment v3 has no stamp fee, so you pay for the Isolated v2 instances you run. If an App Service Environment v3 has no instances deployed, Microsoft charges it as one Windows I1v2 instance.

Can Isolated v2 App Service plans use reserved pricing?

Yes. Isolated v2 App Service plans are eligible for Azure reservations and the Azure savings plan for compute. On App Service Environment v2, reservations applied only to the stamp fee, not to Isolated v1 instances.