Azure: Default Outbound Access wird im September 2025 abgeschafft

Das Wichtigste in Kürze:

• Microsoft schaltet ab 30.09.2025 das automatische „Default Outbound Access“ für neue VNets in Azure ab.
• Ohne explizite Konfiguration gibt es keinen Internetzugriff mehr.
• Azure NAT Gateway, Load Balancer Outbound Rules oder eine direkte Public IP liefern stabile, nachvollziehbare Absender‑Adressen und erleichtern Logging, Security und Compliance.

Am 30. September 2025 stellt Microsoft das bisherige „Default Outbound Access“ für neue virtuelle Netzwerke ein. Künftig erhalten neue VNets keine automatische Fallback-IP mehr. Ohne explizit konfigurierten Ausgangspfad bleibt jeder VM der Weg ins Internet versperrt. Diese Änderung zwingt euch dazu, Outbound-Connectivity von Anfang an bewusst zu planen und zu kontrollieren.

Default Outbound Access wird abgeschafft

Bislang spendierte Azure jeder VM in einem VNet ohne eigene Absender-Adresse eine temporäre Public IP. Das war bequem, aber riskant: Die IP konnte (zumindest bei der Basic SKU) jederzeit wechseln, das Traffic-Monitoring war lückenhaft, und der Ursprung ließ sich nur schwer einem Workload zuordnen. ‍

‍Ab 30.09.2025 gilt für alle neu angelegten VNets: Kein definierter Outbound-Pfad, kein Internetzugriff.

Bestehende VNets behalten die Funktion - vorerst.

Was genau ändert sich?

Microsoft fasst es so zusammen: „After September 30, 2025, new virtual networks will default to requiring explicit outbound connectivity methods“. Künftig stehen drei Optionen zur Wahl:

1. Azure NAT Gateway – der skalierbare Standard für produktive Umgebungen. Eine einzige, feste Public IP oder ein IP-Präfix für tausende VMs.
2. Azure Load Balancer Outbound Rules – interessant, wenn sowieso ein Load Balancer im Spiel ist.
3. Direkt zugewiesene Public IP an der Netzwerkschnittstelle – simpel, aber weniger bequem zu verwalten.

Die Zeit der stillschweigenden „Gratis-IP“ ist vorbei. Wer nach dem Stichtag ein VNet erstellt und keine der drei Methoden implementiert, erhält eine VM ohne Internet-Beine.

Auswirkungen auf bestehende Workloads

VMs in älteren VNets funktionieren zunächst weiter. Doch VMs, deren VNet nach dem 30.09.2025 erstellt wurde, fallen unter die neue Regel. Mischt also niemals alte und neue Designs, ohne vorher einen konsistenten Outbound-Plan zu definieren. Zudem kann Microsoft das alte Verhalten jederzeit deprecaten. Frühzeitiges Umstellen ist risikolos, da alle drei Methoden parallel zu Default Outbound Access laufen.

Best Practice: Azure NAT Gateway

In den meisten Szenarien gewinnt das NAT Gateway:

• Skalierbarkeit: Bis zu 2 Millionen gleichzeitige Verbindungen je Gateway.
• Statische IP-Adresse: Feste Zuweisung einer IP oder eines IP-Bereichs.
• Kostentransparenz: Preis basiert auf der verarbeiteten Datenmenge.

Alternative: Load Balancer Outbound Rules

Wenn ihr sowieso einen Standard Load Balancer benötigt (z. B. für ein VM-Scale-Set), könnt ihr die Outbound Rules gleich mit konfigurieren. Damit teilt sich eingehender und ausgehender Traffic eine IP. Achtet jedoch auf Limits: Ein Load Balancer unterstützt maximal 64.000 SNAT-Ports pro Backend-Instanz - für hochparallele Web-Crawler eventuell zu wenig.

Wann lohnt sich eine direkte Public IP?

Für Jump-Hosts oder Bastion-Systeme, die genau einen Service exponieren, ist die Zuordnung einer Public IP an die Netzwerkschnittstelle legitime Praxis. Beachtet, dass jede dieser IPs als eigenständige Ressource verrechnet wird und ihr das Lifecycle-Management manuell übernehmen müsst.

Sicherheit nicht vergessen

Explizite Outbound-Connectivity macht euch nicht automatisch sicherer, aber sie ermöglicht Sicherheit:

• NSG-Logging & Flow-Logs: Präzises Tracking der ausgehenden Sessions.
• Firewall Integration: Lenkt Traffic via Azure Firewall oder NVA, um DPI und Threat Intel einzubinden.
• Policy-as-Code: Verwaltet NAT Gateways und Regeln in Bicep/Terraform, verknüpft über Azure Policy.

Fahrplan für die Umstellung

1. Inventory: Nutzt Azure Resource Graph oder Network Watcher, um VMs zu identifizieren, die noch Default Outbound Access verwenden.
2. Architektur-Entscheid: Wählt NAT Gateway, Load Balancer oder Public IP pro Workload-Typ.
3. IaC-Anpassung: Aktualisiert Bicep/Terraform-Module.
4. Testing: Rollt in einer Staging-Subscription aus, überwacht Logs.
5. Cut-Over: Produktions-VNets umstellen.

Integration mit Entra ID und Zero Trust

Die neue Pflicht zur expliziten Ausgangsroute passt perfekt in die Zero-Trust-Philosophie von Entra ID: Authentifizierung, Autorisierung und Kontextkontrolle am Perimeter. Beispielsweise könnt ihr Conditional Access Policies formulieren, die den Zugriff auf SaaS-Ressourcen nur dann gestatten, wenn die ausgehende Quell-IP dem NAT Gateway eures Unternehmens entspricht.

Fazit

Die Änderung klingt unspektakulär, hat aber gewaltige Auswirkungen auf jeden Deployment-Prozess. Wer bis Ende 2025 keine explizite Outbound-Strategie etabliert, riskiert Downtime und Diagnose-Marathons. Gleichzeitig bietet die Umstellung eine Chance, Sicherheits- und Kosten-Potenziale zu heben.

Handelt jetzt – plant, testet und migriert eure Workloads rechtzeitig.

Ihr braucht Unterstützung? Nehmt gerne Kontakt mit uns auf: itelio Kontakt