Auf Englisch lesen

Freigeben über

Azure Functions-Hostingoptionen

  • Artikel

Wenn Sie eine Funktions-App in Azure erstellen, müssen Sie eine Hostingoption für die App auswählen. Azure bietet Ihnen diese Hostingoptionen für Ihren Funktionscode:

Hostingoption Dienst Verfügbarkeit Containerunterstützung
Flex-Verbrauchstarif Azure-Funktionen Allgemein verfügbar (Generally Available, GA) Keine
Premium-Plan Azure-Funktionen Allgemein verfügbar Linux
Dedizierter Plan Azure-Funktionen Allgemein verfügbar Linux
Container-Apps Azure Container Apps Allgemein verfügbar Linux
Verbrauchstarif Azure-Funktionen Allgemein verfügbar Keine

Azure Functions-Hostingoptionen werden von der Azure App Service-Infrastruktur auf virtuellen Linux- und Windows-Computern ermöglicht. Die von Ihnen gewählte Hostingoption 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
  • Unterstützung für Linux-Container.

Der von Ihnen ausgewählte Plan wirkt sich auch auf die Kosten für die Ausführung des Funktionscodes aus. Weitere Informationen finden Sie unter Abrechnung.

Dieser Artikel bietet einen detaillierten Vergleich zwischen den verschiedenen Hostingoptionen. Weitere Informationen zum Ausführen und Verwalten Ihres Funktionscodes in Linux-Containern finden Sie unter Linux-Containerunterstützung in Azure Functions.

Übersicht über die Pläne

Es folgt eine Zusammenfassung der Vorteile der verschiedenen Optionen für das Hosting von Azure Functions:

Option Vorteile
Flex-Verbrauchstarif Erfahren Sie mehr über die schnelle horizontale Skalierung mit Computeoptionen, virtuellen Netzwerken und nutzungsbasierter Bezahlung.

Im Flex-Verbrauchsplan werden Instanzen des Funktions-Host basierend auf der konfigurierten Parallelität der Instanz und der Anzahl der eingehenden Ereignisse dynamisch hinzugefügt und entfernt.

✔ Reduzieren Sie Kaltstarts, indem Sie mindestens eine vorab bereitgestellte (immer bereite) Instanz angeben.
✔ Unterstützt virtuelle Netzwerke für zusätzliche Sicherheit.
✔ Bezahlen Sie 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 möchten mehr Kontrolle über Ihre Instanzen haben und mehrere Funktions-Apps im selben Plan mit ereignisgesteuerter Skalierung bereitstellen.
✔ 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 mehr CPU- oder Arbeitsspeicheroptionen, als von Verbrauchsplänen bereitgestellt werden.
✔ Ihr Code muss länger ausgeführt werden, als im Verbrauchsplan als maximal zulässige Ausführungsdauer angegeben ist.
✔ Sie benötigen eine virtuelle Netzwerkkonnektivität.
✔ Sie möchten ein benutzerdefiniertes Linux-Image bereitstellen, in 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 vorhandene und nicht genutzte virtuelle Computer, auf denen bereits andere App Service-Instanzen ausgeführt werden.
✔ Sie benötigen eine vollständig vorhersehbare Abrechnung, oder Sie müssen Instanzen manuell skalieren.
✔ Sie möchten mehrere Web-Apps und Funktions-Apps im selben Plan ausführen
✔ Sie benötigen Zugriff auf größere Computegrößenauswahlen.
✔ Vollständige Computeisolation und sicherer Netzwerkzugriff, der von einem App Service Environment (ASE) bereitgestellt wird.
✔ Sehr hohe Speicherauslastung und hohe Skalierung (ASE).
Container-Apps Erstellen und Bereitstellen von containerisierten Funktions-Apps in einer vollständig verwalteten Umgebung, die von Azure Container Apps gehostet wird.

Verwenden Sie das Programmiermodell von Azure Functions, um ereignisgesteuerte, serverlose, cloudnative Funktions-Apps zu erstellen. Führen Sie Ihre Funktionen zusammen mit anderen Microservices, APIs, Websites und Workflows als containergehostete Programme aus. Überlegen Sie, Ihre Funktionen in Container Apps in den folgenden Situationen zu hosten:

✔ Sie möchten benutzerdefinierte Bibliotheken mit Ihrem Funktionscode verpacken, um Branchen-Apps zu unterstützen.
✔ Sie müssen die Codeausführung von lokalen oder älteren Apps zu cloudnativen Microservices migrieren, die in Containern ausgeführt werden.
✔ Wenn Sie den Aufwand und die Komplexität der Verwaltung von Kubernetes-Clustern und dedizierten Computes vermeiden möchten.
✔ Ihre Funktionen benötigen High-End-Verarbeitungsleistung, die von dedizierten GPU-Computeressourcen bereitgestellt wird.
Verbrauchstarif Zahlen Sie nur für Computeressourcen, wenn Ihre Funktionen ausgeführt werden (nutzungsbasiert) mit automatischer Skalierung.

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

✔ Standardhostingplan, der echtes serverloses Hosting bereitstellt.
✔ Sie bezahlen nur, wenn Ihre Funktionen ausgeführt werden.
✔ Die Skalierung erfolgt automatisch – selbst in Zeiten hoher Last.

Die restlichen Tabellen in diesem Artikel vergleichen Hostingoptionen basierend auf verschiedenen Features und Verhaltensweisen.

Betriebssystemunterstützung

Diese Tabelle zeigt die Unterstützung des Betriebssystems für die Hostingoptionen.

Hosting Linux1-Bereitstellung Windows2-Bereitstellung
Flex-Verbrauchstarif ✅ Nur Code
❌ Container (nicht unterstützt)		 ❌ Nicht unterstützt
Premium-Plan ✅ Nur Code
✅ Container		 ✅ Nur Code
Dedizierter Plan ✅ Nur Code
✅ Container		 ✅ Nur Code
Container-Apps ✅ Nur Container ❌ Nicht unterstützt
Verbrauchstarif ✅ Nur Code
❌ Container (nicht unterstützt)		 ✅ Nur Code
  1. Linux ist das einzige unterstützte Betriebssystem für den Python-Runtimestapel.
  2. Windows-Bereitstellungen enthalten nur Code. Funktionen unterstützen derzeit keine Windows-Container.

Funktions-App-Timeoutdauer

Die Timeoutdauer für Funktionen in einer Funktions-App wird über die functionTimeout-Eigenschaft in der Projektdatei host.json 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 etwas zurückgeben oder reagieren. Um Timeouts zu vermeiden, ist es wichtig, robuste Funktionen zu schreiben. 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
Flex-Verbrauchstarif 30 Unbounded2
Premium-Plan 304 Unbounded2
Dedizierter Plan 304 Unbounded3
Container-Apps 30 Unbegrenzt5
Verbrauchstarif 5 10
  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. Es wird keine maximale Timeoutdauer für die Ausführung erzwungen. Die Toleranzperiode einer Funktionsausführung beträgt jedoch 60 Minuten während der Abskalierung für Flex-Verbrauchs- und Premium-Pläne, und während Plattformupdates wird eine Toleranzperiode von 10 Minuten gewährt.
  3. Hierfür muss der App Service-Plan auf Always On festgelegt werden. Während Plattformupdates wird eine Toleranzperiode von 10 Minuten gewährt.
  4. Das Standardtimeout für Version 1.x der Functions-Host-Runtime ist unbegrenzt.
  5. Wenn die Mindestanzahl von Replikaten auf null festgelegt ist, hängt das Standardtimeout von den spezifischen Triggern ab, die in der App verwendet werden.

Sprachunterstützung

Ausführliche Informationen zur aktuellen Unterstützung der nativen Sprachstapel in Funktionen finden Sie unter Unterstützte Sprachen in Azure Functions.

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
Flex-Verbrauchstarif Skalierung pro Funktion. Ereignisgesteuerte Skalierungsentscheidungen werden pro Funktion berechnet, was eine deterministischere Skalierung der Funktionen in Ihrer App bietet. Mit Ausnahme von HTTP, Blob Storage (Event Grid) und Durable Functions werden alle anderen Funktionstriggertypen in Ihrer App auf unabhängigen Instanzen skaliert. Alle HTTP-Trigger in Ihrer App werden zusammen als Gruppe in denselben Instanzen skaliert, ebenso wie alle BLOB-Speichertrigger (Event Grid). Alle Durable Functions-Trigger nutzen die gleichen Instanzen und werden gemeinsam skaliert. 1.0005
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-1002
Dedizierter Plan3 Manuelle Skalierung/Autoskalierung 10-30
100 (ASE)
Container-Apps 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. 300-10004
Verbrauchstarif Ereignisgesteuert. Skaliert automatisch, auch in Zeiten mit hoher Last. Die 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
  1. Bei der horizontalen Skalierung gibt es derzeit eine Grenze von 500 Instanzen pro Abonnement und Stunde für Linux-Apps mit einem Verbrauchsplan.
  2. In einigen Regionen können Linux-Apps in einem Premium-Plan auf 100 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 App Service-Grenzwerte.
  4. Bei Container-Apps ist die Standardeinstellung 10 Instanzen, Sie können jedoch die maximale Anzahl von Replikaten festlegen. Der Höchstwert beträgt 1.000. Diese Einstellung wird berücksichtigt, solange genügend Kernkontingent verfügbar ist. Wenn Sie Ihre Funktions-App im Azure-Portal erstellen, sind Sie auf 300 Instanzen beschränkt.
  5. Die Gesamtanzahl der Instanzen in einer bestimmten Region wird effektiv durch regionale Abonnementspeicherkontingente begrenzt.

