Freigeben über

Netzwerkoptionen von Azure Functions

  • Artikel

In diesem Artikel werden die Netzwerkfunktionen beschrieben, die für die Hostingoptionen von Azure Functions zur Verfügung stehen. Alle folgenden Netzwerkoptionen geben Ihnen die Möglichkeit zum Zugreifen auf Ressourcen ohne Verwendung von Adressen, die über das Internet geroutet werden können, oder zum Einschränken des Internetzugriffs auf eine Funktions-App.

Die Hostingmodelle weisen verschiedene verfügbare Ebenen der Netzwerkisolation auf. Durch Auswahl der jeweils richtigen Ebene lassen sich Ihre Anforderungen an die Netzwerkisolation erfüllen.

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

*Weitere Informationen finden Sie unter Netzwerk in der Azure Container Apps-Umgebung.

Schnellstart für Ressourcen

Verwenden Sie die folgenden Ressourcen, um schnell mit den Netzwerkszenarien von Azure Functions beginnen zu können. Auf diese Ressourcen wird im gesamten Artikel verwiesen.

Netzwerkfeatures für Eingang

Mit den folgenden Features können Sie eingehende Anforderungen an Ihre Funktions-App filtern.

Einschränkungen für eingehenden Zugriff

Mit Zugriffseinschränkungen können Sie eine nach Priorität sortierte Liste mit IP-Adressen definieren, über die der Zugriff auf Ihre App zugelassen bzw. abgelehnt wird. Die Liste kann IPv4- und IPv6-Adressen oder bestimmte Subnetze eines virtuellen Netzwerks mit Dienstendpunkten enthalten. Wenn mindestens ein Eintrag vorhanden ist, enthält die Liste am Ende einen impliziten Eintrag vom Typ „Alle ablehnen“. IP-Einschränkungen können für alle Hostingoptionen für Funktionen verwendet werden.

Zugriffseinschränkungen sind für Flex-Verbrauch, Elastic Premium, Verbrauch und App Service verfügbar.

Hinweis

Mit den geltenden Netzwerkbeschränkungen können Sie nur in Ihrem virtuellen Netzwerk bereitstellen, oder wenn Sie die IP-Adresse des Computers, mit dem Sie auf das Azure-Portal zugreifen, der Liste der sicheren Empfänger hinzugefügt haben. Sie können die Funktion jedoch weiterhin über das Portal verwalten.

Weitere Informationen finden Sie unter Azure App Service – statische Zugriffseinschränkungen.

Private Endpunkte

Ein privater Azure-Endpunkt ist eine Netzwerkschnittstelle, die Sie privat und sicher mit einem Dienst verbindet, der von Azure Private Link unterstützt wird. Ein privater Endpunkt verwendet eine private IP-Adresse aus Ihrem virtuellen Netzwerk und macht den Dienst so in Ihrem virtuellen Netzwerk verfügbar.

Sie können einen privaten Endpunkt für ihre Funktionen verwenden, die in den Plänen Premium und App Service gehostet werden.

Wenn Sie Aufrufe an private Endpunkte durchführen möchten, müssen Sie sicherstellen, dass Ihre DNS-Suchen zu dem privaten Endpunkt aufgelöst werden. Sie können dieses Verhalten auf eine der folgenden Arten erzwingen:

  • Integrieren mit private Azure DNS-Zonen. Wenn Ihr virtuelles Netzwerk nicht über einen benutzerdefinierten DNS-Server verfügt, erfolgt dies automatisch.
  • Verwalten des privaten Endpunkts im DNS-Server, der von Ihrer App verwendet wird. Hierzu müssen Sie die Adresse des privaten Endpunkts kennen und dann den Endpunkt, den Sie erreichen möchten, mit einem A-Eintrag auf diese Adresse verweisen lassen.
  • Konfigurieren Ihres eigenen DNS-Servers zur Weiterleitung an private Azure DNS-Zonen.

Weitere Informationen finden Sie unter Verwenden privater Endpunkte für Web-Apps.

Konfigurieren Sie zum Aufrufen anderer Dienste, die über eine Verbindung mit einem privaten Endpunkt verfügen (z. B. Speicher oder Service Bus), Ihre App so, dass sie ausgehende Aufrufe an private Endpunkte ausführt. Weitere Details zur Verwendung privater Endpunkte mit dem Speicherkonto für Ihre Funktions-App finden Sie unter Einschränken Ihres Speicherkontos auf ein virtuelles Netzwerk.

Dienstendpunkte

Mithilfe von Dienstendpunkten können Sie viele Azure-Dienste auf ausgewählte Subnetze des virtuellen Netzwerks beschränken, um eine höhere Sicherheitsstufe zu gewährleisten. Mit der regionalen Integration virtueller Netzwerke können Ihre Funktions-Apps Azure-Dienste erreichen, die mit Dienstendpunkten geschützt sind. Diese Konfiguration wird für alle Pläne unterstützt, welche die Integration in ein virtuelles Netzwerk unterstützen. Gehen Sie wie folgt vor, um auf einen durch einen Dienstendpunkt gesicherten Dienst zuzugreifen:

  1. Konfigurieren Sie die regionale Integration des virtuellen Netzwerks in Ihre Funktions-App, um eine Verbindung mit einem bestimmten Subnetz herzustellen.
  2. Wechseln Sie zum Zieldienst, und konfigurieren Sie Dienstendpunkte für das Integrationssubnetz.

Weitere Informationen finden Sie unter VNET-Dienstendpunkte.

Verwenden von Dienstendpunkten

Erstellen Sie zum Einschränken des Zugriffs auf ein bestimmtes Subnetz eine Einschränkungsregel vom Typ Virtual Network. Anschließend können Sie das Abonnement, das virtuelle Netzwerk und das Subnetz auswählen, für das Sie den Zugriff zulassen oder ablehnen möchten.

Falls für das von Ihnen ausgewählte Subnetz nicht bereits Dienstendpunkte mit Microsoft.Web aktiviert sind, wird dies automatisch durchgeführt, sofern Sie nicht das Kontrollkästchen Fehlende Microsoft.Web-Dienstendpunkte ignorieren aktivieren. In einem Szenario, bei dem Sie Dienstendpunkte in der App aktivieren möchten, aber nicht im Subnetz, hängt es vor allem davon ab, ob Sie über die Berechtigungen für die Aktivierung im Subnetz verfügen.

