S3-Buckets regionsübergreifend in AWS – mit (oder ab Nov. 2025: ohne!) VPC Peering

Am 19. November 2025 hat AWS angekündigt: "AWS PrivateLink now supports cross-region connectivity for AWS Services" [1].

Das heißt: Den in diesem Artikel beschriebenen Umweg über VPC Peering und Private Hosted Zone brauchen Sie nicht mehr. Es geht jetzt deutlich direkter (und einfacher!).

Ausführlich erklärt wird das im AWS-Blogbeitrag hier [2].

Wenn Sie trotzdem wissen möchten, wie es früher funktioniert hat, oder Private Hosted Zones für AWS-Dienste besser verstehen wollen, dann read on, Macduff (ja, ich weiß, eigentlich heißt es "Lay on, Macduff"…).

Laut AWS gibt es mehrere Wege, einen S3-Bucket in einer anderen Region zu nutzen – etwa wenn eine EC2-Instanz in us-west-2 auf einen S3-Bucket in us-east-1 zugreifen muss [3]. Hier geht es um die Variante "VPC Interface Endpoint (VPCE) mit VPC Peering".

Was AWS dabei verschweigt: Diese Lösung funktioniert nicht ohne eine kleine zusätzliche S3-Konnektivität in der Region, in der der Bucket nicht liegt (in meinem Beispiel also us-west-2). Darauf gehe ich später in Schritt 6 der Implementierung ein.

Eine EC2-Instanz in us-west-2 soll auf Daten in einem S3-Bucket in us-east-1 zugreifen. Der erste Reflex ist oft, einen S3 Gateway Endpoint in der VPC anzulegen – aber Achtung: S3 Gateway Endpoints bieten keinen regionsübergreifenden Zugriff. (S3 VPC Interface Endpoints standardmäßig übrigens auch nicht – aber genau diese setzen wir ein, um das Problem zu lösen.)

Diese Einschränkung gibt es, weil AWS-VPC-Endpoints darauf ausgelegt sind, private Konnektivität zu Diensten innerhalb derselben Region bereitzustellen.

Die Lösung: eine Brücke zwischen den Regionen per VPC Peering, kombiniert mit DNS-Auflösung, die den Traffic zielgenau lenkt. Folgende Bausteine kommen zum Einsatz:

Komponenten:

• VPC A: Ihre bestehende VPC in us-west-2, in der Ihre EC2-Instanz läuft
• VPC B: Eine neue oder bestehende VPC in us-east-1, in der wir unseren S3 Interface Endpoint platzieren
• VPC-Peering-Verbindung: 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 im Grunde nichts anderes als eine Elastic Network Interface (ENI) in einer Ziel-VPC, die über das AWS-Backbone private und sichere Konnektivität zu S3 bereitstellt (in unserem Fall in us-east-1)

Voraussetzungen

Stellen Sie zunächst sicher, dass Ihre VPCs keine überlappenden CIDR-Blöcke haben. AWS lässt Peering zwischen VPCs mit kollidierenden IP-Bereichen nicht zu. Außerdem setzen wir voraus, dass Ihre EC2-Instanz eine passende Instance Role mit den nötigen S3-Berechtigungen besitzt.

Schritt 1: S3-Endpoint absichern

Legen Sie in VPC B eine Security Group an (nennen wir sie VPC_B_S3_SG), die HTTPS-Traffic auf Port 443 aus dem CIDR-Bereich von VPC A zulässt. Diese Security Group schützt Ihren S3 Interface Endpoint und lässt nur den gewünschten Traffic durch. Falls Sie später Traffic aus weiteren VPCs oder CIDR-Blöcken zulassen möchten, ergänzen Sie diese einfach in der SG.

Schritt 2: S3 VPC Interface Endpoint anlegen

Legen Sie in VPC B (us-east-1) einen S3 VPC Interface Endpoint mit folgenden Einstellungen an [4]:

• Privates DNS deaktivieren
• Die zuvor erstellte Security Group VPC_B_S3_SG zuordnen

Schritt 3: VPC Peering einrichten

Erstellen Sie eine VPC-Peering-Verbindung zwischen VPC A und VPC B. So entsteht eine Netzwerkbrücke, über die Traffic zwischen den Regionen fließen kann [5].

