Integrieren Ihrer App in ein Azure Virtual Network

Hinweis

Ab dem 1. Juni 2024 haben alle neu erstellten App Service-Apps die Möglichkeit, einen eindeutigen Standardhostnamen mit der Namenskonvention <app-name>-<random-hash>.<region>.azurewebsites.net zu erstellen. Vorhandene App-Namen bleiben unverändert.

Beispiel: myapp-ds27dh7271aah175.westus-01.azurewebsites.net

Ausführlichere Informationen finden Sie unter Eindeutiger Standardhostname für App Service-Ressourcen.

In diesem Artikel wird die Azure App Service-Funktion für die Integration in ein virtuelles Netzwerk beschrieben, und Sie erfahren, wie Sie die Funktion mit Apps in App Service einrichten. Mit virtuellen Azure-Netzwerken können Sie viele Ihrer Azure-Ressourcen in einem Netzwerk platzieren, das nicht über das Internet geroutet werden kann. Die App Service-Funktion für die Integration in ein virtuelles Netzwerk ermöglicht Ihren Apps den Zugriff auf Ressourcen in einem virtuellen Netzwerk oder über ein virtuelles Netzwerk.

Hinweis

Informationen zur Integration virtueller Netzwerke, die für das Gateway erforderlich sind, wurden an einen neuen Speicherort verschoben.

Es gibt zwei Varianten der Nutzung von App Service:

• 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. Wenn sich Ihre App in einer App Service-Umgebung befindet, ist sie bereits in ein virtuelles Netzwerk integriert und erfordert nicht, dass Sie das Integrationsfeature für virtuelle Netzwerke konfigurieren, um Ressourcen in demselben 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. Weitere Informationen finden Sie unter private Endpunkte für eingehenden privaten Zugriff.

Die Funktion Integration eines virtuellen Netzwerks:

• Erfordert einen unterstützen App Service-Tarif des Typs Basic oder Standard, Premium, Premium v2, Premium v3 oder Elastic Premium.
• Unterstützt TCP und UDP
• Funktioniert mit App Service-Apps, Funktions-Apps und Logik-Apps.

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 unterstützt das Herstellen einer Verbindung mit einem virtuellen Netzwerk in derselben Region. Die Verwendung der Integration virtueller Netzwerke ermöglicht der App Zugriff auf Folgendes:

• Ressourcen im virtuellen Netzwerk, in das Sie integriert sind
• Ressourcen in virtuellen Netzwerken, die per Peering mit dem virtuellen Netzwerk verbunden sind, in das Ihre App integriert ist, einschließlich Verbindungen mit globalem Peering
• Ressourcen über Azure ExpressRoute-Verbindungen.
• Durch Dienstendpunkte geschützte Dienste
• Dienste, von denen private Endpunkte unterstützt werden

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

• Netzwerksicherheitsgruppen (NSGs): Sie können ausgehenden Datenverkehr mit einer NSG blockieren, die Sie in Ihrem Integrationssubnetz verwenden. 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.
• NAT-Gateway: Sie können NAT-Gateway verwenden, um eine dedizierte ausgehende IP-Adresse abzurufen und die SNAT-Portauslastung zu verringern.

Erfahren Sie, wie Sie die Integration virtueller Netzwerke aktivieren.

Funktionsweise der virtuellen Netzwerkintegration

Apps in App Service werden auf Workerrollen gehostet. Die Integration virtueller Netzwerke beruht auf der Einbindung virtueller Schnittstellen in die Workerrollen mit Adressen im delegierten Subnetz. Die verwendeten virtuellen Schnittstellen sind keine Ressourcen, auf die Kunden direkten Zugriff haben. Da sich die Von-Adresse in Ihrem virtuellen Netzwerk befindet, kann sie ähnlich wie eine VM in Ihrem virtuellen Netzwerk auf die meisten Ressourcen zugreifen, die in Ihrem oder über Ihr virtuelles Netzwerk verfügbar sind.

