Netzwerk in der App Service-Umgebung

Die App Service-Umgebung (App Service Environment, ASE) ist eine Bereitstellung von Azure App Service für einen einzelnen Mandanten zum Hosten von Windows- und Linux-Containern, Web-Apps, API-Apps, Logik-Apps und Funktions-Apps. Wenn Sie eine App Service-Umgebung installieren, wählen Sie die Azure Virtual Network-Instanz aus, in der sie bereitgestellt werden soll. Der gesamte ein- und ausgehende Anwendungsdatenverkehr wird innerhalb des von Ihnen angegebenen virtuellen Netzwerks abgewickelt. Die Bereitstellung erfolgt in einem einzelnen Subnetz in Ihrem virtuellen Netzwerk, wobei keine weiteren Bereitstellungen in diesem Subnetz erfolgen können.

Hinweis

In diesem Artikel wird die App Service-Umgebung v3 beschrieben, die mit isolierten v2-App Service-Plänen verwendet wird.

Subnetzanforderungen

Sie müssen das Subnetz an Microsoft.Web/hostingEnvironments delegieren, und das Subnetz muss leer sein.

Die Größe des Subnetzes kann sich auf die Skalierungsgrenzwerte der App Service-Planinstanzen innerhalb der App Service-Umgebung auswirken. Für den Produktionsmaßstab wird ein /24 Adressraum (256 Adressen) für Ihr Subnetz empfohlen. Wenn Sie planen, die maximale Kapazität von 200 Instanzen in unserer App Service-Umgebung zu skalieren und häufige Up-/Down-Skalierungsvorgänge planen, empfehlen wir einen /23 Adressraum (512 Adressen) für Ihr Subnetz.

Wenn Sie ein kleineres Subnetz verwenden, beachten Sie die folgenden Einschränkungen:

• Jedes spezifische Subnetz verfügt über fünf Adressen, die für Verwaltungszwecke reserviert sind. Zusätzlich zu den Verwaltungsadressen skaliert die App Service-Umgebung die unterstützende Infrastruktur dynamisch und verwendet je nach Konfiguration und Last zwischen 7 und 27 Adressen. Die verbleibenden Adressen können Sie für Instanzen im App Service-Plan verwenden. Die Mindestgröße Ihres Subnetzes ist ein Adressraum vom Typ /27 (32 Adressen).
• Für jede Betriebssystem/SKU-Kombination des App Service-Plans, die in Ihrer App Service-Umgebung verwendet wird, wie z. B. I1v2 Windows, wird eine Standbyinstanz für jeweils 20 aktive Instanzen erstellt. Die Standbyinstanzen erfordern ebenfalls IP-Adressen.
• Wenn Sie App Service-Pläne in der App Service-Umgebung hoch- oder herunterskalieren, wird die Anzahl der vom App Service-Plan verwendeten IP-Adressen während des Skalierungsvorgangs vorübergehend verdoppelt. Die neuen Instanzen müssen vollständig betriebsbereit sein, bevor die bestehenden Instanzen nicht mehr bereitgestellt werden.
• 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 betragen.
• Wenn in Ihrem Subnetz bald keine Adressen mehr verfügbar sind, kann Ihre Fähigkeit zum Aufskalieren Ihrer App Service-Pläne in der App Service-Umgebung eingeschränkt werden. Eine weitere Möglichkeit ist, dass es bei einer intensiven Auslastung des Datenverkehrs zu erhöhter Latenz kommt, wenn Microsoft die unterstützende Infrastruktur nicht skalieren kann.

Hinweis

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 Ihre App Service-Umgebung beispielsweise 2 Windows-Container-App Service-Pläne mit jeweils 25 Instanzen und 5 ausgeführten Apps enthält, benötigen Sie 300 IP-Adressen sowie zusätzliche Adressen zur Unterstützung der horizontalen Skalierung (Auf- und Abskalierung).

Beispielberechnung:

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

Für 25 Instanzen: 6 × 25 = 150 IP-Adressen pro App Service-Plan

Da Sie 2 App Service-Pläne haben, benötigen Sie 2 × 150 = 300 IP-Adressen.

Adressen

Die App Service-Umgebung verfügt bei der Erstellung über die folgenden Netzwerkinformationen:

