Default Outbound Internet Access wird abgeschaltet – was du jetzt in Azure tun musst

Microsoft hat angekündigt, die Default Outbound Internet Access für alle neuen Virtual Networks und Ressourcen Ende März 2026 zu entfernen. Das klingt nach einem technischen Detail im Azure Networking-Stack – ist aber in Wirklichkeit einer der bedeutendsten Breaking Changes der letzten Jahre. Wer seine Deployments, IaC-Templates und Landing Zones nicht aktiv anpasst, wird feststellen, dass neue VMs schlicht kein Internet mehr haben. In diesem Artikel schauen wir uns an, was genau sich ändert, welche Optionen es gibt und was du konkret tun musst, um vorbereitet zu sein.

Was genau ändert sich?

Bisher hat Azure jeder Virtual Machine in einem VNet automatisch ausgehenden Internetzugang bereitgestellt – über eine ephemere, von Azure verwaltete Public IP-Adresse. Dieses Verhalten existiert seit den Anfängen von Azure und war nie als Best Practice gedacht, sondern als Convenience-Feature für schnelle Tests und einfache Szenarien. Microsoft selbst hat es seit Jahren als „not recommended for production workloads“ gekennzeichnet, denn die ephemere IP kann sich ohne Vorwarnung ändern und bietet keinerlei Kontrolle oder Logging.

Ab Ende März 2026 gilt für alle neuen VNets und Ressourcen ein klares Prinzip: Ohne expliziten Outbound-Pfad gibt es keinen ausgehenden Internetzugang. Punkt. Neue Virtual Machines, die in einem frisch erstellten VNet deployt werden, haben ohne zusätzliche Konfiguration schlicht keine ausgehende Internetverbindung. Bestehende VNets und bereits laufende Ressourcen sind vorerst nicht betroffen – aber die Richtung ist unmissverständlich, und es ist nur eine Frage der Zeit, bis Microsoft den Scope erweitert.

Ein wichtiges Detail: Die Änderung betrifft ausschließlich Outbound-Konnektivität. Inbound-Traffic war nie Teil des Default-Verhaltens und bleibt unverändert. Wer also bereits Network Security Groups für eingehenden Traffic konfiguriert hat, muss dort nichts ändern.

Warum macht Microsoft das?

Die Motivation hinter dieser Änderung ist eindeutig: Zero Trust Networking konsequent umsetzen. Default Outbound war schon immer ein Sicherheitsrisiko, das in der Praxis zu realen Problemen geführt hat. Ohne expliziten Egress-Pfad gibt es kein Logging des ausgehenden Traffics, keine Möglichkeit zur URL-Filterung, keine Kontrolle über Data Exfiltration und keine Nachvollziehbarkeit, welche Daten wohin fließen.

Für jede Organisation mit ernsthaften Security-Anforderungen war die allererste Maßnahme bei einem neuen Azure-Deployment immer, Default Outbound durch eine kontrollierte Lösung zu ersetzen. Das war Best Practice in jedem Azure Well-Architected Review, in jedem Landing Zone-Design und in jeder Compliance-Prüfung. Microsoft zieht jetzt die logische Konsequenz und macht expliziten Egress zum Default-Verhalten.

Aus Security-Perspektive ist das der richtige Schritt. Impliziter Outbound war ein Überbleibsel aus einer Zeit, in der Cloud-Deployments noch simpel waren und Security-Anforderungen weniger strikt. In einer Welt, in der Data Exfiltration zu den häufigsten Angriffsvektoren gehört, ist unkontrollierter Outbound-Traffic schlicht nicht mehr akzeptabel. Der kurzfristige Migrationsaufwand ist real – aber die Alternative, nämlich unsichere Defaults beizubehalten, wäre langfristig teurer.

Die vier offiziellen Outbound-Optionen im Vergleich

Azure bietet vier unterstützte Methoden für expliziten Outbound-Zugang. Jede hat spezifische Stärken und Einsatzszenarien:

Für Enterprise-Architekturen im DACH-Mittelstand empfehle ich eine Kombination aus NAT Gateway und Azure Firewall. NAT Gateway kommt als Default in jedes Spoke-VNet – es ist günstig, einfach zu konfigurieren und skaliert automatisch. Azure Firewall sitzt im Hub-VNet und übernimmt Szenarien, die URL-Filtering, Threat Intelligence oder IDPS erfordern. Diese Kombination deckt erfahrungsgemäß 90% der Enterprise-Anforderungen ab und bietet ein gutes Verhältnis zwischen Kosten und Kontrolle.

