Private Subnets by Default in Azure – Was sich fundamental ändert und wie du deine Infrastruktur anpasst

Azure hat mit API-Version 2025-07-01 eine der grundlegendsten Änderungen am Networking-Stack der letzten Jahre vorgenommen: Neue Virtual Networks verwenden standardmäßig private Subnets. Was auf den ersten Blick nach einer kleinen API-Änderung klingt, hat weitreichende Auswirkungen auf Infrastruktur-as-Code, Deployment-Pipelines und die Art, wie Teams neue Workloads provisionieren.

In diesem Artikel erkläre ich, was sich konkret geändert hat, welche Szenarien betroffen sind und wie du deine Infrastruktur anpasst – mit praxisnahen Code-Beispielen für Azure CLI und Bicep. Am Ende findest du eine vierphasige Migrationsstrategie für Enterprise-Umgebungen und eine Checkliste für Landing-Zone-Updates.

Wichtig vorab: Diese Änderung betrifft ausschließlich neue Infrastruktur. Bestehende VNets und Subnets behalten ihr bisheriges Verhalten. Trotzdem sollte jedes Team, das Infrastruktur provisioniert, die Auswirkungen verstehen – denn der nächste Sprint mit einem neuen Microservice in einem frischen Subnet kommt garantiert.

Warum diese Änderung überfällig war

Bis März 2026 erhielt jede VM in einem Azure Virtual Network automatisch eine implizite Outbound Public IP. Azure wies diese IP transparent zu – ohne dass sie in der Ressourcenkonfiguration, in NSG-Regeln oder in Compliance-Reports auftauchte. Für Entwickler war das bequem: Eine frisch provisionierte VM konnte sofort apt update ausführen oder externe APIs aufrufen, ohne dass jemand explizit Outbound-Konnektivität konfigurieren musste.

Das Problem: Dieses Verhalten war ein Sicherheitsrisiko. Workloads konnten unkontrolliert ins Internet kommunizieren. Für Zero-Trust-Architekturen, in denen jeder Netzwerkfluss explizit autorisiert sein muss, war das ein fundamentaler Widerspruch. Security-Teams hatten keine vollständige Sichtbarkeit über ausgehenden Traffic, und FinOps-Teams konnten Outbound-Kosten nicht sauber attribuieren.

Microsoft hat dieses Verhalten mit der Retirement von Default Outbound Access bereits seit 2024 angekündigt und den Zeitplan mehrfach verschoben, um Kunden mehr Vorbereitungszeit zu geben. Seit dem 31. März 2026 ist die Änderung nun aktiv: Neue VNets, die über API-Version 2025-07-01 oder neuer erstellt werden, setzen defaultOutboundAccess auf false.

Für Cloud-Architekten im DACH-Mittelstand ist das besonders relevant: Viele Unternehmen haben in den letzten zwei Jahren ihre Azure-Landschaft aufgebaut und verwenden Standardtemplates, die impliziten Outbound-Zugriff voraussetzen. Diese Templates funktionieren weiterhin für bestehende Infrastruktur, aber bei der nächsten Erweiterung oder beim Aufbau einer neuen Umgebung greifen die neuen Defaults. Wer nicht vorbereitet ist, verliert wertvolle Stunden mit der Fehlersuche, warum eine frisch provisionierte VM plötzlich keine Pakete mehr installieren kann.

Was sich technisch geändert hat

Bevor wir in die Details einsteigen: Die Änderung selbst ist einfach zu verstehen. Die Umsetzung erfordert aber Anpassungen an mehreren Stellen gleichzeitig – von IaC-Templates über Landing Zones bis hin zu internen Dokumentationen. Deshalb lohnt es sich, die technischen Details genau zu kennen, bevor man mit der Implementierung beginnt.

Die Änderung betrifft drei Bereiche:

1. Subnet-Property defaultOutboundAccess ist standardmäßig false. Neue Subnets haben keinen impliziten Internet-Zugang.

2. Keine impliziten Public IPs. Azure weist VMs in neuen Subnets keine versteckten Outbound-IPs mehr zu. Der effectiveOutboundIPs-Wert ist leer, bis eine explizite Methode konfiguriert ist.

3. Explizite Outbound-Methode erforderlich. Für jedes Subnet mit Internet-Bedarf muss eine der folgenden Optionen konfiguriert werden:

Welche Szenarien betroffen sind

