Azure Functions Flex Consumption: When to Replace the Premium Plan in 2026

When Microsoft GA-ed Flex Consumption for Azure Functions in 2024, most enterprise teams did not react – the Premium plan was established, worked, and nobody wanted to change a working thing. In Q2 2026 at Christie's we ran a FinOps audit of serverless workloads and Flex emerged as the unexpected champion: 60% of our Premium Function Apps could move to Flex at half the cost without losing functionality.

This article is the breakdown of when and how to use Flex.

A Quick Comparison of the Three Plans

Three real game changers of Flex over Consumption:

1. VNet integration – Flex supports private endpoints, Consumption does not. For PE-only architectures (see the June 2026 article) this is the choice between "usable" and "unusable"
2. Pre-warmed instances – minimum 0, maximum 100. Cold start anxiety disappears
3. Per-second billing with GB-second – cheaper than Premium per-plan for burst workloads

Real Cost Example: a Christie's REST API

Workload: a REST API for an internal reporting tool. ~200 requests/hour during business hours, 0 outside. p95 latency requirement: 500 ms.

For this API we migrated to Flex with 1 always-ready instance – EUR 68/month savings vs Premium EP1, plus EUR 308 vs EP1 zone-redundant. Scaled across 15 similar APIs: ~EUR 1 000/month savings.

Flex Consumption in Bicep

// Server farm with the Flex SKU
resource flexPlan 'Microsoft.Web/serverfarms@2024-04-01' = {
  name: 'asp-api-flex-prod'
  location: location
  sku: {
    tier: 'FlexConsumption'
    name: 'FC1'
  }
  properties: {
    reserved: true  // Linux
  }
}
 
// Function App
resource flexFunc 'Microsoft.Web/sites@2024-04-01' = {
  name: 'func-api-flex-prod'
  location: location
  kind: 'functionapp,linux'
  identity: { type: 'SystemAssigned' }
  properties: {
    serverFarmId: flexPlan.id
    virtualNetworkSubnetId: functionSubnet.id
    vnetRouteAllEnabled: true
    publicNetworkAccess: 'Disabled'
    functionAppConfig: {
      deployment: {
        storage: {
          type: 'blobContainer'
          value: '${storageAccount.properties.primaryEndpoints.blob}deployments'
          authentication: {
            type: 'SystemAssignedIdentity'
          }
        }
      }
      scaleAndConcurrency: {
        instanceMemoryMB: 2048
        maximumInstanceCount: 100
        alwaysReady: [
          {
            name: 'http'
            instanceCount: 1   // 1 always-ready for HTTP triggers
          }
        ]
      }
      runtime: {
        name: 'dotnet-isolated'
        version: '9.0'
      }
    }
  }
}

Three important parameters versus Premium:

1. functionAppConfig.deployment.storage – Flex deploys packages into a Blob container via MSI, not the classic WEBSITE_RUN_FROM_PACKAGE SAS URL
2. scaleAndConcurrency.instanceMemoryMB – you have to pick a memory tier (2048, 4096); per-second billing scales accordingly
3. alwaysReady – per-trigger configuration (HTTP vs queue); a different count per trigger

Deployment via GitHub Actions

name: Deploy Flex Function
on:
  push:
    branches: [main]
 
permissions:
  id-token: write
  contents: read
 
jobs:
  deploy:
    runs-on: ubuntu-latest
    environment: production
    steps:
      - uses: actions/checkout@v4
 
      - uses: actions/setup-dotnet@v4
        with:
          dotnet-version: '9.0.x'
 
      - name: Build and package
        run: |
          dotnet publish src/Api.csproj -c Release -o output
          cd output
          zip -r ../app.zip .
 
      - uses: azure/login@v2
        with:
          client-id: ${{ secrets.AZURE_CLIENT_ID }}
          tenant-id: ${{ secrets.AZURE_TENANT_ID }}
          subscription-id: ${{ secrets.AZURE_SUBSCRIPTION_ID }}
 
      - name: Upload to Flex deployment container
        run: |
          az storage blob upload \
            --account-name "${{ vars.STORAGE_NAME }}" \
            --container-name "deployments" \
            --name "app-${{ github.sha }}.zip" \
            --file app.zip \
            --auth-mode login \
            --overwrite
 
      - name: Sync Flex Function App
        run: |
          az functionapp deployment source config-zip \
            --resource-group "${{ vars.RG_NAME }}" \
            --name "${{ vars.FUNC_NAME }}" \
            --src "https://${{ vars.STORAGE_NAME }}.blob.core.windows.net/deployments/app-${{ github.sha }}.zip" \
            --build-remote false

Heads up: Flex has no Kudu for file inspection and no SCM endpoint for the classic Zip Deploy. Deployment flows through Blob storage with MSI authentication. If you have a legacy CI/CD pipeline that relies on az functionapp deployment source config-zip with a SAS URL, you must adjust.

When NOT to Switch From Premium to Flex

Three scenarios where Premium remains the right call:

1. In-memory state / cache between requests – Flex pre-warm instances do not aggregate state perfectly; periodic shutdown drops memory. Premium with alwaysOn=true has persistent instances
2. Workloads with 24/7 fixed load – for steady 5+ instance load, Premium 3Y reserved comes out cheaper than Flex per-second
3. Deployment slots for blue/green – Flex has only 1 slot (production). If you do slot swaps, stay on Premium

Migration Playbook: Premium → Flex in One Sprint

At Christie's we did the migration per Function App like this:

1. Day 1 – new Flex Function App next to the existing one, deploy the same code, smoke test
2. Day 2 – point integration tests at Flex, performance comparison (p50, p95, p99 latency)
3. Day 3 – Front Door / APIM routes 10% of traffic to Flex, monitor for 24h
4. Day 4 – 50% of traffic, verify cost projection
5. Day 5 – 100% cutover, keep Premium for 7 days as rollback
6. Day +7 – delete the Premium plan

The key: deployment via blob storage with MSI requires deployment pipeline tweaks (~2 hours). Everything else is unchanged – same runtime, same code, same app settings.

Limits Worth Calling Out

For 95% of workloads the limits are irrelevant. Custom container support is the biggest miss – if you have a Function with a custom Docker image, Flex is not an option.

Conclusion

Flex Consumption is the most overlooked optimization in an Azure FinOps audit checklist in May 2026. For most Premium Function Apps it delivers identical functionality at 30–50% of the cost. Migration is a one-sprint affair; the deployment pipeline is the only thing that changes.

At Christie's and CostSentry.AI we saved hundreds of EUR per month by flipping 70% of our Premium Function Apps – with no compromise on latency or SLA.

If you are auditing your own serverless stack and want to identify Flex Consumption candidates, check out our cloud architecture services or reach out for a FinOps review.