Azure Functions-Hostingoptionen

Wenn Sie eine Funktions-App in Azure erstellen, müssen Sie einen Hostingplan für die App auswählen. Für Azure Functions gibt es drei grundlegende Hostingpläne: Verbrauchstarif, Premium-Tarif und Dedicated-Tarif (App Service). Alle Hostingpläne sind sowohl für Linux- als auch für Windows-VMs allgemein verfügbar.

Der von Ihnen gewählte Hostingplan bestimmt folgendes Verhalten:

  • Wie Ihre Funktions-App skaliert wird.
  • Die für jede Instanz der Funktions-App verfügbaren Ressourcen.
  • Die Unterstützung für erweiterte Funktionen wie Azure Virtual Network-Konnektivität

Dieser Artikel enthält einen ausführlichen Vergleich der verschiedenen Hostingpläne und Kubernetes-basiertem Hosting.

Hinweis

Wenn Sie Ihre Funktionen in einem Kubernetes-Cluster hosten möchten, sollten Sie einen Azure Arc-fähigen Kubernetes-Cluster verwenden. Hosting auf einem für Azure Arc aktivierten Kubernetes-Cluster befindet sich derzeit in der Vorschau. Weitere Informationen finden Sie unter App Service, Funktionen und Logic Apps in Azure Arc.

Übersicht über die Pläne

Im Folgenden finden Sie eine Zusammenfassung der Vorteile der drei wichtigsten Hostingpläne für Functions:

Planen Vorteile
Verbrauchsplan Skalieren Sie Ihre Computeressourcen automatisch, und zahlen Sie nur dann für diese Ressourcen, wenn Ihre Funktionen tatsächlich ausgeführt werden.

Im Verbrauchsplan werden Instanzen des Functions-Hosts basierend auf der Anzahl von eingehenden Ereignissen dynamisch hinzugefügt und entfernt.

✔ Standardhostingplan.
✔ Sie bezahlen nur, wenn Ihre Funktionen ausgeführt werden.
✔ Die Skalierung erfolgt automatisch – selbst in Zeiten hoher Last.
Premium-Plan In diesem Plan werden Ressourcen automatisch nach Bedarf skaliert. Nutze vorab aufgewärmte (also betriebsbereite) Worker, um Anwendungen nach einem Leerlauf ohne jede Verzögerung auszuführen. Profitiere von leistungsstärkeren Instanzen für die Ausführung, und stelle Verbindungen mit virtuellen Netzwerken her.

Ziehen Sie den Premium-Plan für Azure Functions in folgenden Situationen in Betracht:

✔ Ihre Funktions-Apps werden kontinuierlich oder nahezu kontinuierlich ausgeführt.
✔ Sie verfügen über eine hohe Anzahl kleiner Ausführungen und haben im Verbrauchstarif hohe Ausführungskosten, aber geringe Kosten für Gigabytesekunden.
✔ Sie benötigen weitere CPU- oder Arbeitsspeicheroptionen zusätzlich zu den vom Verbrauchsplan bereitgestellten.
✔ Ihr Code muss länger ausgeführt werden, als im Verbrauchsplan als maximal zulässige Ausführungsdauer angegeben ist.
✔ Sie benötigen Features, die im Rahmen des Verbrauchstarifs nicht zur Verfügung stehen, z. B. Konnektivität mit virtuellen Netzwerken.
✔ Sie möchten ein benutzerdefiniertes Linux-Image bereitstellen, auf dem Ihre Funktionen ausgeführt werden sollen.
Dedizierter Plan Führen Sie Ihre Funktionen in einem App Service-Plan zu den regulären Preisen dieses Plans aus.

Dieser Plan eignet sich am besten in zeitintensiven Szenarien, in denen Durable Functions nicht verwendet werden kann. Ziehen Sie einen App Service-Plan in folgenden Situationen in Betracht:

✔ Sie verfügen über nicht ausgelastete virtuelle Computer, auf denen bereits andere App Service-Instanzen ausgeführt werden.
✔ Sie benötigen vorhersagbare Skalierung und Kosten.

