App Service benötigt VNet-Zugriff? App-Service-Netzwerk konfigurieren

CloudTrips muss aus seiner Web-App Ressourcen erreichen, die über ein virtuelles Azure-Netzwerk verfügbar sind. VNet Integration gibt einer App-Service-App einen ausgehenden Pfad in ein VNet, ohne die mandantenfähige App selbst in das Subnetz zu verschieben.

Der Unterschied ist wichtig:

VNet Integration: Ausgehender Verkehr von der App zum VNet
Private Endpoint:  Eingehender Verkehr vom VNet zur App

Dieser eigenständige Trip konfiguriert ausgehende VNet Integration. Die öffentliche URL der App bleibt erreichbar.

Erstelle das virtuelle Netzwerk

Suche nach Virtual networks, wähle Create und trage ein:

Subscription: CloudTrips TEST
Resource group: rg-cloudtrips-appservice-vnet-test-weu
Name: vnet-cloudtrips-appservice-test-weu
Region: West Europe
IPv4 address space: 10.60.0.0/16

Erstelle dieses Subnetz:

Subnet name: snet-appservice-integration
Subnet address range: 10.60.1.0/24
Delegation: Microsoft.Web/serverFarms

Die Delegierung reserviert das Subnetz für App Service VNet Integration und erlaubt Azure, die vom Dienst benötigte Netzwerkkonfiguration anzuwenden. Platziere keine Private Endpoints oder virtuellen Maschinen in diesem Integrationssubnetz.

Wähle Review + create > Create.

Erstelle die Web-App

Suche nach App Services, wähle Create > Web App und trage ein:

Subscription: CloudTrips TEST
Resource group: rg-cloudtrips-appservice-vnet-test-weu
Name: app-cloudtrips-vnet-dmytro-test-weu
Publish: Code
Runtime stack: Node 24 LTS
Operating System: Linux
Region: West Europe
Linux Plan: Create new
Plan name: asp-cloudtrips-vnet-test-weu
Pricing plan: Basic B1
Zone redundancy: Disabled

Der Web-App-Name muss global eindeutig sein. Basic B1 unterstützt regionale VNet Integration und verursacht Kosten, bis es gelöscht wird. App, Plan und VNet liegen in West Europe, weil App und VNet für regionale Integration dieselbe Region verwenden müssen.

Wähle Review + create > Create.

Füge VNet Integration hinzu

Öffne app-cloudtrips-vnet-dmytro-test-weu, wähle Settings > Networking und suche Outbound traffic configuration. Wähle Not configured neben Virtual network integration und anschließend Add virtual network integration.

Wähle:

Virtual network: vnet-cloudtrips-appservice-test-weu
Subnet: snet-appservice-integration

Wähle Connect. Der Vorgang startet die App neu. Danach sollte die Networking-Seite VNet und Subnetz anstelle von Not configured anzeigen.

Verstehe das Routing

Öffne den verbundenen VNet-Integrationseintrag. Unter Application routing steuert Outbound internet traffic, ob Internetanfragen aus deinem Anwendungscode durch das integrierte VNet geleitet werden. Beispiele sind Aufrufe der App an:

https://api.github.com
https://api.stripe.com
https://example.com

Wenn Outbound internet traffic deaktiviert ist:

Privater VNet-Verkehr → durch VNet Integration
Internetverkehr       → direkt durch das App-Service-Netzwerk

Wenn Outbound internet traffic aktiviert ist:

Privater VNet-Verkehr → durch VNet Integration
Internetverkehr       → ebenfalls durch das VNet

Aktiviere die Einstellung, wenn Internetverkehr durch eine VNet-Firewall, ein NAT Gateway, eine virtuelle Netzwerk-Appliance oder eine benutzerdefinierte Route laufen muss. Leitest du Internetverkehr durch das VNet, benötigt das Subnetz funktionierende DNS-, Routing- und Outbound-Konnektivität. Andernfalls kann die App den Zugriff auf ihre Abhängigkeiten verlieren.

Lasse Outbound internet traffic für diesen Trip deaktiviert. Das Ziel ist nur, der App Zugriff auf private VNet-Ressourcen zu geben. Die Einstellung betrifft ausgehende Verbindungen, die von der App gestartet werden; sie steuert nicht die Besucher, die sich mit der Web-App verbinden.

VNet Integration weist keine dedizierte eingehende Adresse zu, sperrt die öffentliche URL nicht und macht die App nicht privat. Das sind separate Entscheidungen für eingehendes Networking.

Prüfe die Integration

Bestätige auf deinem Mac, dass Azure die Integration meldet:

az webapp vnet-integration list \
  --resource-group rg-cloudtrips-appservice-vnet-test-weu \
  --name app-cloudtrips-vnet-dmytro-test-weu \
  --output table

Das Ergebnis sollte vnet-cloudtrips-appservice-test-weu und snet-appservice-integration nennen.

Öffne in der App Development Tools > SSH und führe aus:

printenv WEBSITE_PRIVATE_IP

Die Ausgabe sollte eine Adresse aus 10.60.1.0/24 sein. Das ist die private IP, welche die aktuelle App-Service-Instanz verwendet, wenn sie Verkehr durch VNet Integration sendet:

App-Instanz → 10.60.1.x → private VNet-Ressource

Sie ist keine eingehende Adresse. Benutzer und andere Anwendungen können sich nicht über diese IP mit der Web-App verbinden; sie verwenden weiterhin den öffentlichen Hostnamen der App. Benötigt die App eine private eingehende IP, ist ein App Service Private Endpoint erforderlich.

Die Integrations-IP kann sich ändern, wenn Azure die App neu startet oder verschiebt oder wenn der Plan auf zusätzliche Instanzen skaliert. Jede Instanz kann eine andere IP aus dem Integrationssubnetz erhalten. Ziel-Firewalls und NSGs müssen deshalb das vollständige Integrationssubnetz 10.60.1.0/24 statt einer beobachteten Adresse wie 10.60.1.4 erlauben.

Wenn Outbound internet traffic deaktiviert ist, verwendet nur privater Verkehr diese Integrations-IP. Aufrufe ins öffentliche Internet umgehen das VNet und verwenden eine der öffentlichen Outbound IP addresses des App-Service-Plans, sichtbar unter Settings > Properties. Ist Outbound internet traffic aktiviert, gelangen auch Internetaufrufe über das Integrationssubnetz ins VNet und verlassen es anschließend über den konfigurierten VNet-Ausgang, beispielsweise NAT Gateway oder Azure Firewall.

Bereinigen

Lösche die isolierte Ressourcengruppe, um die B1-Kosten zu beenden:

az group delete \
  --name rg-cloudtrips-appservice-vnet-test-weu \
  --yes

Bestätige die Löschung:

az group exists --name rg-cloudtrips-appservice-vnet-test-weu

Erwartetes Ergebnis:

false