Adresstyp	BESCHREIBUNG
Virtuelles Netzwerk der App Service-Umgebung	Das virtuelle Netzwerk als Ziel der Bereitstellung.
Subnetz der App Service-Umgebung	Das Subnetz als Ziel der Bereitstellung.
Domänensuffix	Das Domänensuffix das von den erstellten Apps verwendet wird.
Virtuelle IP-Adresse (VIP)	Der verwendete VIP-Typ. Die beiden möglichen Werte lauten „intern“ und „extern“.
Adresse für eingehenden Datenverkehr	Die Adresse für eingehenden Datenverkehr ist die Adresse, unter der Ihre Apps erreichbar sind. Wenn Sie über eine interne VIP verfügen, handelt es sich um eine Adresse in Ihrem App Service-Umgebungssubnetz. Wenn die Adresse extern ist, handelt es sich um eine öffentlich erreichbare Adresse.
Ausgehende Standardadressen	Die Apps verwenden diese Adresse standardmäßig, wenn sie ausgehende Aufrufe an das Internet senden.

Details finden Sie im Bereich IP-Adressen des Portals, wie im folgenden Screenshot gezeigt:

Wenn Sie Ihre App Service-Pläne in Ihrer App Service-Umgebung hochskalieren, verwenden Sie mehr Adressen aus Ihrem Subnetz. Die Anzahl der von Ihnen verwendeten Adressen variiert in Abhängigkeit von der Anzahl ihrer App Service-Planinstanzen und dem vorhandenen Datenverkehr. Apps in der App Service-Umgebung haben keine dedizierten Adressen im Subnetz. Die spezifischen Adressen, die von einer App im Subnetz verwendet werden, ändern sich im Laufe der Zeit.

Bringen Sie Ihre eigene eingehende Adresse mit

Sie können Ihre eigene eingehende Adresse in Ihre App-Dienstumgebung bringen. Wenn Sie eine App Service-Umgebung mit einer internen VIP erstellen, können Sie eine statische IP-Adresse im Subnetz angeben. Wenn Sie eine App Service-Umgebung mit einer externen VIP erstellen, können Sie Ihre eigene öffentliche Azure-IP-Adresse verwenden, indem Sie die Ressourcen-ID der öffentlichen IP-Adresse angeben. Im Folgenden sind Einschränkungen für die Einholung Ihrer eigenen eingehenden Adresse aufgeführt:

• Für die App-Dienstumgebung mit externer VIP muss sich die Azure Public IP-Adressressource im selben Abonnement wie die App Service-Umgebung befinden.
• Die eingehende Adresse kann nach dem Erstellen der App Service-Umgebung nicht mehr geändert werden.

Ports und Netzwerkeinschränkungen

Damit Ihre App Datenverkehr empfangen kann, stellen Sie sicher, dass die Regeln für eingehende Netzwerksicherheitsgruppen (NSGs) es dem Subnetz der App Service-Umgebung ermöglichen, Datenverkehr von den erforderlichen Ports zu empfangen. Neben den Ports, über die Sie Datenverkehr empfangen möchten, sollten Sie sicherstellen, dass Azure Load Balancer am Port 80 eine Verbindung mit dem Subnetz herstellen kann. Dieser Port wird für Integritätsprüfungen des internen virtuellen Computers verwendet. Datenverkehr, der am Port 80 vom virtuellen Netzwerk an Ihr Subnetz gesendet wird, kann weiterhin gesteuert werden.

Es empfiehlt sich, die folgende NSG-Eingangsregel zu konfigurieren:

Quell-/Zielport(s)	Direction	`Source`	Ziel	Zweck
* / 80,443	Eingehend	VirtualNetwork	Subnetzbereich der App Service-Umgebung	Zulassen von App-Datenverkehr und internem Integritäts-Ping-Datenverkehr

Folgende Mindestanforderungen müssen erfüllt sein, damit eine App Service-Umgebung betriebsbereit ist:

Quell-/Zielport(s)	Direction	`Source`	Ziel	Zweck
* / 80	Eingehend	AzureLoadBalancer	Subnetzbereich der App Service-Umgebung	Zulassen von internem Integritäts-Ping-Datenverkehr

Wenn Sie die Mindestanforderungsregel verwenden, benötigen Sie möglicherweise eine oder mehrere Regeln für Ihren Anwendungsdatenverkehr. Wenn Sie eine der Bereitstellungs- oder Debugoptionen verwenden, müssen Sie diesen Datenverkehr auch an das Subnetz der App Service-Umgebung zulassen. Bei der Quelle dieser Regeln kann es sich um das virtuelle Netzwerk oder um einzelne oder mehrere spezifische Client-IP-Adressen oder IP-Adressbereiche handeln. Das Ziel ist immer der Subnetzbereich der App Service-Umgebung. Der interne Integritäts-Ping-Datenverkehr an Port 80 ist zwischen dem Load Balancer und den internen Servern isoliert. Der Integritäts-Ping-Endpunkt kann von keinem externen Datenverkehr erreicht werden.