Wenn die Integration virtueller Netzwerke aktiviert ist, sendet Ihre App ausgehende Aufrufe über das virtuelle Netzwerk. Ihre App verwendet nach wie vor die ausgehenden Adressen, die im Portal für die App-Eigenschaften aufgeführt sind. Wenn Ihr ausgehender Aufruf jedoch an einen virtuellen Computer oder einen privaten Endpunkt im virtuellen Integrationsnetzwerk oder einem virtuellen Netzwerk mit Peering gerichtet ist, ist die ausgehende Adresse eine Adresse aus dem Integrationssubnetz. Die private IP-Adresse, die einer Instanz zugewiesen ist, wird über die Umgebungsvariable „WEBSITE_PRIVATE_IP“ verfügbar gemacht.

Wenn das gesamte Datenverkehrsrouting aktiviert ist, wird der gesamte ausgehende Datenverkehr an Ihr virtuelles Netzwerk gesendet. Ist das gesamte Datenverkehrsrouting deaktiviert, werden nur privater Datenverkehr (RFC1918) und Dienstendpunkte, die im Integrationssubnetz konfiguriert sind, an das virtuelle Netzwerk gesendet. Ausgehender Datenverkehr in das Internet wird direkt von der App weitergeleitet.

Die virtuelle Netzwerkintegration unterstützt zwei virtuelle Schnittstellen pro Worker. Zwei virtuelle Schnittstellen pro Worker bedeuten zwei Integrationen virtueller Netzwerke pro App Service-Plan. Anders ausgedrückt: Ein App Service-Plan kann virtuelle Netzwerkintegrationen mit bis zu zwei Subnetzen/virtuellen Netzwerken enthalten. Die zu einem App Service-Plan gehörigen Apps können nur eine der virtuellen Netzwerkintegrationen in ein bestimmtes Subnetz verwenden. Das bedeutet, dass eine App zu einem bestimmten Zeitpunkt nur über eine einzelne virtuelle Netzwerkintegration verfügen kann.

Subnetzanforderungen

Die Integration virtueller Netzwerke hängt von der Verwendung eines dedizierten Subnetzes ab. Wenn Sie ein Subnetz erstellen, verbraucht das Azure-Subnetz von Anfang an fünf IP-Adressen. Für jede Instanz des App Service-Plans wird eine Adresse aus dem Integrationssubnetz verwendet. Wenn Sie Ihre App auf vier Instanzen skalieren, werden vier Adressen verwendet.

Wenn Sie in der Instanzgröße nach oben/unten skalieren, wird die Anzahl der vom App Service-Plan verwendeten IP-Adressen vorübergehend verdoppelt, während der Skalierungsvorgang abgeschlossen wird. Die neuen Instanzen müssen vollständig betriebsbereit sein, bevor die bestehenden Instanzen nicht mehr bereitgestellt werden. Der Skalierungsvorgang wirkt sich auf die tatsächlichen, verfügbaren unterstützten Instanzen für eine bestimmte Subnetzgröße aus. Plattformupgrades setzen freie IP-Adressen voraus, um sicherzustellen, dass das Upgrade ohne Unterbrechung des ausgehenden Datenverkehrs durchgeführt werden kann. Nach Abschluss des Hoch-, Herunter- oder Abskalierens kann es eine kurze Zeit dauern, bis IP-Adressen freigegeben werden. In seltenen Fällen kann dieser Vorgang bis zu 12 Stunden dauern, und wenn Sie schnell auf-/abskalieren oder hoch-/herunterskalieren, benötigen Sie mehr IP-Adressen als bei der maximalen Skalierung.

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. Sie sollten auch IP-Adressen für Plattformupgrades reservieren. Um Probleme mit der Subnetzkapazität zu vermeiden, wird empfohlen, die IP-Adressen Ihrer geplanten maximalen Skalierung zu verdoppeln. Bei /26 mit 64 Adressen wird die maximale Skalierung eines einzelnen App Service-Plans für mehrere Mandanten abgedeckt. Beim Erstellen von Subnetzen im Azure-Portal im Rahmen der Integration in das virtuelle Netzwerk ist eine Mindestgröße von /27 erforderlich. Wenn das Subnetz bereits vor der Integration durch das Portal vorhanden ist, können Sie ein /28-Subnetz verwenden.