Die Änderung betrifft nur neue Infrastruktur – bestehende VNets und Subnets behalten ihr bisheriges Verhalten. Aber: Das Azure Portal nutzt die neue API seit dem 1. April 2026. Wer manuell ein VNet im Portal erstellt, bekommt automatisch private Subnets.

Konkret betroffen sind folgende Szenarien:

VMs in neuen VNets: Eine frisch provisionierte VM in einem neuen Subnet kann ohne NAT Gateway oder Public IP kein apt update, pip install oder DNS-Lookup gegen externe Resolver ausführen.

AKS-Cluster: Node Pools in neuen VNets brauchen explizit NAT Gateway für Container Image Pulls von Docker Hub, GitHub Container Registry oder anderen externen Registries. Wer bereits Azure Container Registry mit Private Link nutzt und ausschließlich interne Images pullt, ist nicht betroffen.

Azure Functions und App Service mit VNet Integration: Outbound-Calls an externe APIs (Payment Provider, SaaS-Dienste, externe Webhooks) schlagen fehl, wenn das integrierte Subnet kein NAT Gateway hat.

DevOps Build Agents: Self-hosted Agents in neuen VNets brauchen Outbound-Konnektivität für Package Downloads, Docker Hub Access und Kommunikation mit Azure DevOps.

Managed Services mit VNet-Injection: Dienste wie API Management (in VNet deployed), Azure Databricks und Azure Spring Apps, die in Kunden-Subnets deployt werden, brauchen ebenfalls explizite Outbound-Konnektivität. Hier lohnt sich ein Blick in die jeweilige Service-Dokumentation, da einige Dienste eigene Anforderungen an NAT Gateway oder Service Endpoints mitbringen.

Ein häufig übersehener Punkt: Auch DNS-Resolution gegen externe Resolver (z.B. 8.8.8.8) erfordert Outbound-Konnektivität. Wer Azure Private DNS Zones und den Azure-internen Resolver (168.63.129.16) nutzt, ist davon nicht betroffen. Aber Custom DNS-Konfigurationen mit externen Forwardern funktionieren in privaten Subnets ohne NAT Gateway nicht mehr.

NAT Gateway als Standard-Lösung

Microsoft empfiehlt NAT Gateway als primäre Lösung für Outbound-Konnektivität. Der Service ist Subnet-scoped, benötigt keine Routing-Konfiguration und liefert sofort Outbound-Konnektivität nach der Zuweisung.

Schritt 1: NAT Gateway mit Public IP erstellen

bash

# Resource Group und Location definieren
RG="rg-networking-prod"
LOCATION="westeurope"
# Public IP erstellen (Standard SKU, statische Allokation)
az network public-ip create \
  --name pip-natgw-prod-weu \
  --resource-group $RG \
  --location $LOCATION \
  --sku Standard \
  --allocation-method Static \
  --zone 1 2 3
# NAT Gateway erstellen
az network nat gateway create \
  --name natgw-prod-weu \
  --resource-group $RG \
  --location $LOCATION \
  --sku Standard \
  --idle-timeout 10 \
  --public-ip-addresses pip-natgw-prod-weu

Schritt 2: NAT Gateway einem Subnet zuweisen

bash

# Bestehendes Subnet aktualisieren
az network vnet subnet update \
  --name snet-workloads \
  --vnet-name vnet-prod-weu \
  --resource-group $RG \
  --nat-gateway natgw-prod-weu

Schritt 3: Konnektivität verifizieren

bash

# Von einer VM im Subnet testen
az vm run-command invoke \
  --resource-group $RG \
  --name vm-test \
  --command-id RunShellScript \
  --scripts "curl -s ifconfig.me && echo '' && curl -s -o /dev/null -w '%{http_code}' https://azure.microsoft.com"

Bicep-Template: VNet mit NAT Gateway

Für Infrastructure-as-Code ist die Anpassung der Templates der wichtigste Schritt. Hier ein vollständiges Bicep-Template, das ein VNet mit NAT Gateway als Standard erstellt:

bicep

