In vielen Azure-Umgebungen, die ich betreue, stoße ich nach wie vor auf Basic Public IPs und Basic Load Balancer. Bei Workloads, die vor einigen Jahren aufgebaut wurden, war das damals schlicht der Standard. Nun rückt das Supportende näher, denn am 30. September 2025 stellt Microsoft den Support für Basic Public IP Addresses und Basic Load Balancer ein. Das wirkt noch weit weg, kann sich aber schnell zur Baustelle auswachsen, sobald produktive Systeme oder externe Schnittstellen betroffen sind.

Zuerst müssen die betroffenen Ressourcen sichtbar werden

Oft hakt es schon daran, die Ressourcen überhaupt zu finden. Basic Public IPs liegen gern in Resource Groups, um die sich niemand mehr kümmert, hängen an Test-VMs oder sind Überbleibsel älterer Deployments. In solchen Fällen greife ich immer zum Azure Resource Graph Explorer, mit dem sich gezielt alle Basic Public IPs aufspüren lassen:

resources
| where type == "microsoft.network/publicipaddresses"
| where sku.name == "Basic"

Die Abfrage lässt sich direkt im Azure Portal → Azure Resource Graph Explorer ausführen. Wer lieber über die Oberfläche sucht, kann auf den Azure Advisor zurückgreifen. Er gibt Warnungen aus, sobald er im Tenant Basic-IP-Adressen oder Basic Load Balancer findet. Dabei sollte man sich nicht auf die offensichtlichen Produktionsressourcen beschränken, sondern auch Dev- und Testumgebungen durchsehen.

Die Standard-SKU hält Ports geschlossen, bis eine Regel sie öffnet

Häufig werde ich gefragt, warum der Wechsel überhaupt nötig ist. In der Praxis stammen Basic Public IPs und Basic Load Balancer meist aus einer Zeit, in der niemand „Port offen, alles erreichbar“ als Sicherheitsrisiko betrachtet hat. Die wichtigsten Unterschiede im Überblick:

  • Standard Public IPs sind standardmäßig nicht erreichbar – erst passende NSG-Regeln (Network Security Group) öffnen Ports nach außen.
  • Sie unterstützen Zonenredundanz und werden fest (statisch) zugewiesen.
  • Basic Load Balancer und Basic IPs sind dagegen von vornherein offen und weniger ausfallsicher.

Damit entsprechen die Standard-Komponenten genau den Security-Best-Practices, die heute in jedem Tenant Pflicht sind. Vor allem der Grundsatz „Secure by default“ sorgt dafür, dass versehentlich offen gelassene Ports kein Thema mehr sind. Weitere Details finden sich in der offiziellen Microsoft-Dokumentation.

Für IPs und Load Balancer gibt es unterschiedliche Upgrade-Wege

Für Public IPs bietet Azure inzwischen erfreulicherweise ein In-place-Upgrade von Basic auf Standard an, bei dem die IP-Adresse erhalten bleibt. Allerdings muss die Adresse vorher von allen Ressourcen (z. B. VM-NICs oder Load Balancern) getrennt werden. Das bedeutet in der Regel einen kurzen Ausfall, ohne Wartungsfenster geht es also nicht. Nach dem Upgrade lässt sich die IP wieder zuweisen. Ein echtes „Live-Upgrade“ ohne Downtime gibt es nicht.

Bei Basic Load Balancern sieht der Weg anders aus. Hier hilft das PowerShell-Modul AzureBasicLoadBalancerUpgrade, das die Migration auf einen Standard Load Balancer samt Backend-Pools und Regeln automatisiert. Die Konfiguration sollte man trotzdem gründlich prüfen, denn Features wie Floating IPs oder bestimmte Protokollkombinationen bilden die beiden SKUs unterschiedlich ab.

Tipp aus der Praxis: Wer viele IPs und Load Balancer migrieren muss, sollte das Vorgehen zunächst in einer Testumgebung anhand von Musterabläufen durchspielen, bevor er produktive Ressourcen umstellt. Das erspart böse Überraschungen, gerade bei komplexen Multi-Tier-Systemen.

Ohne sauber geplantes Wartungsfenster drohen Ausfälle

Leider erlebe ich immer wieder, dass Teams nur auf die Azure-Ressourcen schauen und die Abhängigkeiten vergessen. Besonders heikel sind VMs, denen eine Basic Public IP direkt zugewiesen ist. Für das Upgrade muss die IP gelöst werden, wodurch das Netzwerk kurz unterbrochen wird. Davon können auch VPN-Gateways, Bastion Hosts oder externe Schnittstellen betroffen sein, die fest auf bestimmte IPs zeigen. Eine detaillierte Dokumentation und ein sauber abgestimmtes Wartungsfenster helfen hier weiter. Am besten testet man die Konnektivität vor und nach dem Upgrade und hält bei Bedarf eine Rollback-Strategie bereit.

Zur Veranschaulichung habe ich ein einfaches Flussdiagramm erstellt, das den Weg von der Bestandsaufnahme bis zur abgeschlossenen Migration zeigt:

flowchart TD
    Start["Start"] --> Finden["Basic IPs/Load Balancer finden"]
    Finden --> Entscheiden["Upgrade nötig?"]
    Entscheiden -- "Ja" --> Trennen["Ressourcen trennen"]
    Trennen --> Upgrade["Upgrade durchführen"]
    Upgrade --> Prüfen["Konnektivität prüfen"]
    Prüfen --> Fertig["Fertig"]
    Entscheiden -- "Nein" --> Fertig

Abbildung: Ablauf der Migration von Basic auf Standard Public IP bzw. Load Balancer im Überblick.

Ein früher Start nimmt der Umstellung den Schrecken

Wer schon jetzt anfängt, seine Azure-Ressourcen auf das Supportende für Basic Public IPs und Load Balancer vorzubereiten, erspart sich Stress und unnötige Ausfälle. Vor allem in größeren Tenants mit vielen Altbeständen führt an einer strukturierten Suche und Planung kein Weg vorbei. Die Standard-Komponenten bringen echte Sicherheitsvorteile mit, verlangen aber auch, dass man Netzwerkzugriffe aktiv steuert. Vor der eigentlichen Migration empfehle ich Testläufe und eine Dokumentation der eigenen Abläufe. Außerdem lohnt sich ein regelmäßiger Blick in die Advisor-Empfehlungen, denn dort tauchen häufig noch vergessene Basic-Ressourcen auf. Wer Unterstützung braucht, findet im Microsoft-Umfeld zahlreiche Anleitungen, und auch ich halte meine Blogserie zu diesem Thema auf dem aktuellen Stand.