Wer Azure-Workloads absichert, kennt diese Frage: Soll dieses Storage Account, diese SQL-Datenbank oder dieser Key Vault über einen Service Endpoint oder einen Private Endpoint erreicht werden? Beide klingen ähnlich, beide “machen den Traffic privat”, und das Azure-Portal bietet bereitwillig beides an. Sie funktionieren aber völlig unterschiedlich — und die falsche Wahl kostet dich entweder Geld oder reißt eine Sicherheitslücke auf.
In diesem Blog-Beitrag erkläre ich Service Endpoints vs Private Endpoints in einfacher Sprache. Ich zeige, was beide wirklich tun, wo VNet Integration hingehört (das wird ständig mit Private Endpoints verwechselt), und dann ergänze ich den Teil, den die meisten Vergleiche weglassen: wie das mit NSG, Azure Firewall und WAF zusammenhängt — und wann ich was nehme. Am Ende gibt es einen Entscheidungsbaum, den ich wirklich nutze. Ich habe versucht, es einfach zu halten, mit einer Grafik für jedes Konzept.
Table of contents
Welches Problem lösen wir eigentlich?
Standardmäßig hat ein Azure-PaaS-Dienst wie Azure Storage einen öffentlichen Endpunkt. Die Daten liegen hinter einem öffentlichen DNS-Namen und einer öffentlichen IP, geschützt durch deine Keys, Identitäten und eine Firewall. Das funktioniert — aber für viele Firmen ist “die Eingangstür steht im öffentlichen Internet” nicht gut genug: wegen Compliance, wegen Schutz vor Datenabfluss, oder weil das Security-Review schlicht Nein sagt.
Das Ziel ist also immer dasselbe: Mein virtuelles Netzwerk soll mit dem PaaS-Dienst sprechen, ohne ihn dem öffentlichen Internet auszusetzen. Service Endpoints und Private Endpoints lösen das beide — aber auf unterschiedlichen Ebenen. Schauen wir uns beide an.
Was ist ein Service Endpoint?
Ein Service Endpoint ist eine Einstellung, die du pro Subnet und pro Diensttyp aktivierst (zum Beispiel Microsoft.Storage). Ist sie an, nimmt der Traffic aus diesem Subnet zu diesem Diensttyp eine optimierte Route über das Microsoft-Backbone statt über das öffentliche Internet. Der Dienst sieht dann, dass die Anfrage aus deinem virtuellen Netzwerk kommt — du kannst also eine Firewall-Regel schreiben, die sagt “erlaube nur dieses VNet/Subnet”.
Das Wichtige steht im Bild: Der Traffic geht weiterhin zum öffentlichen Endpunkt des Dienstes. Er läuft nicht durchs öffentliche Internet — er bleibt auf dem Azure-Backbone — aber das Ziel ist nach wie vor die öffentliche IP des Dienstes. Nichts bekommt eine private IP. Du versteckst den Dienst nicht; du bringst den Dienst dazu, deiner VNet-Identität zu vertrauen.
Hinweis: Service Endpoints sind kostenlos, mit zwei Klicks aktiviert und auf ein virtuelles Netzwerk begrenzt. Der Haken: Sie wirken auf Dienst-Ebene, nicht auf Ressourcen-Ebene (für feinere Kontrolle gibt es Service Endpoint Policies), sie funktionieren nicht von on-premises (ein lokaler Host hat keine VNet-Identität), und nur für die Azure-Dienste, die sie unterstützen.
Was ist ein Private Endpoint?
Ein Private Endpoint ist eine andere Idee. Er erzeugt eine Netzwerkschnittstelle (NIC) mit einer privaten IP aus deinem Subnet und verknüpft sie über Azure Private Link mit genau einer PaaS-Ressource. Ab dann antwortet der Dienst auf einer privaten IP in deinem VNet — als würde er dort leben.
Sieh dir den Unterschied an: Das Storage Account hat jetzt die Adresse 10.0.1.4 innerhalb meines Netzwerks. Ich kann seinen öffentlichen Endpunkt komplett deaktivieren, sodass er aus dem Internet gar nicht mehr erreichbar ist. Und weil es nur eine private IP ist, erreichen on-premises-Clients ihn über VPN oder ExpressRoute — etwas, das ein Service Endpoint nie kann.
Das ist die Variante, die Microsoft für privaten Zugriff empfiehlt, und mein Standard für alles Sensible. Der Preis: Ein Private Endpoint ist ein Objekt auf Ressourcen-Ebene (eines pro Ressource bzw. pro Sub-Ressource wie blob vs. file), er ist nicht kostenlos (du zahlst pro Stunde plus verarbeitete Daten), und er braucht Private DNS — dazu unten mehr.
Service Endpoint vs Private Endpoint: die Unterschiede, die zählen
Das ist der Spickzettel, den ich im Kopf habe. Halte ihn schlank — die zwei Zeilen, die die meisten Designs entscheiden, sind “private IP” und “on-premises”.
| Service Endpoint | Private Endpoint | |
|---|---|---|
| Was er tut | Optimierte Route zum öffentlichen Endpunkt | Gibt dem Dienst eine private IP im VNet |
| Bekommt private IP? | Nein | Ja (eine NIC im Subnet) |
| Granularität | Diensttyp, pro Subnet | Eine konkrete Ressource |
| On-premises-Zugriff | Nein | Ja (VPN / ExpressRoute) |
| Öffentlich abschaltbar? | Nein (nur filtern) | Ja (vollständig privat) |
| DNS-Änderung nötig? | Keine | Ja — Private DNS Zone |
| Kosten | Kostenlos | Pro Stunde + verarbeitete Daten |
| Aufwand | Zwei Klicks | Mehr bewegliche Teile |
Die Kurzfassung, die ich Leuten sage: Ein Service Endpoint lässt die Tür öffentlich, öffnet sie aber nur für dein VNet. Ein Private Endpoint holt die Tür ins Haus. Brauchst du echte Isolation, on-premises-Zugriff oder “gar kein öffentlicher Zugriff”, willst du einen Private Endpoint. Willst du nur kostenlos Azure-zu-Azure-Traffic vom Internet fernhalten, reicht ein Service Endpoint.
Wo gehört VNet Integration hin?
Das ist der Punkt, der die Leute verwirrt — deshalb hat er ein eigenes Bild. VNet Integration ist die umgekehrte Richtung. Bei einem Private Endpoint geht es um Traffic, der in einen Dienst hineinkommt. Bei VNet Integration geht es um einen Azure-Compute-Dienst — typischerweise ein App Service oder eine Function — der Traffic hinaus in dein virtuelles Netzwerk schickt.
Wenn du die regionale VNet Integration aktivierst, werden die ausgehenden Aufrufe deiner Web-App in ein delegiertes Subnet injiziert. Von dort erreicht die App Private Endpoints, interne Load Balancer, andere VNet-Ressourcen und on-premises über VPN/ExpressRoute. Sie gibt der App keine private eingehende Adresse — willst du die App selbst eingehend privat machen, setzt du einen Private Endpoint auf die App.
Hinweis: Die beiden ergänzen sich, sie sind keine Alternativen. Ein sehr häufiges Muster: Mein App Service nutzt VNet Integration, um rauszukommen, und ruft dann ein Storage Account über dessen Private Endpoint, um reinzukommen. Beide Schalter an, eine App. Sobald du es als “rein vs. raus” siehst, verschwindet die Verwirrung.
Und NSG, Azure Firewall und WAF? Wann nehme ich was?
Endpoints entscheiden, wie ein Dienst erreicht wird. Sie filtern Traffic nicht nach Regeln. Genau dafür sind NSG, Azure Firewall und eine WAF da. Das sind keine Konkurrenten zu Endpoints — sie sitzen auf anderen Ebenen, und ein echtes Design nutzt mehrere davon zusammen. Dieses Bild ist das Mental Model, das ich verwende.
NSG — die kostenlose Grundlage
Eine Network Security Group ist ein kostenloser, zustandsbehafteter (stateful) Filter auf Layer 3/4, den du an ein Subnet oder eine NIC hängst. Sie erlaubt oder verbietet Traffic nach dem klassischen Fünf-Tupel: Quell-/Ziel-IP, Port und Protokoll. Ich nutze NSGs überall als Grundlage für Mikrosegmentierung — jedes Subnet bekommt eine. Sie sind günstig (kostenlos), einfach, und deine erste Antwort auf “wer darf innerhalb des VNets mit wem reden”.
Was eine NSG nicht ist: Sie versteht keine FQDNs, sie inspiziert keinen Anwendungsinhalt, und sie ist nicht für zentrale Egress-Policy über viele VNets gebaut. Dafür gehst du eine Ebene höher.
Hinweis: Da NSGs auf Service Tags filtern können (wie Storage oder Sql), nutzen Leute sie manchmal, um Traffic zu einem Service Endpoint einzuschränken. Das ist legitim, bleibt aber Fünf-Tupel-/Tag-Filterung — nicht die tiefe Kontrolle einer Firewall.
Azure Firewall — zentrale Egress- und FQDN-Kontrolle
Azure Firewall ist eine verwaltete, zustandsbehaftete, zentrale Firewall. Ich greife dazu, wenn ich ausgehende (Egress-) Kontrolle brauche — zum Beispiel “VMs dürfen nur diese freigegebenen FQDNs erreichen” — oder wenn ich eine Policy über ein Hub-and-Spoke-Netzwerk will, Threat-Intelligence-Filterung und L3–L7-Regeln an einem Ort. Sie ist das Werkzeug für die Frage “womit darf meine Umgebung im Internet überhaupt sprechen?”
Der Haken sind Kosten und Betrieb: Azure Firewall wird pro Stunde plus verarbeitete Daten abgerechnet und ist eine echte Plattform, die betrieben werden will. Für ein kleines Setup decken NSGs plus Private Endpoints oft alles ab. Für einen Enterprise-Hub verdient die Firewall ihr Geld.
WAF — Schutz für eingehende Web-Apps
Eine Web Application Firewall sitzt auf Azure Application Gateway oder Azure Front Door und schützt eingehende Web-Anwendungen auf Layer 7. Sie blockt die Angriffe auf Anwendungsebene, die eine NSG und eine Netzwerk-Firewall nie sehen: SQL Injection, Cross-Site-Scripting, die OWASP Top 10, böse Bots. Wenn du eine Web-App veröffentlichst, hält eine WAF den hässlichen Traffic draußen.
Eine WAF ist keine Netzwerk-Firewall — sie macht keine allgemeine Fünf-Tupel-Filterung und kein Egress. Sie ist auf HTTP/S vor deinen Apps spezialisiert. Du betreibst sie zusammen mit NSGs und (oft) einem privaten Backend hinter Private Endpoints.
So halte ich sie in einem Atemzug auseinander: NSG = kostenlose L3/4-Grundlage überall. Azure Firewall = zentrale Egress- und FQDN-Kontrolle. WAF = Schutz für eingehende Web-Apps (L7). Endpoints = wie der PaaS-Dienst privat erreicht wird. Verschiedene Aufgaben, gemeinsam genutzt.
Kurzer Hinweis zu DNS — der Teil, der kaputtgeht
Wenn ein Private Endpoint “nicht funktioniert”, ist in neun von zehn Fällen DNS der Grund. Wenn du einem Dienst eine private IP gibst, muss der öffentliche DNS-Name jetzt auf diese private IP auflösen — für Clients innerhalb des VNets. Das macht eine Private DNS Zone (zum Beispiel privatelink.blob.core.windows.net), die mit deinem VNet verknüpft ist, meist automatisch eingerichtet, wenn du den Endpoint im Portal erstellst.
Hinweis: Wenn eine VM dein Storage Account auf eine öffentliche IP auflöst, fehlt die Private DNS Zone oder ist nicht verknüpft — kein Firewall-Problem. Service Endpoints brauchen dagegen gar keine DNS-Änderung, weil der Name weiterhin auf den öffentlichen Endpunkt zeigt. Dieser DNS-Aufwand gehört real zu den “Kosten” eines Private Endpoints und sollte von vornherein eingeplant werden.
Was kostet das?
Geld entscheidet oft. Service Endpoints sind kostenlos. Ein Private Endpoint kostet rund 0,01 \$ pro Stunde (etwa 7–8 \$ pro Endpoint und Monat) plus verarbeitete Daten, und du zahlst pro Endpoint und pro Sub-Ressource — das summiert sich über eine große Umgebung. Azure Firewall und WAF kommen mit eigenen Stunden- und Datenkosten obendrauf. Das ehrliche Muster lautet also: Nutze die kostenlosen Kontrollen (NSG, Service Endpoints), wo sie reichen, und gib Geld für Private Endpoints, Firewall und WAF aus, wo das Risiko es rechtfertigt. Aktuelle Zahlen immer auf der Azure-Private-Link-Preisseite prüfen.
Der Entscheidungsbaum, den ich wirklich nutze
Wenn ich den Zugriff für eine neue Ressource designe, gehe ich das im Kopf durch. Es bewahrt mich davor, ein Dev-Storage-Account zu over-engineeren und eine Produktionsdatenbank zu unterschätzen.
- Eingehend zu einem PaaS-Dienst? Brauche ich eine private IP, on-premises-Zugriff oder will ich öffentlichen Zugriff vollständig abschalten → Private Endpoint.
- Will ich nur Azure-zu-Azure-Traffic vom Internet fernhalten, kostenlos, ohne DNS-Arbeit → Service Endpoint.
- Muss ein App Service oder eine Function ins VNet hineingreifen (einen Private Endpoint, eine interne Ressource, on-premises aufrufen)? → VNet Integration aktivieren. Sie ergänzt, sie ersetzt nicht.
- Dann die Filter schichten: NSG als Grundlage überall, Azure Firewall für zentrales Egress, WAF vor jeder veröffentlichten Web-App.
Fehler, die ich heute vermeide
- VNet Integration für einen Private Endpoint halten. Sie ist ausgehend aus deiner App, nicht eingehend zu einem Dienst. Andere Richtung, anderer Schalter.
- Private DNS vergessen. Der Endpoint ist erstellt, die App trifft trotzdem die öffentliche IP, und alle schimpfen auf die Firewall. Zuerst die Private DNS Zone prüfen.
- Den öffentlichen Endpunkt anlassen. Ein Private Endpoint deaktiviert öffentlichen Zugriff nicht automatisch. Ist Isolation das Ziel, schalte den öffentlichen Netzwerkzugriff explizit ab.
- Eine WAF als Netzwerk-Firewall nutzen (oder umgekehrt). Sie schützen verschiedene Ebenen. Meist brauchst du beide.
- Für alles Private Endpoints zahlen. Für nicht-sensiblen, reinen Azure-Traffic sind ein kostenloser Service Endpoint plus eine NSG oft die richtige Wahl.
Wohin das geht
Die klare Richtung von Microsoft sind Private Link und Private Endpoints als Standard für privaten PaaS-Zugriff, während Service Endpoints die kostenlose, einfache Option für die Fälle bleiben, die keine volle Isolation brauchen. Wenn du etwas Neues baust, würde ich von “Private Endpoint, außer es gibt einen Grund dagegen” ausgehen und Service Endpoints für die günstigen, Azure-internen Pfade reservieren. Und dann das Ganze in die richtigen Filter packen — NSG, Firewall, WAF — für die Aufgabe, die jeder davon erfüllt.
Wenn du tiefer einsteigen willst, ist die offizielle Doku gut: Azure Virtual Network Service Endpoints, Azure Private Link und VNet Integration für Azure-Dienste. Und wenn du diese Art von Hands-on-Erklärung magst, findest du mehr auf meinem Blog.
Ich hoffe, das ist eine kleine Hilfe und macht die Entscheidung Service Endpoints vs Private Endpoints leichter, wenn sie das nächste Mal auf deinem Tisch landet.
Stay healthy, Cheers Jannik