04In meinen Azure-Kursen taucht diese Frage zuverlässig in jeder Netzwerk-Session auf: „Was ist eigentlich der Unterschied zwischen einem Private Endpoint und einem Service Endpoint – und wann nehme ich was?“ Die kurze Antwort lautet: Beide Mechanismen beschränken den Zugriff auf Azure-PaaS-Dienste (Platform as a Service, also verwaltete Dienste wie Storage, SQL oder Key Vault), aber sie tun das architektonisch vollständig verschieden. Wer das nicht versteht, baut entweder eine zu schwache Sicherheitsarchitektur oder zahlt drauf – und zwar unnötig.
Service Endpoints: Der direkte Weg mit Einschränkungen
Ein Service Endpoint erweitert die Identität eines virtuellen Netzwerks (VNet) bis zum Azure-Backbone. Konkret bedeutet das: Wenn Sie einen Service Endpoint für, sagen wir, Microsoft.Storage auf einem Subnetz aktivieren, wird der Datenverkehr aus diesem Subnetz zum Storage-Dienst über das Microsoft-Backbone geroutet – statt über das öffentliche Internet. Der Storage Account selbst bleibt dabei aber weiterhin unter einer öffentlichen IP erreichbar. Sie schränken lediglich ein, welche VNets zugreifen dürfen.
Das klingt gut, hat aber einen entscheidenden Haken: Der Dienst ist von außerhalb Ihres Netzwerks nach wie vor über seine öffentliche Endpunkt-Adresse erreichbar – sofern Sie die Firewall nicht zusätzlich konfigurieren. Außerdem gilt: Service Endpoints funktionieren nur innerhalb derselben Azure-Region oder in gepaarten Regionen. Cross-Subscription-Szenarien, also Zugriffe aus einem anderen Azure-Abonnement heraus, sind nur begrenzt möglich.
Service Endpoint auf Subnetz-Ebene aktivieren – die Konfiguration ist in wenigen Sekunden erledigt.
Merksatz: Ein Service Endpoint ändert die Route des Datenverkehrs, aber nicht die öffentliche Erreichbarkeit des Zieldienstes. Ohne zusätzliche Firewall-Regeln auf dem Dienst selbst bringt er allein wenig Sicherheitsgewinn.
Private Endpoints: Netzwerkidentität für PaaS-Dienste
Ein Private Endpoint geht einen entscheidenden Schritt weiter. Er weist einem Azure-PaaS-Dienst eine private IP-Adresse direkt in Ihrem VNet zu – über einen Netzwerk-Schnittstelleneintrag (NIC, Network Interface Card). Der Dienst bekommt damit eine echte Adresse in Ihrem privaten Adressraum, und der öffentliche Endpunkt kann vollständig deaktiviert werden.
Sobald ein Private Endpoint erstellt ist, muss die DNS-Auflösung (Domain Name System, Namensauflösung) korrekt konfiguriert sein. Azure empfiehlt dafür Private DNS Zones. Wenn Sie z. B. einen Private Endpoint für einen Storage Account anlegen, muss meinaccount.blob.core.windows.net intern auf die private IP auflösen – und nicht mehr auf die öffentliche. Wer das in seinen On-Premises-Umgebungen oder über hybride DNS-Setups abbilden möchte, kommt schnell in Konfigurationstiefe, die ich in meinen Azure-Kursen regelmäßig mit praktischen Lab-Übungen begleite.
Ein genehmigter Private Endpoint mit zugewiesener privater IP und korrekter DNS-Zone-Verknüpfung.
Private Endpoints funktionieren subscription- und mandantenübergreifend, sind regionunabhängig und lassen sich mit Network Policies (Netzwerkrichtlinien für Subnetze) feingranular steuern. Der Preis dafür: Sie zahlen pro Stunde für den Endpoint sowie für verarbeitete Datenmenge – das ist bei Service Endpoints nicht der Fall.
Der direkte Vergleich: Was wann einsetzen?
| Merkmal | Service Endpoint | Private Endpoint |
|---|---|---|
| Netzwerkidentität des Dienstes | Bleibt öffentlich | Private IP im eigenen VNet |
| Öffentlicher Endpunkt deaktivierbar | Nein (nur per Firewall einschränkbar) | Ja, vollständig |
| DNS-Konfiguration notwendig | Nein | Ja (Private DNS Zone empfohlen) |
| Cross-Subscription-Zugriff | Eingeschränkt | Vollständig unterstützt |
| Cross-Region-Zugriff | Nur gepaarte Regionen | Ja |
| Kosten | Keine zusätzlichen Kosten | Stundensatz + Datendurchsatz |
| Konfigurationsaufwand | Gering | Mittel bis hoch (DNS, Netzwerkpolicies) |
| Geeignet für Compliance-Anforderungen | Bedingt | Ja, auch strenge Anforderungen |
| On-Premises-Integration (Hybrid) | Nein | Ja (über VPN/ExpressRoute) |
Folgendes Problem aus der Praxis: Ich hatte mich in diesem Zusammenhang mit einem Kunden auseinandergesetzt, der einen Azure SQL Server per Service Endpoint „abgesichert“ hatte – und sich sicher wähnte. Bei näherer Betrachtung war der öffentliche Endpunkt aktiv, die Firewall-Regel ließ den eigenen IP-Bereich zu und hatte zusätzlich versehentlich „Azure Services erlauben“ aktiviert. Ergebnis: Faktisch kein nennenswerter Schutz. Ein Private Endpoint mit deaktiviertem Public Access hätte das verhindert.
Praxistipp: Wenn Sie Service Endpoints einsetzen, deaktivieren Sie unbedingt explizit den öffentlichen Zugriff auf den Zieldienst und setzen Sie enge Firewall-Regeln. Verlassen Sie sich nie allein auf den Endpoint selbst als Sicherheitsmaßnahme.
Praxisempfehlung: KMU-taugliche Entscheidungsstruktur
Noch mal in Kürze – kurz, knapp und strukturiert, zum Abharken:
Service Endpoint ist die richtige Wahl, wenn:
- Sie einen schnellen, kostenlosen Basisschutz für einen einzelnen PaaS-Dienst innerhalb einer Region brauchen.
- Compliance-Anforderungen keine vollständige Isolation des öffentlichen Endpunkts verlangen.
- Kein hybrider Zugriff aus On-Premises-Umgebungen erforderlich ist.
- Der Konfigurationsaufwand minimal sein soll und kein dediziertes DNS-Management vorhanden ist.
Private Endpoint ist die richtige Wahl, wenn:
- Sie den öffentlichen Endpunkt vollständig abschalten müssen – aus Compliance-, Datenschutz- oder regulatorischen Gründen.
- On-Premises-Systeme über VPN oder ExpressRoute auf Azure-Dienste zugreifen sollen.
- Der Zugriff subscription- oder mandantenübergreifend stattfindet.
- Sie eine einheitliche, skalierbare Netzwerkarchitektur mit zentralem DNS aufbauen wollen.
Für KMUs empfehle ich folgende Faustregel als Einstieg: Starten Sie mit Service Endpoints für nicht-kritische Dienste innerhalb einer Region, und setzen Sie Private Endpoints überall dort ein, wo personenbezogene Daten, Secrets (Key Vault) oder geschäftskritische Datenbanken im Spiel sind. Das ist kein entweder-oder – beide Mechanismen können und sollten in derselben Architektur nebeneinander existieren.
Wenn Sie tiefer in Azure-Netzwerkarchitekturen einsteigen möchten – von VNet-Design über DNS-Konzepte bis hin zu Hybrid-Connectivity – finden Sie passendes Material in meinen Azure-Kursen. Die Frage „Private oder Service Endpoint?“ ist dort übrigens immer ein Lab, kein reines Theoriethema.