Die normalen eingehenden App-Zugriffsports lauten:

Zweck	Ports
HTTP/HTTPS	80, 443
FTP/FTPS	21, 990, 10001-10020
Remotedebuggen in Visual Studio	4022, 4024, 4026
Web Deploy-Dienst	8172

Hinweis

Selbst wenn Sie Standard-FTP für den FTP-Zugriff an Port 21 nicht zulassen möchten, müssen Sie dennoch Datenverkehr vom LoadBalancer an den Subnetzbereich der App Service-Umgebung an Port 21 zulassen, da dieser speziell für internen Ping-Integritätsdatenverkehr für den FTP-Dienst verwendet wird.

Netzwerkrouting

Sie können Routingtabellen ohne Einschränkung festlegen. Sie können den gesamten ausgehenden Anwendungsdatenverkehr von Ihrer App Service-Umgebung zu einem ausgehenden Firewallgerät, z. B. Azure Firewall, tunneln. In diesem Szenario müssen Sie sich nur um Ihre Anwendungsabhängigkeiten kümmern.

Anwendungsabhängigkeiten umfassen Endpunkte, die Ihre App während der Laufzeit benötigt. Neben APIs und Diensten, die die App aufruft, können Abhängigkeiten 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.

Sie können Ihre Web Application Firewall-Geräte wie Azure Application Gateway vor dem eingehenden Datenverkehr platzieren. Auf diese Weise können Sie bestimmte Apps in dieser App Service-Umgebung verfügbar machen.

Ihre Anwendung verwendet eine der standardmäßigen ausgehenden Adressen für den ausgehenden Datenverkehr an öffentliche Endpunkte. Wenn Sie die Adresse für ausgehenden Datenverkehr Ihrer Anwendungen in einer App Service-Umgebung anpassen möchten, können Sie Ihrem Subnetz eine NAT Gateway-Instanz hinzufügen.

Hinweis

Ausgehende SMTP-Konnektivität (Port 25) wird für App Service-Umgebung v3 unterstützt. Die Unterstützungsfähigkeit wird jedoch durch eine Einstellung des 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 sowie Informationen zur Problembehandlung finden Sie unter Behandeln von Problemen mit ausgehenden SMTP-Verbindungen in Azure.

Privater Endpunkt

Um private Endpunkte für Apps zu aktivieren, die in Ihrer App Service-Umgebung gehostet werden, müssen Sie dieses Feature zuerst auf Ebene der App Service-Umgebung aktivieren.

Sie können es über das Azure-Portal aktivieren. Aktivieren Sie im Konfigurationsportal der App Service-Umgebung die Einstellung Allow new private endpoints. Alternativ kann die folgende CLI dies aktivieren:

az appservice ase update --name myasename --allow-new-private-endpoint-connections true

Weitere Informationen zum privaten Endpunkt und zur Web-App finden Sie unter Privater Endpunkt der Azure-Web-App.

DNS

In den folgenden Abschnitten werden die DNS-Aspekte sowie die Konfiguration für ein- und ausgehenden Datenverkehr Ihrer App Service-Umgebung beschrieben. In den Beispielen wird das Domänensuffix appserviceenvironment.net aus der öffentlichen Azure-Cloud verwendet. Wenn Sie andere Clouds wie Azure Government verwenden, müssen Sie das entsprechende Domänensuffix verwenden. Für Domänen in App Service-Umgebungen wird der Websitename aufgrund von DNS-Grenzwerten bei 40 Zeichen abgeschnitten. Wenn Sie über einen Slot verfügen, wird der Name des Slots bei 19 Zeichen abgeschnitten.

Eingehende DNS-Konfiguration zu Ihrer App Service-Umgebung

Wenn Ihre App Service-Umgebung mit einer externen VIP erstellt wird, werden Ihre Apps automatisch in ein öffentliches DNS eingebunden. Wenn Ihre App Service-Umgebung mit einer internen VIP erstellt wird, wird DNS in Ihrem virtuellen Netzwerk konfiguriert, wenn Sie bei der Erstellung Ihrer App Service-Umgebung auswählen, dass private Azure DNS-Zonen automatisch konfiguriert werden. Wenn Sie die manuelle Konfiguration für DNS ausgewählt haben, müssen Sie entweder Ihren eigenen DNS-Server verwenden oder es in den privaten Zonen von Azure DNS konfigurieren. Um die eingehende Adresse zu finden, wechseln Sie zum App Service-Umgebungsportal, und wählen Sie IP-Adressen aus.