Die Vergleichstabellen in diesem Artikel enthalten auch die folgenden Hostingoptionen, die die größtmögliche Kontrolle und Isolation bereitstellen, in denen Sie Ihre Funktions-Apps ausführen können.

Hostingoption Details
ASE Die App Service-Umgebung (App Service Environment, ASE) ist ein App Service-Feature, das eine vollständig isolierte und dedizierte Umgebung zur sicheren Ausführung von App Service-Apps in großem Maßstab bereitstellt.

App Service-Umgebungen eignen sich ideal für Anwendungsworkloads mit folgenden Anforderungen:

✔ Sehr großer Umfang.
✔ Vollständige Computeisolation und sicherer Netzwerkzugriff
✔ Hohe Speicherauslastung
Kubernetes
(Direkt oder
Azure Arc)
Kubernetes bietet eine vollständig isolierte und dedizierte Umgebung, die auf der Kubernetes-Plattform aufsetzt.

Kubernetes eignet sich für Anwendungsworkloads mit folgenden Anforderungen:
✔ Benutzerdefinierte Hardwareanforderungen.
✔ Isolierung und sicherer Netzwerkzugriff.
✔ Möglichkeit zur Ausführung in Hybrid- oder Multicloudumgebungen.
✔ Parallele Ausführung mit vorhandenen Kubernetes-Anwendungen und -Diensten.

In den verbleibenden Tabellen in diesem Artikel werden die verschiedenen Features und Verhaltensweisen der Pläne verglichen. Einen Kostenvergleich zwischen dynamischen Hostingplänen (Verbrauch und Premium) finden Sie auf der Seite Azure Functions – Preise. Die Preise für die verschiedenen Optionen bei einem dedizierten Plan finden Sie auf der Seite App Service – Preise.

Betriebssystem/Runtime

In der folgenden Tabelle werden die in den einzelnen Hostingplänen unterstützten Betriebssysteme und Programmiersprachen gezeigt.

Linux1,2
Nur Code
Windows, nur Code Linux1,2,3
Docker-Container
Verbrauchsplan C#
JavaScript
Java
Python
PowerShell Core
TypeScript
C#
JavaScript
Java
PowerShell Core
TypeScript
Keine Unterstützung
Premium-Plan C#
JavaScript
Java
Python
PowerShell Core
TypeScript
C#
JavaScript
Java
PowerShell Core
TypeScript
C#
JavaScript
Java
PowerShell Core
Python
TypeScript
Dedizierter Plan C#
JavaScript
Java
Python
TypeScript
C#
JavaScript
Java
PowerShell Core
TypeScript
C#
JavaScript
Java
PowerShell Core
Python
TypeScript
ASE C#
JavaScript
Java
Python
TypeScript
C#
JavaScript
Java
PowerShell Core
TypeScript
C#
JavaScript
Java
PowerShell Core
Python
TypeScript
Kubernetes (direkt) C#
JavaScript
Java
PowerShell Core
Python
TypeScript
Azure Arc (Vorschauversion) C#
JavaScript
Java
Python
TypeScript
C#
JavaScript
Java
PowerShell Core
Python
TypeScript

1 Linux ist das einzige unterstützte Betriebssystem für den Python-Runtimestapel.
2 Die PowerShell-Unterstützung unter Linux befindet sich derzeit in der Vorschau.
3 Linux ist das einzige unterstützte Betriebssystem für Docker-Container.

Funktions-App-Timeoutdauer

Die Timeoutdauer für Funktionen in einer Funktions-App wird durch die functionTimeout-Eigenschaft in der host.json-Projektdatei definiert. Diese Eigenschaft gilt speziell für Funktionsausführungen. Nachdem der Trigger die Ausführung der Funktion gestartet hat, muss die Funktion innerhalb der Timeoutdauer eine Rückgabe durchführen/reagieren. Weitere Informationen finden Sie unter Optimieren der Leistung und Zuverlässigkeit von Azure Functions.