Einen Sonderfall stellt der Load Balancer dar: Wer bereits einen Azure Load Balancer im Einsatz hat, kann dessen Outbound Rules nutzen, ohne zusätzliche Ressourcen zu deployen. Allerdings ist SNAT Port Exhaustion ein reales Risiko bei vielen VMs hinter einem einzigen LB – hier muss die Kapazität sorgfältig geplant werden. Public IPs direkt auf der NIC sind für Produktions-Workloads nur in Ausnahmefällen sinnvoll, da sie kein zentrales Management ermöglichen und die Angriffsfläche vergrößern.

Hands-on: NAT Gateway per Azure CLI einrichten

Die schnellste und unkomplizierteste Methode, ein bestehendes Subnet auf expliziten Outbound umzustellen, ist die Einrichtung eines NAT Gateways via Azure CLI. In drei Befehlen ist alles konfiguriert:

bash

# NAT Gateway Public IP erstellen
az network public-ip create \
  --resource-group myRG \
  --name nat-gw-pip \
  --sku Standard \
  --allocation-method Static
# NAT Gateway erstellen
az network nat gateway create \
  --resource-group myRG \
  --name myNATGateway \
  --public-ip-addresses nat-gw-pip \
  --idle-timeout 10
# NAT Gateway dem Subnet zuweisen
az network vnet subnet update \
  --resource-group myRG \
  --vnet-name myVNet \
  --name mySubnet \
  --nat-gateway myNATGateway

Nach der Zuweisung nutzen alle VMs im Subnet automatisch die statische Public IP des NAT Gateways für ausgehenden Traffic. Die bisherige ephemere Default-IP wird sofort nicht mehr verwendet. Das ist übrigens auch ein Vorteil gegenüber dem alten Verhalten: Die statische IP des NAT Gateways ist vorhersagbar und kann in Firewall-Whitelists bei Drittanbietern eingetragen werden – etwas, das mit der ephemeren Default-IP nie zuverlässig möglich war.

Für den Produktionseinsatz empfehle ich zusätzlich, mehrere Public IPs dem NAT Gateway zuzuweisen. Jede Public IP stellt 64.512 SNAT-Ports bereit. Bei Workloads mit vielen gleichzeitigen ausgehenden Verbindungen – etwa Web-Crawlern, API-Gateways oder Batch-Processing – reicht eine einzelne IP möglicherweise nicht aus.

Audit: Welche Ressourcen nutzen aktuell Default Outbound?

Bevor du migrierst, musst du zwingend wissen, welche Ressourcen aktuell auf Default Outbound angewiesen sind. Azure Resource Graph ist dafür das Mittel der Wahl, weil es über alle Subscriptions hinweg in Sekunden Ergebnisse liefert:

bash

# VMs ohne Public IP identifizieren
az graph query -q "
Resources
| where type == 'microsoft.compute/virtualMachines'
| extend nicId = tostring(properties.networkProfile.networkInterfaces[0].id)
| join kind=leftouter (
    Resources
    | where type == 'microsoft.network/networkinterfaces'
    | extend subnetId = tostring(properties.ipConfigurations[0].properties.subnet.id)
    | extend hasPublicIP = isnotnull(properties.ipConfigurations[0].properties.publicIPAddress)
    | project nicId = id, subnetId, hasPublicIP
) on nicId
| where hasPublicIP == false
| project name, resourceGroup, location
" --first 200

Jede VM in dieser Liste, die in einem Subnet ohne NAT Gateway, Azure Firewall Route oder Load Balancer mit Outbound Rules sitzt, nutzt aktuell Default Outbound und ist potenziell betroffen. Im nächsten Schritt solltest du für jede dieser VMs prüfen, ob das zugehörige Subnet bereits einen NAT Gateway zugewiesen hat – und falls nicht, ob die VM überhaupt Outbound-Konnektivität benötigt.

Nicht jede VM braucht Internet. Datenbank-Server, interne Application Server und andere Backend-Workloads kommen oft ohne ausgehende Internetverbindung aus. Für diese Fälle ist die Änderung sogar ein Sicherheitsgewinn, weil der bisher implizite Outbound-Zugang ohne Zutun wegfällt.

