Accéder à des buckets S3 entre régions AWS, avec (ou sans ! Nov. 2025 !) VPC Peering

Le 19 novembre 2025, AWS a annoncé : AWS PrivateLink prend désormais en charge la connectivité inter-régions pour les services AWS [1].

Autrement dit, vous n'avez plus besoin de mettre en place tout le VPC Peering ni la Private Hosted Zone décrits dans cet article. Le processus est désormais bien plus direct (et simple !).

Pour une explication complète, consultez l'article du blog AWS ici [2].

Si vous souhaitez tout de même découvrir comment cela se faisait auparavant, ou comprendre les Private Hosted Zones pour les services AWS, alors read on, Macduff (oui, je sais, la vraie citation est Lay on, Macduff…).

AWS nous indique que pour utiliser un bucket S3 dans une autre région (par exemple, une instance EC2 dans us-west-2 qui doit accéder à un bucket S3 dans us-east-1), plusieurs options s'offrent à nous [3]. Celle que je traite ici est l'option VPC interface endpoint (VPCE) avec VPC peering.

Ce qu'AWS ne précise pas, c'est que cela ne fonctionnera pas sans un petit complément de connectivité vers S3 dans la région qui n'héberge pas le bucket (dans mon exemple, us-west-2). J'y reviendrai plus loin, à l'étape 6 de la mise en œuvre.

Une instance EC2 fonctionnant dans us-west-2 doit accéder à des données stockées dans un bucket S3 situé dans us-east-1. Votre premier réflexe serait sans doute de créer un S3 Gateway Endpoint dans votre VPC, mais attention — les S3 Gateway Endpoints ne permettent pas l'accès inter-régions. (Les S3 VPC Interface Endpoints non plus, par défaut, mais nous allons les utiliser pour résoudre ce problème.)

Cette limitation tient au fait que les VPC endpoints AWS sont conçus pour fournir une connectivité privée à des services au sein de la même région.

La solution consiste à créer un pont entre les régions à l'aide du VPC peering, puis à exploiter la résolution DNS pour acheminer le trafic correctement. Voici ce que nous allons construire :

Composants :

• VPC A : votre VPC existant dans us-west-2, où s'exécute votre instance EC2
• VPC B : un VPC, nouveau ou existant, dans us-east-1 où nous placerons notre S3 Interface Endpoint
• Connexion VPC Peering : le pont entre nos deux VPC
• Private Hosted Zone : DNS Route53 pour résoudre correctement les S3 Endpoints
• S3 VPC Interface Endpoint : un Endpoint n'est rien d'autre qu'une Elastic Network Interface (ENI) dans un VPC cible, qui fournit une connectivité privée et sécurisée à S3 via le réseau backbone AWS (dans notre cas, dans us-east-1)

Prérequis

Avant de commencer, vérifiez que vos VPC n'ont pas de plages CIDR qui se chevauchent. AWS ne permet pas d'appairer des VPC dont les plages d'IP sont en conflit. On suppose également que votre instance EC2 dispose d'un rôle d'instance approprié, lui accordant les permissions nécessaires pour interagir avec S3.

Étape 1 : sécuriser votre S3 Endpoint

Créez un security group dans VPC B (appelons-le VPC_B_S3_SG) qui autorise le trafic HTTPS sur le port 443 depuis la plage CIDR de VPC A. Ce security group protégera votre S3 Interface Endpoint en n'autorisant que le trafic souhaité. Si, par la suite, vous devez autoriser l'Interface Endpoint à recevoir du trafic d'autres VPC ou plages CIDR, vous pourrez toujours les ajouter au SG.

Étape 2 : créer le S3 VPC Interface Endpoint

Dans VPC B (us-east-1), créez un S3 VPC Interface Endpoint avec ces paramètres précis [4] :

• Désactiver le DNS privé
• Attacher le security group VPC_B_S3_SG créé précédemment

Étape 3 : établir le VPC Peering

Créez une connexion de VPC peering entre VPC A et VPC B. Cela crée un pont réseau qui permet au trafic de circuler entre les régions [5].

Étape 4 : configurer la résolution DNS avec une PHZ

Dans Route53, créez une Private Hosted Zone (PHZ) pour le domaine s3.us-east-1.amazonaws.com et associez-la à VPC A dans us-west-2. Répétez cette association avec d'autres VPC, dans la même région ou dans d'autres, que vous prévoyez d'appairer avec us-east-1, afin de permettre au trafic d'atteindre le S3 VPC Interface Endpoint de us-east-1.

Associer VPC A de us-west-2 à la nouvelle PHZ

Au sein de cette PHZ, créez deux enregistrements Alias A pointant vers le nom DNS régional* de votre S3 VPC Interface Endpoint :

1. Enregistrement racine : laissez le nom de l'enregistrement vide pour créer un enregistrement pour

s3.us-east-1.amazonaws.com

Enregistrement racine — laissez le champ Record name vide

2. Enregistrement wildcard : utilisez * comme nom d'enregistrement pour gérer

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

Catch All — saisissez * dans le champ Record name

\* Un nom DNS régional est le nom sans spécification de zone de disponibilité.

Il ressemble à :

*.vpce-0123456789abcdefg-dawd972fe.s3.us-east-1.vpce.amazonaws.com Et non us-east-1a (qui est un nom DNS zonal).

Un nom DNS zonal est utile dans les architectures qui isolent les workloads par zone de disponibilité. Il peut par exemple aider à réduire les coûts de transfert de données régionaux en garantissant que le trafic reste dans la même AZ et la même région que l'ENI de l'Interface Endpoint. Toutefois, cet avantage ne vaut que pour des accès au sein de la même région et de la même AZ, ce qui ne s'applique pas dans un scénario inter-régions.

