Azure App Service – Consider Upgrading Standard Service Plans to Premium v3

The Azure App Service Standard to Premium v3 upgrade policy flags App Service plans running on a Standard tier SKU (S1, S2, or S3) and recommends the equivalent Premium v3 SKU instead. On Linux, a P1v3 plan costs about 18% less per instance than an S2 plan in East US, with more than twice the memory and five times the storage. Apply this policy to any azurerm_service_plan whose sku_name is S1, S2, or S3, especially when a plan runs several instances that Premium v3 can consolidate.

Why This Policy Matters

How It Helps Reduce Cloud Costs

Azure App Service bills per instance of an App Service plan, so the plan SKU and the instance count set the monthly cost. The Standard tier is an older generation with 1.75 GB of memory per core and 50 GB of storage per plan.

Premium v3 runs on newer hardware with faster processors and SSD storage. A Premium v3 instance gives 4 GB of memory per vCPU and 250 GB of storage, and Microsoft also offers memory-optimized Premium v3 sizes.

That extra memory per instance is where most of the saving comes from. Memory-bound apps on Standard often scale out to more instances than they need for CPU, and Premium v3 lets the same workload run on fewer instances.

Premium v3 also qualifies for Azure reservations and the Azure savings plan for compute. The Standard tier does not, which leaves Standard plans locked to pay-as-you-go pricing.

This is a common source of wasted spend in App Service estates built several years ago. The plan SKU was chosen once and never revisited.

Potential Savings

The Azure App Service Standard to Premium v3 upgrade saves the most on Linux plans, where Premium v3 costs less per instance than the Standard SKU it replaces. The figures below are East US list prices from the Azure Retail Prices API at the time of writing, based on 730 hours per month.

On Linux, moving one S2 instance to P1v3 cuts its cost by about 18%. A one-year reservation brings Linux P1v3 to about $74 per month, roughly 47% below S2 pay-as-you-go.

Windows works differently. A Windows P1v3 instance costs about 57% more than a Windows S2 instance, so Windows plans save money only when Premium v3 lets the team run fewer instances or buy reserved capacity.

Prices vary by region, operating system, and commitment type. Confirm current list prices for your region 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 the Standard tier, and the corrected Premium v3 configuration.

Non-compliant configuration: Linux App Service plan on Standard S2

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            = "S2"
  worker_count        = 4
}

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            = "S2"
  worker_count        = 4
}

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            = "S2"
  worker_count        = 4
}

Four S2 instances give 8 cores and 14 GB of memory for about $555 per month on Linux in East US. This configuration pays for older hardware and scales out to reach memory it could get on fewer, larger instances.

Compliant configuration: Linux App Service plan on Premium v3 P1v3

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            = "P1v3"
  worker_count        = 2
}

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            = "P1v3"
  worker_count        = 2
}

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            = "P1v3"
  worker_count        = 2
}

Two P1v3 instances give 16 GB of memory for about $226 per month, about 59% less than the S2 plan. The vCPU count drops from 8 to 4, so reduce worker_count only after load testing confirms the app is memory-bound or runs well on faster cores.

If the codebase still uses the legacy azurerm_app_service_plan resource, the same change sits in the sku block. That resource is deprecated in the azurerm provider, so plan a move to azurerm_service_plan.

resource "azurerm_app_service_plan" "api" {
  name                = "plan-api-prod"
  resource_group_name = azurerm_resource_group.api.name
  location            = azurerm_resource_group.api.location
  kind                = "Linux"
  reserved            = true

  sku {
    tier = "PremiumV3"
    size = "P1v3"
  }
}

resource "azurerm_app_service_plan" "api" {
  name                = "plan-api-prod"
  resource_group_name = azurerm_resource_group.api.name
  location            = azurerm_resource_group.api.location
  kind                = "Linux"
  reserved            = true

  sku {
    tier = "PremiumV3"
    size = "P1v3"
  }
}

resource "azurerm_app_service_plan" "api" {
  name                = "plan-api-prod"
  resource_group_name = azurerm_resource_group.api.name
  location            = azurerm_resource_group.api.location
  kind                = "Linux"
  reserved            = true

  sku {
    tier = "PremiumV3"
    size = "P1v3"
  }
}

Use this mapping to pick the Premium v3 SKU for each Standard SKU.

Step-by-Step Fix Instructions

1. Search Terraform for sku_name values of S1, S2, or S3 on azurerm_service_plan, and for tier = "Standard" in the sku block of the legacy azurerm_app_service_plan.

2. Check shared modules, .tfvars files, and variable defaults. App Service plan SKUs often sit in a variable "sku_name" default rather than in the resource block.