IaC-Templates: Die versteckte Falle

Der mit Abstand größte Impact dieser Änderung liegt nicht bei bestehenden Workloads, die bereits laufen – sondern bei Infrastructure-as-Code-Templates. Viele Terraform-Module, Bicep-Templates und ARM-Vorlagen erstellen VNets und Subnets ohne jegliche explizite Outbound-Konfiguration, weil Default Outbound bisher implizit vorhanden war. Nach dem Stichtag produzieren diese Templates Deployments ohne Internetkonnektivität.

Typische Problemmuster in Terraform sehen so aus:

hcl

# VORHER: Funktioniert nur mit Default Outbound
resource "azurerm_virtual_network" "example" {
  name                = "myVNet"
  address_space       = ["10.0.0.0/16"]
  location            = azurerm_resource_group.example.location
  resource_group_name = azurerm_resource_group.example.name
}
resource "azurerm_subnet" "example" {
  name                 = "mySubnet"
  resource_group_name  = azurerm_resource_group.example.name
  virtual_network_name = azurerm_virtual_network.example.name
  address_prefixes     = ["10.0.1.0/24"]
}
# NACHHER: Expliziter Outbound mit NAT Gateway
resource "azurerm_public_ip" "nat" {
  name                = "nat-gw-pip"
  location            = azurerm_resource_group.example.location
  resource_group_name = azurerm_resource_group.example.name
  allocation_method   = "Static"
  sku                 = "Standard"
}
resource "azurerm_nat_gateway" "example" {
  name                = "myNATGateway"
  location            = azurerm_resource_group.example.location
  resource_group_name = azurerm_resource_group.example.name
  sku_name            = "Standard"
}
resource "azurerm_nat_gateway_public_ip_association" "example" {
  nat_gateway_id       = azurerm_nat_gateway.example.id
  public_ip_address_id = azurerm_public_ip.nat.id
}
resource "azurerm_subnet_nat_gateway_association" "example" {
  subnet_id      = azurerm_subnet.example.id
  nat_gateway_id = azurerm_nat_gateway.example.id
}

Wer Azure Landing Zones mit dem Cloud Adoption Framework nutzt, sollte unbedingt prüfen, ob die verwendeten Module bereits NAT Gateway als Standard-Komponente enthalten. Die aktuellen CAF Terraform-Module in der neuesten Version unterstützen das – aber ältere Versionen tun es definitiv nicht. Ein Upgrade der Module ist in den meisten Fällen der schnellste Weg, um konform zu werden.

Besonders tückisch: Bicep-Module aus internen Registries. Viele Organisationen betreiben eine interne Bicep Registry mit bewährten Modulen, die über Jahre gewachsen sind. Diese Module wurden in einer Welt geschrieben, in der Default Outbound existierte. Ein systematisches Audit aller internen Module ist unerlässlich.

Besonders kritische Szenarien im Detail

Einige Dienste und Deployment-Patterns sind deutlich stärker von der Änderung betroffen als andere. Hier die wichtigsten:

Custom Script Extensions und Cloud-Init: Sehr viele VM-Deployments laden Post-Deployment-Skripte oder Software-Pakete aus dem Internet herunter. Ohne ausgehende Konnektivität scheitern diese Skripte komplett – und damit häufig das gesamte Deployment, weil nachgelagerte Konfigurationsschritte nicht ausgeführt werden können. Wer apt-get, yum, pip oder chocolatey in Custom Script Extensions nutzt, muss entweder Outbound sicherstellen oder auf Private Package Repositories umstellen.

Azure DevOps Self-Hosted Agents: Self-Hosted Build Agents, die in VNets ohne expliziten Outbound laufen, verlieren die Verbindung zu Azure DevOps Services. Pipelines brechen ab, Deployments bleiben stecken, und das Team wundert sich, warum der Agent offline ist. Dieses Szenario ist besonders kritisch, weil der Zusammenhang zwischen Networking-Änderung und Pipeline-Ausfall nicht sofort offensichtlich ist.

Windows Activation und Updates: Neue Windows VMs benötigen zwingend ausgehenden Zugang zum Azure KMS-Service unter kms.core.windows.net auf Port 1688 sowie zu Windows Update-Endpunkten. Ohne Outbound bleibt die VM unlizenziert und erhält keine Sicherheitsupdates – ein Compliance-Risiko, das bei Audits sofort auffällt.