Mit dem Multiplan-Subnetzbeitritt (multi plan subnet join, MPSJ) können Sie mehrere App Service-Pläne mit demselben Subnetz verbinden. Alle App Service-Pläne müssen sich im selben Abonnement befinden, aber das virtuelle Netzwerk/Subnetz kann sich in einem anderen Abonnement befinden. Jede Instanz aus jedem App Service-Plan erfordert eine IP-Adresse aus dem Subnetz und für die Verwendung von MPSJ eine Mindestgröße des /26-Subnetzes. Wenn Sie beabsichtigen, viele und/oder große Pläne zu verbinden, sollten Sie größere Subnetzbereiche planen.

Wichtig

Aufgrund eines bekannten Fehlers schlägt MPSJ fehl, wenn mehrere Standorte erstellt und versucht wird, die gleichzeitig in das virtuelle Netzwerk zu integrieren. Ein Fix wird in Kürze bereitgestellt. In der Zwischenzeit können Sie das Problem mit einer der folgenden Methoden umgehen:

• Wenn Sie Websites manuell erstellen, erstellen und integrieren Sie die Webseiten einzeln.
• Wenn Sie Websites programmgesteuert erstellen, z. B. mithilfe von Terraform- oder ARM-Vorlagen, fügen Sie jeder Webseite in Ihren Vorlagen ein dependsOn-Element hinzu, damit alle Seiten außer der ersten von der Erstellung der vorherigen Webseite abhängig sind. Dadurch entsteht eine Verzögerung zwischen der Websiteerstellung und der Integration des virtuellen Netzwerks für jeden Standort und wird daher nicht durch den bekannten Fehler blockiert. Weitere Informationen finden Sie unter Definieren der Reihenfolge für die Bereitstellung von Ressourcen in ARM-Vorlagen.

Spezifische Grenzwerte für Windows-Container

Windows Container verwendet eine zusätzliche IP-Adresse pro App für jede Instanz des App Service-Plans, und Sie müssen das Subnetz entsprechend dimensionieren. Wenn Sie beispielsweise 10 Windows Container App Service Plan-Instanzen mit vier ausgeführten Apps haben, benötigen Sie 50 IP-Adressen und zusätzliche Adressen zur Unterstützung der horizontalen (Auf-/Herunter-) Skalierung.

Beispielberechnung:

Für jede Instanz des App Service-Plans benötigen Sie Folgendes: 4 Windows-Container-Apps = 4 IP-Adressen und 1 IP-Adresse pro App Service-Plan-Instanz, also 4 + 1 = 5 IP-Adressen

Für 10 Instanzen: 5 × 10 = 50 IP-Adressen pro App Service-Plan

Da Sie 1 App Service-Plan haben, benötigen Sie 1 × 50 = 50 IP-Adressen.

Darüber hinaus sind Sie durch die Anzahl der Kerne begrenzt, die in der verwendeten Worker-Ebene verfügbar sind. Jeder Kern fügt drei Netzwerkeinheiten hinzu. Der Worker selbst verwendet eine Einheit, und jede virtuelle Netzwerkverbindung verwendet eine Einheit. Die verbleibenden Einheiten können für Apps verwendet werden.

Beispielberechnung:

Die App Service-Plan-Instanz mit view ausgeführten Apps mit der Integration virtueller Netzwerke. Die Apps sind mit zwei verschiedenen Subnetzen (virtuelle Netzwerkverbindungen) verbunden. Diese Konfiguration erfordert sieben Netzwerkeinheiten (1 Worker + 2 Verbindungen + 4 Apps). Die Mindestgröße für die Ausführung dieser Konfiguration wäre I2v2 (4 Kerne × 3 Einheiten = 12 Einheiten).

Mit I1v2 können Sie maximal vier Apps mit derselben (1) Verbindung oder drei Apps mit zwei Verbindungen ausführen.

Berechtigungen

