PostgreSQL Flexible Server: raus aus dem delegierten Subnetz, hin zum Private Endpoint

Warum sich der Wechsel lohnen kann

Microsoft nennt Private Link inzwischen die empfohlene Alternative zur VNet-Integration. Die Gründe stehen in den Einschränkungen der VNet-Integration:

• Ein Server im delegierten Subnetz lässt sich nicht in ein anderes VNet oder Subnetz verschieben.
• Das Subnetz lässt sich nicht vergrößern, sobald Ressourcen darin liegen.
• Im delegierten Subnetz darf nichts anderes liegen, und Private Link steht dort nicht zur Verfügung.

Mit einem Private Endpoint liegt der Server außerhalb des eigenen Netzes und wird über eine private IP-Adresse erreicht. Mehrere Endpunkte in verschiedenen VNets sind möglich, ebenso Zugriff aus dem lokalen Netz über VPN oder ExpressRoute. Hochverfügbarkeit, Lesereplikate und Versionsupgrades funktionieren laut Microsoft auch mit Private Endpoints.

Mehr dazu: Standard Service Endpoint: Wann er Private Endpoints ersetzt und wann nicht

Was beim Umschalten passiert

Die Reihenfolge im Wartungsfenster

• Vorher: Subnetz für den Private Endpoint festlegen und die private DNS-Zone privatelink.postgres.database.azure.com mit allen VNets verknüpfen, aus denen zugegriffen wird. Bei lokalen DNS-Servern die Weiterleitung prüfen.
• Vorher: Verbindungszeichenfolgen kontrollieren. Microsoft rät, immer den vollqualifizierten Namen zu verwenden, weil sich die IP-Adresse ändern kann.
• Im Fenster: den Wechsel starten und warten, bis der Status von „Updating“ auf „Ready“ springt.
• Sofort danach: Private Endpoint anlegen und prüfen, ob der Servername auf die private Adresse auflöst.
• Danach: Anwendungen, Sicherungswerkzeuge und Überwachung testen.

az postgres flexible-server migrate-network \
  --resource-group <resource_group> \
  --name <server>

az postgres flexible-server show \
  --resource-group <resource_group> \
  --name <server> \
  --query "state"

Im Portal heißt die Option unter Netzwerk „Public access (allowed IP addresses) and private endpoints“. Der Bestätigungsdialog nennt die Folgen noch einmal ausdrücklich.

Drei Stellen, an denen es hakt

Terraform ist die gefährlichste. Steht in der Konfiguration noch delegated_subnet_id, plant Terraform einen neuen Server, weil dieser Wert einen Austausch erzwingt. Außerdem setzt der Provider public_network_access_enabled ohne Angabe auf true und würde den öffentlichen Zugriff wieder öffnen. Vor dem nächsten apply also beides anpassen und im plan prüfen, dass kein Austausch geplant ist.

Logische Replikation kann reißen. Abonnenten bauen die Verbindung zum Herausgeber selbst auf. Der private Weg über das delegierte Subnetz entfällt, jeder Abonnent muss den Private Endpoint erreichen, über dasselbe VNet, Peering, VPN oder ExpressRoute.

Fest eingetragene IP-Adressen in Anwendungen, Firewalls oder Skripten zeigen nach dem Wechsel ins Leere. Das betrifft auch Freigaben in Firewalls lokaler Standorte.

Betroffene Server finden

Die Abfrage im Azure Resource Graph listet alle Flexible Server, die noch in einem delegierten Subnetz liegen.

resources
| where type =~ 'microsoft.dbforpostgresql/flexibleservers'
| extend subnet = tostring(properties.network.delegatedSubnetResourceId)
| where isnotempty(subnet)
| project name, resourceGroup, location, version = tostring(properties.version), subnet
| order by version asc

Die Spalte version zeigt zugleich, welche Server ohnehin bald ein Versionsupgrade brauchen. Für PostgreSQL 14 beginnt am 1. Februar 2027 der kostenpflichtige Extended Support. Wer beide Eingriffe gemeinsam plant, stimmt sich nur einmal mit den Anwendungsverantwortlichen ab, auch wenn es zwei Wartungsfenster bleiben.

Mehr dazu: PostgreSQL 14 auf Azure: Ab 1. Februar 2027 kostet jeder vCore extra

Lohnt es sich für jeden Server?

Nein. Ein Server, der nur von Anwendungen im selben VNet genutzt wird und nicht wachsen muss, läuft mit VNet-Integration weiter ohne Nachteil. Interessant wird der Wechsel, wenn Zugriffe aus mehreren VNets oder vom Standort nötig sind, das Subnetz zu klein wird oder die Netzarchitektur auf Private Endpoints vereinheitlicht werden soll. Ein Architekturreview ordnet jeden Server einer dieser Gruppen zu, den Wechsel selbst führt Ihr Team im Wartungsfenster durch.