Azure Functions Flex Consumption: VNet, Bicep und das Aus für Consumption

Kennst du das? Ein Kunde will „nur kurz” eine Function, die nachts Daten aus einem internen System zieht und in SharePoint oder Teams etwas auslöst. Dann kommt die Security-Abteilung und sagt: „Das Backend hängt in einem VNet. Da kommt nichts Öffentliches ran.”

Beim klassischen Consumption Plan war das Gespräch damit oft beendet. Virtual Network Integration? Nicht unterstützt. Also Premium Plan, also Grundkosten, also Diskussion mit dem Budget.

Genau diese Lücke schließt Flex Consumption. Und es gibt einen zweiten Grund, warum du dich jetzt damit beschäftigen solltest: Der alte Plan läuft aus. Hier steht, was Flex Consumption ist, was sich ändert, wie du es per Bicep aufsetzt und worauf du als Admin achten solltest.

Was ist Flex Consumption?

Flex Consumption ist ein Linux-basierter Hosting Plan für Azure Functions. Er baut auf dem Pay-per-Use-Modell des Consumption Plans auf und bringt privates Networking, wählbare Instanzgrößen und schnelles, großes Scale-out mit. Microsoft nennt ihn den empfohlenen Serverless-Plan für Azure Functions.

Kurz gesagt: Es bleibt Serverless, aber du bekommst Stellschrauben, die du vorher nur im Premium Plan hattest.

Warum du jetzt hinschauen solltest

Microsoft führt den klassischen Consumption Plan inzwischen offiziell als Legacy. Das Hosting unter Linux im Consumption Plan endet am 30. September 2028, und bis dahin gibt es dort keine neuen Features oder Sprachversionen mehr. Windows-Apps sind aktuell nicht betroffen.

Flex Consumption vs. Consumption

Feature	Flex Consumption	Consumption (Legacy)
Scale to zero	Ja	Ja
VNet-Integration (ausgehend)	Ja	Nein
Private Endpoints (eingehend)	Ja	Nein
Always-ready-Instanzen	Optional	Keine
Abrechnung	Ausführungszeit + Always ready	Nur Ausführungszeit
Max. Scale-out	1.000 pro Function-Gruppe (Quota beachten)	200 (Windows), 100 (Linux)
Max. Ausführungszeit	Keine feste Grenze (Standard 30 Min.)	10 Minuten
Apps pro Plan	1	100
Deployment Slots	Nein	Ja
Betriebssystem	Nur Linux	Windows (Linux läuft aus)

Zwei Zeilen sind besonders wichtig. Linux only heißt: Läuft deine bestehende App auf Windows, ist das kein Klick-und-fertig-Umzug. Und die Laufzeit: Im Consumption Plan ist nach spätestens 10 Minuten Schluss. Für längere Batch-Jobs ist Flex Consumption deutlich entspannter. Ein Limit bleibt aber in jedem Plan: HTTP-getriggerte Functions müssen innerhalb von 230 Sekunden antworten.

Die vier Dinge, die du verstehen musst

1. VNet-Integration

Deine Function kann jetzt auf Ressourcen zugreifen, die in einem Virtual Network abgeschottet sind: Storage, Key Vault, Datenbanken. Dafür muss der Resource Provider Microsoft.App in der Subscription registriert sein, und das Subnetz wird an Microsoft.App/environments delegiert. Das ist die Stolperfalle, wenn der Deploy zum ersten Mal scheitert. Zusätzlich sind private Endpoints für eingehenden Traffic möglich. Damit kannst du die Function auch von außen dichtmachen.

2. Instanzgrößen

Du wählst die Speichergröße pro Instanz:

• 512 MB (ca. 0,25 Kerne)
• 2.048 MB (ca. 1 Kern)
• 4.096 MB (ca. 2 Kerne)

Microsoft empfiehlt 2.048 MB als Standard für die meisten Szenarien, und du kannst die Größe jederzeit ändern. Fang also nicht mit 4 GB „zur Sicherheit” an. Das kostet nur.

3. Always ready gegen Cold Starts

Standardmäßig ist der Wert 0, die App skaliert also komplett auf null. Willst du keine Cold Starts, legst du Always-ready-Instanzen fest, pro Scale-Gruppe oder pro Function. Setzt du für die HTTP-Gruppe zwei Instanzen, laufen zwei dauerhaft und bearbeiten Anfragen zuerst. Danach skaliert die Plattform mit On-Demand-Instanzen weiter.