Sie müssen mindestens über die folgenden Berechtigungen für die rollenbasierte Zugriffssteuerung im Subnetz oder eine höhere Ebene verfügen, um die Integration virtueller Netzwerke über das Azure-Portal, die CLI oder beim direkten Festlegen der Site-Eigenschaft virtualNetworkSubnetId zu konfigurieren:

Aktion	BESCHREIBUNG
Microsoft.Network/virtualNetworks/read	Liest die Definition des virtuellen Netzwerks
Microsoft.Network/virtualNetworks/subnets/read	Liest eine Subnetzdefinition für virtuelle Netzwerke aus
Microsoft.Network/virtualNetworks/subnets/join/action	Verknüpft ein virtuelles Netzwerk.

Wenn sich das virtuelle Netzwerk in einem anderen Abonnement als die App befindet, müssen Sie sicherstellen, dass das Abonnement beim virtuellen Netzwerk für den Ressourcenanbieter Microsoft.Web registriert ist. Sie können den Anbieter explizit registrieren, indem Sie diese Dokumentation befolgen. Er wird aber auch automatisch registriert, wenn Sie die erste Web-App in einem Abonnement erstellen.

Routen

Sie können steuern, welcher Datenverkehr über die Integration in ein virtuelles Netzwerk fließt. Es gibt drei Arten von Routing, die Sie beim Konfigurieren der Integration virtueller Netzwerke berücksichtigen sollten. Mit Anwendungsrouting wird definiert, welcher Datenverkehr von Ihrer App an das virtuelle Netzwerk weitergeleitet wird. Konfigurationsrouting wirkt sich auf Vorgänge aus, die vor oder während des Starts Ihrer App ausgeführt werden. Beispiele hierfür sind Pull- und App-Einstellungen mit Key Vault-Verweis für Containerimages. Netzwerkrouting ist die Möglichkeit, zu steuern, wie App- und Konfigurationsdatenverkehr in Ihr und aus Ihrem virtuellen Netzwerk geleitet wird.

Mithilfe der Optionen für das Anwendungs- oder Konfigurationsrouting können Sie konfigurieren, welcher Datenverkehr über die Integration des virtuellen Netzwerks gesendet wird. Datenverkehr unterliegt nur dem Netzwerkrouting, wenn er über die VNet-Integration gesendet wird.

Weiterleitung von Bewerbungen

Anwendungsrouting gilt für Datenverkehr, der von Ihrer App gesendet wird, nachdem sie gestartet wurde. Unter Konfigurationsrouting finden Sie Informationen zum Datenverkehr während des Starts. Wenn Sie das Anwendungsrouting konfigurieren, können Sie entweder den gesamten oder nur privaten Datenverkehr (auch RFC1918-Datenverkehr genannt) an Ihr virtuelles Netzwerk weiterleiten. Sie konfigurieren dieses Verhalten über die Einstellung für ausgehenden Internetdatenverkehr. Wenn ausgehender Internetdatenverkehr deaktiviert ist, wird von Ihrer App nur privater Datenverkehr an Ihr virtuelles Netzwerk weitergeleitet. Wenn Sie den gesamten ausgehenden App-Datenverkehr an Ihr virtuelles Netzwerk weiterleiten möchten, müssen Sie sicherstellen, dass ausgehender Internetdatenverkehr aktiviert ist.

• Nur Datenverkehr, der im Anwendungs- oder Konfigurationsrouting konfiguriert ist, unterliegt den NSGs und UDRs, die auf Ihr Integrationssubnetz angewendet werden.
• Wenn die Weiterleitung des ausgehenden Internetdatenverkehrs aktiviert ist, ist die Quelladresse für den ausgehenden Datenverkehr aus Ihrer App immer noch eine der IP-Adressen, die in den Eigenschaften Ihrer App aufgeführt sind. Wenn Sie den Datenverkehr über eine Firewall oder ein NAT-Gateway leiten, stammt die Quell-IP-Adresse aus diesem Dienst.

Hier erfahren Sie, wie Sie das Anwendungsrouting konfigurieren.

