Default Outbound Access in Azure wird abgeschaltet

Microsoft hat angekündigt, der bisher automatisch bereitgestellte „Default Outbound Access“ in Azure wird abgeschaltet. Diese Änderung greift nach dem 31.03.2026 und betrifft nahezu alle Azure‑Kunden – egal ob sie kleine Testumgebungen oder komplexe Produktivsysteme betreiben.
Während bisher jede VM ohne zusätzliche Konfiguration ins Internet kommunizieren konnte, wird dies nun nicht mehr der Fall sein.

In diesem Blogbeitrag erkläre ich:

• Was genau Microsoft ändert – und warum.
• Welche Auswirkungen entstehen, wenn Sie nichts unternehmen.
• Welche technischen Alternativen es gibt und was deren Vor- und Nachteile sind.

Was bedeutet diese Änderung?

Azure stellt seit vielen Jahren standardmäßig einen automatisch konfigurierten SNAT‑Mechanismus bereit (“Default Outbound Access”). Dadurch konnten VMs das Internet erreichen, auch ohne:

• Public IP
• NAT Gateway
• Load Balancer
• explizite User‑Defined‑Routes

Dieses Verhalten war zwar bequem, aber sicherheitstechnisch und architektonisch problematisch:

• Nicht deterministische IP‑Adressen (SNAT IP konnte sich ändern und war nicht unter eigener Kontrolle)
• Unklare Verantwortlichkeit: Outbound Traffic ohne explizite Konfiguration
• Security‑Risiken durch unbeabsichtigten Internetzugang
• Eingeschränkte Skalierbarkeit (Ports, SNAT‑Pool‑Limits etc.)
• Nicht für Conditional Access Regeln in Entra ID geeignet

Microsoft schafft diesen Mechanismus für neue virtuelle Netzwerke nun zum 31.03.2025 ab und verlangt, dass Outbound‑Traffic explizit konfiguriert wird. Ausgenommen hiervon sind die Azure Cloud Services mit extended Support.

Das bedeutet, dass alle ab dem 01.04.2026 neu erstellten virtuellen Netzwerke (vnet) standardmäßig private Neztwerke ohne ein- oder ausgehende Konnektivität sind.

Was passiert, wenn Sie nichts tun?

Kurz gesagt: Für bereits bestehende virtuelle Netzwerke ändert sich nichts. Ich empfehle dennoch auch in bestehenden Netzwerken die Umstellung auf die alternativen, wenn die Netzwerke produktiv genutzt werden.

Jedes neu erstellte virtuelle Netzwerk das ab dem 01.04.2026 erstellt wird, ist standardmäßig ein privates Netzwerk ohne ein- oder ausgehende Konnektivität. Um Konnektivität sicherzustellen, muss diese explizit eingerichtet werden.

Welche Alternativen gibt es?

Microsoft stellt verschiedene Möglichkeiten bereit, um kontrollierten und sicheren Outbound‑Zugriff zu ermöglichen. Microsoft hat in einem Learn-Artikel einige Optionen beschrieben.

Nachfolgend zeigen wir alternativen und beschreiben, wann diese verwendet werden sollten.

Option 1: NAT Gateway

Nutzbar für Entwicklungszwecke, oder Umgebungen, die nur ausgehenden Netzwerk Verkehr benötigen und dabei vollständig getrennt vom Unternehmensnetzwerk bleiben sollen.

Vorteile:

• Hochskalierbar
• Statische, dedizierte IP
• Kein SNAT‑Port‑Exhaustion
• Einfacher Betrieb (Subnetz‑Level)

Nachteile:

• Keine Absicherung mittels Firewall möglich
• Ausgehender Datenverkehr kann nicht kontrolliert werden
• Keine Anbindung ans Unternehmensnetzwerk ohne weitere Konfiguration

Option 2: Azure Load Balancer (Standard SKU)

Wenn sowieso ein Load Balancer eingesetzt wird, kann dieser die Outbound‑Verbindungen übernehmen.

Vorteile:

• Kostengünstiger als NAT Gateway
• Kombinierbar mit Inbound Load Balancing

Nachteile:

• SNAT‑Port‑Limits müssen beachtet werden
• Keine klare Trennung zwischen Load Balancing und Outbound NAT

Option 3: Public IP / Public IP Prefix direkt an der VM

Eine einfache, aber meist weniger sichere Variante. Sollte nur für einzelne Systeme verwendet werden, die direkt ins Internet verbunden werden sollen (bspw. Firewalls).

Vorteile:

• Statische, dedizierte IP
• Kein SNAT‑Port‑Exhaustion
• Einfache Konfiguration

Nachteile:

• Systeme sind allen Risiken im Internet direkt ausgesetzt
• Schlechte Skalierbarkeit
• Systeme müssen entsprechend abgesichert werden

Option 4: Azure Firewall / Security Appliances

Für produktive Umgebungen die reguliert werden sollen oder Zugriff auf das Unternehmensnetzwerk benötigen.

Vorteile:

• Zentrale Kontrolle
• Logging, Filtering, TLS‑Inspection
• Outbound‑Policies zur Einschränkung des Datenverkehrs

Nachteile:

• Teurer als andere Varianten
• Höherer administrativer Aufwand

Option 5: Private Endpoints + Kein Outbound Internet

Für Zero‑Trust‑Ansätze oder vollständig isolierte Workloads die ausschließlich interne Azure‑Dienste anspricht.

Vorteile:

• Keine Angriffsfläche von außen
• Einfache Konfiguration

Nachteile:

• Kein Zugriff auf Software Updates aus anderen Netzwerken / dem Internet
• Monitoring Möglichkeiten der System eingeschränkt

Fazit

Die Änderung von Microsoft, dass der Default Outbound Access in Azure abgeschaltet wird, ist ein sinnvoller Schritt von Microsoft, um Azure‑Umgebungen sicherer, transparenter und planbarer zu machen.
Für Kunden bedeutet dies jedoch Handlungsbedarf, da sich Outbound‑Internet‑Zugriff nicht mehr „von selbst ergibt“. Wer rechtzeitig eine klare Outbound‑Strategie umsetzt, reduziert Risiken, erhöht Sicherheit und verbessert die Skalierbarkeit seiner Azure‑Workloads.

Wenn Sie Unterstützung bei der Analyse, Architektur oder Umsetzung benötigt, helfen wir euch gerne weiter!