Die folgende Tabelle zeigt die Standard- und Höchstwerte (in Minuten) für bestimmte Pläne:

Plan Standard Maximum1
Verbrauchsplan 5 10
Premium-Plan 302 Unbegrenzt
Dedizierter Plan 302 Unbegrenzt

1 Unabhängig von der Timeouteinstellung der Funktions-App stellen 230 Sekunden die längste Zeit dar, die einer über HTTP ausgelösten Funktion bis zur Reaktion auf eine Anfrage bleibt. Dies hat seinen Grund im Standard-Leerlauftimeout von Azure Load Balancer. Erwägen Sie für längere Verarbeitungszeiten die Verwendung des asynchronen Durable Functions-Musters oder stellen Sie die eigentliche Arbeit zurück, und geben Sie unmittelbar eine Antwort zurück.
2 Das Standardtimeout für Version 1.x der Functions-Runtime ist unbegrenzt.

Skalieren

In der folgenden Tabelle wird das Skalierungsverhalten der verschiedenen Hostingpläne verglichen.
Die maximalen Instanzen werden pro Funktions-App (Verbrauch) oder pro Plan (Premium/Dedicated) angezeigt, sofern nicht anders angegeben.

Planen Aufskalieren Maximale Anzahl Instanzen
Verbrauchsplan Ereignisgesteuert. Das Aufskalieren erfolgt automatisch – selbst in Zeiten hoher Lasten. Die Azure Functions-Infrastruktur skaliert CPU- und Arbeitsspeicherressourcen durch Hinzufügen zusätzlicher Instanzen des Functions-Hosts basierend auf der Anzahl der eingehenden Triggerereignisse. Windows: 200
Linux: 1001
Premium-Plan Ereignisgesteuert. Das Aufskalieren erfolgt automatisch – selbst in Zeiten hoher Lasten. Die Azure Functions-Infrastruktur skaliert CPU- und Arbeitsspeicherressourcen durch Hinzufügen zusätzlicher Instanzen des Functions-Hosts basierend auf der Anzahl der Ereignisse, für die Funktionen ausgelöst werden. Windows: 100
Linux: 20-402
Dedizierter Plan3 Manuelle Skalierung/Autoskalierung 10 – 20
ASE3 Manuelle Skalierung/Autoskalierung 100
Kubernetes Ereignisgesteuerte Autoskalierung für Kubernetes-Cluster über KEDA. Variiert je nach Cluster

1 Bei der horizontale Skalierung gibt es derzeit eine Grenze von 500 Instanzen pro Abonnement und Stunde für Linux-Anwendungen mit einem Verbrauchsplan.
2 In einigen Regionen können Linux-Apps mit einem Premium-Tarif auf 40 Instanzen skaliert werden. Weitere Informationen finden Sie im Artikel zum Premium-Plan.
3 Spezifische Grenzwerte für die verschiedenen Optionen des App Service-Plans finden Sie unter Grenzwerte für App Service-Pläne.

Kaltstartverhalten

Planen Details
Verbrauchsplan Apps im Leerlauf werden möglicherweise auf null skaliert, sodass bei einigen Anforderungen die Latenz beim Start steigen kann. Der Verbrauchsplan bietet einige Optimierungen, um die Kaltstartzeit zu verkürzen, beispielsweise den Abruf von vorab aufgewärmten (betriebsbereiten) Platzhalterfunktionen, für die bereits der Funktionshost und die Sprachprozesse ausgeführt werden.
Premium-Plan Ständig betriebsbereite (warme) Instanzen, um jegliche Kaltstarts zu vermeiden.
Dedizierter Plan In einem Dedicated-Plan kann der Functions-Host kontinuierlich ausgeführt werden, sodass ein Kaltstart kein Problem darstellt.
ASE In einem Dedicated-Plan kann der Functions-Host kontinuierlich ausgeführt werden, sodass ein Kaltstart kein Problem darstellt.
Kubernetes Abhängig von der KEDA-Konfiguration können Apps so konfiguriert werden, dass ein Kaltstart vermieden wird. Wenn sie für die Skalierung auf null konfiguriert sind, tritt bei neuen Ereignissen ein Kaltstart auf.

Diensteinschränkungen

Resource Verbrauchstarif Premium-Plan Dedizierter Plan ASE Kubernetes
Standardmäßige Timeoutdauer (in Minuten) 5 30 301 30 30
Maximale Timeoutdauer (in Minuten) 10 unbounded7 unbounded2 unbounded unbounded
Maximale Anzahl ausgehender Verbindungen (pro Instanz) 600 aktive (insgesamt 1.200) unbounded unbounded unbounded unbounded
Maximale Anforderungsgröße (MB)3 100 100 100 100 Abhängig von Cluster
Maximale Länge der Abfragezeichenfolge3 4096 4096 4096 4096 Abhängig von Cluster
Maximale Länge der Anforderungs-URL3 8192 8192 8192 8192 Abhängig von Cluster
ACU pro Instanz 100 210–840 100–840 210–2508 AKS – Preise
Maximaler Arbeitsspeicher (GB pro Instanz) 1.5 3,5–14 1,75–14 3,5–14 Jeder Knoten wird unterstützt.
Maximale Instanzanzahl (Windows/Linux) 200/100 100/20 variiert je nach SKU9 1009 Abhängig von Cluster
Funktions-Apps pro Plan 100 100 unbounded4 unbounded unbounded
App Service-Pläne 100 pro Region 100 pro Ressourcengruppe 100 pro Ressourcengruppe - -
Bereitstellungsslots pro App10 2 3 1–209 20
Speicher5 5 TB 250 GB 50–1.000 GB 1 TB
Benutzerdefinierte Domänen pro App 5006 500 500 500
benutzerdefinierte Domäne SSL-Unterstützung Unbegrenzte Anzahl von SNI SSL-Verbindungen inbegriffen Unbegrenzte Anzahl von SNI SSL-Verbindungen und 1 IP-SSL-Verbindung inbegriffen Unbegrenzte Anzahl von SNI SSL-Verbindungen und 1 IP-SSL-Verbindung inbegriffen Unbegrenzte Anzahl von SNI SSL-Verbindungen und 1 IP-SSL-Verbindung inbegriffen

1 Das Timeout für die Laufzeit von Functions 1.x in einem App Service-Plan ist standardmäßig unbegrenzt.
2 Hierfür muss der App Service-Plan auf Always On festgelegt werden. Die Bezahlung erfolgt zu den üblichen Raten.
3 Diese Grenzwerte werden auf dem Host festgelegt.
4 Die tatsächliche Anzahl der Funktions-Apps, die Sie hosten können, hängt von der Aktivität der Apps, der Größe der Computerinstanzen und der entsprechenden Ressourcenauslastung ab.
5 Der Speichergrenzwert entspricht der gesamten Inhaltsgröße aller Apps im gleichen App Service-Plan im temporären Speicher. Der Verbrauchsplan verwendet Azure Files zur temporären Speicherung.
6 Wenn Ihre Funktions-App unter einem Verbrauchsplan gehostet wird, wird nur die CNAME-Option unterstützt. Für Funktions-Apps unter einem Premium-Plan oder einem App Service-Plan können Sie eine benutzerdefinierte Domäne entweder mit einem CNAME- oder einem A-Eintrag zuordnen.
7 Garantiert für bis zu 60 Minuten
8 Worker sind Rollen, die Kunden-Apps hosten. Worker sind in drei festen Größen verfügbar: Eine vCPU/3,5 GB RAM; zwei vCPUs/7 GB RAM; vier vCPUs/14 GB RAM.
9 Ausführliche Informationen finden Sie unter App Service-Grenzwerte.
10 Einschließlich des Produktionsslots.

Einschränkungen für das Erstellen neuer Funktions-Apps in einer vorhandenen Ressourcengruppe