Falls die Dienstendpunkte im Subnetz bei Ihnen von einer anderen Person aktiviert werden müssen, sollten Sie das Kontrollkästchen Fehlende Microsoft.Web-Dienstendpunkte ignorieren aktivieren. Ihre App wird für Dienstendpunkte konfiguriert, weil damit zu rechnen ist, dass diese später im Subnetz aktiviert werden.

Screenshot: Bereich „Add IP Restriction“ (IP-Einschränkung hinzufügen) mit Auswahl des Typs „Virtual Network“

Sie können Dienstendpunkte nicht nutzen, um den Zugriff auf Apps einzuschränken, die in einer App Service-Umgebung ausgeführt werden. Wenn Ihre App in einer App Service-Umgebung enthalten ist, können Sie den Zugriff darauf steuern, indem Sie IP-Zugriffsregeln anwenden.

Informationen zum Einrichten von Dienstendpunkten Sie unter Tutorial: Einrichten von privatem Websitezugriff für Azure Functions.

Integration in ein virtuelles Netzwerk

Durch die Integration des virtuellen Netzwerks kann die Funktions-App auf Ressourcen eines virtuellen Netzwerks zugreifen. Azure Functions unterstützt zwei Arten der Integration virtueller Netzwerke:

  • Die dedizierten Computetarife, einschließlich Basic, Standard, Premium, Premium v2 und Premium v3.
  • Die App Service-Umgebung, die direkt in Ihrem virtuellen Netzwerk mit dedizierter unterstützender Infrastruktur bereitgestellt wird und die Tarife „Isoliert“ und „Isoliert v2“ nutzt.

Die Funktion für die Integration in ein virtuelles Netzwerk wird in dedizierten Computetarifen von App Service verwendet. In einer App Service-Umgebung befindet sich Ihre App bereits in einem virtuellen Netzwerk, und sie benötigt daher das VNet-Integrationsfeature nicht, um Ressourcen im selben virtuellen Netzwerk zu erreichen. Weitere Informationen zu allen Netzwerkfunktionen finden Sie unter App Service-Netzwerkfunktionen.

Die Integration virtueller Netzwerke ermöglicht Ihrer App den Zugriff auf Ressourcen in Ihrem virtuellen Netzwerk, gewährt aber keinen eingehenden privaten Zugriff auf Ihre App aus dem virtuellen Netzwerk. Privater Websitezugriff bezieht sich darauf, den Zugriff auf eine App nur über ein privates Netzwerk zuzulassen, z. B. über ein virtuelles Azure-Netzwerk. Die Integration virtueller Netzwerke wird nur für ausgehende Aufrufe aus Ihrer App an Ihr virtuelles Netzwerk verwendet. Die Funktion für die Integration in ein virtuelles Netzwerk weist abhängig davon, ob sie mit virtuellen Netzwerken in derselben Region oder mit virtuellen Netzwerken in anderen Regionen verwendet wird, ein unterschiedliches Verhalten auf. Die Funktion für die Integration in ein virtuelles Netzwerk ist in zwei Varianten verfügbar:

  • Integration regionaler virtueller Netzwerke: Wenn Sie eine Verbindung mit virtuellen Netzwerken in derselben Region herstellen, benötigen Sie ein dediziertes Subnetz in dem virtuellen Netzwerk, in das Sie integrieren.
  • Integration virtueller Netzwerke mit erforderlichem Gateway: Wenn Sie eine Verbindung mit virtuellen Netzwerken in anderen Regionen oder mit einem klassischen virtuellen Netzwerk in derselben Region direkt herstellen, benötigen Sie ein Azure Virtual Network-Gateway, das im virtuellen Zielnetzwerk erstellt wurde.

Die Funktion Integration eines virtuellen Netzwerks:

Einige Dinge werden von der Integration eines virtuellen Netzwerks nicht unterstützt, z. B.:

  • Einbindung eines Laufwerks
  • Beitritt zu einer Windows Server Active Directory-Domäne
  • NetBIOS

Die Integration virtueller Netzwerke mit erforderlichem Gateway ermöglicht nur den Zugriff auf Ressourcen im virtuellen Zielnetzwerk oder in Netzwerken, die mit dem virtuellen Zielnetzwerk über Peering oder VPNs verbunden sind. Die Integration virtueller Netzwerke mit erforderlichem Gateway ermöglicht keinen Zugriff auf Ressourcen, die über Azure ExpressRoute-Verbindungen verfügbar sind oder mit Dienstendpunkten funktionieren.

Unabhängig von der verwendeten Version ermöglicht die Integration virtueller Netzwerke Ihrer App den Zugriff auf Ressourcen in Ihrem virtuellen Netzwerk, gewährt aber keinen eingehenden privaten Zugriff auf Ihre App aus dem virtuellen Netzwerk. Privater Websitezugriff bezieht sich darauf, den Zugriff auf Ihre App nur über ein privates Netzwerk zuzulassen, z. B. über ein virtuelles Azure-Netzwerk. Die Integration des virtuellen Netzwerks wird nur für ausgehende Aufrufe verwendet, die von Ihrer App an Ihr virtuelles Netzwerk gerichtet werden.

Bei der Integration virtueller Netzwerke in Azure Functions wird die gemeinsame Infrastruktur mit App Service-Web-Apps verwendet. Weitere Informationen zu den beiden Arten der Integration virtueller Netzwerke finden Sie unter:

Informationen zum Einrichten der Integration virtueller Netzwerke finden Sie unter Aktivieren der Integration virtueller Netzwerke.

Aktivieren der Integration virtueller Netzwerke

  1. Wählen Sie in Ihrer Funktions-App im Azure-Portal die Option Netzwerk und anschließend unter VNET-Integration die Option Klicken Sie hier, um die Konfiguration auszuführen aus.

  2. Wählen Sie VNET hinzufügen aus.

    Auswählen der VNET-Integration

  3. Die Dropdownliste enthält alle virtuellen Azure Resource Manager-Netzwerke in Ihrem Abonnement in derselben Region. Wählen Sie das virtuelle Netzwerk aus, das Sie für die Integration verwenden möchten.

    Auswählen des VNETs

    • Die Tarife „Flex-Verbrauch“ und „Elastic Premium“ von Functions unterstützen ausschließlich eine regionale Integration virtueller Netzwerke. Wenn sich das virtuelle Netzwerk in derselben Region befindet, erstellen Sie entweder ein neues Subnetz, oder wählen Sie ein leeres, bereits vorhandenes Subnetz aus.

    • Wenn Sie ein virtuelles Netzwerk in einer anderen Region auswählen möchten, müssen Sie über ein virtuelles Netzwerkgateway verfügen, für das Point-to-Site aktiviert ist. Die regionsübergreifende Integration virtueller Netzwerke wird nur für Dedicated-Pläne unterstützt, globale Peerings funktionieren jedoch mit der regionalen Integration virtueller Netzwerke.

