Azure stellt Default Outbound Access 2025 für neue VNets ein

Mir ist kaum ein Azure-Projekt untergekommen, in dem der Internetzugriff aus VMs heraus kein Thema gewesen wäre. Das gilt für schnell aufgesetzte Testumgebungen genauso wie für klassische Applikationsserver oder Legacy-Migrationen. VMs, die ohne viel Planung deployt werden, bekommen oft unbemerkt einen Internetzugang, den sogenannten Default Outbound Access. Azure gewährt ihn bisher allen VMs in einem VNet, für das keine ausgehende Verbindung explizit konfiguriert ist. Damit ist bald Schluss. Microsoft hat angekündigt, die Funktion ab dem 30. September 2025 für neue VNets komplett abzuschalten. Bestehende Umgebungen bleiben vorerst unangetastet, doch spätestens bei neuen Deployments muss man sich darum kümmern.

Default Outbound Access versorgt VMs bislang stillschweigend mit Internet

Läuft eine VM in einem Subnetz ohne explizite ausgehende Methode – also ohne NAT Gateway, öffentliche IP-Adresse, Load Balancer mit Outbound-Regeln oder Firewall bzw. NVA per User Defined Route –, erhält sie bisher automatisch einen dynamisch zugewiesenen öffentlichen Absender-IP-Bereich. Das ist bequem, birgt aber Risiken. Über die Quelle der ausgehenden Verbindungen hat man keine Kontrolle, die IPs wechseln, und in Firewalls oder SaaS-Whitelistings taucht auf einmal Traffic auf, mit dem niemand gerechnet hat. Wie das Ganze im Detail funktioniert und welche Einschränkungen es gibt, beschreibt die Microsoft-Dokumentation.

Vor allem in Tenants mit vielen kleinen VNets, Testsystemen oder Lift-and-Shift-Szenarien erlebe ich immer wieder, dass Default Outbound Access still im Hintergrund mitläuft, meist ohne dass es jemandem bewusst ist. Nach dem Stichtag kommen VMs in neuen VNets nicht mehr ins Internet, solange der Zugang nicht ausdrücklich geregelt ist.

Vier explizite Outbound-Methoden ersetzen den impliziten Zugang

Wer aus Subnetzen heraus ins Internet muss, hat das künftig selbst in der Hand. Azure bietet dafür vier gängige Wege:

• Public IP direkt an der Netzwerkkarte der VM (nur in sehr speziellen Szenarien sinnvoll)
• NAT Gateway, das dem Subnetz zugeordnet wird – ideal, wenn man statische ausgehende IPs braucht
• Standard Load Balancer mit Outbound-Regeln (siehe Outbound Rules)
• Azure Firewall oder Network Virtual Appliance (NVA) als zentraler Ausgangspunkt, gesteuert per UDR

Welcher Weg passt, entscheiden Sicherheitsanforderungen, Routing-Komplexität und Kosten. In Produktivumgebungen rate ich fast immer zu NAT Gateway oder Firewall. Ein NAT Gateway nur an das Subnetz zu binden, genügt allerdings nicht. Auch die Routingregeln des Subnetzes und etwaige NSGs müssen Ausnahmen für das Gateway zulassen. Weitere Hintergründe zum NAT Gateway liefert diese Übersicht.

Sobald nach außen feste IPs für Whitelistings nötig sind, etwa für SaaS-APIs, Partner oder die eigenen On-Premises-Firewalls, führt an einer expliziten Steuerung kein Weg vorbei. Jetzt ist der richtige Zeitpunkt, alle Subnetze zu prüfen und die Dokumentation zu aktualisieren.

Resource Graph und Advisor zeigen die betroffenen Subnetze

Viele Admins wollen nun wissen, welche ihrer VMs noch Default Outbound Access nutzen. Für die Bestandsaufnahme stellt Microsoft zwei Werkzeuge bereit. Im Azure-Portal meldet sich der Advisor, wenn Ressourcen betroffen sind. Für einen breiteren und automatisierten Überblick eignet sich der Azure Resource Graph Explorer. Die folgende Beispielabfrage listet alle Subnetze auf, die noch auf Default Outbound Access angewiesen sind:

Resources
| where type == "microsoft.network/virtualnetworks/subnets"
| extend props = properties
| where isnull(props.privateEndpointNetworkPolicies) or props.privateEndpointNetworkPolicies != "Disabled"
| where isnull(props.natGateway.id)
| where isnull(props.routeTable.id)
| project name, id, properties

Resource Graph Explorer → Query, benötigt mindestens Leserechte auf den betroffenen Subscriptions.

Unter Umständen muss man die Abfrage noch erweitern, damit vorhandene Outbound-Konfigurationen wie Load Balancer oder Firewall berücksichtigt werden. Subnetze ohne explizite Methode fallen damit in der Praxis aber schnell auf.

Praxis-Tipp: Wer Azure Policy nutzt, kann mit eigenen Audit-Regeln Subnetze ohne NAT Gateway oder Firewall früh aufspüren und Fehlkonfigurationen von vornherein verhindern.

Mit defaultOutboundAccess lassen sich neue Subnetze schon heute privat schalten

Zusammen mit der Abkündigung hat Microsoft eine weitere Funktion eingeführt. Subnetze lassen sich ausdrücklich als „privat“ kennzeichnen, indem man defaultOutboundAccess auf false setzt. Dann entsteht garantiert kein impliziter Internetzugang, auch nicht in bestehenden VNets. Auf diese Weise erlebt man mit neuen Subnetzen schon jetzt keine Überraschungen mehr. Wer Subnetze per ARM oder Bicep anlegt, gibt die Option gleich mit:

{
  "name": "app-subnet",
  "properties": {
    "defaultOutboundAccess": false
  }
}

Beispielausschnitt aus der Subnetzkonfiguration eines ARM-Templates.

Azure prüft für jedes Subnetz die konfigurierte Outbound-Methode

Das folgende Ablaufdiagramm stellt das Grundprinzip der ausgehenden Kommunikation vereinfacht dar:

flowchart TD
    VM["VM sendet Traffic"] --> Subnetz["Subnetz überprüft Outbound-Methode"]
    Subnetz -->|"NAT Gateway vorhanden"| NAT["NAT Gateway übernimmt"]
    Subnetz -->|"Public IP an VM"| PublicIP["Public IP übernimmt"]
    Subnetz -->|"Load Balancer Outbound-Rule"| LB["Load Balancer übernimmt"]
    Subnetz -->|"UDR zur Firewall/NVA"| FW["Firewall/NVA übernimmt"]
    Subnetz -->|"Keine Methode"| Default["Default Outbound Access (wird eingestellt)"]

Abbildung: Ablauf der ausgehenden Verbindungen aus einem Azure-Subnetz je nach Konfiguration.

Gut zu erkennen ist, dass ohne explizite Methode künftig keine Verbindung nach außen mehr aufgebaut wird. Einen impliziten Notausgang gibt es ab 2025 nicht mehr.

Eine Inventur noch in diesem Jahr erspart den Stress im Jahr 2025

In vielen Tenants, die ich mir ansehe, liegt das Thema Outbound Access seit Jahren brach. Meist fällt es erst auf, wenn eine neue Anwendung nicht mehr läuft oder ein Partner sich über geänderte IPs beschwert. Die Abkündigung bietet einen guten Anlass, endlich aufzuräumen und alles ordentlich zu dokumentieren. Ich rate dazu, noch in diesem Jahr sämtliche Subnetze zu erfassen, die Outbound-Pfade festzuhalten und, wo nötig, auf NAT Gateway oder Firewall umzustellen. Wer das jetzt angeht, vermeidet 2025 unnötige Hektik und hat seine Azure-Umgebung nebenbei deutlich besser im Griff, auch was die Sicherheit angeht.