Acceso a buckets de S3 entre regiones de AWS con (¡y sin! Nov 2025) VPC Peering

El 19 de noviembre de 2025, AWS anunció: "AWS PrivateLink ahora admite conectividad entre regiones para servicios de AWS" [1].

Esto significa que ya no hace falta pasar por todo el proceso de VPC Peering y Private Hosted Zone que se explica en este artículo. Ahora es algo mucho más directo (¡y sencillo!).

Para una explicación completa, consulta el blog de AWS aquí [2].

Si aun así quieres ver cómo se hacía antes, o entender las Private Hosted Zones para servicios de AWS, entonces, read on, Macduff (sí, ya sé que la frase original es "Lay on, Macduff"…)

AWS nos indica que, para usar un bucket de S3 en otra región (por ejemplo, una instancia EC2 en us-west-2 que necesita un bucket de S3 en us-east-1), tenemos varias opciones [3]. La que voy a abordar es la de "VPC interface endpoint (VPCE) con VPC peering".

Lo que AWS no menciona es que esto no funcionará sin agregar un poco de conectividad a S3 en la región que no tiene el bucket (en mi ejemplo, us-west-2). Lo abordaré más adelante en el paso 6 de la implementación.

Una instancia EC2 que se ejecuta en us-west-2 necesita acceder a datos de un bucket de S3 ubicado en us-east-1. Tu primer instinto podría ser crear un S3 Gateway Endpoint en tu VPC, pero ahí está el detalle: los S3 Gateway Endpoints no permiten el acceso entre regiones. (Tampoco lo hacen los S3 VPC Interface Endpoints por defecto, pero sí los aprovecharemos para resolver el problema.)

Esta limitación existe porque los VPC endpoints de AWS están diseñados para ofrecer conectividad privada a servicios dentro de la misma región.

La solución consiste en tender un puente entre regiones mediante VPC peering y aprovechar la resolución de DNS para enrutar el tráfico de forma adecuada. Esto es lo que vamos a construir:

Componentes:

• VPC A: tu VPC actual en us-west-2, donde reside tu instancia EC2
• VPC B: una VPC nueva o existente en us-east-1 donde colocaremos nuestro S3 Interface Endpoint
• Conexión de VPC Peering: el puente entre nuestras dos VPCs
• Private Hosted Zone: DNS de Route53 para resolver correctamente los Endpoints de S3
• S3 VPC Interface Endpoint: un Endpoint no es más que una Elastic Network Interface (ENI) en la 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)

Requisitos previos

Antes de empezar, asegúrate de que tus VPCs no tengan bloques CIDR superpuestos. AWS no te dejará hacer peering entre VPCs con rangos de IP en conflicto. También se asume que tu instancia EC2 cuenta con un instance role adecuado que le otorga permisos para interactuar con S3.

Paso 1: Asegura tu Endpoint de S3

Crea un security group en VPC B (llamémoslo VPC_B_S3_SG) que permita tráfico HTTPS por el puerto 443 desde el rango CIDR de VPC A. Este security group protegerá tu S3 Interface Endpoint y solo dejará pasar el tráfico que tú definas. Si más adelante necesitas que el Interface Endpoint reciba tráfico de otras VPCs o bloques CIDR, siempre puedes sumarlos al SG.

Paso 2: Crea el S3 VPC Interface Endpoint

En VPC B (us-east-1), crea un S3 VPC Interface Endpoint con esta configuración específica [4]:

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

Paso 3: Establece el VPC Peering

Crea una conexión de VPC peering entre VPC A y VPC B. Así se genera un puente de red que permite que el tráfico fluya entre las regiones [5].

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

En Route53, crea una Private Hosted Zone (PHZ) para el dominio s3.us-east-1.amazonaws.com y asóciala con la VPC A en us-west-2. Repite esta asociación con otras VPCs en la misma o en otras regiones que pienses emparejar con us-east-1, para que el tráfico llegue al S3 VPC Interface Endpoint de us-east-1.

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 nombre del registro

2. Registro comodín: usa * como nombre del registro para manejar

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

Catch All: ingresa "*" en el nombre del registro

\* 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-1a (que sería un nombre DNS zonal).

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

Registros resultantes:

Registros resultantes en la nueva PHZ

Paso 5: Configura el enrutamiento

Actualiza tus tablas de enrutamiento para que el tráfico pueda fluir entre las VPCs:

• VPC A: en la tabla de enrutamiento de la subred donde se ejecuta tu instancia EC2, agrega una regla que redirija el tráfico hacia el bloque CIDR de VPC B a través de la conexión de peering
• 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 VPC A a través de la misma conexión de peering

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

Esta es una pieza crítica que muchas veces se pasa por alto: tu instancia EC2 en VPC A necesita poder llegar a su endpoint regional de S3 (s3.us-west-2.amazonaws.com) para determinar a qué región pertenece un bucket. Sin esto, tendrás que añadir un "--region " cada vez que accedas a buckets que residen en la región us-east-1.

Puedes lograrlo con alguno de estos métodos:

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

El enfoque recomendado es contar con un S3 Gateway Endpoint en cada VPC/región donde necesites acceder a S3, ya que es gratuito tanto en cargo por hora como en procesamiento de tráfico, a diferencia de las alternativas.

Cuando accedes a buckets de S3 entre regiones a través de VPC peering, configura tu AWS SDK para manejar correctamente las solicitudes entre regiones:

Opción 1: Especificar endpoints regionales

Define la URL específica del endpoint regional (por ejemplo, s3.us-east-1.amazonaws.com) para la región del bucket de destino.

Ejemplo para JavaScript SDK V2:

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

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

Opción 2: Habilitar el acceso entre regiones

• Java SDK v2: usa crossRegionAccessEnabled(true) en el builder de tu cliente S3 [9]
• JavaScript SDK v3: establece followRegionRedirects: true en la configuración de tu cliente S3 [10]

Ejemplo para JavaScript SDK v3:

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

const s3Client = new S3Client({
});

Nota: con Java SDK V2, la primera solicitud a un bucket en una región distinta puede tener mayor latencia, pero las siguientes se benefician de la información de región almacenada en caché.

Esto no aplica para JavaScript SDK V3, que no almacena en caché la información de región. Cada solicitud entre regiones puede sumar latencia por redirección. Para mejor rendimiento con patrones de acceso entre regiones conocidos, conviene especificar la URL exacta del endpoint regional.

El AWS CLI gestiona estas redirecciones automáticamente y no requiere la región del bucket ni la URL del endpoint, siempre que hayas seguido el paso 6 anterior.

Cuando tu instancia EC2 intenta acceder a un bucket en us-east-1, el flujo es este:

1. La instancia consulta a su servicio regional de S3 para determinar la ubicación del bucket
2. Una vez que sabe que el bucket está en us-east-1, consulta al DNS las IPs de us-east-1
3. Tu Private Hosted Zone intercepta esta consulta DNS y la resuelve a la IP privada de tu S3 Interface Endpoint en VPC B
4. La IP privada de tu S3 Interface Endpoint se devuelve a la EC2
5. La regla que agregaste a la tabla de enrutamiento de la subred de la EC2 en VPC A redirigirá el tráfico de las IPs privadas a través de la conexión de VPC peering hacia VPC B y, desde ahí, al S3 VPC Interface Endpoint
6. El endpoint ofrece acceso seguro y privado a los buckets de S3 en us-east-1

Cualquier respuesta de S3 (por ejemplo, si solicitaste un objeto) regresará a través de la conexión de VPC Peering hasta la instancia EC2 en VPC A.

Diagrama conceptual de la arquitectura

Esta solución sortea con elegancia las limitaciones regionales de AWS al:

• Aprovechar el VPC peering para crear conectividad entre regiones
• Usar la resolución de DNS privado mediante PHZ para obtener la IP privada del endpoint regional correcto de S3
• Mantener la seguridad a través de VPC endpoints en lugar de enrutamiento por internet
• Sin cambios en tus aplicaciones cliente: tus aplicaciones no requieren modificaciones (no hace falta agregar una región ni una URL de endpoint) y pueden usar simplemente el nombre del bucket

Consideraciones de costo: el VPC peering genera costos de transferencia de datos [6], mientras que los Interface Endpoints generan cargos por hora más tarifas de procesamiento de datos [7]. Tenlo presente al tomar decisiones de arquitectura.

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, evalúa estrategias de replicación de buckets como alternativa [8].

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

Espero que este artículo te haya aportado información valiosa. Si quieres saber más o te interesan nuestros servicios, no dudes en escribirnos. Puedes contactarnos aquí.

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. Qué es VPC Peering
12. Gateway endpoints para Amazon S3
13. Trabajar con Private Hosted Zones