Während der Integration wird Ihre App neu gestartet. Wenn die Integration abgeschlossen ist, werden Details zu dem virtuellen Netzwerk angezeigt, in das Sie integriert sind. Standardmäßig ist „Route All“ (Gesamten Datenverkehr weiterleiten) aktiviert, und der gesamte Datenverkehr wird an Ihr virtuelles Netzwerk geroutet.

Wenn Sie nur Ihren privaten Datenverkehr (RFC1918-Datenverkehr) routen möchten, führen Sie die in der App Service-Dokumentation beschriebenen Schritte aus.

Regionale Integration des virtuellen Netzwerks

Die Verwendung der regionalen Integration virtueller Netzwerke ermöglicht der App Zugriff auf Folgendes:

  • Ressourcen im selben virtuellen Netzwerk wie Ihre App.
  • Ressourcen in virtuellen Netzwerken, die per Peering mit dem virtuellen Netzwerk verbunden sind, in das Ihre App integriert ist.
  • Durch Dienstendpunkte geschützte Dienste.
  • Ressourcen über Azure ExpressRoute-Verbindungen.
  • Ressourcen über Verbindungen mit Peering, einschließlich von Azure ExpressRoute-Verbindungen.
  • Private Endpunkte

Wenn Sie die regionale Integration virtueller Netzwerke verwenden, können Sie die folgenden Azure-Netzwerkfunktionen nutzen:

  • Netzwerksicherheitsgruppen (NSGs) : Sie können ausgehenden Datenverkehr mit einer NSG blockieren, die in Ihrem Integrationssubnetz platziert ist. Die Regeln für eingehenden Datenverkehr gelten nicht, da Sie die Integration virtueller Netzwerke nicht verwenden können, um eingehenden Zugriff auf Ihre App bereitzustellen.
  • Routingtabellen (UDRs) : Sie können eine Routingtabelle im Integrationssubnetz platzieren, um ausgehenden Datenverkehr an beliebige gewünschte Ziele zu senden.

Hinweis

Wenn Sie den gesamten ausgehenden Datenverkehr in Ihr virtuelles Netzwerk weiterleiten, unterliegt dieser den NSGs und UDRs, die auf Ihr Integrationssubnetz angewendet werden. Wenn das virtuelle Netzwerk integriert ist, wird der ausgehende Datenverkehr Ihrer Funktions-App an öffentliche IP-Adressen weiterhin von den Adressen gesendet, die in den Eigenschaften Ihrer App aufgeführt sind – es sei denn, Sie geben Routen an, die den Datenverkehr an ein anderes Ziel leiten.

Für die regionale Integration virtueller Netzwerke kann Port 25 nicht verwendet werden.

Flex-Verbrauch-Plan:

  1. Stellen Sie sicher, dass der Microsoft.App-Azure-Ressourcenanbieter für Ihr Abonnement aktiviert ist, indem Sie die folgenden Anweisungen befolgen. Die Subnetzdelegierung, die von Flex-Verbrauch-Apps benötigt wird, lautet Microsoft.App/environments.
  2. Die Subnetzdelegierung, die von Flex-Verbrauch-Apps benötigt wird, lautet Microsoft.App/environments. Dies ist eine Änderung gegenüber Elastic Premium und App Service, für die eine andere Delegierungsanforderung gilt.
  3. Sie können planen, dass maximal 40 IP-Adressen für eine Funktions-App verwendet werden, auch wenn die App auf über 40 skaliert wird. Wenn Sie beispielsweise fünfzehn Funktions-Apps mit Flex-Verbrauch haben, die über VNet in dasselbe Subnetz integriert werden, können Sie 15x40 = 600 IP-Adressen planen, die höchstens verwendet werden. Dieser Grenzwert kann geändert werden und wird nicht erzwungen.
  4. Das Subnetz darf nicht bereits für andere Zwecke verwendet werden (z. B. für private Endpunkte oder Dienstendpunkte oder an einen anderen Hostingplan oder Dienst delegiert). Sie können zwar dasselbe Subnetz mit mehreren Flex-Verbrauch-Apps teilen, die Netzwerkressourcen werden jedoch für diese Funktions-Apps gemeinsam verwendet. Dies kann dazu führen, dass eine Funktions-App sich auf die Leistung anderer Apps im selben Subnetz auswirkt.

Bei der Verwendung virtueller Netzwerke müssen einige Einschränkungen berücksichtigt werden:

  • Das Feature ist für Flex-Verbrauch, Elastic Premium und App Service Premium V2 und Premium V3 verfügbar. Es ist außerdem im Tarif „Standard“ verfügbar, jedoch nur in neueren App Service-Bereitstellungen. Wenn Sie eine ältere Bereitstellung nutzen, können Sie das Feature nur in einem App Service-Plan vom Typ „Premium V2“ verwenden. Wenn Sie sicherstellen möchten, dass Sie das Feature in einem „Standard“-App Service-Plan verwenden können, erstellen Sie Ihre App in einem „Premium V3“-App Service-Plan. Diese Pläne werden nur für unsere neuesten Bereitstellungen unterstützt. Sie können anschließend nach Bedarf herunterskalieren.
  • Das Integrationssubnetz kann nur von einem App Service-Plan verwendet werden.
  • Die Funktion kann nicht für Apps im Plan „App Service (isoliert)“ in einer App Service-Umgebung verwendet werden.
  • Für das Feature ist ein nicht genutztes Subnetz vom Typ /28 oder größer in einem virtuellen Azure Resource Manager-Netzwerk erforderlich.
  • Die App und das virtuelle Netzwerk müssen sich in derselben Region befinden.
  • Ein virtuelles Netzwerk mit einer integrierten App kann nicht gelöscht werden. Entfernen Sie die Integration, bevor Sie das virtuelle Netzwerk löschen.
  • Sie können bis zu zwei regionale Integrationen virtueller Netzwerke pro App Service-Plan verwenden. Ein Integrationssubnetz kann von mehreren Apps innerhalb des gleichen App Service-Plans genutzt werden.
  • Sie können das Abonnement einer App oder eines Plans nicht ändern, solange eine App mit regionaler VNet-Integration vorhanden ist.

