Azure Functions-Hostingoptionen
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 eine Reihe von vorab bereitgestellten (immer bereit) Instanzen 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 |
- Linux ist das einzige unterstützte Betriebssystem für den Python-Runtimestapel.
- 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 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. 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 |
- 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.
- Es wird keine maximale Ausführungstimeoutdauer 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.
- Hierfür muss der App Service-Plan auf Always On festgelegt werden. Während Plattformupdates wird eine Toleranzperiode von 10 Minuten gewährt.
- Das Standardtimeout für Version 1.x der Functions-Host-Runtime ist unbegrenzt.
- 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. | Ist nur beschränkt auf die Gesamtspeicherauslastung aller Instanzen in einem bestimmten Bereich. Weitere Informationen finden Sie unter Instanzspeicher. |
| 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 |
- Bei der horizontalen Skalierung gibt es derzeit eine Grenze von 500 Instanzen pro Abonnement und Stunde für Linux-Apps mit einem Verbrauchsplan.
- 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.
- Spezifische Grenzwerte für die verschiedenen Optionen des App Service-Plans finden Sie unter App Service-Grenzwerte.
- 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.
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 Einstellung Null: Apps können beim Leerlauf auf Null skaliert werden, und einige Anforderungen haben beim Start möglicherweise längere Wartezeiten. • Bei der Einstellung 1 oder höher: Der Hostprozess wird kontinuierlich ausgeführt. Deshalb ist ein Kaltstart kein Problem. |
| Verbrauchstarif | Apps können beim Leerlauf auf Null skaliert werden, was bedeutet, dass einige Anforderungen beim Start möglicherweise mehr Latenz haben. 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) | 4<sup4 | 3,5–14 | 1,75–256/8–256 | variiert | 1.5 |
| Maximale Instanzanzahl (Windows/Linux) | 100/20 | variiert je nach SKU/10011 | 10–30018 | 200/100 | 1.000 15 |
| Funktions-Apps pro Plan13 | 100 | 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 SSL-Unterstützung | 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 | Nicht unterstützt | Unbegrenzte Anzahl von SNI SSL-Verbindungen inbegriffen |
Hinweise zu Dienstgrenzwerten:
- Das Standardtimeout für die Laufzeit von Functions 1.x in einem App Service-Plan ist unbegrenzt.
- 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.
- Diese Grenzwerte werden auf dem Host festgelegt.
- 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.
- 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.
- 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.
- Unter Linux müssen Sie eine eigene Azure Files-Freigabe explizit einbinden.
- 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.
- Es wird keine maximale Ausführungstimeoutdauer erzwungen. Die Toleranzperiode für eine Funktionsausführung beträgt jedoch 60 Minuten während der Abskalierung und 10 Minuten während Plattformupdates.
- 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.
- Weitere Informationen finden Sie unter App Service-Grenzwerte.
- Einschließlich des Produktionsslots.
- Derzeit existiert ein Grenzwert von 5.000 Funktions-Apps in einem bestimmten Abonnement.
- Die Instanzengrößen des Flex-Verbrauchsplans sind derzeit als 2.048 MB oder 4.096 MB definiert. Weitere Informationen finden Sie unter Instanzspeicher.
- 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.
- Wenn die Mindestanzahl von Replikaten auf Null festgelegt ist, hängt das Standardtimeout von den spezifischen Triggern ab, die in der App verwendet werden.
- Wenn die Mindestanzahl von Replikaten auf mindestens ein Replikat festgelegt ist.
- In Container-Apps können Sie die maximale Anzahl von Replikatenfestlegen, die berücksichtigt wird, solange genügend Kernkontingent verfügbar ist.
Netzwerkfeatures
- Weitere Informationen finden Sie unter Netzwerk in der Azure Container Apps-Umgebung.
- Bei der Arbeit mit virtuellen Netzwerktriggern sind besondere Überlegungen vorzunehmen.
- 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 <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. 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.