@description('Location for all resources')
param location string = resourceGroup().location
@description('Environment prefix')
param envPrefix string = 'prod'
// Public IP for NAT Gateway
resource natGatewayPip 'Microsoft.Network/publicIPAddresses@2025-07-01' = {
  name: 'pip-natgw-${envPrefix}-${location}'
  location: location
  sku: { name: 'Standard' }
  zones: ['1', '2', '3']
  properties: {
    publicIPAllocationMethod: 'Static'
  }
}
// NAT Gateway
resource natGateway 'Microsoft.Network/natGateways@2025-07-01' = {
  name: 'natgw-${envPrefix}-${location}'
  location: location
  sku: { name: 'Standard' }
  properties: {
    idleTimeoutInMinutes: 10
    publicIpAddresses: [{ id: natGatewayPip.id }]
  }
}
// Virtual Network with Private Subnets + NAT Gateway
resource vnet 'Microsoft.Network/virtualNetworks@2025-07-01' = {
  name: 'vnet-${envPrefix}-${location}'
  location: location
  properties: {
    addressSpace: {
      addressPrefixes: ['10.0.0.0/16']
    }
    subnets: [
      {
        name: 'snet-workloads'
        properties: {
          addressPrefix: '10.0.1.0/24'
          defaultOutboundAccess: false
          natGateway: { id: natGateway.id }
        }
      }
      {
        name: 'snet-private-endpoints'
        properties: {
          addressPrefix: '10.0.2.0/24'
          defaultOutboundAccess: false
          // Kein NAT Gateway - Private Endpoints brauchen keinen Outbound
        }
      }
      {
        name: 'snet-aks-nodes'
        properties: {
          addressPrefix: '10.0.4.0/22'
          defaultOutboundAccess: false
          natGateway: { id: natGateway.id }
        }
      }
    ]
  }
}

Beachte: Nicht jedes Subnet braucht NAT Gateway. Subnets, die ausschließlich Private Endpoints hosten, brauchen keinen Outbound-Zugriff. Die Zuweisung gezielt nur dort vornehmen, wo Internet-Konnektivität tatsächlich benötigt wird. Ein typisches Muster in Enterprise-Umgebungen sieht drei Subnet-Typen vor: Workload-Subnets mit NAT Gateway für VMs und Container, Private-Endpoint-Subnets ohne jegliche Outbound-Konfiguration, und AKS-Node-Subnets mit NAT Gateway für Image Pulls und externe API-Kommunikation. Dieses Muster lässt sich gut in ein wiederverwendbares Bicep-Modul kapseln, das dann als Baustein in der Landing Zone dient.

Für Umgebungen mit besonders strengen Outbound-Anforderungen kann statt NAT Gateway auch Azure Firewall als zentrale Outbound-Instanz dienen. Der Vorteil: Granulare Application Rules und FQDN-basierte Filterung, sodass nicht nur der Outbound-Pfad explizit ist, sondern auch die erlaubten Ziele. Der Nachteil: Deutlich höhere Kosten und komplexere Konfiguration. Für die meisten Szenarien im Mittelstand ist NAT Gateway die pragmatischere Wahl.

Diagnostik: Prüfen ob bestehende Subnets betroffen sind

Bevor du Änderungen ausrollst, solltest du den aktuellen Status deiner Infrastruktur kennen. Mit folgendem Skript identifizierst du alle Subnets, die noch impliziten Outbound-Zugriff haben – und damit potenzielle Kandidaten für eine NAT-Gateway-Zuweisung bei der nächsten Migration:

bash

# Alle Subnets auflisten, die noch defaultOutboundAccess=true haben
az network vnet list \
  --query "[].{VNet:name, RG:resourceGroup, Subnets:subnets[?defaultOutboundAccess==true].name}" \
  -o json
# Subnets ohne NAT Gateway identifizieren
az network vnet list \
  --query "[].subnets[?natGateway==null].{Subnet:name, VNet:id}" \
  -o table

Beachte: Bestehende Subnets behalten ihr Verhalten. Aber sobald du ein bestehendes VNet erweiterst (neues Subnet hinzufügst) und dabei API-Version 2025-07-01 verwendest, gelten die neuen Defaults für das neue Subnet. Das kann in Mixed-State-Situationen führen, in denen ältere Subnets Outbound haben und neuere nicht – ein Debugging-Albtraum, wenn man die Ursache nicht kennt.

Terraform-Anpassung

Für Terraform-Nutzer: Der AzureRM Provider muss auf eine Version aktualisiert werden, die API-Version 2025-07-01 unterstützt. Das azurerm_subnet-Resource hat bereits das Attribut default_outbound_access_enabled:

hcl

resource "azurerm_subnet" "workloads" {
  name                            = "snet-workloads"
  resource_group_name             = azurerm_resource_group.main.name
  virtual_network_name            = azurerm_virtual_network.main.name
  address_prefixes                = ["10.0.1.0/24"]
  default_outbound_access_enabled = false
  # NAT Gateway zuweisen - nicht vergessen!
}
resource "azurerm_subnet_nat_gateway_association" "workloads" {
  subnet_id      = azurerm_subnet.workloads.id
  nat_gateway_id = azurerm_nat_gateway.main.id
}