Subnetze

Die Integration virtueller Netzwerke hängt von der Verwendung eines dedizierten Subnetzes ab. Wenn Sie ein Subnetz bereitstellen, verliert das Azure-Subnetz von Anfang an fünf IP-Adressen. Für jede Instanz des Elastic Premium- und App Service-Plans wird eine Adresse aus dem Integrationssubnetz verwendet. Wenn Sie Ihre App auf vier Instanzen skalieren, werden vier Adressen verwendet. Für Flex-Verbrauch gilt dies nicht, und Instanzen verwenden IP-Adressen gemeinsam.

Wenn Sie die Größe hoch- oder herunterskaliert haben, wird der erforderliche Adressraum für einen kurzen Zeitraum verdoppelt. Dies wirkt sich auf die tatsächlichen, verfügbaren unterstützten Instanzen für eine bestimmte Subnetzgröße aus. Die folgende Tabelle zeigt sowohl die maximal verfügbaren Adressen pro CIDR-Block als auch die Auswirkungen auf die horizontale Skalierung:

CIDR-Blockgröße Maximal verfügbare Adressen Maximale horizontale Skalierung (Instanzen)*
/28 11 5
/27 27 13
/26 59 29

*Geht davon aus, dass irgendwann ein Hoch- oder Herunterskalieren der Größe oder SKU erforderlich ist.

Da die Subnetzgröße nach der Zuweisung nicht mehr geändert werden kann, verwenden Sie ein Subnetz, das für die Aufnahme jedweder Skalierung Ihrer App groß genug ist. Um Probleme mit der Subnetzkapazität für Functions Elastic Premium-Pläne zu vermeiden, sollten Sie /24 mit 256 Adressen für Windows und /26 mit 64 Adressen für Linux verwenden. Beim Erstellen von Subnetzen im Azure-Portal im Rahmen der Integration in das virtuelle Netzwerk ist eine Mindestgröße von /24 oder /26 für Windows bzw. Linux erforderlich.

Wenn Ihre Apps in einem anderen Plan ein virtuelles Netzwerk erreichen sollen, das bereits mit Apps in einem anderen Plan verbunden ist, müssen Sie ein anderes Subnetz auswählen als das von der bereits vorhandenen Integration virtueller Netzwerke verwendete Subnetz.

Das Feature wird für Windows- und Linux-Apps vollständig unterstützt, einschließlich benutzerdefinierten Containern. Das Verhalten ist in Windows- und Linux-Apps gleich.

Netzwerksicherheitsgruppen

Mit Netzwerksicherheitsgruppen können Sie eingehenden und ausgehenden Datenverkehr an Ressourcen in einem virtuellen Netzwerk blockieren. Eine App mit regionaler VNet-Integration kann eine Netzwerksicherheitsgruppe verwenden, um ausgehenden Datenverkehr an Ressourcen in Ihrem virtuellen Netzwerk oder im Internet zu blockieren. Wenn Datenverkehr an öffentliche Adressen blockiert werden soll, muss die Integration des virtuellen Netzwerks mit der Option „Route All“ (Gesamten Datenverkehr weiterleiten) aktiviert sein. Die Regeln für eingehenden Datenverkehr in einer NSG gelten nicht für Ihre App, weil sich die VNet-Integration nur auf ausgehenden Datenverkehr von Ihrer App auswirkt.

Um den eingehenden Datenverkehr für Ihre App zu steuern, verwenden Sie das Feature für Zugriffsbeschränkungen. Eine NSG, die auf Ihr Integrationssubnetz angewendet wird, ist unabhängig von den Routen wirksam, die auf Ihr Integrationssubnetz angewendet werden. Wenn die Integration des virtuellen Netzwerks mit aktivierter Option „Route all“ (Gesamten Datenverkehr weiterleiten) erfolgt ist und Sie über keine Routen verfügen, die sich auf den Datenverkehr der öffentlichen Adresse in Ihrem Integrationssubnetz auswirken, unterliegt der gesamte ausgehende Datenverkehr den NSGs, die Ihrem Integrationssubnetz zugewiesen sind. Ist „Route All“ (Gesamten Datenverkehr weiterleiten) nicht aktiviert, werden NSGs nur auf RFC1918-Datenverkehr angewendet.

Routen

Sie können mithilfe von Routingtabellen ausgehenden Datenverkehr von Ihrer App an beliebige Ziele weiterleiten. Routingtabellen wirken sich standardmäßig nur auf Datenverkehr mit dem Ziel RFC1918 aus. Wenn „Route All“ (Gesamten Datenverkehr weiterleiten) aktiviert ist, sind alle ausgehenden Aufrufe betroffen. Wenn Route All (Gesamten Datenverkehr weiterleiten) deaktiviert ist, ist nur privater Datenverkehr (RFC1918) von Ihren Routingtabellen betroffen. Routen, die für Ihr Integrationssubnetz festgelegt werden, wirken sich nicht auf Antworten auf eingehende App-Anforderungen aus. Gängige Ziele können Firewallgeräte oder Gateways beinhalten.

Wenn Sie den gesamten ausgehenden Datenverkehr lokal weiterleiten möchten, können Sie eine Routingtabelle verwenden, um den gesamten ausgehenden Datenverkehr an das ExpressRoute-Gateway zu senden. Wenn Sie Datenverkehr nicht an ein Gateway weiterleiten, müssen Sie unbedingt Routen im externen Netzwerk festlegen, über die Antworten zurückgesendet werden.

BGP-Routen (Border Gateway Protocol) wirken sich ebenfalls auf den App-Datenverkehr aus. Wenn Sie über BGP-Routen von einem ExpressRoute-Gateway verfügen, ist der ausgehende Datenverkehr Ihrer App betroffen. BGP-Routen wirken sich standardmäßig nur auf Datenverkehr mit dem Ziel RFC1918 aus. Wenn Ihre Funktions-App in ein virtuelles Netzwerk mit aktivierter Option „Route All“ (Gesamten Datenverkehr weiterleiten) integriert ist, können sich Ihre BGP-Routen auf den gesamten ausgehenden Datenverkehr auswirken.