Wenn Sie einen eigenen DNS-Server verwenden möchten, fügen Sie die folgenden Einträge hinzu:

1. Erstellen Sie eine Zone für <App Service Environment-name>.appserviceenvironment.net.
2. Erstellen Sie in dieser Zone einen A-Eintrag, der * auf die IP-Adresse für den eingehenden Datenverkehr verweist, die von Ihrer App Service-Umgebung verwendet wird.
3. Erstellen Sie in dieser Zone einen A-Eintrag, der @ auf die IP-Adresse für den eingehenden Datenverkehr verweist, die von Ihrer App Service-Umgebung verwendet wird.
4. Erstellen Sie eine Zone in <App Service Environment-name>.appserviceenvironment.net, und nennen Sie sie scm.
5. Erstellen Sie in der Zone scm einen A-Eintrag, der * auf die vom privaten Endpunkt Ihrer App Service-Umgebung verwendete IP-Adresse verweist.

So konfigurieren Sie DNS in privaten Azure DNS-Zonen

1. Erstellen Sie eine private Azure DNS-Zone mit dem Namen <App Service Environment-name>.appserviceenvironment.net.
2. Erstellen Sie einen A-Eintrag in dieser Zone, der * auf die IP-Adresse für den eingehenden Datenverkehr verweist.
3. Erstellen Sie einen A-Eintrag in dieser Zone, der @ auf die IP-Adresse für den eingehenden Datenverkehr verweist.
4. Erstellen Sie einen A-Eintrag in dieser Zone, der *.scm auf die IP-Adresse für den eingehenden Datenverkehr verweist.

Zusätzlich zu der Standarddomäne, die beim Erstellen einer App bereitgestellt wird, können Sie Ihrer App auch eine benutzerdefinierte Domäne hinzufügen. Sie können einen benutzerdefinierten Domänennamen ohne jegliche Validierung für Ihre Apps festlegen. Wenn Sie benutzerdefinierte Domänen verwenden, müssen Sie darauf achten, dass DNS-Einträge für sie konfiguriert sind. Sie können die oben angegebene Anleitung ausführen, um DNS-Zonen und -Einträge für einen benutzerdefinierten Domänennamen zu konfigurieren (ersetzen Sie den Namen der Standarddomäne durch den Namen der benutzerdefinierten Domäne). Der benutzerdefinierte Domänenname funktioniert für App-Anforderungen, aber nicht für die scm-Site. Die scm-Site ist nur unter <appname>.scm.<asename>.appserviceenvironment.net verfügbar.

DNS-Konfiguration für FTP-Zugriff

Für den FTP-Zugriff insbesondere auf den internen Load Balancer (ILB), App Service-Umgebung v3, müssen Sie sicherstellen, dass DNS konfiguriert ist. Konfigurieren Sie eine private Azure DNS-Zone oder ein entsprechendes benutzerdefiniertes DNS mit den folgenden Einstellungen:

1. Erstellen Sie eine private Azure DNS-Zone mit dem Namen ftp.appserviceenvironment.net.
2. Erstellen Sie einen A-Eintrag in dieser Zone, der <App Service Environment-name> auf die IP-Adresse für den eingehenden Datenverkehr verweist.

Neben der Einrichtung von DNS müssen Sie DNS auch in der App Service-Umgebungskonfiguration und auf der App-Ebene aktivieren.

Ausgehende DNS-Konfiguration von Ihrer App Service-Umgebung

Die Apps in Ihrer App Service-Umgebung verwenden das DNS, mit dem Ihr virtuelles Netzwerk konfiguriert ist. Wenn Sie möchten, dass einige Apps einen anderen DNS-Server verwenden, können Sie diesen mit den App-Einstellungen WEBSITE_DNS_SERVER und WEBSITE_DNS_ALT_SERVER manuell pro App festlegen. WEBSITE_DNS_ALT_SERVER konfiguriert den sekundären DNS-Server. Der sekundäre DNS-Server wird nur verwendet, wenn keine Antwort vom primären DNS-Server vorliegt.

Weitere Ressourcen

• Referenz zu Umgebungsvariablen und App-Einstellungen