Ein API-Call von einer EC2-Instanz an S3 oder DynamoDB nimmt ohne weitere Konfiguration den Weg über das Internet-Gateway deiner VPC, selbst wenn Quelle und Ziel beide bei AWS liegen. Für private Subnetze ohne Internet-Gateway heißt das: ein NAT-Gerät muss den Traffic nach außen schleusen, nur damit der Call wieder zu einem AWS-Service zurückfindet. Der Datenverkehr verlässt dabei zwar nicht das AWS-Netz, läuft aber über einen öffentlichen Pfad mit zusätzlichen Hops, NAT-Gateway-Kosten und einer größeren Angriffsfläche.

AWS PrivateLink und VPC-Endpoints lösen genau dieses Problem: die Anfrage bleibt innerhalb der VPC beziehungsweise im privaten AWS-Netz, ganz ohne Internet-Gateway oder NAT. Es geht hier ausschließlich um diesen Netzwerkpfad, nicht darum, wer mit welcher Rolle auf welche Ressource zugreifen darf.

Zwei Typen von VPC-Endpoints

AWS unterscheidet für den Zugriff auf AWS-Services zwei relevante Endpoint-Typen: Gateway Endpoints und Interface Endpoints. Beide sorgen dafür, dass der Call die VPC nicht über das offene Internet verlässt, technisch funktionieren sie aber grundverschieden.

Gateway Endpoint: Routing-Eintrag, kostenlos, nur zwei Services

Ein Gateway Endpoint existiert ausschließlich für Amazon S3 und DynamoDB. Technisch ist er ein Eintrag in der Routing-Tabelle: AWS legt dort automatisch eine Route an, deren Ziel eine von AWS verwaltete Prefix-Liste für den jeweiligen Service ist, das eigentliche Ziel dieser Route ist der Gateway Endpoint selbst. Jede Subnetz-Routing-Tabelle, die du mit dem Endpoint verknüpfst, nutzt ihn automatisch; Instanzen in nicht verknüpften Subnetzen laufen weiterhin über den öffentlichen Service-Endpunkt.

Für die Nutzung von Gateway Endpoints fallen laut AWS keine zusätzlichen Kosten an. Er nutzt kein PrivateLink und keine eigene Netzwerkkarte, deshalb bleibt er auf S3 und DynamoDB begrenzt. Beide Services lassen sich auch klassisch über ihre öffentlichen Endpunkte erreichen, der Gateway Endpoint ersetzt dabei nur den Pfad.

Interface Endpoint: eigene Netzwerkkarte mit PrivateLink

Ein Interface Endpoint ist technisch etwas anderes: AWS legt pro ausgewähltem Subnetz eine Elastic Network Interface (ENI) an und vergibt ihr eine private IP-Adresse aus dem Subnetz. Diese ENI ist der Eintrittspunkt für Traffic, der per AWS PrivateLink an den jeweiligen Service geht; einen Internet-Gateway oder NAT braucht es dafür nicht. Über Interface Endpoints erreichst du einen deutlich größeren Kreis an AWS-Services als nur S3 und DynamoDB. Welche Services das im Einzelnen sind, listet AWS in der PrivateLink-Dokumentation zu den unterstützten AWS-Services.

Interface Endpoints kosten anders als Gateway Endpoints: abgerechnet wird eine Stundenpauschale pro Endpoint-ENI und je verarbeitetem GB Traffic, gestaffelt nach Datenvolumen pro Region.

DNS-Auflösung: damit der Standardname privat zeigt

Damit bestehender Code, zum Beispiel ein SDK-Aufruf an den öffentlichen Service-Hostnamen, automatisch über den Interface Endpoint läuft statt über das Internet, braucht es private DNS. Beim Anlegen eines Interface Endpoints ist die Option „Enable DNS name“ für die meisten Services standardmäßig aktiv; AWS empfiehlt ausdrücklich, das so zu lassen. Voraussetzung dafür ist, dass in der VPC DNS-Hostnamen und DNS-Auflösung aktiviert sind, sonst lässt sich private DNS gar nicht nutzen. Ist die Option aktiv, lösen Anfragen an den öffentlichen Servicenamen innerhalb der VPC auf die private IP-Adresse der Endpoint-ENI auf, ohne dass sich im Code etwas ändert.

Sicherheitsgruppen am Interface-Endpoint

Ein Interface Endpoint hängt an einer Sicherheitsgruppe wie jede andere ENI. AWS verlangt dafür ausdrücklich eine eigene Sicherheitsgruppe am Endpoint, die den erwarteten Traffic zulässt, zum Beispiel eingehendes HTTPS, wenn eine Anwendung per AWS CLI oder SDK auf den Service zugreift. Fehlt diese Freigabe, bleibt der Call auf Netzwerkebene hängen, meist mit einem Timeout, der sich zunächst wie ein DNS-Fehler liest, tatsächlich aber die fehlende Sicherheitsgruppenregel ist.

Endpoint-Policies: eine Grenze, die nicht IAM ist

Zusätzlich zur Sicherheitsgruppe lässt sich an jeden VPC-Endpoint eine Endpoint-Policy hängen. Das ist eine IAM-Resource-Policy, die direkt am Endpoint sitzt und festlegt, welche Prinzipale diesen konkreten Netzwerkpfad überhaupt nutzen dürfen. Ohne eigene Policy gilt die Standardeinstellung: voller Zugriff für alle Prinzipale auf alle Ressourcen über diesen Endpoint. Wichtig ist die Abgrenzung: die Endpoint-Policy entscheidet, was über diesen Pfad technisch möglich ist, nicht was eine Rolle oder ein Nutzer grundsätzlich darf. Diese zweite Frage, Rollen, Policies, Permission Boundaries, Service Control Policies, ist hier bewusst ausgeklammert.

Abgrenzung zu den anderen Beiträgen hier im Blog

Hier im Blog ging es bisher dreimal um die IAM-Seite von AWS-Governance: in „AWS IAM ohne Schmerzen: Rollen, Policies und häufige Fehler“ (22.06.2026), in „AWS Organizations Service Control Policies: Warum AdministratorAccess im Mitgliedskonto trotzdem nichts bringt“ (19.10.2026) und in „AWS IAM Permission Boundaries: die Obergrenze, die ein Nutzer sich selbst nicht erweitern kann“ (30.10.2026). Dazu kommt „AWS Config statt manueller Checkliste: der Ist-Zustand, nicht die Momentaufnahme“ (06.11.2026) zur laufenden Kontrolle des Zustands.

Alle vier Beiträge klären, wer was anfragen darf. Dieser Beitrag klärt eine andere Frage: auf welchem Weg die Anfrage überhaupt das AWS-Netz erreicht. Eine wasserdichte IAM-Policy nützt wenig, wenn der Call vorher über ein NAT-Gateway ins offene Internet und zurück läuft, und ein Interface Endpoint ersetzt keine einzige IAM-Regel. Er sorgt nur dafür, dass der Pfad dorthin privat bleibt.

Kurzer Hinweis zum Schluss

Fragen zu PrivateLink, VPC-Endpoints oder dem Zusammenspiel mit den oben verlinkten IAM-Themen beantworte ich direkt per Mail. Wer die nächsten Beiträge nicht verpassen will, abonniert den Newsletter unten auf dieser Seite.