Hinweis

Ausgehende SMTP-Konnektivität (Port 25) wird für App Service unterstützt, wenn der SMTP-Datenverkehr über die Integration virtueller Netzwerke weitergeleitet wird. Die Unterstützungsfähigkeit wird jedoch durch eine Einstellung im Abonnements bestimmt, in dem das virtuelle Netzwerk bereitgestellt ist. Für virtuelle Netzwerke/Subnetze, die vor dem 1. August 2022 erstellt wurden, müssen Sie eine vorübergehende Konfigurationsänderung für das virtuelle Netzwerk/Subnetz vornehmen, damit die Einstellung im Abonnement synchronisiert werden kann. Beispielsweise könnten Sie ein temporäres Subnetz hinzufügen, vorübergehend eine NSG zuordnen/ihre Zuordnung aufheben oder temporär einen Dienstendpunkt konfigurieren. Weitere Informationen finden Sie unter Behandeln von Problemen mit ausgehenden SMTP-Verbindungen in Azure.

Konfigurationsrouting

Wenn Sie die VNet-Integration verwenden, können Sie konfigurieren, wie Teile des Konfigurationsdatenverkehrs verwaltet werden. Standardmäßig wird Konfigurationsdatenverkehr direkt über die öffentliche Route geleitet, aber für die genannten einzelnen Komponenten können Sie aktiv konfigurieren, dass er über die Integration in ein virtuelles Netzwerk geleitet wird.

Inhaltsfreigabe

Standardmäßig verwendet Azure Functions eine Inhaltsfreigabe als Bereitstellungsquelle beim Skalieren von Funktions-Apps unter einem Premium-Plan. Sie müssen eine zusätzliche Einstellung konfigurieren, um sicherzustellen, dass Datenverkehr über die VNet-Integration an diese Inhaltsfreigabe weitergeleitet wird. Weitere Informationen finden Sie unter Konfigurieren des Routings für Inhaltsfreigaben.

Zusätzlich zum Konfigurieren des Routings müssen Sie auch sicherstellen, dass jede Firewall oder Netzwerksicherheitsgruppe, die für Datenverkehr aus dem Subnetz konfiguriert ist, Datenverkehr an Port 443 und 445 zulässt.

Pullen eines Containerimages

Wenn Sie benutzerdefinierte Container verwenden, können Sie den Container über die Integration des virtuellen Netzwerks pullen. Um den Container-Pulldatenverkehr über die Integration des virtuellen Netzwerks weiterzuleiten, müssen Sie sicherstellen, dass die Routingeinstellung konfiguriert ist. Erfahren Sie mehr über das Konfigurieren des Routings für das Pullen von Images.

Sichern/Wiederherstellen

App Service verfügt über integrierte Sicherung/Wiederherstellung, aber wenn Sie in Ihrem eigenen Speicherkonto sichern möchten, können Sie das benutzerdefinierte Sicherungs-/Wiederherstellungsfeature verwenden. Wenn Sie den Datenverkehr über die Integration des virtuellen Netzwerks an das Speicherkonto weiterleiten möchten, müssen Sie die Routeneinstellung konfigurieren. Die Datenbanksicherung wird nicht über die Integration virtueller Netzwerke unterstützt.

App-Einstellungen mit Key Vault-Verweisen

App-Einstellungen, die Key Vault-Verweise verwenden, versuchen, Geheimnisse über die öffentliche Route zu beziehen. Wenn Key Vault Datenverkehr blockiert und die App die Integration in ein virtuelles Netzwerk verwendet, wird versucht, die Geheimnisse über die Integration in ein virtuelles Netzwerk zu erhalten.

Hinweis

• Das Konfigurieren von SSL/TLS-Zertifikaten in privaten Schlüsseltresoren wird derzeit nicht unterstützt.
• App Service-Protokolle in privaten Speicherkonten werden derzeit nicht unterstützt. Es wird empfohlen, die Diagnoseprotokollierung zu verwenden und vertrauenswürdige Dienste für das Speicherkonto zuzulassen.