In einigen Fällen erhalten Sie bei dem Versuch, einen neuen Hostingplan für Ihre Funktions-App in einer vorhandenen Ressourcengruppe zu erstellen, möglicherweise einen der folgenden Fehler:

  • Der Tarif ist in dieser Ressourcengruppe unzulässig
  • <SKU_name>-Worker sind in der Ressourcengruppe <ressourcengruppen_name> nicht verfügbar.

Dies kann unter folgenden Umständen vorkommen:

  • Sie erstellen eine Funktions-App in einer vorhandenen Ressourcengruppe, die niemals eine andere Funktions-App oder Web-App enthalten hat.
  • Ihre neue Funktions-App wird in derselben Region wie die vorherige App erstellt.
  • Die vorherige App ist in irgendeiner Weise nicht mit Ihrer neuen App kompatibel. Dies kann zwischen SKUs, Betriebssystemen oder aufgrund anderer Features auf Plattformebene auftreten, z. B. Verfügbarkeitszonenunterstützung.

Der Grund hierfür liegt darin, wie die Funktions-App und Web-App-Pläne verschiedenen Ressourcenpools zugeordnet werden, wenn sie erstellt werden. Verschiedene SKUs erfordern verschiedene Sammlungen von Infrastrukturfunktionen. Wenn Sie eine App in einer Ressourcengruppe erstellen, wird diese Ressourcengruppe einem Ressourcenpool zugeordnet und zugewiesen. Wenn Sie versuchen, einen anderen Plan in dieser Ressourcengruppe zu erstellen und der zugeordnete Pool nicht über erforderliche Ressourcen verfügt, tritt dieser Fehler auf.

Wenn dieser Fehler auftritt, erstellen Sie Ihre Funktions-App und den Hostingplan stattdessen in einer neuen Ressourcengruppe.

Netzwerkfeatures

Funktion Verbrauchstarif Premium-Plan Dedizierter Plan ASE Kubernetes
IP-Einschränkungen für eingehenden Datenverkehr ✅Ja ✅Ja ✅Ja ✅Ja ✅Ja
Eingehende private Endpunkte ❌Nein ✅Ja ✅Ja ✅Ja ✅Ja
Integration in ein virtuelles Netzwerk ❌Nein ✅Ja (regional) ✅Ja (regional und Gateway) ✅Ja ✅Ja
Trigger für virtuelle Netzwerke (nicht HTTP) ❌Nein ✅Ja ✅Ja ✅Ja ✅Ja
Hybridverbindungen (nur Windows) ❌Nein ✅Ja ✅Ja ✅Ja ✅Ja
IP-Einschränkungen für ausgehenden Datenverkehr ❌Nein ✅Ja ✅Ja ✅Ja ✅Ja

Abrechnung

Planen Details
Verbrauchsplan Sie bezahlen nur für die Zeit, in der Ihre Funktionen ausgeführt werden. Die Abrechnung erfolgt auf der Grundlage der Anzahl von Ausführungen, der Ausführungszeit und des verwendeten Arbeitsspeichers.
Premium-Plan Die Abrechnung für den Premium-Plan basiert auf der Anzahl von Kernsekunden und dem für benötigte und vorab aufgewärmte Instanzen verwendeten Arbeitsspeicher. Mindestens eine Instanz pro Plan muss immer warmgehalten werden. Dieser Plan bietet die am besten vorhersagbaren Preise.
Dedizierter Plan Sie zahlen für Funktions-Apps in einem App Service-Plan das gleiche wie für andere App Service-Ressourcen, etwa Web-Apps.
App Service-Umgebung (ASE) Es gibt eine monatliche Pauschalgebühr für eine ASE, mit der die Infrastruktur abgedeckt ist und die sich nicht mit der Größe der ASE ändert. Darüber hinaus fallen Kosten pro vCPU im App Service-Plan an. Alle in einer ASE gehosteten Apps befinden sich in der isolierten Preis-SKU.
Kubernetes Sie zahlen nur die Kosten für Ihren Kubernetes-Cluster, keine zusätzlichen Gebühren für Functions. Ihre Funktions-App wird als Anwendungsworkload in Ihrem Cluster ausgeführt, genau wie eine ganz normale App.

Nächste Schritte