Third-Party Monitoring und Security Agents: Nahezu alle gängigen Monitoring-Lösungen wie Datadog, Dynatrace, New Relic und Splunk setzen impliziten Outbound für die Agent-zu-Backend-Kommunikation voraus. Dasselbe gilt für Security-Agents von CrowdStrike, SentinelOne und anderen Anbietern. Ohne Outbound senden diese Agents keine Daten mehr – und die Lücken in Monitoring und Security-Telemetrie fallen oft erst Tage später auf.

DNS-Auflösung und NTP: Auch wenn Azure DNS für die interne Namensauflösung keinen Outbound benötigt, setzen viele Custom DNS-Konfigurationen auf externe Forwarder. Ebenso benötigen NTP-Clients Outbound-Zugang zu Zeitservern. Ohne korrekte Zeitsynchronisation können Kerberos-Authentifizierung, Zertifikatsvalidierung und Log-Korrelation fehlschlagen.

Proaktive Absicherung mit Azure Policy

Neben der technischen Migration empfehle ich dringend, Azure Policy einzusetzen, um sicherzustellen, dass neue Subnets immer eine explizite Outbound-Lösung erhalten. Eine Custom Policy Definition, die Subnets ohne NAT Gateway oder Route Table flaggt, verhindert, dass zukünftige Deployments das Problem erneut einführen. Kombiniert mit einer Deny-Wirkung sorgt diese Policy dafür, dass kein Subnet mehr ohne expliziten Egress erstellt werden kann – ein zusätzliches Sicherheitsnetz über die technische Migration hinaus.

Zeitplan und konkreter Aktionsplan

Die Abschaltung gilt ab Ende März 2026 für alle neuen VNets und Ressourcen. Microsoft hat bisher keinen konkreten Zeitplan für die Migration bestehender VNets kommuniziert – aber die Empfehlung ist unmissverständlich: Nicht warten, sondern jetzt handeln.

Mein konkreter Aktionsplan in vier Schritten:

1. Sofort: Resource Graph Query ausführen und alle Ressourcen identifizieren, die aktuell Default Outbound nutzen. Das Ergebnis in eine Excel-Liste exportieren und mit den verantwortlichen Teams teilen.
2. Diese Woche: Alle IaC-Templates, Bicep-Module und Terraform-Konfigurationen systematisch auf implizite Outbound-Abhängigkeiten prüfen. Custom Script Extensions und Cloud-Init-Skripte nicht vergessen.
3. Bis Ende März: NAT Gateway als Standard-Komponente in alle Landing Zone-Definitionen aufnehmen. Interne Template-Registries aktualisieren. CI/CD-Pipelines testen.
4. Laufend: Azure Policy mit Deny-Wirkung einrichten, die Subnets ohne explizite Outbound-Lösung blockiert. Monitoring für Outbound-Konnektivität etablieren.

Fazit

Die Entfernung der Default Outbound Internet Access ist ein überfälliger und richtiger Schritt in Richtung Zero Trust Networking. Der kurzfristige Migrationsaufwand ist real und sollte nicht unterschätzt werden – besonders der Audit von IaC-Templates und internen Modulen kostet Zeit. Aber die langfristigen Vorteile in Sachen Security, Compliance-Nachvollziehbarkeit und Kontrolle über den Datenfluss überwiegen bei weitem. Wer seine Landing Zones und IaC-Module jetzt anpasst, ist auf der sicheren Seite – und spart sich den Stress, wenn Microsoft den Scope auf bestehende VNets erweitert.

Dieser Artikel basiert auf der aktuellen Ausgabe von „Last Week in Azure & Tech“ – dem wöchentlichen Newsletter für Cloud-Architekten und IT-Leiter im DACH-Raum. Jetzt abonnieren

Quellen

• Default outbound access for VMs in Azure – Microsoft Learn
• Azure NAT Gateway documentation – Microsoft Learn
• Azure Firewall documentation – Microsoft Learn
• Azure Resource Graph queries – Microsoft Learn
• Azure Landing Zones (CAF) – Microsoft Learn
• Azure Virtual Network documentation – Microsoft Learn
• Azure Policy documentation – Microsoft Learn