Accéder aux buckets S3 entre régions AWS via VPC Peering

Un guide pratique pour comprendre pourquoi l'accès S3 inter-régions exige bien plus que des VPC Interface Endpoints avec DNS privé.

Contexte

Ce qu'AWS ne précise pas, c'est que cela ne fonctionnera pas sans un petit ajout de connectivité vers S3 dans la région qui ne contient pas le bucket (par exemple, dans mon cas us-west-2). J'y reviendrai à l'étape 6 de l'implémentation.

Scénario

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

Architecture de la solution

Composants :

VPC B : un VPC nouveau ou existant en us-east-1 où nous placerons notre S3 Interface Endpoint
VPC Peering Connection : 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 qu'une Elastic Network Interface (ENI) dans un VPC cible, qui fournit une connectivité privée et sécurisée vers S3 via le réseau backbone d'AWS (dans notre cas, en us-east-1)

Implémentation pas à pas

Prérequis

Étape 1 : Sécuriser votre S3 Endpoint

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

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

Étape 3 : Établir le VPC Peering

Étape 4 : Configurer la résolution DNS via la PHZ

Associez le VPC A de us-west-2 à la nouvelle PHZ

Dans 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-1` a (qui est un nom DNS zonal).

Un nom DNS zonal est utile dans les architectures qui isolent les workloads par Availability Zone. Il permet par exemple de 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. Cet avantage ne vaut toutefois que pour un accès intra-région et intra-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

VPC A : dans la table de routage du sous-réseau où s'exécute votre instance EC2, ajoutez une règle qui redirige le trafic destiné au bloc CIDR du 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 qui redirige le trafic destiné au bloc CIDR du VPC A via la même connexion de peering

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

Plusieurs méthodes permettent d'y parvenir :

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

L'approche recommandée consiste à déployer un S3 Gateway Endpoint dans chaque VPC/région où vous avez besoin d'accéder à S3 : il est gratuit — tant pour le tarif horaire que pour le traitement du trafic — contrairement aux autres options.

Configuration du SDK AWS pour l'accès S3 inter-régions

Option 1 : Spécifier des endpoints régionaux

Exemple avec le SDK JavaScript V2 :

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

JavaScript SDK v3 : définissez followRegionRedirects: true dans la configuration de votre client S3 [8]

Exemple JavaScript SDK v3 :

Remarque : avec le SDK Java V2, la première requête vers un bucket d'une autre région peut subir une latence plus élevée, mais les requêtes suivantes profitent de la mise en cache des informations de région.

Ce n'est pas le cas du SDK JavaScript V3, qui ne met pas ces informations en cache. Chaque requête inter-régions peut donc subir une latence de 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 ces redirections automatiquement et n'a besoin ni de la région ni de l'URL d'endpoint pour un bucket, à condition d'avoir suivi l'étape 6 ci-dessus.

Vue d'ensemble du fonctionnement

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

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

Schéma d'architecture conceptuel

Pourquoi cette approche fonctionne

Tirer parti du VPC peering pour créer une connectivité inter-régions
S'appuyer sur la résolution DNS d'une PHZ privée pour obtenir l'IP privée du bon S3 endpoint régional
Préserver la sécurité grâce aux VPC endpoints plutôt qu'à un routage via Internet
Aucune modification de vos applications clientes — elles n'ont besoin d'aucun changement (inutile d'ajouter une région ou une URL d'endpoint) et peuvent simplement utiliser le nom du bucket

Points à garder à l'esprit

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

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

Appel à l'action

Références

Avez-vous déjà mis en place une connectivité VPC inter-régions dans votre environnement AWS ? Vos retours d'expérience et les variantes de cette approche que vous auriez pu découvrir m'intéressent vivement.