Auswirkungen auf Azure Landing Zones

Wer den Azure Landing Zone Accelerator (ALZ) einsetzt, sollte prüfen, ob die aktuelle Version bereits Private Subnets berücksichtigt. Die offizielle ALZ-Referenzimplementierung auf GitHub wird laufend aktualisiert, aber Custom-Forks und ältere Deployments brauchen manuelle Anpassung.

Checkliste für Landing Zone-Updates:

• Alle Subnet-Module auf defaultOutboundAccess: false prüfen
• NAT Gateway als Pflicht-Ressource in Networking-Module aufnehmen
• Connectivity Subscription: Hub-VNet mit NAT Gateway für Spoke-Subnets, die Transit-Routing nutzen
• Policy-Definition erstellen, die defaultOutboundAccess: true in neuen Subnets verhindert
• Dokumentation und Runbooks aktualisieren

Kostenbetrachtung

NAT Gateway ist nicht kostenlos – und bei vielen Subnets summieren sich die Kosten:

Ein NAT Gateway kann mehreren Subnets im selben VNet zugewiesen werden – das reduziert die Basiskosten. Für Hub-Spoke-Topologien reicht oft ein zentraler NAT Gateway im Hub-VNet, wenn Spoke-Subnets über VNet Peering und UDRs routen.

Tipp: Azure Advisor gibt Empfehlungen für unterdimensionierte oder überdimensionierte NAT Gateways. Nach 30 Tagen Betrieb die Metriken prüfen und ggf. konsolidieren. Wer die neuen Azure Savings Plans nutzt, sollte prüfen, ob NAT-Gateway-Kosten in die Gesamtbetrachtung der Netzwerkkosten einfließen. Für FinOps-Teams ist das ein neuer Posten, der bei der Budgetplanung berücksichtigt werden muss – insbesondere wenn bisher kein expliziter Outbound-Dienst im Einsatz war und die Kosten dadurch unsichtbar blieben.

Einschränkungen und bekannte Probleme

• NAT Gateway ist regional – kein Cross-Region-Support. Jede Region braucht einen eigenen NAT Gateway
• Kein Support für IPv6-only Subnets – NAT Gateway arbeitet nur mit IPv4
• Basic Load Balancer inkompatibel – Subnets mit NAT Gateway können keinen Basic Load Balancer verwenden (Standard LB erforderlich)
• Availability Zone Mismatch – Die Public IP des NAT Gateways muss in denselben Zonen liegen wie die Ressourcen im Subnet, oder zone-redundant sein (empfohlen)
• SNAT Port Limits – NAT Gateway bietet 64.512 SNAT Ports pro Public IP. Bei hohem Outbound-Traffic ggf. mehrere Public IPs zuweisen
• Azure Policy Timing – Wenn du Azure Policy verwendest, um Outbound-Konfigurationen zu erzwingen, beachte, dass die Policy-Engine die API-Version des Deployments evaluiert. Policies, die auf ältere API-Versionen zielen, greifen nicht bei neuen Deployments

Für DACH-Unternehmen in regulierten Branchen hat die Änderung einen zusätzlichen Vorteil: Compliance-Audits werden einfacher, weil jeder Outbound-Pfad explizit dokumentiert und konfiguriert sein muss. Kein impliziter Traffic mehr, der durch NSG-Regeln rutscht, ohne in Logs aufzutauchen. Das erleichtert den Nachweis gegenüber Auditoren erheblich – besonders in Umgebungen, die ISO 27001 oder BSI Grundschutz unterliegen

Migration-Strategie für große Umgebungen

In Enterprise-Umgebungen mit hunderten Subnets empfehle ich eine schrittweise Vorgehensweise:

Phase 1 – Inventarisierung (Woche 1): Alle VNets und Subnets katalogisieren. Welche nutzen impliziten Outbound? Welche haben bereits NAT Gateway oder Load Balancer mit Outbound Rules? Ein einfaches Azure Resource Graph Query liefert die Antwort:

bash

az graph query -q "
  Resources
  | where type == 'microsoft.network/virtualnetworks'
  | mv-expand subnet = properties.subnets
  | project vnetName=name, subnetName=subnet.name,
    hasNatGw=isnotnull(subnet.properties.natGateway),
    defaultOutbound=subnet.properties.defaultOutboundAccess
  | where hasNatGw == false