Azure DNS Private Zones

Nachdem Ihre App in Ihr virtuelles Netzwerk integriert wurde, nutzt sie den gleichen DNS-Server, mit dem Ihr virtuelles Netzwerk konfiguriert ist, und funktioniert mit den privaten Azure DNS-Zonen, die mit dem virtuellen Netzwerk verknüpft sind.

Einschränken Ihres Speicherkontos auf ein virtuelles Netzwerk

Hinweis

Um schnell eine Funktions-App mit privaten Endpunkten bereitzustellen, die für das Speicherkonto aktiviert sind, verwenden Sie diese Vorlage: Funktions-App mit privaten Azure Storage-Endpunkten.

Beim Erstellen einer Funktions-App müssen Sie ein allgemeines Azure Storage-Konto erstellen oder verknüpfen, das Blob-, Queue- und Table Storage unterstützt. Sie können dieses Speicherkonto durch eines ersetzen, das mit Dienstendpunkten oder privaten Endpunkten geschützt ist.

Dieses Feature wird für alle Windows- und Linux-SKUs mit Unterstützung für virtuelle Netzwerke im Plan „Dedicated“ (App Service) und für die Elastic Premium-Pläne sowie für den Flex-Verbrauch-Plan unterstützt. Der Verbrauchsplan wird nicht unterstützt. Informationen zum Einrichten einer Funktion mit einem Speicherkonto, das auf ein privates Netzwerk beschränkt ist, finden Sie unter Einschränken des Speicher Kontos für ein virtuelles Netzwerk.

Verwenden von Key Vault-Verweisen

Sie können mithilfe von Azure Key Vault-Verweisen Geheimnisse aus Ihrer Azure Key Vault-Instanz in Ihrer Azure Functions-Anwendung verwenden, ohne dass Codeänderungen erforderlich sind. Azure Key Vault ist ein Dienst, der eine zentralisierte Verwaltung von Geheimnissen mit voller Kontrolle über Zugriffsrichtlinien und Überprüfungsverlauf ermöglicht.

Wenn für die App die VNet-Integration konfiguriert ist, können Key Vault-Verweise zum Abrufen von Geheimnissen aus einem Tresor mit Netzwerkeinschränkung verwendet werden.

Trigger für virtuelle Netzwerke (nicht HTTP)

HTTP-fremde Triggerfunktionen können aktuell auf zwei Arten von einem virtuellen Netzwerk aus verwendet werden:

  • Führen Sie Ihre Funktions-App in einem Elastic Premium-Plan aus und aktivieren Sie die Unterstützung für virtuelle Netzwerktrigger.
  • Sie können Ihre Funktions-App in einem Flex-Verbrauch-Plan, App Service-Plan oder in einer App Service-Umgebung ausführen.

Elastic Premium-Plan mit Triggern für virtuelle Netzwerke

Mit dem Elastic Premium-Tarif können Sie Funktionen erstellen, die von Diensten innerhalb eines virtuellen Netzwerks ausgelöst werden. Diese Nicht-HTTP-Trigger werden als virtuelle Netzwerktrigger bezeichnet.

Standardmäßig führen virtuelle Netzwerktrigger nicht dazu, dass sie von Ihrer Funktions-App über die Anzahl ihrer vorab aufgewärmten Instanzen hinaus skaliert werden. Bestimmte Erweiterungen unterstützen jedoch virtuelle Netzwerktrigger, die dazu führen, dass sie von Ihrer Funktions-App dynamisch skaliert werden. Sie können diese Überwachung der dynamischen Skalierung in Ihrer Funktions-App für unterstützte Erweiterungen auf eine der folgenden Arten aktivieren:

  1. Navigieren Sie im Azure-Portal zu Ihrer Funktions-App.

  2. Wählen Sie unter Einstellungen die Option Konfiguration aus, und legen Sie dann auf der Registerkarte Einstellungen der Funktionsruntime Überwachung der Runtimeskalierung auf Ein fest.

  3. Wählen Sie Speichern aus, um die Konfiguration der Funktions-App zu aktualisieren, und starten Sie die App neu.

VNETToggle

Tipp

Das Aktivieren der Überwachung virtueller Netzwerktrigger hat möglicherweise Auswirkungen auf die Leistung Ihrer Anwendung, obwohl diese Auswirkung wahrscheinlich sehr gering ist.

Die Unterstützung für die Überwachung der dynamischen Skalierung virtueller Netzwerktrigger ist in der Version 1.x der Funktionsruntime nicht verfügbar.

Die Erweiterungen in dieser Tabelle unterstützen die Überwachung der dynamischen Skalierung virtueller Netzwerktrigger. Um die beste Skalierungsleistung zu erzielen, sollten Sie ein Upgrade auf Versionen durchführen, die auch die zielbasierte Skalierung unterstützen.

Erweiterung (Mindestversion) Nur Überwachung der Runtimeskalierung Mit zielbasierter Skalierung
Microsoft.Azure.WebJobs.Extensions.CosmosDB > 3.0.5 > 4.1.0
Microsoft.Azure.WebJobs.Extensions.DurableTask > 2.0.0 –
Microsoft.Azure.WebJobs.Extensions.EventHubs > 4.1.0 > 5.2.0
Microsoft.Azure.WebJobs.Extensions.ServiceBus > 3.2.0 > 5.9.0
Microsoft.Azure.WebJobs.Extensions.Storage > 3.0.10 > 5.1.0*

* Nur Warteschlangenspeicher.

Wichtig

Wenn Sie die Überwachung virtueller Netzwerktrigger aktivieren, können nur Trigger für diese Erweiterungen dazu führen, dass Ihre App dynamisch skaliert wird. Sie können zwar weiterhin Trigger aus Erweiterungen verwenden, die sich nicht in dieser Tabelle befinden, aber sie führen nicht dazu, dass sie über die Anzahl ihrer vorab aufgewärmten Instanzen hinaus skaliert werden. Eine vollständige Liste aller Trigger- und Bindungserweiterungen finden Sie unter Trigger und Bindungen.

App Service-Plan und App Service-Umgebung mit Triggern für virtuelle Netzwerke

Wenn Ihre Funktions-App entweder in einem App Service-Plan oder in einer App Service-Umgebung ausgeführt wird, können Sie HTTP-fremde Triggerfunktionen verwenden. Damit Ihre Funktionen ordnungsgemäß ausgelöst werden, muss eine Verbindung mit einem virtuellen Netzwerk bestehen. Außerdem muss auf die in der Triggerverbindung definierte Ressource zugegriffen werden können.