Enregistrements obtenus :

Enregistrements obtenus dans la nouvelle PHZ

Étape 5 : configurer le routage

Mettez à jour vos tables de routage pour que le trafic puisse circuler entre les VPC :

• VPC A : dans la table de routage du sous-réseau où s'exécute votre instance EC2, ajoutez une règle redirigeant le trafic destiné à la plage CIDR de VPC B via la connexion de peering
• VPC B : dans la table de routage du ou des sous-réseaux où vous avez placé votre VPC Interface Endpoint, ajoutez une règle redirigeant le trafic destiné à la plage CIDR de VPC A via la même connexion de peering

Étape 6 : activer l'accès régional à S3 pour le DNS local

Voici un élément crucial souvent négligé : votre instance EC2 dans VPC A doit pouvoir joindre son endpoint S3 régional (s3.us-west-2.amazonaws.com) afin de déterminer à quelle région appartient un bucket. Sans cela, vous devrez ajouter un --region à chaque accès aux buckets situés dans la région us-east-1.

Pour y parvenir, plusieurs méthodes sont possibles :

• Une Internet Gateway ou une NAT Gateway pour l'accès à Internet
• Un S3 Gateway Endpoint dans VPC A (recommandé pour des raisons de coût)
• Un S3 VPC Interface Endpoint dans VPC A avec le DNS privé activé

L'approche recommandée consiste à disposer d'un S3 Gateway Endpoint dans chaque VPC/région où vous devez accéder à S3, car il est gratuit, tant en tarif horaire qu'en traitement du trafic, contrairement aux alternatives.

Lorsque vous accédez à des buckets S3 inter-régions via le VPC peering, configurez votre SDK AWS pour gérer correctement les requêtes inter-régions :

Option 1 : spécifier les endpoints régionaux

Définissez l'URL de l'endpoint régional spécifique (par exemple, s3.us-east-1.amazonaws.com) correspondant à la région du bucket cible.

Exemple pour le SDK JavaScript V2 :

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

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

Option 2 : activer l'accès inter-régions

• SDK Java v2 : utilisez crossRegionAccessEnabled(true) dans le builder de votre client S3 [9]
• SDK JavaScript v3 : définissez followRegionRedirects: true dans la configuration de votre client S3 [10]

Exemple pour le SDK JavaScript v3 :

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

const s3Client = new S3Client({
});

Remarque : avec le SDK Java V2, la première requête vers un bucket d'une autre région peut entraîner une latence accrue, mais les requêtes suivantes bénéficient des informations de région mises en cache.

Ce n'est pas le cas du SDK JavaScript V3, qui ne met pas en cache ces informations. Chaque requête inter-régions peut donc subir une latence liée à la redirection. Pour de meilleures performances avec des schémas d'accès inter-régions connus, mieux vaut spécifier directement l'URL exacte de l'endpoint régional.

L'AWS CLI gère automatiquement ces redirections et ne nécessite ni la région du bucket ni l'URL de l'endpoint, à condition que vous ayez bien suivi l'étape 6 ci-dessus.

Lorsque votre instance EC2 tente d'accéder à un bucket dans us-east-1, voici le déroulé :

1. L'instance interroge son service S3 régional pour déterminer l'emplacement du bucket
2. Une fois qu'elle sait que le bucket se trouve dans us-east-1, elle interroge un DNS pour obtenir ses IP dans us-east-1
3. Votre Private Hosted Zone intercepte cette requête DNS et la résout vers l'IP privée de votre S3 Interface Endpoint dans VPC B
4. L'IP privée de votre S3 Interface Endpoint est renvoyée à l'EC2
5. La règle ajoutée à la table de routage du sous-réseau de l'EC2 dans VPC A redirigera le trafic destiné aux IP privées via la connexion de VPC peering vers VPC B, puis jusqu'au S3 VPC Interface Endpoint
6. L'endpoint fournit un accès sécurisé et privé aux buckets S3 dans us-east-1

Toute réponse de S3 (par exemple si vous avez demandé un objet) reviendra via la connexion de VPC Peering jusqu'à l'instance EC2 dans VPC A.

Schéma d'architecture conceptuel

Cette solution contourne élégamment les limitations régionales d'AWS :

• En exploitant le VPC peering pour créer une connectivité inter-régions
• En utilisant la résolution DNS via une PHZ privée pour obtenir l'IP privée du bon endpoint S3 régional
• En préservant la sécurité grâce aux VPC endpoints, sans passer par Internet
• Sans modifier vos applications client — vos applications ne nécessitent aucun changement (pas besoin d'ajouter une région ni une URL d'endpoint) et peuvent simplement utiliser le nom du bucket

Coûts : le VPC peering entraîne des frais de transfert de données [6], tandis que les Interface Endpoints génèrent des frais horaires auxquels s'ajoutent des frais de traitement des données [7]. Tenez-en compte dans vos décisions d'architecture.

Impact sur la latence : le trafic inter-régions présente une latence plus élevée que les accès intra-région. Si la performance est critique, envisagez plutôt des stratégies de réplication de buckets [8].

Compromis sur la complexité : cette configuration ajoute de la complexité architecturale. Évaluez si les bénéfices (coût et sécurité intra-VPC) justifient la charge opérationnelle supplémentaire.

J'espère que cet article vous a apporté des informations précieuses. Si vous souhaitez en savoir plus ou si nos services vous intéressent, n'hésitez pas à nous contacter. Vous pouvez nous joindre ici.

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