Das ändert die Abrechnung. Für Always-ready-Instanzen zahlst du die bereitgestellte Speichermenge auch im Leerlauf als Baseline, und für diese Instanzen gibt es keine Freikontingente. Deine On-Demand-Instanzen behalten ihre Freikontingente. Die aktuellen Preise stehen auf der Azure-Preisseite. Rechne das für deinen Fall durch, bevor du es aktivierst.

4. Per-Function-Scaling

Functions skalieren unabhängig voneinander, jeweils nach ihrer eigenen Last. Alle HTTP-Trigger skalieren gemeinsam als Gruppe, ebenso alle Blob-Trigger und alle Durable-Functions-Trigger. Alle anderen Functions skaliert die Plattform einzeln auf eigenen Instanzen. Du musst dafür nichts konfigurieren. Der Effekt: Ein Queue-Backlog zieht nicht deine HTTP-API mit in die Höhe.

Was sich beim Deployment ändert

Es gibt genau einen Weg: Du baust dein Projekt, zippst es und lädst das Paket in einen Blob-Storage-Container. Beim Start holt sich die App das Paket von dort. Standardmäßig ist das derselbe Storage Account, den die Function App ohnehin für Host-Metadaten nutzt. Du kannst aber einen anderen angeben und die Authentifizierung selbst wählen.

Rolling Updates für Deployments ohne Downtime gibt es, sie sind laut Doku aktuell aber in Public Preview. Deployment Slots werden dagegen nicht unterstützt. Wer sein Release-Konzept auf Slots gebaut hat, muss also umdenken.

Neu ist außerdem: Du kannst Azure-Files-Freigaben direkt mounten. Das ist praktisch für große Binaries oder Referenzdaten, die du nicht ins Deployment packen willst.

Flex Consumption per Bicep: Was geht, was nicht

Wenn du deine Azure-Ressourcen ohnehin als Code verwaltest, gute Nachricht: Flex Consumption lässt sich komplett per Bicep aufsetzen. Microsoft liefert dafür sogar einen offiziellen Quickstart mit Template. Die App verbindet sich darin über Managed Identities mit Entra ID zu den anderen Azure-Ressourcen. Genau so solltest du es auch machen.

Das Grundgerüst

Der Unterschied zum klassischen Consumption Plan steckt an zwei Stellen: der SKU des Plans und dem neuen Block functionAppConfig an der App. Alles, was du aus diesem Artikel kennst, also Instanzgröße, Always ready, Runtime und Deployment-Container, landet dort.

resource plan 'Microsoft.Web/serverfarms@2024-04-01' = {
  name: 'plan-${resourceToken}'
  location: location
  kind: 'functionapp'
  sku: {
    tier: 'FlexConsumption'
    name: 'FC1'
  }
  properties: {
    reserved: true // Linux
  }
}

resource functionApp 'Microsoft.Web/sites@2024-04-01' = {
  name: appName
  location: location
  kind: 'functionapp,linux'
  identity: {
    type: 'UserAssigned'
    userAssignedIdentities: {
      '${uami.id}': {}
    }
  }
  properties: {
    serverFarmId: plan.id
    httpsOnly: true
    virtualNetworkSubnetId: appSubnet.id
    functionAppConfig: {
      deployment: {
        storage: {
          type: 'blobContainer'
          value: '${storage.properties.primaryEndpoints.blob}${containerName}'
          authentication: {
            type: 'UserAssignedIdentity'
            userAssignedIdentityResourceId: uami.id
          }
        }
      }
      scaleAndConcurrency: {
        instanceMemoryMB: 2048
        maximumInstanceCount: 100
        alwaysReady: [
          {
            name: 'http'
            instanceCount: 1
          }
        ]
      }
      runtime: {
        name: 'powerShell'
        version: '7.4'
      }
    }
  }
}

Fürs VNet brauchst du zusätzlich ein Subnetz mit der richtigen Delegation:

{
  name: 'snet-func'
  properties: {
    addressPrefix: '10.0.2.0/24'
    delegations: [
      {
        name: 'flex'
        properties: {
          serviceName: 'Microsoft.App/environments'
        }
      }
    ]
  }
}