Angenommen, Sie möchten Azure Cosmos DB so konfigurieren, dass nur Datenverkehr aus einem virtuellen Netzwerk akzeptiert wird. In diesem Fall müssen Sie Ihre Funktions-App in einem App Service-Plan bereitstellen, der die VNET-Integration mit diesem virtuellen Netzwerk ermöglicht. Die Integration ermöglicht das Auslösen einer Funktion durch diese Azure Cosmos DB-Ressource.

Hybridverbindungen

Hybrid Connections ist ein Feature von Azure Relay, das Sie zum Zugreifen auf Anwendungsressourcen in anderen Netzwerken verwenden können. Es ermöglicht den Zugriff von Ihrer App auf einen Anwendungsendpunkt. Sie können es nicht verwenden, um auf Ihre Anwendung zuzugreifen. Hybrid Connections steht für Funktionen unter Windows in allen Tarifen (mit Ausnahme des Verbrauchstarifs) zur Verfügung.

Bei der Verwendung in Azure Functions entspricht jede Hybridverbindung einer Kombination aus einem einzelnen TCP-Host und einem Port. Dies bedeutet, dass sich der Hybridverbindungsendpunkt in einem beliebigen Betriebssystem und einer beliebigen Anwendung befinden kann, solange der Zugriff über einen TCP-Überwachungsport erfolgt. Das Feature „Hybrid Connections“ verfügt nicht über Informationen zum Anwendungsprotokoll oder zum abzurufenden Inhalt und benötigt diese Informationen auch nicht. Es ermöglicht lediglich den Netzwerkzugriff.

Weitere Informationen finden Sie in der App Service-Dokumentation zu Hybrid Connections. Diese Konfigurationsschritte unterstützen auch Azure Functions.

Wichtig

Hybrid Connections wird nur in Windows-Tarifen unterstützt. Linux wird nicht unterstützt.

IP-Einschränkungen für ausgehenden Datenverkehr

IP-Einschränkungen für ausgehenden Datenverkehr sind in einem Flex-Verbrauch-Plan, Elastic Premium-Plan, einem App Service-Plan oder in einer App Service-Umgebung verfügbar. Sie können ausgehende Einschränkungen für das virtuelle Netzwerk konfigurieren, wo Ihre App Service-Umgebung bereitgestellt wird.

Wenn Sie eine Funktions-App in einen Elastic Premium-Tarif oder einen App Service-Plan mit einem virtuellen Netzwerk integrieren, kann die App standardmäßig weiterhin ausgehende Aufrufe ins Internet vornehmen. Durch die Integration Ihrer Funktions-App in ein virtuelles Netzwerk mit aktivierter Option „Route All“ (Gesamten Datenverkehr weiterleiten) erzwingen Sie, dass der gesamte ausgehende Datenverkehr an Ihr virtuelles Netzwerk gesendet wird, in dem gegebenenfalls Netzwerksicherheitsgruppen-Regeln zum Einschränken des Datenverkehrs angewendet werden. Für Flex-Verbrauch wird der gesamte Datenverkehr bereits über das virtuelle Netzwerk weitergeleitet, und „Route All“ ist nicht erforderlich.

Informationen zum Steuern der ausgehenden IP-Adresse mithilfe eines virtuellen Netzwerks finden Sie unter Tutorial: Steuern der ausgehenden IP-Adresse von Azure Functions mit einem Azure Virtual Network-NAT-Gateway.

Automation

Die folgenden APIs ermöglichen es Ihnen, regionale Integrationen virtueller Netzwerke programmgesteuert zu verwalten:

  • Azure CLI: Verwenden Sie die Befehle az functionapp vnet-integration, um eine regionale Integration des virtuellen Netzwerks hinzuzufügen, aufzulisten oder zu entfernen.
  • ARM-Vorlagen: Die Integration regionaler virtueller Netzwerke kann mithilfe einer Azure Resource Manager-Vorlage aktiviert werden. Ein vollständiges Beispiel finden Sie in dieser Functions-Schnellstartvorlage.

Testüberlegungen

Wenn Sie Funktionen in einer Funktions-App mit privaten Endpunkten testen, müssen Sie Ihre Tests innerhalb desselben virtuellen Netzwerks durchführen, z. B. auf einem virtuellen Computer (VM) in diesem Netzwerk. Um die Option Code + Test im Portal von dieser VM aus verwenden zu können, müssen Sie Ihrer Funktions-App die folgenden CORS-Ursprünge hinzufügen:

  • https://functions-next.azure.com
  • https://functions-staging.azure.com
  • https://functions.azure.com
  • https://portal.azure.com

Wenn Sie den Zugriff auf Ihre Funktions-App mit privaten Endpunkten oder einer anderen Zugriffseinschränkung eingeschränkt haben, müssen Sie auch das Diensttag AzureCloud zur Positivliste hinzufügen. So aktualisieren Sie die Positivliste:

  1. Navigieren Sie zu Ihrer Funktions-App, und wählen Sie Einstellungen>Netzwerk und dann Konfiguration für eingehenden Zugriff>Öffentlicher Netzwerkzugriff aus.

  2. Vergewissern Sie sich, dass die Einstellung Öffentlicher Netzwerkzugriff auf Aus ausgewählten virtuellen Netzwerken und IP-Adressen aktiviert festgelegt ist.

  3. Wählen Sie unter „Websitezugriff und -regeln“ die Option Regel hinzufügen aus:

    1. Wählen Sie Service Tag als Typ für die Quelleinstellungen und AzureCloud als Diensttag aus.

    2. Stellen Sie sicher, dass die Aktion Zulassen ausgewählt ist, und legen Sie den gewünschten Namen und die gewünschte Priorität fest.

Problembehandlung

Die Funktion ist zwar einfach einzurichten, dies bedeutet jedoch nicht, dass keinerlei Probleme auftreten. Sollten beim Zugreifen auf den gewünschten Endpunkt Probleme auftreten, können Sie einige Hilfsprogramme verwenden, um die Verbindung über die App-Konsole zu testen. Sie können zwei Konsolen verwenden. Eine ist die Kudu-Konsole, und die andere ist die Konsole im Azure-Portal. Greifen Sie in der App auf Tools>Kudu zu, um zur Kudu-Konsole zu gelangen. Sie können auch die Kudo-Konsole unter „[sitename].scmn.azurewebsites.net“ erreichen. Wechseln Sie nach dem Laden der Website zur Registerkarte Debugging-Konsole. Um auf die über das Azure-Portal gehostete Konsole zuzugreifen, navigieren Sie in der App zu Extras>Konsole.

