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. Nutzen Sie vorab aufgewärmte (also betriebsbereite) Worker, um Anwendungen nach einem Leerlauf ohne jede Verzögerung auszuführen, profitieren Sie von leistungsstärkeren Instanzen für die Ausführung, und stellen Sie 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
Nur Code
Windows2
Nur Code
Linux1,3
Docker-Container
Verbrauchsplan .NET Core 3.1
.NET 5.0
JavaScript
Java
Python
TypeScript
.NET Core 3.1
.NET 5.0
JavaScript
Java
PowerShell Core
TypeScript
Keine Unterstützung
Premium-Plan .NET Core 3.1
.NET 5.0
JavaScript
Java
Python
TypeScript
.NET Core
.NET 5.0
JavaScript
Java
PowerShell Core
TypeScript
.NET Core
Node.js
Java
PowerShell Core
Python
TypeScript
Dedizierter Plan .NET Core 3.1
.NET 5.0
JavaScript
Java
Python
TypeScript
.NET Core 3.1
.NET 5.0
JavaScript
Java
PowerShell Core
TypeScript
.NET Core 3.1
.NET 5.0
JavaScript
Java
PowerShell Core
Python
TypeScript
ASE .NET Core 3.1
.NET 5.0
JavaScript
Java
Python
TypeScript
.NET Core 3.1
.NET 5.0
JavaScript
Java
PowerShell Core
TypeScript
.NET Core 3.1
.NET 5.0
JavaScript
Java
PowerShell Core
Python
TypeScript
Kubernetes (direkt) .NET Core 3.1
.NET 5.0
JavaScript
Java
PowerShell Core
Python
TypeScript
Azure Arc (Vorschauversion) .NET Core 3.1
.NET 5.0
JavaScript
Java
Python
TypeScript
.NET Core 3.1
.NET 5.0
JavaScript
Java
PowerShell Core
Python
TypeScript

1 Linux ist das einzige unterstützte Betriebssystem für den Python-Runtimestapel.
2 Windows ist das einzige unterstützte Betriebssystem für den PowerShell-Runtimestapel.
3 Linux ist das einzige unterstützte Betriebssystem für Docker-Container.

Funktions-App-Timeoutdauer

Die Timeoutdauer einer Funktions-App wird durch die functionTimeout-Eigenschaft in der functionTimeout-Projektdatei definiert. Die folgende Tabelle listet die Standard- und Maximalwerte in Minuten für beide Pläne und die unterschiedlichen Laufzeitversionen auf:

Planen Laufzeitversion Standard Maximum
Nutzung 1.x 5 10
Nutzung 2.x 5 10
Nutzung 3.x 5 10
Premium 1.x Unbegrenzt Unbegrenzt
Premium 2.x 30 Unbegrenzt
Premium 3.x 30 Unbegrenzt
App Service 1.x Unbegrenzt Unbegrenzt
App Service 2.x 30 Unbegrenzt
App Service 3.x 30 Unbegrenzt

Hinweis

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.

Skalieren

In der folgenden Tabelle wird das Skalierungsverhalten der verschiedenen Hostingpläne verglichen.

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. 200
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. 100
Dedicated-Plan1 Manuelle Skalierung/Autoskalierung 10 – 20
ASE1 Manuelle Skalierung/Autoskalierung 100
Kubernetes Ereignisgesteuerte Autoskalierung für Kubernetes-Cluster über KEDA. Variiert je nach Cluster

1 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 200 1009 variiert je nach SKU10 10010 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 - -
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 Bei der Ausführung unter Linux in einem Premium-Plan sind Sie derzeit auf 20 Instanzen beschränkt.
10 Ausführliche Informationen finden Sie unter App Service-Grenzwerte.

Netzwerkfeatures

Funktion Verbrauchstarif Premium-Plan Dedizierter Plan ASE Kubernetes
IP-Einschränkungen für eingehenden Datenverkehr und Zugriff auf private Sites ✅Ja ✅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. Pro Plan muss immer mindestens eine Instanz aufgewärmt sein. 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