Kaltstartverhalten

Planen Details
Flex-Verbrauchstarif Unterstützt immer einsatzbereite Instanzen, um die Verzögerung beim Bereitstellen neuer Instanzen zu verringern.
Premium-Plan Unterstützt immer einsatzbereite Instanzen, um Kaltstarts zu vermeiden, indem Sie eine oder mehrere dauerhaft warme Instanzen beibehalten können.
Dedizierter Plan Bei der Ausführung in einem dedizierten Plan kann der Funktionshost kontinuierlich auf einer vorgegebenen Anzahl von Instanzen ausgeführt werden, was bedeutet, dass der Kaltstart kein Problem ist.
Container-Apps Hängt von der Mindestanzahl der Replikate ab:
• Bei der Festlegung auf null: Apps können im Leerlauf auf null skaliert werden, und einige Anforderungen weisen beim Start möglicherweise längere Wartezeiten auf.
• Bei der Einstellung 1 oder höher: Der Hostprozess wird kontinuierlich ausgeführt. Deshalb ist ein Kaltstart kein Problem.
Verbrauchstarif Apps können im Leerlauf auf null skaliert werden, sodass einige Anforderungen beim Start möglicherweise längere Wartezeiten aufweisen. Der Verbrauchsplan bietet einige Optimierungen, um die Kaltstartzeit zu verkürzen, beispielsweise den Abruf von vorab aufgewärmten (betriebsbereiten) Platzhalterfunktionen, für die der Host und die Sprachprozesse bereits ausgeführt werden.

Diensteinschränkungen

Resource Flex-Verbrauchstarif Premium-Plan Dedizierter Plan/ASE Container-Apps Verbrauchstarif
Standardmäßige Timeoutdauer (in Minuten) 30 30 301 3016 5
Maximale Timeoutdauer (in Minuten) unbegrenzt9 unbegrenzt9 unbounded2 unbegrenzt15 10
Maximale Anzahl ausgehender Verbindungen (pro Instanz) unbounded unbounded unbounded unbounded 600 aktive (insgesamt 1.200)
Maximale Anforderungsgröße (MB)3 210 210 210 210 210
Maximale Länge der Abfragezeichenfolge3 4096 4096 4096 4096 4096
Maximale Länge der Anforderungs-URL3 8192 8192 8192 8192 8192
ACU pro Instanz 210–840 100–840/210–25010 variiert 100 variiert
Maximaler Arbeitsspeicher (GB pro Instanz) 414 3,5–14 1,75–256/8–256 variiert 1.5
Maximale Anzahl der Instanzen (Windows | Linux) Nicht verfügbar | 1.00015 variiert je nach SKU | 10011 10–30018 200 | 100 1.000
Funktions-Apps pro Plan13 1 100 unbounded4 unbounded4 100
App Service-Pläne Nicht zutreffend 100 pro Ressourcengruppe 100 pro Ressourcengruppe Nicht zutreffend 100 pro Region
Bereitstellungsslots pro App12 Nicht zutreffend 3 1–2011 Nicht unterstützt 2
Speicher (temporär)5 0.8 GB 21-140 GB 11-140 GB Nicht zutreffend 0,5 GB
Speicher (persistent) 0 GB7 250 GB 10–1.000 GB11 Nicht zutreffend 1 GB6,7
Benutzerdefinierte Domänen pro App 500 500 500 Nicht unterstützt 5007
Benutzerdefinierte Domäne TSL/SSL-Unterstützung Unbegrenzte Anzahl von SNI SSL-Verbindungen und eine IP-SSL-Verbindung inbegriffen Unbegrenzte Anzahl von SNI SSL-Verbindungen und eine IP-SSL-Verbindung inbegriffen Unbegrenzte Anzahl von SNI SSL-Verbindungen und eine IP-SSL-Verbindung inbegriffen Nicht unterstützt Unbegrenzte Anzahl von SNI SSL-Verbindungen inbegriffen

