Acceso a buckets de S3 entre regiones de AWS con VPC Peering

Una guía práctica para entender por qué el acceso a S3 entre regiones requiere algo más que VPC Interface Endpoints con DNS privado

Contexto

Lo que AWS no nos dice es que esto no funciona sin sumar un poco de conectividad a S3 en la región que no tiene el bucket (en mi ejemplo, us-west-2). Lo retomo más adelante, en el paso 6 de la implementación.

Escenario

Esta limitación se debe a que los VPC endpoints de AWS están pensados para dar conectividad privada a los servicios dentro de la misma región.

Arquitectura de la solución

Componentes:

VPC B: una VPC nueva o existente en us-east-1 donde colocaremos el S3 Interface Endpoint
VPC Peering Connection: el puente entre nuestras dos VPCs
Private Hosted Zone: DNS de Route53 para resolver correctamente los S3 Endpoints
S3 VPC Interface Endpoint: un Endpoint es simplemente una Elastic Network Interface (ENI) en una VPC de destino que ofrece conectividad privada y segura a S3 a través de la red troncal de AWS (en nuestro caso, en us-east-1)

Implementación paso a paso

Requisitos previos

Paso 1: Asegura tu S3 Endpoint

Paso 2: Crea el S3 VPC Interface Endpoint

Deshabilita el DNS privado
Asocia el security group VPC_B_S3_SG que creaste antes

Paso 3: Establece el VPC Peering

Paso 4: Configura la resolución DNS con la PHZ

Asocia la VPC A de us-west-2 con la nueva PHZ

Dentro de esta PHZ, crea dos registros Alias A que apunten al nombre DNS regional* de tu S3 VPC Interface Endpoint:

1. Registro raíz: deja el nombre del registro en blanco para crear un registro para

s3.us-east-1.amazonaws.com

Registro raíz: deja vacío el campo Record name

2. Registro wildcard: usa * como nombre del registro para manejar

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

Catch All: ingresa "*" en el campo Record name

\* Un nombre DNS regional es el nombre sin especificación de zona de disponibilidad.

Se ve así:

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

Y no us-east-1` a(que es un nombre DNS zonal).

Un nombre DNS zonal resulta útil en arquitecturas que aíslan los workloads por zona de disponibilidad. Por ejemplo, ayuda a reducir los costos de transferencia de datos regional al asegurar que el tráfico se mantenga dentro de la misma AZ y región que la ENI del Interface Endpoint. Sin embargo, este beneficio aplica solo al acceso dentro de la misma región y la misma AZ, lo que no se da en un escenario entre regiones.

Registros resultantes:

Registros resultantes en la nueva PHZ

Paso 5: Configura el enrutamiento

VPC A: en la tabla de rutas de la subred donde corre tu instancia EC2, agrega una regla que redirija el tráfico hacia el bloque CIDR de la VPC B a través de la peering connection
VPC B: en la tabla de rutas de la(s) subred(es) donde colocaste tu VPC Interface Endpoint, agrega una regla que redirija el tráfico hacia el bloque CIDR de la VPC A a través de la misma peering connection

Paso 6: Habilita el acceso regional a S3 para el DNS local

Puedes lograrlo con alguno de estos métodos:

Un Internet Gateway o NAT Gateway para acceso a internet
Un S3 Gateway Endpoint en la VPC A (recomendado por costo)
Un S3 VPC Interface Endpoint en la VPC A con DNS privado habilitado

Lo recomendable es contar con un S3 Gateway Endpoint en cada VPC/región donde necesites acceder a S3, ya que no tiene costo —ni por hora ni por procesamiento de tráfico—, a diferencia de las alternativas.

Configuración del AWS SDK para acceso a S3 entre regiones

Opción 1: Especifica los endpoints regionales

Ejemplo para JavaScript SDK V2:

Opción 2: Habilita el acceso entre regiones

JavaScript SDK v3: define followRegionRedirects: true en la configuración de tu cliente S3 [8]

Ejemplo de JavaScript SDK v3:

Nota: con Java SDK V2, la primera solicitud a un bucket en otra región puede tener mayor latencia, pero las solicitudes posteriores se benefician de la información de región guardada en caché.

Esto no ocurre con el JavaScript SDK V3, que no cachea la información de región. Cada solicitud entre regiones puede sumar latencia por redirección. Para mejorar el rendimiento cuando ya conoces los patrones de acceso entre regiones, conviene especificar la URL exacta del endpoint regional.

El AWS CLI sabe manejar estas redirecciones de forma automática y no necesita la región ni la URL del endpoint para un bucket, siempre que hayas seguido el paso 6 anterior.

Cómo funciona todo en conjunto

La instancia consulta a su servicio S3 regional para determinar la ubicación del bucket
Una vez que sabe que el bucket está en us-east-1, consulta al DNS por sus IPs en us-east-1
Tu Private Hosted Zone intercepta esa consulta DNS y la resuelve a la IP privada de tu S3 Interface Endpoint en la VPC B
La IP privada de tu S3 Interface Endpoint se devuelve a la EC2
La regla que agregaste a la tabla de rutas de la subred de la EC2 en la VPC A redirige el tráfico de las IPs privadas a través de la VPC peering connection hacia la VPC B y, desde allí, al S3 VPC Interface Endpoint
El endpoint da acceso seguro y privado a los buckets de S3 en us-east-1

Cualquier respuesta de S3 (por ejemplo, si solicitaste un objeto) regresa por la VPC Peering connection hacia la instancia EC2 en la VPC A.

Diagrama conceptual de la arquitectura

Por qué funciona este enfoque

Se aprovecha el VPC peering para crear conectividad entre regiones
Se usa la resolución DNS de la PHZ privada para obtener la IP privada del S3 endpoint regional correcto
Se mantiene la seguridad mediante VPC endpoints en lugar de enrutar por internet
Sin cambios en tus aplicaciones cliente: tus apps no requieren ninguna modificación (no hace falta indicar región ni URL de endpoint) y pueden usar el nombre del bucket sin más

Aspectos a tener en cuenta

Impacto en la latencia: el tráfico entre regiones tendrá mayor latencia que el acceso dentro de la misma región. Si el rendimiento es crítico, considera estrategias de replicación de buckets [6].

Equilibrio en la complejidad: esta configuración añade complejidad arquitectónica. Evalúa si los beneficios (costo y seguridad intra-VPC) justifican la carga operativa adicional.

Llamada a la acción

Referencias

¿Has implementado conectividad VPC entre regiones en tu entorno de AWS? Me encantaría conocer tu experiencia y las variantes de este enfoque que hayas descubierto.