Tools

In nativen Windows-Apps funktionieren die Tools ping, nslookup und tracert funktionieren aufgrund von Sicherheitseinschränkungen nicht über die Konsole (sie funktionieren in benutzerdefinierten Windows-Containern). Es wurden zwei separate Tools hinzugefügt, um diese Lücke zu füllen. Zum Testen der DNS-Funktionalität haben wir ein Tool mit dem Namen nameresolver.exe hinzugefügt. Die Syntax ist:

nameresolver.exe hostname [optional: DNS Server]

Sie können „nameresolver“ verwenden, um die Hostnamen zu überprüfen, von denen Ihre App abhängig ist. So können Sie testen, ob für das DNS etwas falsch konfiguriert ist oder ob ggf. kein Zugriff auf Ihren DNS-Server besteht. Den von Ihrer App verwendeten DNS-Server können Sie in der Konsole in den Umgebungsvariablen WEBSITE_DNS_SERVER und WEBSITE_DNS_ALT_SERVER einsehen.

Hinweis

Das Tool „nameresolver.exe“ funktioniert zurzeit nicht in benutzerdefinierten Windows-Containern.

Mit dem nächsten Tool können Sie die TCP-Verbindung mit einer Host-Port-Kombination testen. Dieses Tool hat den Namen tcpping und die folgende Syntax:

tcpping.exe hostname [optional: port]

Das tcpping-Hilfsprogramm teilt Ihnen mit, ob Sie einen bestimmten Host und Port erreichen können. Es kann nur unter folgenden Bedingungen erfolgreich ausgeführt werden: Eine Anwendung lauscht auf der Host- und Portkombination, und von Ihrer App aus ist Netzwerkzugriff auf den angegebenen Host und Port möglich.

Debuggen des Zugriffs auf im virtuellen Netzwerk gehostete Ressourcen

Es gibt verschiedene Gründe, aus denen Ihre App einen bestimmten Host und Port nicht erreichen kann. In den meisten Fällen liegt eine der drei folgenden Ursachen vor:

  • Eine Firewall. Falls eine Firewall den Zugriff verhindert, wird das TCP-Timeout ausgelöst. Das TCP-Timeout entspricht hier 21 Sekunden. Überprüfen Sie die Verbindung mithilfe des tcpping-Tools. TCP-Timeouts können zwar auch viele andere Ursachen haben, es empfiehlt sich jedoch, bei der Firewall zu beginnen.
  • Kein DNS-Zugriff. Das DNS-Timeout beträgt 3 Sekunden pro DNS-Server. Wenn Sie zwei DNS-Server besitzen, beträgt das Timeout 6 Sekunden. Überprüfen Sie mithilfe des nameresolver-Tools, ob DNS funktioniert. Das nslookup-Tool kann nicht verwendet werden, da es nicht das DNS verwendet, mit dem Ihr virtuelles Netzwerk konfiguriert ist. Dieses Problem kann darauf zurückzuführen sein, dass eine Firewall oder Netzwerksicherheitsgruppe den Zugriff auf das DNS blockiert.

Sollte das Problem weiterhin bestehen, überprüfen Sie zunächst Folgendes:

Regionale Integration des virtuellen Netzwerks

  • Ist Ihr Ziel eine RFC 1918-fremde Adresse und Route All (Gesamten Datenverkehr weiterleiten) nicht aktiviert?
  • Blockiert eine Netzwerksicherheitsgruppe ausgehenden Datenverkehr aus Ihrem Integrationssubnetz?
  • Bei einer Verbindung über Azure ExpressRoute oder ein VPN: Ist Ihr lokales Gateway zum Zurückleiten von Datenverkehr an Azure konfiguriert? Wenn Sie die Endpunkte in Ihrem virtuellen Netzwerk erreichen können, aber nicht lokal, überprüfen Sie Ihre Routen.
  • Verfügen Sie über ausreichende Berechtigungen, um Delegierung für das Integrationssubnetz festzulegen? Während der Konfiguration der Integration des regionalen virtuellen Netzwerks wird Ihr Integrationssubnetz an „Microsoft.Web/serverFarms“ delegiert. Das Subnetz wird von der Benutzeroberfläche der VNET-Integration automatisch an „Microsoft.Web/serverFarms“ delegiert. Wenn Ihr Konto nicht über ausreichende Netzwerkberechtigungen verfügt, um Delegierung festzulegen, benötigen Sie eine Person, die in Ihrem Integrationssubnetz Attribute festlegen kann, um das Subnetz zu delegieren. Wenn Sie das Subnetz für die Integration manuell delegieren möchten, wechseln Sie zur Benutzeroberfläche des Azure Virtual Network-Subnetzes, und legen Sie die Delegierung für „Microsoft.Web/serverFarms“ fest.

Integration des virtuellen Netzwerks mit erforderlichem Gateway

  • Liegt der Point-to-Site-Adressbereich in den RFC 1918-Bereichen (10.0.0.0-10.255.255.255/172.16.0.0-172.31.255.255/192.168.0.0-192.168.255.255)?
  • Wird im Portal angezeigt, dass das Gateway ausgeführt wird? Fahren Sie das Gateway hoch, wenn es heruntergefahren ist.
  • Werden Zertifikate als synchronisiert angezeigt, oder vermuten Sie, dass die Netzwerkkonfiguration geändert wurde? Wenn Ihre Zertifikate nicht synchronisiert sind oder Sie vermuten, dass an Ihrer VNET-Konfiguration eine Änderung vorgenommen wurde, die nicht mit Ihren ASPs synchronisiert wurde, wählen Sie Netzwerk synchronisieren aus.
  • Bei einer Verbindung über ein VPN: Ist Ihr lokales Gateway zum Zurückleiten von Datenverkehr an Azure konfiguriert? Wenn Sie die Endpunkte in Ihrem virtuellen Netzwerk erreichen können, aber nicht lokal, überprüfen Sie Ihre Routen.
  • Versuchen Sie, ein Koexistenzgateway zu verwenden, das sowohl Point-to-Site als auch ExpressRoute unterstützt? Koexistenzgateways werden bei der Integration virtueller Netzwerke nicht unterstützt.