Schritt 4: DNS-Auflösung mit PHZ konfigurieren

Legen Sie in Route53 eine Private Hosted Zone (PHZ) für die Domain s3.us-east-1.amazonaws.com an und verknüpfen Sie sie mit VPC A in us-west-2. Wiederholen Sie diese Verknüpfung für weitere VPCs in derselben oder in anderen Regionen, die Sie mit us-east-1 peeren wollen, damit der Traffic den S3 VPC Interface Endpoint in us-east-1 erreicht.

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 regionalen DNS-Namen* Ihres S3 VPC Interface Endpoints zeigen:

1. Root-Record: Lassen Sie das Feld "Record name" leer, um einen Eintrag für

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

Root-Record – Feld "Record name" leer lassen

2. Wildcard-Record: Setzen Sie * als Record name für

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

Catch-All – im Feld "Record name" ein "*" eintragen

\* Ein regionaler 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-1a (das wäre ein zonaler DNS-Name).

Ein zonaler DNS-Name ist sinnvoll in Architekturen, die workloads pro Availability Zone isolieren. Er kann zum Beispiel regionale Datentransferkosten senken, indem der Traffic in derselben AZ und Region wie die ENI des Interface Endpoints bleibt. Dieser Vorteil greift jedoch nur beim Zugriff innerhalb derselben Region und AZ – also nicht in einem regionsübergreifenden Szenario.

Resultierende Records:

Resultierende Records in der neuen PHZ

Schritt 5: Routing konfigurieren

Passen Sie Ihre Routing-Tabellen so an, dass Traffic zwischen den VPCs fließen kann:

• VPC A: Ergänzen Sie in der Routing-Tabelle des Subnetzes, in dem Ihre EC2-Instanz läuft, eine Regel, die den Traffic zum CIDR-Block von VPC B über die Peering-Verbindung leitet
• VPC B: Ergänzen Sie in der Route Table des Subnetzes (oder der Subnetze), in dem Ihr VPC Interface Endpoint liegt, eine Regel, die den Traffic zum CIDR-Block von VPC A über dieselbe Peering-Verbindung leitet

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

Hier kommt der entscheidende Punkt, der oft übersehen wird: Ihre EC2-Instanz in VPC A muss ihren regionalen S3-Endpoint (s3.us-west-2.amazonaws.com) erreichen können, um zu ermitteln, in welcher Region ein Bucket liegt. Ohne das müssen Sie beim Zugriff auf Buckets in us-east-1 jedes Mal explizit "--region " angeben.

Erreichen lässt sich das auf eine der folgenden Arten:

• Ein Internet Gateway oder NAT Gateway für Internetzugriff
• Ein S3 Gateway Endpoint in VPC A (aus Kostengründen 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 müssen – er ist im Gegensatz zu den Alternativen sowohl bei der Stundenrate als auch bei der Datenverarbeitung kostenfrei.

Wenn Sie über VPC Peering regionsübergreifend auf S3-Buckets zugreifen, sollten Sie Ihr AWS SDK so konfigurieren, dass es regionsübergreifende Anfragen sauber verarbeitet:

Variante 1: Regionale Endpoints angeben

Geben Sie die spezifische regionale Endpoint-URL (z. B. s3.us-east-1.amazonaws.com) für die Zielregion Ihres Buckets an.

Beispiel für JavaScript SDK V2:

const AWS = require('aws-sdk');

const s3 = new AWS.S3({
  endpoint: 's3.us-east-1.amazonaws.com'
});

Variante 2: Cross-Region-Zugriff aktivieren

• Java SDK v2: Verwenden Sie crossRegionAccessEnabled(true) in Ihrem S3-Client-Builder [9]
• JavaScript SDK v3: Setzen Sie followRegionRedirects: true in der Konfiguration Ihres S3-Clients [10]

Beispiel für JavaScript SDK v3:

const { S3Client } = require('@aws-sdk/client-s3');

const s3Client = new S3Client({
});

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

Für das JavaScript SDK V3 gilt das nicht – es cached keine Regionsinformationen. Jede regionsübergreifende Anfrage kann also zusätzliche Redirect-Latenz mit sich bringen. Bei bekannten Cross-Region-Zugriffsmustern empfiehlt es sich daher, stattdessen die exakte regionale Endpoint-URL anzugeben.

Die AWS CLI behandelt solche Redirects automatisch und braucht weder die Region noch die Endpoint-URL des Buckets, sofern Sie Schritt 6 oben befolgt haben.

Wenn Ihre EC2-Instanz auf einen Bucket in us-east-1 zugreifen will, läuft Folgendes ab:

1. Die Instanz fragt ihren regionalen S3-Dienst ab, um den Standort des Buckets zu ermitteln
2. Sobald sie weiß, dass der Bucket in us-east-1 liegt, fragt sie per DNS dessen IPs in us-east-1 ab
3. 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
4. Die private IP des S3 Interface Endpoints geht an die EC2-Instanz zurück
5. Die in der Routing-Tabelle des EC2-Subnetzes in VPC A hinzugefügte Regel leitet den Traffic dieser privaten IPs über die VPC-Peering-Verbindung an VPC B – und von dort zum S3 VPC Interface Endpoint
6. Der Endpoint stellt sicheren, privaten Zugriff auf S3-Buckets in us-east-1 bereit

Antworten von S3 (z. B. ein angefordertes Objekt) laufen über die VPC-Peering-Verbindung zurück an die EC2-Instanz in VPC A.

Konzeptionelles Architekturdiagramm

Diese Lösung umgeht die regionalen Einschränkungen von AWS auf elegante Weise:

• VPC Peering schafft regionsübergreifende Konnektivität
• Die private DNS-Auflösung der PHZ liefert die private IP des passenden regionalen S3-Endpoints
• Sicherheit bleibt gewahrt – über VPC-Endpoints statt Internet-Routing
• Keine Änderungen an Ihren Client-Anwendungen – Ihre Anwendungen müssen nicht angepasst werden (keine Region, keine Endpoint-URL nötig) und können einfach den Bucket-Namen verwenden

Kostenaspekte: VPC Peering verursacht Datentransferkosten [6], Interface Endpoints schlagen mit Stundengebühren plus Datenverarbeitungsgebühren zu Buche [7]. Beziehen Sie das in Ihre Architekturentscheidungen ein.

Latenz: Regionsübergreifender Traffic hat eine höhere Latenz als Zugriffe innerhalb derselben Region. Wenn Performance entscheidend ist, sollten Sie stattdessen über Bucket-Replikation nachdenken [8].

Komplexität: Dieses Setup erhöht die Architekturkomplexität. Prüfen Sie, ob die Vorteile (Kosten und Sicherheit innerhalb der VPC) den zusätzlichen Betriebsaufwand rechtfertigen.

Ich hoffe, dieser Artikel war hilfreich. Wenn Sie mehr erfahren möchten oder sich für unsere Services interessieren, melden Sie sich gerne bei uns. Sie erreichen uns hier.

1. https://aws.amazon.com/about-aws/whats-new/2025/11/aws-privatelink-cross-region-connectivity-aws-services/
2. https://aws.amazon.com/blogs/networking-and-content-delivery/aws-privatelink-extends-cross-region-connectivity-to-aws-services/
3. https://repost.aws/articles/ARjzluyMS8RbeOOK4MGXRG6Q/cost-effective-methods-for-accessing-s3-buckets-cross-region
4. https://docs.aws.amazon.com/vpc/latest/privatelink/create-interface-endpoint.html#create-interface-endpoint-aws
5. https://docs.aws.amazon.com/vpc/latest/peering/create-vpc-peering-connection.html
6. https://aws.amazon.com/vpc/pricing/
7. https://aws.amazon.com/privatelink/pricing/
8. https://docs.aws.amazon.com/AmazonS3/latest/userguide/replication.html
9. https://docs.aws.amazon.com/sdk-for-java/latest/developer-guide/s3-cross-region.html
10. https://docs.aws.amazon.com/AWSJavaScriptSDK/v3/latest/Package/-aws-sdk-middleware-sdk-s3/Interface/S3InputConfig/
11. What is VPC Peering
12. Gateway endpoints for Amazon S3
13. Working with Private Hosted Zones