Was du später per Bicep ändern kannst

Einstellung	Per Redeploy änderbar?
Instanzgröße (instanceMemoryMB)	Ja, jederzeit
Maximale Instanzzahl	Ja
Always-ready-Instanzen	Ja, pro Gruppe oder Function
Runtime-Version	Ja
VNet-Integration	Ja, auch nachträglich
Deployment-Container und Authentifizierung	Ja
Wechsel von Consumption zu Flex	Nein, nur als neue App
Wechsel von Flex zurück	Nein
Dein Code	Nicht über Bicep, separat als Zip-Paket

Drei Stolperfallen beim Umbau

Erstens, das Template blind übernehmen. Microsofts Quickstart-Template lässt nur 2.048 und 4.096 MB zu und verlangt mindestens 40 als maximale Instanzzahl. Das sind Vorgaben des Templates, nicht der Plattform. Die erlaubt auch 512 MB und ein Maximum von 1. Pass die Parameter an deinen Fall an.

Zweitens, alte App-Settings mitschleppen. Im Flex Consumption Plan sind viele klassische App-Settings und Site-Properties veraltet oder verschoben, und Microsoft rät ausdrücklich davon ab, sie bei automatisierten Deployments zu setzen. Die Runtime gehört zum Beispiel jetzt in functionAppConfig.runtime. Wer sein altes Consumption-Template kopiert und nur die SKU tauscht, baut sich Fehler ein.

Drittens, „Umhängen” statt Neubau. Du kannst eine bestehende Consumption-App nicht per Bicep auf einen Flex-Plan setzen. Plan die Migration deshalb als Parallelbetrieb: neue App per Bicep aufbauen, Code deployen, testen, Traffic umstellen, alte App abschalten.

Die Stolpersteine

Bevor du migrierst, geh diese Liste durch:

• Kein In-Place-Umzug. Du legst eine neue Function App im Flex Consumption Plan an und deployst deinen Code neu.
• Eine App pro Plan. Du kannst nicht mehrere Apps in einem Flex-Plan bündeln.
• Nur Linux. Windows-Workloads bleiben draußen.
• PowerShell ohne Managed Dependencies. Module musst du mit dem App-Content hochladen. Für alle, die Graph- oder PnP-Module nutzen, ist das der wichtigste Punkt auf der Liste.
• C# nur im Isolated Worker Model. Das In-Process-Modell wird nicht unterstützt.
• Keine Zeitzonen-Settings. WEBSITE_TIME_ZONE und TZ werden aktuell nicht unterstützt. Dein nächtlicher Timer-Trigger läuft also in UTC. Plan die Zeitumstellung ein.
• Blob-Trigger nur über Event Grid. Der klassische Polling-Trigger geht nicht.
• Start-Timeout von 30 Sekunden. Braucht deine App länger, siehst du gRPC-bezogene Timeout-Fehler, und der Wert ist aktuell nicht konfigurierbar.
• Durable Functions: Unterstützt sind nur Azure Storage und der Durable Task Scheduler als Provider.
• Regionen. Nicht jede Azure-Region wird unterstützt. Prüf das vorab.

Wer vom Linux Consumption Plan kommt, findet bei Microsoft eine Schritt-für-Schritt-Migrationsanleitung. Lies sie, bevor du loslegst. Die Pläne unterscheiden sich in mehr Details, als der erste Blick vermuten lässt.

Wann lohnt sich Flex Consumption?

Ja, wenn:

• deine Function auf Ressourcen im VNet zugreifen muss
• du heute im Linux Consumption Plan unterwegs bist (du musst sowieso umziehen)
• du Cold Starts gezielt vermeiden willst, ohne gleich Premium zu zahlen
• Jobs länger als 10 Minuten laufen oder Lastspitzen stark schwanken

Nein (oder erst prüfen), wenn:

• deine Workloads unter Windows laufen
• du auf Deployment Slots angewiesen bist
• du mehrere Apps in einem Plan betreiben willst
• du PowerShell mit Managed Dependencies nutzt und den Umbau noch nicht eingeplant hast

Hast du Flex Consumption schon im Einsatz oder hängst du noch am klassischen Consumption Plan? Schreib mir auf LinkedIn, was bei dir der Blocker ist.