Hinweise zu Dienstgrenzwerten:

  1. Das Timeout für die Functions 1.x-Runtime 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. Während Plattformupdates wird eine Toleranzperiode von 10 Minuten gewährt.
  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 im temporären Speicher aller Apps im gleichen App Service-Plan. Für Verbrauchspläne unter Linux beträgt der Speicher derzeit 1,5 GB.
  6. Der Verbrauchsplan verwendet eine Azure Files-Freigabe für persistenten Speicher. Wenn Sie Ihre eigene Azure Files-Freigabe bereitstellen, hängen die spezifischen Größenbeschränkungen für die Freigabe von dem Speicherkonto ab, das Sie für WEBSITE_CONTENTAZUREFILECONNECTIONSTRING festgelegt haben.
  7. Unter Linux müssen Sie eine eigene Azure Files-Freigabe explizit einbinden.
  8. Wenn Ihre Funktions-App in 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.
  9. Es wird kein Timeout für die maximale Ausführungsdauer erzwungen. Die Toleranzperiode für eine Funktionsausführung beträgt jedoch 60 Minuten während der Abskalierung und 10 Minuten während Plattformupdates.
  10. 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.
  11. Weitere Informationen finden Sie unter App Service-Grenzwerte.
  12. Einschließlich des Produktionsslots.
  13. Derzeit gilt ein Grenzwert von 5.000 Funktions-Apps pro Abonnement.
  14. Die Instanzengrößen des Flex-Verbrauchsplans sind derzeit als 2.048 MB oder 4.096 MB definiert. Weitere Informationen finden Sie unter Instanzspeicher.
  15. Der Flex-Verbrauchsplan verfügt über ein regionales Abonnementkontingent, das die Gesamtspeicherauslastung aller Instanzen in einer bestimmten Region begrenzt. Weitere Informationen finden Sie unter Instanzspeicher.
  16. Wenn die Mindestanzahl von Replikaten auf null festgelegt ist, hängt das Standardtimeout von den spezifischen Triggern ab, die in der App verwendet werden.
  17. Wenn die Mindestanzahl von Replikaten auf mindestens ein Replikat festgelegt ist.
  18. In Container-Apps können Sie die maximale Anzahl von Replikatenfestlegen, die berücksichtigt wird, solange genügend Kernkontingent verfügbar ist.

Netzwerkfeatures

Funktion Flex-Verbrauchstarif Verbrauchstarif Premium-Plan Dedizierter Plan/ASE Container Apps1
IP-Einschränkungen für eingehenden Datenverkehr ✔ ✔ ✔ ✔ ✔
Eingehende private Endpunkte ✔ ✔ ✔
Integration in ein virtuelles Netzwerk ✔ ✔2 ✔3 ✔
IP-Einschränkungen für ausgehenden Datenverkehr ✔ ✔ ✔ ✔
  1. Weitere Informationen finden Sie unter Netzwerk in der Azure Container Apps-Umgebung.
  2. Bei der Arbeit mit virtuellen Netzwerktriggern sind besondere Überlegungen vorzunehmen.
  3. Nur der dedizierte/ASE-Plan unterstützt die durch vom Gateway benötigte Integration des virtuellen Netzwerks.

Abrechnung

Planen Details
Flex-Verbrauchstarif Die Abrechnung basiert auf der Anzahl der Ausführungen, dem Speicher von Instanzen, wenn sie Funktionen aktiv ausführen, sowie den Kosten für alle immer einsatzbereite Instanzen. Weitere Informationen finden Sie unter Abrechnung für Flex Consumption-Plan.
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.

Für eine ASE gibt es eine monatlichen Pauschalgebühr, die für die Infrastruktur zahlt und sich nicht mit der Größe der Umgebung ä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. Weitere Informationen finden Sie im ASE-Übersichtsartikel.
Container-Apps Die Abrechnung in Azure Container Apps basiert auf Ihrem Plantyp. Weitere Informationen finden Sie unter Abrechnung in Azure Container Apps.
Verbrauchstarif 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.

Einen direkten Kostenvergleich zwischen dynamischen Hostingplänen (Verbrauch, FlexVerbrauch und Premium) finden Sie auf der Azure Functions-Preisseite. Die Preise für die verschiedenen Optionen bei einem dedizierten Plan finden Sie auf der Seite App Service – Preise. Preise für Container-Apps-Hosting finden Sie unter Azure Container Apps-Preise.

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 <Ressourcengruppenname> 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. Beispielsweise werden Linux-Verbrauchs-Apps nicht in derselben Ressourcengruppe wie Linux Dedicated- oder Linux Premium-Pläne unterstützt.
  • 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. Dieser Fehler 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.

Nächste Schritte