Das Debuggen von Netzwerkproblemen ist eine Herausforderung, da Sie nicht sehen können, was den Zugriff auf eine bestimmte Host:Port-Kombination blockiert. Mögliche Ursachen:

  • Sie verfügen über eine aktivierte Firewall auf Ihrem Host, die den Zugriff auf den Anwendungsport über Ihren Point-to-Site-IP-Adressbereich verhindert Für die Durchquerung von Subnetzen ist häufig öffentlicher Zugriff erforderlich.
  • Zielhost ausgefallen
  • Anwendung nicht verfügbar
  • Falsche IP-Adresse oder falscher Hostname
  • Die Anwendung lauscht über einen anderen Port als erwartet. Sie können Ihre Prozess-ID auf den lauschenden Port festlegen, indem Sie auf dem Endpunkthost „netstat -aon“ verwenden.
  • Netzwerksicherheitsgruppen sind so konfiguriert, dass der Zugriff auf Ihren Anwendungshost und -port aus Ihrem Point-to-Site-IP-Adressbereich verhindert wird.

Ihnen ist nicht bekannt, welche Adresse Ihre App tatsächlich verwendet. Es kann sich um eine beliebige Adresse im Integrationssubnetz oder Point-to-Site-Adressbereich handeln. Sie müssen daher den Zugriff vom gesamten Adressbereich zulassen.

Weitere Debugschritte sind unter anderem:

  • Stellen Sie eine Verbindung mit einer VM im virtuellen Netzwerk her, und versuchen Sie, die Ressource host:port von dort aus zu erreichen. Zum Testen des TCP-Zugriffs verwenden Sie den PowerShell-Befehl Test-NetConnection. Die Syntax ist:
Test-NetConnection hostname [optional: -Port]
  • Rufen Sie eine Anwendung auf einer VM auf, und testen Sie den Zugriff auf den jeweiligen Host und Port über die Konsole der App mit tcpping.

Lokale Ressourcen

Wenn Ihre App eine Ressource lokal nicht erreichen kann, überprüfen Sie, ob Sie die Ressource über Ihr virtuelles Netzwerk erreichen können. Verwenden Sie den PowerShell-Befehl Test-NetConnection, um den TCP-Zugriff zu überprüfen. Wenn Ihre VM die lokale Ressource nicht erreichen kann, ist Ihre VPN- oder ExpressRoute-Verbindung möglicherweise nicht richtig konfiguriert.

Wenn die im virtuellen Netzwerk gehostete VM auf ein lokales System zugreifen kann, die App jedoch nicht, trifft wahrscheinlich einer der folgenden Gründe zu:

  • Die Routen sind in Ihrem lokalen Gateway nicht mit Ihren Subnetz- oder Point-to-Site-Adressbereichen konfiguriert.
  • Die Netzwerksicherheitsgruppen blockieren den Zugriff auf den Point-to-Site-IP-Adressbereich.
  • Die lokalen Firewalls blockieren den Datenverkehr des Point-to-Site-IP-Adressbereichs.
  • Sie versuchen, eine RFC 1918-fremde Adresse mit der Funktion für die Integration regionaler virtueller Netzwerke zu erreichen.

Löschen des App Service-Plans oder der Web-App vor dem Trennen der VNet-Integration

Wenn Sie die Web-App oder den App Service-Plan gelöscht haben, ohne zuvor die VNet-Integration aufzuheben, können Sie keine Aktualisierungs-/Löschvorgänge in dem virtuellen Netzwerk oder Subnetz durchführen, das für die Integration mit der gelöschten Ressource verwendet wurde. Eine Subnetzdelegierung von „Microsoft.Web/serverFarms“ bleibt Ihrem Subnetz zugewiesen und verhindert die Aktualisierungs-/Löschvorgänge.

Um das Subnetz oder virtuelle Netzwerk erneut zu aktualisieren oder zu löschen, müssen Sie die VNet-Integration neu erstellen und dann die Verbindung trennen:

  1. Erstellen Sie den App Service-Plan und die Web-App neu (Sie müssen unbedingt genau denselben Web-App-Namen wie zuvor verwenden).
  2. Navigieren Sie in der Web-App zum Blatt „Netzwerk“, und konfigurieren Sie die VNet-Integration.
  3. Nachdem die VNet-Integration konfiguriert wurde, wählen Sie die Schaltfläche „Trennen“ aus.
  4. Löschen Sie den App Service-Plan oder die Web-App.
  5. Aktualisieren/Löschen Sie das Subnetz oder das virtuelle Netzwerk.

Wenn nach dem Ausführen der obigen Schritte weiterhin Probleme mit der VNet-Integration auftreten, wenden Sie sich an den Microsoft-Support.

Netzwerkproblembehandlung

Sie können auch die Netzwerkproblembehandlung verwenden, um Verbindungsprobleme zu beheben. Rufen Sie die App im Azure-Portal auf, um die Netzwerkproblembehandlung zu öffnen. Wählen Sie Diagnose und Problemlösung aus, und suchen Sie dann nach Netzwerkproblembehandlung.

Verbindungsprobleme: Überprüft den Status der VNet-Integration, einschließlich einer Überprüfung, ob allen Instanzen des Plans und in den DNS-Einstellungen eine private IP-Adresse zugewiesen wurde. Wenn kein benutzerdefiniertes DNS konfiguriert ist, wird das standardmäßige Azure DNS verwendet. Die Problembehandlung prüft außerdem auf gängige Abhängigkeiten von Funktions-Apps, darunter die Konnektivität für Azure Storage und andere Bindungsabhängigkeiten.

Screenshot, der eine laufende Problembehandlung für Verbindungsprobleme zeigt.

Konfigurationsprobleme: Überprüft, ob Ihr Subnetz für die VNet-Integration zulässig ist.

Screenshot, der eine laufende Problembehandlung für Konfigurationsprobleme zeigt.

Problem beim Löschen von Subnetz/VNet: Überprüft, ob für Ihr Subnetz Sperren vorliegen und ob nicht verwendete Dienstzuordnungslinks vorhanden sind, die eine Löschung des VNet/Subnetzes blockieren könnten.

Nächste Schritte

Weitere Informationen zum Netzwerk und zu Azure Functions: