Azure-Functions- und App-Service-Preise

Azure Functions Kosten hängen vom Hostingplan ab: Consumption und Flex Consumption berechnen Ausführungen und Gigabyte-Sekunden aktiver Instanzen, der Premium-Plan vCPU-Stunden und GiB-Stunden bereitgestellter Instanzen, und ein Dedicated-Plan ist ein App-Service-Plan, der je Instanz und Stunde kostet, ob darin Funktionen laufen oder nicht. Auf der Rechnung dominieren in den meisten Teams nicht die Ausführungen, sondern die Instanzen, die ohne Last weiterlaufen: Always-Ready-Instanzen, die Mindestinstanz des Premium-Plans und App-Service-Pläne, in denen nur noch eine kleine App steckt.

Preisdimensionen

Der Consumption-Plan ist laut Microsoft ein Legacy-Plan: Für neue serverlose Apps empfiehlt Microsoft Flex Consumption, Linux-Apps im Consumption-Plan sind bereits zurückgezogen, und das Linux-Hosting in diesem Plan endet am 2028-09-30. Flex Consumption rechnet nicht den gemessenen, sondern den eingestellten Arbeitsspeicher ab: Wer die Instanzgröße 2.048 MB wählt, zahlt 2 GB je Sekunde aktiver Ausführung, auch wenn der Code weniger braucht; die 272 MB Puffer der Plattform werden nicht berechnet. Im On-Demand-Modus gibt es je Monat ein Freikontingent an GB-Sekunden und Ausführungen; Always-Ready-Instanzen haben keines. Die Leerlaufzeit zwischen Ausführungen kostet im On-Demand-Modus nichts, weil nur aktive Zeit zählt.

Der Premium-Plan hat keinen Ausführungspreis. Er berechnet die zugeteilten Instanzen nach vCPU und Arbeitsspeicher in den Größen EP1 (1 vCPU, 3,5 GB), EP2 (2 vCPU, 7 GB) und EP3 (4 vCPU, 14 GB), und zwar für jede Instanz, solange sie zugeteilt ist: Die Mindestinstanzen des Plans ergeben sich aus der höchsten Always-Ready-Einstellung seiner Apps, und die vorgewärmte Instanz wird berechnet, sobald sie bereitgestellt ist. Mehrere Function Apps teilen sich die Instanzen eines Premium-Plans.

Ein Dedicated-Plan ist ein gewöhnlicher App-Service-Plan. In den Stufen Basic und höher berechnet Azure jede VM-Instanz des Plans, unabhängig davon, wie viele Apps und Slots darauf laufen; im Shared-Plan wird jede App für ihr CPU-Kontingent berechnet, und der Free-Plan kostet nichts. Functions unterstützt Free und Shared nicht, und ein Plan ohne Always On lässt die Functions-Laufzeit nach wenigen Minuten einschlafen. Die Logik aller Anbieter beschreibt Serverlose Funktionen; Container Apps ist der fünfte Hostingweg für Functions, abgerechnet nach den Regeln von Container Apps.

So erscheint es in den Abrechnungsdaten

Im Kostenexport steht Functions unter MeterCategory Functions. MeterSubCategory nennt den Plan: Functions für den Consumption-Plan mit den Zählern Standard Execution Time je 1 GB Second und Standard Total Executions je 10; Flex Consumption mit On Demand Execution Time, On Demand Total Executions, Always Ready Baseline, Always Ready Execution Time und Always Ready Total Executions; Premium Functions mit Premium vCPU Duration je 1 Hour und Premium Memory Duration je 1 GiB Hour. Die Freikontingente erscheinen als Zeilen mit Preis 0 und gefüllter Quantity, erst die Menge über dem Kontingent trägt einen Preis. ConsumedService ist Microsoft.Web, und ResourceId endet auf sites/ und dem Namen der Function App; beim Premium- und beim Dedicated-Plan zeigt die Zeile auf serverfarms/ und den Plan, nicht auf die App.

Ein Dedicated-Plan steht unter MeterCategory Azure App Service mit MeterSubCategory wie Azure App Service Premium v3 Plan - Linux und MeterName wie P1 v3 App je 1 Hour; Windows-Pläne führen kein Linux im Namen. Static Web Apps stehen unter derselben Kategorie mit MeterSubCategory Static Web Apps und den Zählern Standard App je 1/Month sowie Standard Bandwidth Usage je 1 GB, von denen die ersten 100 GB zum Preis 0 stehen. Das Speicherkonto der Function App und die Telemetrie in Application Insights stehen unter Storage und Log Analytics, nicht bei Functions. Den Aufbau des Exports beschreibt Azure-Kostenexporte.

Im FOCUS-Export werden alle diese Zeilen zu ChargeCategory Usage mit PricingCategory Standard, bei reservierten App-Service-Plänen Committed; MeterName landet in SkuMeter, und ServiceName leitet Microsoft aus ConsumedService und Ressourcentyp ab, sodass Function Apps, Web Apps und App-Service-Pläne über den Ressourcentyp zu trennen sind (FOCUS-Spalten).

Stellhebel

Konfiguration: In Flex Consumption bestimmt die Instanzgröße den Preis je Sekunde, und die Parallelität je Instanz bestimmt, wie viele Instanzen für eine Last laufen; eine I/O-lastige Funktion mit hoher Parallelität braucht eine Instanz, wo eine CPU-lastige mit Parallelität 1 zehn braucht. Always-Ready-Instanzen lohnen sich nur, wo der Kaltstart messbar schadet, weil sie ohne Freikontingent rund um die Uhr Sockelkosten erzeugen. Im Premium-Plan sind die Mindestinstanzen und die Größe der Hebel; im App-Service-Plan die Stufe, die Instanzzahl und die Frage, ob die Apps eines Plans zusammengelegt werden können (Rightsizing). Autoscale-Regeln und Zeitpläne für Pläne ohne Nachtlast beschreibt Zeitpläne und Auto-Scaling.

Kaufoption: Für Premium v3 und Isolated v2 App-Service-Pläne gibt es Reservierungen, für Premium-Functions-Pläne und App-Service-Pläne den Savings Plan für Compute; für Consumption und Flex Consumption gibt es kein Commitment, dort senken nur Instanzgröße und Laufzeit den Preis (Commitment-Strategie).

Architektur: Serverless im On-Demand-Modus ist für sporadische Last die günstigste Form, weil Leerlauf nichts kostet; gleichmäßige Dauerlast ist im Premium-Plan oder in einem geteilten App-Service-Plan günstiger, weil der Ausführungspreis entfällt. Durable Functions berechnen Wartezeiten in Orchestrierungen nicht, lange synchrone Wartezeiten dagegen voll. Viele kleine Apps gehören in einen Plan, nicht in viele (Architekturentscheidungen und Kosten).

Wo es schiefgeht

• Der Plan läuft, die App nicht. Ein App-Service-Plan kostet seine Instanzen auch dann, wenn alle Apps darin gelöscht oder gestoppt sind. Suchen Sie serverfarms-Ressourcen ohne laufende sites (ungenutzte und verwaiste Ressourcen).
• Premium statt Flex gewählt. Ein Plan mit SKU P1v2 oder P1v3 ist ein Dedicated-Plan ohne elastische Skalierung, kein Premium-Plan für Functions; der heißt EP1 bis EP3. Die Zeilen stehen unter Azure App Service, nicht unter Functions.
• Always Ready ohne Last. Always-Ready-Instanzen erzeugen in Flex Consumption einen Sockel in GB-Sekunden rund um die Uhr, ohne Freikontingent. Prüfen Sie Always Ready Baseline gegen Always Ready Execution Time; ein großer Abstand heißt, dass die Instanzen meist warten.
• Die Mindestinstanz des Premium-Plans. Jeder Premium-Plan berechnet mindestens eine Instanz, auch ohne Ausführungen, und die Always-Ready-Einstellung der größten App setzt das Minimum für den ganzen Plan.
• Die Instanzgröße passt nicht zur Last. In Flex Consumption wird die eingestellte Größe berechnet, nicht der Verbrauch; eine 4.096-MB-Instanz für eine Funktion, die 300 MB braucht, kostet je Sekunde das Doppelte der 2.048-MB-Größe.
• Die Nebenkosten stehen woanders. Speicherkonto, Application Insights und Bandbreite werden getrennt berechnet; bei kleinen Apps übersteigt die Telemetrie in Log Analytics oft die Ausführungskosten.
• Linux-Consumption-Apps auf Zeit. Apps im Linux-Consumption-Plan erhalten keine neuen Sprachversionen mehr und müssen bis 2028-09-30 in Flex Consumption umziehen; ein Umzug erfordert eine neue Function App, weil eine In-Place-Migration nicht unterstützt wird.

Beispiel

Listenpreise der Azure Retail Prices API für Germany West Central, gelesen am 2026-10-21. In EUR: Der Premium-Plan kostet 0,1487 EUR je vCPU-Stunde und 0,0106 EUR je GiB-Stunde, eine EP1-Instanz mit 1 vCPU und 3,5 GB also 0,1858 EUR je Stunde. Ein App-Service-Plan kostet auf Linux 0,0159 EUR je Stunde für B1, 0,0836 EUR für S1, 0,0783 EUR für P0v3 und 0,1566 EUR für P1 v3; auf Windows 0,066 EUR für B1 und 0,2974 EUR für P1 v3; der Shared-Plan 0,0114 EUR je App und Stunde, Free 0. Static Web Apps kosten im Standard-Plan 9,5037 EUR je App und Monat und 0,2112 EUR je GB Bandbreite über 100 GB. Die Zähler für Ausführungszeit und Ausführungen gibt die API in EUR nur mit vier Nachkommastellen aus, sodass sie als 0 erscheinen; dieselbe Abfrage in USD nennt für Flex Consumption 0,000037 USD je GB-Sekunde über 100.000 freien GB-Sekunden und 0,40 USD je Million Ausführungen über 250.000 freien, für Always Ready 0,000005 USD je GB-Sekunde Sockel und 0,000019 USD je aktive GB-Sekunde, und für den Consumption-Plan 0,000016 USD je GB-Sekunde über 400.000 freien und 0,20 USD je Million Ausführungen über einer Million freien. Die Zahlen zeigen, dass ein kleiner Linux-App-Service-Plan je Stunde weniger kostet als ein Zehntel einer EP1-Instanz und dass die Always-Ready-Sockelrate ein Siebtel des On-Demand-Preises je GB-Sekunde beträgt, dafür aber jede Sekunde anfällt.

Quellen

Gelesen am 2026-10-21. Preise: Azure Retail Prices API, Functions in Germany West Central in EUR, dieselbe Abfrage in USD, App-Service-Pläne in EUR, Static Web Apps in EUR, P1 v3 mit Reservierungs- und Savings-Plan-Preisen, Premium-Plan mit Savings-Plan-Preisen, Dokumentation der Azure Retail Prices API. Abrechnungsdaten: Felder der Kostendetails, Umwandlung von Cost-Management-Daten nach FOCUS, Verbrauchsbasierte Kosten schätzen. Dienst: Hostingoptionen von Azure Functions, Flex-Consumption-Plan, Premium-Plan, Dedicated-Plan, App-Service-Pläne, Hostingpläne für Static Web Apps.