3. Record the operating system (os_type) and current worker_count for each Standard plan. Linux plans save money per instance; Windows plans save only through consolidation or reservations.

4. Pull CPU and memory metrics for the plan in Azure Monitor for the past 30 days. Memory-bound plans are the best candidates for running fewer Premium v3 instances.

5. Confirm Premium v3 is available for the app's region and deployment with az appservice list-locations --sku P1V3 (add --linux-workers-enabled for Linux). If it is not available, the app must be redeployed to a new App Service plan.

6. Change sku_name to the matching Premium v3 SKU and run terraform plan. Confirm the plan shows an in-place update to sku_name, not a replacement of the App Service plan.

7. Apply the change, keep worker_count the same at first, and watch response times and memory usage.

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

Best Practices

• Default shared Terraform modules for Azure App Service to a Premium v3 sku_name, and add a validation block that rejects Standard tier SKUs.

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

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

• Use autoscale rules on Premium v3 plans so the reduced baseline worker_count can still absorb traffic peaks.

• This policy is aimed at production and steady-state workloads. A Windows plan running a single small instance with no reservation will usually cost more on Premium v3, not less.

Tools and Scripts

How does Infracost detect Standard tier App Service plans automatically?

The Azure App Service Standard to Premium v3 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 Standard tier 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 S2 plan before it merges, not on next month's invoice.

Infracost also scans connected repositories for Standard tier 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 Standard tier SKUs in a Terraform codebase:

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

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

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

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

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

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

az appservice plan list \
  --query "[?sku.tier=='Standard'].{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 scaling up in the Azure portal. Otherwise the next terraform apply sets the Standard SKU again.

Examples of Impact

Savings from the Azure App Service Standard to Premium v3 upgrade come mostly from instance consolidation, not from the per-instance price change alone.

Illustrative example: a memory-bound Linux API. A platform team runs a Linux API on four S2 instances because each instance runs out of memory under load, not CPU. Moving to two P1v3 instances gives more total memory and cuts the plan from about $6,660 to about $2,720 per year at East US list prices.

Illustrative example: a Windows plan with a reservation. A DevOps team runs a memory-bound Windows .NET app on two S2 instances. Moving to one P1v3 instance on a three-year reservation brings the monthly cost to about $141, against about $292 for the two S2 instances on pay-as-you-go.

(These are illustrative scenarios based on list prices, not specific customer accounts.)

Considerations and Caveats

The Azure App Service Standard to Premium v3 upgrade lowers per-instance cost on Linux, but on Windows the saving depends on consolidation or reservations.

• Windows pricing. Premium v3 costs more per instance than Standard on Windows. The upgrade only reduces Windows cost when it lowers the instance count or qualifies the plan for reservation pricing.

• Availability. Premium v3 is not available on every App Service deployment. Apps on an older deployment may need to move to a new App Service plan, which can change outbound IP addresses.

• Fewer cores after consolidation. Running fewer Premium v3 instances can lower the total vCPU count. CPU-bound apps may need the same instance count, which still saves money on Linux.

• Reservation commitments. Azure reservations for Premium v3 lock in a one-year or three-year term. Buy them after the target instance count is stable.

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

Related Policies and Concepts

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

• Azure App Service - consider upgrading Isolated service plans to v2: a Compute-group policy that moves App Service Environment workloads to Isolated v2 and removes the stamp fee.

• App Service - consider using latest TLS version: a related Azure App Service policy that covers 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 Standard to Premium v3 upgrade policy is supported in Infracost and available in the free trial. Infracost flags App Service plans using a Standard tier SKU in pull requests, so the team can change the SKU before merge.

Can this policy be customized?

Yes. Teams can adjust how the Azure App Service Standard to Premium v3 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 Standard tier App Service plan in the pull request. Choosing the Premium v3 SKU and the new instance count depends on the workload's CPU and memory profile, so the team makes that change.

Is this policy cloud-agnostic?

No. The Azure App Service Standard to Premium v3 upgrade policy targets Azure App Service plans through the azurerm Terraform provider. Other clouds have their own managed app platforms, with different resource names and pricing.

Is Premium v3 cheaper than Standard on Windows App Service plans?

Not per instance. A Windows P1v3 instance costs more than a Windows S2 instance at list price, so Windows App Service plans save money on Premium v3 only by running fewer instances or by buying reserved capacity.

How often should I review Azure App Service plan tiers?

Teams running Infracost in CI/CD get a check on every pull request that touches an Azure App Service plan. For existing App Service plans, a quarterly review of SKU, instance count, and memory usage is a reasonable cadence.