Routing-App-Einstellungen

Der App-Dienst verfügt über vorhandene App-Einstellungen zum Konfigurieren des Anwendungs- und Konfigurationsroutings. Websiteeigenschaften setzen die App-Einstellungen außer Kraft, wenn beide vorhanden sind. Websiteeigenschaften haben den Vorteil, dass sie mit Azure Policy überwacht und zum Zeitpunkt der Konfiguration überprüft werden können. Es wird empfohlen, Websiteeigenschaften zu verwenden.

Sie können weiterhin die vorhandene WEBSITE_VNET_ROUTE_ALL-App-Einstellung verwenden, um das Anwendungsrouting zu konfigurieren.

App-Einstellungen sind auch für einige Konfigurationsroutingoptionen vorhanden. Diese App-Einstellungen heißen WEBSITE_CONTENTOVERVNET und WEBSITE_PULL_IMAGE_OVER_VNET.

Netzwerkrouting

Sie können mithilfe von Routingtabellen ausgehenden Datenverkehr von Ihrer App ohne Einschränkungen weiterleiten. Gängige Ziele können Firewallgeräte oder Gateways beinhalten. Sie können außerdem die Netzwerksicherheitsgruppe (NSG) verwenden, um ausgehenden Datenverkehr an Ressourcen in Ihrem virtuellen Netzwerk oder im Internet zu blockieren. Eine NSG, die Sie auf Ihr Integrationssubnetz anwenden, ist unabhängig von den Routingtabellen wirksam, die ggf. auf Ihr Integrationssubnetz angewendet werden.

Routentabellen und Netzwerksicherheitsgruppen gelten nur für Datenverkehr, der über die Integration in ein virtuelles Netzwerks geleitet wird. Details finden Sie unter Anwendungsrouting und Konfigurationsrouting. Routen gelten nicht für Antworten von eingehenden App-Anforderungen und Eingangsregeln in einer NSG gelten nicht für Ihre App. Die Integration virtueller Netzwerke betrifft nur ausgehenden Datenverkehr von Ihrer App. Um den eingehenden Datenverkehr für Ihre App zu steuern, verwenden Sie das Feature für Zugriffsbeschränkungen oder private Endpunkte.

Wenn Sie Netzwerksicherheitsgruppen oder Routingtabellen konfigurieren, die für ausgehenden Datenverkehr gelten, müssen Sie sicherstellen, dass Sie Ihre Anwendungsabhängigkeiten berücksichtigen. Anwendungsabhängigkeiten umfassen Endpunkte, die Ihre App während der Laufzeit benötigt. Neben APIs und Diensten, die die App aufruft, können diese Endpunkte auch abgeleitete Endpunkte wie Überprüfungsendpunkte für Zertifikatssperrlisten (CRL) und Identitäts-/Authentifizierungsendpunkte sein, z. B. Microsoft Entra-ID. Wenn Sie Continuous Deployment in App Service verwenden, müssen Sie abhängig von Typ und Sprache möglicherweise auch Endpunkte zulassen. Speziell für Continuous Deployment unter Linux müssen Sie oryx-cdn.microsoft.io:443 zulassen. Für Python müssen Sie zusätzlich files.pythonhosted.org, pypi.org zulassen.

Azure verwendet UDP-Port 30.000, um Netzwerkintegritätsprüfungen durchzuführen. Wenn Sie diesen Datenverkehr blockieren, wirkt sich dies nicht direkt auf Ihre App aus, aber es ist für den Azure-Support schwieriger, netzwerkbezogene Probleme zu erkennen und zu beheben.

Wenn Sie ausgehenden Datenverkehr lokal weiterleiten möchten, können Sie eine Routingtabelle verwenden, um ausgehenden Datenverkehr an das Azure ExpressRoute-Gateway zu senden. Wenn Sie Datenverkehr an ein Gateway weiterleiten, legen Sie Routen im externen Netzwerk fest, ü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. Ähnlich wie benutzerdefinierte Routen wirken sich BGP-Routen gemäß Ihrer Routingbereichseinstellung auf den Datenverkehr aus.