"

Phase 2 – Template-Updates (Woche 2-3): Alle Bicep-Module, Terraform-Module und ARM-Templates aktualisieren. NAT Gateway als Standard-Ressource in Netzwerk-Module aufnehmen. CI/CD-Pipelines mit What-If-Checks erweitern, die bei fehlender Outbound-Konfiguration warnen.

Phase 3 – Policy Enforcement (Woche 4): Azure Policy erstellen, die defaultOutboundAccess: true in neuen Subnets verhindert. Das stellt sicher, dass keine Team versehentlich die alte Konfiguration deployed. Die Policy sollte im Audit-Modus starten und nach einer Übergangsphase auf Deny wechseln.

Phase 4 – Monitoring und Optimierung (laufend): NAT Gateway Metriken überwachen – insbesondere SNAT Port Utilization und Data Processed. Nach 30 Tagen evaluieren, ob NAT Gateways konsolidiert werden können (ein Gateway pro Hub-VNet statt pro Spoke).

Ein Punkt, der in vielen Migrationsplänen fehlt: die Kommunikation an Entwicklerteams. Wer Self-Service-Portale oder Backstage-Templates für Infrastruktur-Provisionierung anbietet, muss diese Templates aktualisieren, bevor Entwickler bei ihrem nächsten Deployment scheitern. Proaktive Kommunikation über interne Channels – Confluence, Teams, Slack – spart Support-Tickets und Frustration. Ich empfehle einen kurzen internen Blogpost oder eine Lunch-and-Learn-Session, die das Thema in 15 Minuten erklärt. Die Kernbotschaft: „Neue Subnets brauchen NAT Gateway – hier ist unser aktualisiertes Template.“

Zusätzlich sollten Teams, die mit Azure Policy arbeiten, eine Compliance-Policy erstellen, die neue Subnets ohne explizite Outbound-Konfiguration flaggt. Im Audit-Modus eingeführt, gibt sie Transparenz darüber, wo noch nachgebessert werden muss, ohne bestehende Deployments zu blockieren. Nach einer Übergangsphase von vier bis sechs Wochen kann die Policy auf Deny-Modus umgeschaltet werden.

Fazit

Die Umstellung auf Private Subnets by Default ist ein konsequenter Schritt in Richtung Secure-by-Default. Für bestehende Infrastruktur ändert sich nichts – aber jedes neue Deployment muss diese Realität berücksichtigen. Der Aufwand ist überschaubar: NAT Gateway erstellen, Subnets zuweisen, IaC-Templates aktualisieren. Wer das jetzt macht, vermeidet böse Überraschungen bei der nächsten Workload-Provisionierung.

Die eigentliche Herausforderung liegt nicht im Technischen, sondern im Organisatorischen: Alle Teams, die Infrastruktur provisionieren – Plattform-Engineering, DevOps, Entwickler mit Self-Service – müssen verstehen, dass „VNet erstellen und VM reinstellen“ nicht mehr out-of-the-box funktioniert. Schulung und Template-Updates sind der Schlüssel.

Mein Rat: Behandle diese Änderung nicht als reines Infrastruktur-Ticket. Es ist ein Enablement-Thema. Die Teams, die am schnellsten produktiv bleiben, sind die, deren Plattform-Team aktualisierte Templates und Self-Service-Module bereitstellt – nicht die, die erwarten, dass jeder Entwickler NAT Gateway-Konfiguration versteht.

Wer die Umstellung als Chance begreift, kann seine Netzwerkarchitektur gleichzeitig konsolidieren: NAT Gateway zentralisieren, Outbound-Traffic über Azure Monitor Pipeline sichtbar machen und FinOps-Teams erstmals einen vollständigen Überblick über Outbound-Kosten geben. Azure hat jahrelang implizite Konnektivität geschenkt – ab jetzt wird Outbound-Zugriff zu einer bewussten Architekturentscheidung. Und das ist genau richtig so.

Dieser Artikel basiert auf der „Last Week in Azure & Tech – Vol. 11“ Newsletter-Ausgabe. Du willst wöchentlich die wichtigsten Azure-Updates kompakt aufbereitet? Dann folge mir auf LinkedIn oder besuche rayscloudblog.com.

Quellen

• Private subnets by default in Azure Virtual Networks
• What is Azure NAT Gateway?
• Default Outbound Access in Azure
• Design virtual networks with NAT Gateway
• Azure Landing Zone Accelerator