S3-Buckets regionsübergreifend per VPC Peering nutzen

Praxisleitfaden: Warum regionsübergreifender S3-Zugriff mehr braucht als VPC Interface Endpoints mit privatem DNS

Hintergrund

Was AWS dabei verschweigt: Ohne eine zusätzliche Anbindung an S3 in der Region ohne Bucket (in meinem Beispiel us-west-2) funktioniert das schlicht nicht. Darauf gehe ich später in Schritt 6 der Umsetzung ein.

Szenario

Diese Einschränkung rührt daher, dass AWS VPC Endpoints private Konnektivität ausschließlich zu Diensten innerhalb derselben Region bereitstellen.

Die Lösungsarchitektur

Komponenten:

VPC B: Eine neue oder bestehende VPC in us-east-1, in der wir unseren S3 Interface Endpoint platzieren
VPC Peering Connection: Die Brücke zwischen unseren beiden VPCs
Private Hosted Zone: Route53-DNS, das S3 Endpoints korrekt auflöst
S3 VPC Interface Endpoint: Ein Endpoint ist letztlich nichts anderes als eine Elastic Network Interface (ENI) in einer Ziel-VPC, die über das AWS-Backbone-Netzwerk private und sichere Konnektivität zu S3 bereitstellt (in unserem Fall in us-east-1)

Schritt-für-Schritt-Umsetzung

Voraussetzungen

Schritt 1: S3 Endpoint absichern

Schritt 2: S3 VPC Interface Endpoint anlegen

Privates DNS deaktivieren
Die zuvor angelegte Security Group VPC_B_S3_SG zuweisen

Schritt 3: VPC Peering einrichten

Schritt 4: DNS-Auflösung über die PHZ konfigurieren

VPC A aus us-west-2 mit der neuen PHZ verknüpfen

Legen Sie innerhalb dieser PHZ zwei Alias-A-Records an, die auf den Regional DNS Name* Ihres S3 VPC Interface Endpoints zeigen:

1. Root-Record: Lassen Sie den Record-Namen leer, um einen Eintrag für

s3.us-east-1.amazonaws.com

anzulegen.

Root-Record — Record-Namen leer lassen

2. Wildcard-Record: Tragen Sie * als Record-Namen ein, um

*.s3.us-east-1.amazonaws.com

abzudecken.

Catch-All — "*" als Record-Namen eintragen

\* Ein Regional DNS Name ist der Name ohne Angabe einer Availability Zone.

Er sieht so aus:

`*.vpce-0123456789abcdefg-dawd972fe.s3.us-east-1.vpce.amazonaws.com

Und nicht us-east-1` a(das wäre ein Zonal DNS Name).

Ein Zonal DNS Name ist sinnvoll in Architekturen, die workloads pro Availability Zone isolieren. So lassen sich etwa regionale Datenübertragungskosten senken, indem der Traffic in derselben AZ und Region bleibt wie die ENI des Interface Endpoints. Dieser Vorteil greift jedoch nur bei Zugriffen innerhalb derselben Region und AZ – im regionsübergreifenden Szenario also nicht.

Die resultierenden Records:

Resultierende Records in der neuen PHZ

Schritt 5: Routing konfigurieren

VPC A: Ergänzen Sie in der Routing-Tabelle des Subnetzes, in dem Ihre EC2-Instanz läuft, eine Regel, die den Traffic für den CIDR-Block von VPC B über die Peering Connection leitet
VPC B: Ergänzen Sie in der Route-Tabelle der Subnetze, in denen Ihr VPC Interface Endpoint liegt, eine Regel, die den Traffic für den CIDR-Block von VPC A über dieselbe Peering Connection leitet

Schritt 6: Regionalen S3-Zugriff für lokales DNS aktivieren

Dafür haben Sie mehrere Möglichkeiten:

Ein Internet Gateway oder NAT Gateway für Internetzugriff
Ein S3 Gateway Endpoint in VPC A (aus Kostensicht empfohlen)
Ein S3 VPC Interface Endpoint in VPC A mit aktiviertem privatem DNS

Empfehlenswert ist ein S3 Gateway Endpoint in jeder VPC bzw. Region, in der Sie auf S3 zugreifen – er ist kostenfrei, sowohl beim Stundensatz als auch bei der Traffic-Verarbeitung, anders als die Alternativen.

AWS-SDK-Konfiguration für regionsübergreifenden S3-Zugriff

Option 1: Regionale Endpoints angeben

Beispiel für JavaScript SDK V2:

Option 2: Cross-Region-Zugriff aktivieren

JavaScript SDK v3: Setzen Sie followRegionRedirects: true in Ihrer S3-Client-Konfiguration [8]

Beispiel für JavaScript SDK v3:

Hinweis: Beim Java SDK V2 kann die erste Anfrage an einen Bucket in einer anderen Region eine erhöhte Latenz haben; nachfolgende Anfragen profitieren von gecachten Regionsinformationen.

Für das JavaScript SDK V3 gilt das nicht – es cached keine Regionsinformationen. Jede regionsübergreifende Anfrage kann daher eine Redirect-Latenz mit sich bringen. Für bessere Performance bei bekannten regionsübergreifenden Zugriffsmustern lohnt es sich, stattdessen die exakte regionale Endpoint-URL anzugeben.

Die AWS CLI verarbeitet solche Redirects automatisch und benötigt – sofern Sie Schritt 6 befolgt haben – weder Region noch Endpoint-URL für einen Bucket.

So greift alles ineinander

Die Instanz fragt ihren regionalen S3-Dienst ab, um den Standort des Buckets zu ermitteln
Sobald klar ist, dass der Bucket in us-east-1 liegt, fragt sie per DNS nach dessen IPs in us-east-1
Ihre Private Hosted Zone fängt diese DNS-Anfrage ab und löst sie auf die private IP Ihres S3 Interface Endpoints in VPC B auf
Die private IP Ihres S3 Interface Endpoints wird an die EC2-Instanz zurückgegeben
Die Regel, die Sie der Routing-Tabelle des EC2-Subnetzes in VPC A hinzugefügt haben, leitet den Traffic an die privaten IPs über die VPC Peering Connection nach VPC B und von dort zum S3 VPC Interface Endpoint
Der Endpoint stellt sicheren, privaten Zugriff auf S3-Buckets in us-east-1 bereit

Antworten von S3 (etwa beim Abruf eines Objekts) laufen über dieselbe VPC Peering Connection zurück zur EC2-Instanz in VPC A.

Konzeptionelles Architekturdiagramm

Warum dieser Ansatz funktioniert

VPC Peering sorgt für regionsübergreifende Konnektivität
Private DNS-Auflösung über die PHZ liefert die private IP des passenden regionalen S3 Endpoints
Sicherheit bleibt durch VPC Endpoints gewahrt – ganz ohne Routing über das Internet
Keine Anpassung der Client-Apps nötig – Ihre Anwendungen kommen ohne Änderungen aus (keine Region, keine Endpoint-URL erforderlich) und können einfach den Bucket-Namen verwenden

Worauf Sie achten sollten

Latenz: Regionsübergreifender Traffic ist langsamer als Zugriffe innerhalb derselben Region. Wenn Performance entscheidend ist, sind Bucket-Replikationsstrategien die bessere Wahl [6].

Komplexitäts-Trade-off: Dieses Setup erhöht die architektonische Komplexität. Prüfen Sie, ob die Vorteile (Kosten und VPC-interne Sicherheit) den zusätzlichen operativen Aufwand rechtfertigen.

Handlungsaufforderung

Quellen

Haben Sie bereits regionsübergreifende VPC-Konnektivität in Ihrer AWS-Umgebung umgesetzt? Ich freue mich über Ihre Erfahrungen und Varianten dieses Ansatzes.