Dienstendpunkte

Mit der Integration virtueller Netzwerke können Sie Azure-Dienste erreichen, die mit Dienstendpunkten geschützt sind. Führen Sie die folgenden Schritte aus, um auf einen durch einen Dienstendpunkt gesicherten Dienst zuzugreifen:

1. Konfigurieren Sie die Integration virtueller Netzwerke in Ihrer Web-App, um eine Verbindung mit einem bestimmten Subnetz für die Integration herzustellen.
2. Wechseln Sie zum Zieldienst, und konfigurieren Sie Dienstendpunkte für das Integrationssubnetz.

Private Endpunkte

Wenn Sie Aufrufe an private Endpunkte senden möchten, stellen Sie sicher, 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. Falls Ihr virtuelles Netzwerk nicht über einen benutzerdefinierten DNS-Server verfügt, erfolgt die Integration automatisch, wenn die Zonen mit dem virtuellen Netzwerk verknüpft werden.
• Verwalten des privaten Endpunkts im DNS-Server, der von Ihrer App verwendet wird. Zum Verwalten der Konfiguration müssen Sie die IP-Adresse des privaten Endpunkts kennen. Verweisen Sie dann mithilfe eines A-Eintrags den Endpunkt, den Sie erreichen möchten, auf diese Adresse.
• Konfigurieren Ihres eigenen DNS-Servers zur Weiterleitung an private Azure DNS-Zonen.

Azure DNS Private Zones

Nachdem Ihre App in Ihr virtuelles Netzwerk integriert wurde, verwendet sie denselben DNS-Server, mit dem auch Ihr virtuelles Netzwerk konfiguriert ist. Ist kein benutzerdefiniertes DNS angegeben, werden Azure-Standard-DNS und alle privaten Zonen verwendet, die mit dem virtuellen Netzwerk verknüpft sind.

Einschränkungen

Es gibt einige Einschränkungen bei der Verwendung der Integration virtueller Netzwerke:

• Das Feature ist in allen App Service-Bereitstellungen in den Tarifen „Premium v2“ und „Premium v3“ verfügbar. Es ist außerdem im Tarif „Basic“ und „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 „Basic“- oder „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 nach dem Erstellen des Plans nach Bedarf herunterskalieren.
• Das Feature ist für isolierte Plan-Apps in einer App Service-Umgebung nicht verfügbar.
• Sie können keine Ressourcen über Peeringverbindungen mit klassischen virtuellen Netzwerken erreichen.
• Für das Feature ist ein nicht genutztes Subnetz, das ein IPv4-/28-Block oder größer ist, in einem virtuellen Azure Resource Manager-Netzwerk erforderlich. MPSJ erfordert einen /26-Block (oder größer).
• Die App und das virtuelle Netzwerk müssen sich in derselben Region befinden.
• Im virtuellen Integrationsnetzwerk dürfen keine IPv6-Adressräume definiert sein.
• Für das Integrationssubnetz dürfen keine Dienstendpunktrichtlinien aktiviert sein.
• Ein virtuelles Netzwerk mit einer integrierten App kann nicht gelöscht werden. Entfernen Sie die Integration, bevor Sie das virtuelle Netzwerk löschen.
• Pro App Service-Plan sind nicht mehr als zwei Integrationen virtueller Netzwerke zulässig. Mehrere Apps im gleichen App Service-Plan können die gleiche Integration virtueller Netzwerke verwenden.
• Sie können das Abonnement einer App oder eines Plans nicht ändern, solange eine App mit der Integration virtueller Netzwerke vorhanden ist.

Zugriff auf lokale Ressourcen

Für die Integration virtueller Netzwerke ist keine zusätzliche Konfiguration erforderlich, um über Ihr virtuelles Netzwerk lokale Ressourcen zu erreichen. Sie müssen Ihr virtuelles Netzwerk lediglich über ExpressRoute oder ein Site-to-Site-VPN mit lokalen Ressourcen verbinden.

Peering

Wenn Sie Peering mit Integration virtueller Netzwerke verwenden, sind keine weiteren Konfigurationsschritte erforderlich.

Verwalten der Integration virtueller Netzwerke

Das Verbinden und Trennen der Verbindung mit einem virtuellen Netzwerk erfolgt auf App-Ebene. Vorgänge, die sich auf die VNet-Integration über mehrere Apps auswirken können, werden auf Ebene des App Service-Plans ausgeführt. Sie können im Portal unter „App“ >Netzwerk>VNet-Integration Details zu Ihrem virtuellen Netzwerk abrufen. Ähnliche Informationen finden Sie auf der App Service-Planebene im Portal unter App Service-Plan>Netzwerk>VNET-Integration.

In der App-Ansicht Ihrer Instanz zur Integration virtueller Netzwerke können Sie Ihre App vom virtuellen Netzwerk trennen und das Anwendungsrouting konfigurieren. Um Ihre App von einem virtuellen Netzwerk zu trennen, wählen Sie Verbindung trennen aus. Wenn Sie die Verbindung mit einem virtuellen Netzwerk trennen, wird Ihre App neu gestartet. Das Trennen der Verbindung führt nicht zu Änderungen in Ihrem virtuellen Netzwerk. Das Subnetz wird nicht entfernt. Wenn Sie Ihr virtuelles Netzwerk löschen möchten, trennen Sie zuerst Ihre App vom virtuellen Netzwerk.

Die private IP-Adresse, die der Instanz zugewiesen ist, wird über die Umgebungsvariable WEBSITE_PRIVATE_IP verfügbar gemacht. Auf der Benutzeroberfläche der Kudu-Konsole wird auch die Liste der Umgebungsvariablen angezeigt, die für die Web-App verfügbar sind. Diese IP-Adresse wird aus dem Adressbereich des integrierten Subnetzes zugewiesen. Diese IP-Adresse wird von der Web-App zum Herstellen einer Verbindung mit den Ressourcen über das virtuelle Azure-Netzwerk verwendet.

Hinweis

Der Wert von WEBSITE_PRIVATE_IP ist veränderlich. Es handelt sich jedoch um eine IP-Adresse innerhalb des Adressbereichs des Integrationssubnetzes. Sie müssen daher den Zugriff vom gesamten Adressbereich zulassen.

Preisübersicht

Bei der Funktion für die Integration virtueller Netzwerke fallen neben den Gebühren für den Tarif des App Service-Plans keine zusätzlichen Gebühren an.

Problembehandlung

Die Funktion ist zwar einfach einzurichten, dies bedeutet jedoch nicht, dass keinerlei Probleme auftreten. Wenn beim Zugriff auf den gewünschten Endpunkt Probleme auftreten, können Sie je nach Beobachtung verschiedene Schritte unternehmen. Weitere Informationen finden Sie im Leitfaden zur Problembehandlung bei der Integration des virtuellen Netzwerks.

Hinweis

• Die Integration virtueller Netzwerke wird für Docker Compose-Szenarien in App Service nicht unterstützt.
• Zugriffsbeschränkungen gelten nicht für Datenverkehr, der über einen privaten Endpunkt eingeht.

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

Wenn Sie die App oder den App Service-Plan gelöscht haben, ohne zuvor die Integration virtueller Netzwerke 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. Die Subnetzdelegierung „Microsoft.Web/serverFarms“ bleibt Ihrem Subnetz zugewiesen und verhindert die Aktualisierungs- und Löschvorgänge.

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

1. Erstellen Sie den App Service-Plan und die App neu (es ist zwingend erforderlich, genau den gleichen Namen der Web-App wie zuvor zu verwenden).
2. Navigieren Sie in der App im Azure-Portal zu Netzwerk, und konfigurieren Sie die Integration virtueller Netzwerke.
3. Nachdem die Integration virtueller Netzwerke konfiguriert wurde, wählen Sie die Schaltfläche „Trennen“ aus.
4. Löschen Sie den App Service-Plan oder die App.
5. Aktualisieren/Löschen Sie das Subnetz oder das virtuelle Netzwerk.

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