Acessando Buckets S3 entre Regiões AWS Com(sem! Nov 2025!) VPC Peering

Em 19/11/2025, a AWS anunciou: "AWS PrivateLink now supports cross-region connectivity for AWS Services" [1].

Isso significa que você não precisa mais passar por todo aquele processo de VPC Peering e Private Hosted Zone explicado neste artigo. Agora é tudo bem mais direto (e fácil!).

Para uma explicação completa, confira o post no AWS Blog aqui [2].

Se mesmo assim você quiser ver como era feito antes, ou entender as Private Hosted Zones para serviços AWS, então, read on, Macduff (sim, eu sei que o original é "Lay on, Macduff"…)

A AWS nos informa que, para usar um bucket S3 em outra região (por exemplo, uma instância EC2 em us-west-2 que precisa acessar um bucket S3 em us-east-1), temos várias opções [3]. A que vou abordar é a opção "VPC interface endpoint (VPCE) com VPC peering".

O que a AWS não conta é que isso não vai funcionar sem uma pequena adição de conectividade ao S3 na região que não tem o bucket (no meu exemplo, us-west-2). Vou tratar disso mais adiante, no passo 6 da implementação.

Uma instância EC2 rodando em us-west-2 precisa acessar dados em um bucket S3 localizado em us-east-1. O primeiro impulso pode ser criar um S3 Gateway Endpoint na sua VPC, mas tem uma pegadinha — S3 Gateway Endpoints não oferecem acesso entre regiões. (Os S3 VPC Interface Endpoints também não, por padrão, mas vamos usá-los para resolver o problema.)

Essa limitação existe porque os VPC endpoints da AWS foram projetados para fornecer conectividade privada a serviços dentro da mesma região.

A solução envolve criar uma ponte entre regiões usando VPC peering e aproveitar a resolução de DNS para rotear o tráfego corretamente. Veja o que vamos construir:

Componentes:

• VPC A: sua VPC existente em us-west-2, onde sua instância EC2 está rodando
• VPC B: uma VPC nova ou já existente em us-east-1, onde vamos colocar nosso S3 Interface Endpoint
• Conexão de VPC Peering: a ponte entre as duas VPCs
• Private Hosted Zone: DNS do Route53 para resolver corretamente os S3 Endpoints
• S3 VPC Interface Endpoint: um Endpoint nada mais é do que uma Elastic Network Interface (ENI) em uma VPC de destino, que oferece conectividade privada e segura ao S3 usando a rede backbone da AWS (no nosso caso, em us-east-1)

Pré-requisitos

Antes de começar, confirme que suas VPCs não têm blocos CIDR sobrepostos. A AWS não permite peering entre VPCs com faixas de IP conflitantes. Também partimos do princípio de que sua instância EC2 tem uma instance role apropriada, com permissões para interagir com o S3.

Passo 1: proteja seu S3 Endpoint

Crie um security group na VPC B (vamos chamá-lo de VPC_B_S3_SG) que permita tráfego HTTPS na porta 443 vindo da faixa CIDR da VPC A. Esse security group vai proteger seu S3 Interface Endpoint, liberando apenas o tráfego que você quer. Se mais tarde você precisar permitir que o Interface Endpoint receba tráfego de outras VPCs ou blocos CIDR, basta adicioná-los ao SG.

Passo 2: crie o S3 VPC Interface Endpoint

Na VPC B (us-east-1), crie um S3 VPC Interface Endpoint com estas configurações específicas [4]:

• Desabilite o DNS privado
• Anexe o security group VPC_B_S3_SG que você criou no passo anterior

Passo 3: estabeleça o VPC Peering

Crie uma conexão de VPC peering entre a VPC A e a VPC B. Isso cria uma ponte de rede que permite o fluxo de tráfego entre as regiões [5].

Passo 4: configure a resolução de DNS com PHZ

No Route53, crie uma Private Hosted Zone (PHZ) para o domínio s3.us-east-1.amazonaws.com e associe-a à VPC A em us-west-2. Repita essa associação com outras VPCs, na mesma região ou em outras, com as quais você pretende fazer peering com us-east-1, para que o tráfego consiga chegar ao S3 VPC Interface Endpoint em us-east-1.

Associe a VPC A de us-west-2 à nova PHZ

Dentro dessa PHZ, crie dois registros Alias A apontando para o nome DNS Regional* do seu S3 VPC Interface Endpoint:

1. Registro raiz: deixe o nome do registro em branco para criar um registro para

s3.us-east-1.amazonaws.com

Registro raiz — deixe o Record name vazio

2. Registro curinga: use * como nome do registro para tratar

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

Catch All — informe "*" no Record name

\* Um nome DNS Regional é o nome sem especificar a zona de disponibilidade.

É algo como:

*.vpce-0123456789abcdefg-dawd972fe.s3.us-east-1.vpce.amazonaws.com e não us-east-1a (que seria um nome DNS Zonal).

Um nome DNS Zonal é útil em arquiteturas que isolam workloads por Availability Zone. Por exemplo, ele ajuda a reduzir custos de transferência de dados regionais ao garantir que o tráfego permaneça na mesma AZ e Região da ENI do Interface Endpoint. Esse benefício, porém, só vale para acesso na mesma Região e mesma AZ, o que não se aplica em um cenário entre regiões.

Registros resultantes:

Registros resultantes na nova PHZ

Passo 5: configure o roteamento

Atualize as tabelas de roteamento para que o tráfego possa fluir entre as VPCs:

• VPC A: na tabela de roteamento da subnet em que sua instância EC2 está rodando, adicione uma regra direcionando o tráfego destinado ao bloco CIDR da VPC B pela conexão de peering
• VPC B: na tabela de rotas da(s) subnet(s) em que você colocou seu VPC Interface Endpoint, adicione uma regra direcionando o tráfego destinado ao bloco CIDR da VPC A pela mesma conexão de peering

Passo 6: habilite o acesso S3 regional para o DNS local

Aqui está uma peça crítica que costuma passar despercebida: sua instância EC2 na VPC A precisa conseguir alcançar o endpoint S3 da própria região (s3.us-west-2.amazonaws.com) para descobrir a qual região um determinado bucket pertence. Sem isso, você vai precisar adicionar um "--region " toda vez que acessar buckets que estão em us-east-1.

Você pode resolver isso usando uma destas abordagens:

• Um Internet Gateway ou NAT Gateway para acesso à internet
• Um S3 Gateway Endpoint na VPC A (recomendado por questão de custo)
• Um S3 VPC Interface Endpoint na VPC A com DNS privado habilitado

O recomendado é ter um S3 Gateway Endpoint em cada VPC/Região onde você precisa acessar o S3, já que ele é gratuito tanto na taxa horária quanto no processamento de tráfego, ao contrário das alternativas.

Ao acessar buckets S3 entre regiões via VPC peering, configure seu AWS SDK para lidar corretamente com requisições entre regiões:

Opção 1: especificar endpoints regionais

Defina a URL específica do endpoint regional (por exemplo, s3.us-east-1.amazonaws.com) referente à região do bucket de destino.

Exemplo no JavaScript SDK V2:

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

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

Opção 2: habilitar acesso entre regiões

• Java SDK v2: use crossRegionAccessEnabled(true) no builder do seu cliente S3 [9]
• JavaScript SDK v3: defina followRegionRedirects: true na configuração do seu cliente S3 [10]

Exemplo no JavaScript SDK v3:

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

const s3Client = new S3Client({
});

Observação: no Java SDK V2, a primeira requisição a um bucket em outra região pode ter latência maior, mas as requisições seguintes aproveitam as informações de região em cache.

Isso não vale para o JavaScript SDK V3, que não armazena em cache as informações de região. Cada requisição entre regiões pode sofrer latência de redirecionamento. Para ter melhor desempenho com padrões de acesso entre regiões já conhecidos, considere especificar diretamente a URL do endpoint regional.

O AWS CLI lida automaticamente com esses redirecionamentos e dispensa informar a região do bucket ou a URL do endpoint, desde que você tenha seguido o passo 6 acima.

Quando sua instância EC2 tenta acessar um bucket em us-east-1, este é o fluxo:

1. A instância consulta o serviço S3 da própria região para descobrir onde o bucket está
2. Sabendo que o bucket está em us-east-1, ela consulta um DNS para obter os IPs em us-east-1
3. Sua Private Hosted Zone intercepta essa consulta DNS e a resolve para o IP privado do seu S3 Interface Endpoint na VPC B
4. O IP privado do seu S3 Interface Endpoint é devolvido para o EC2
5. A regra que você adicionou na tabela de roteamento da subnet do EC2 na VPC A vai direcionar o tráfego destinado a esses IPs privados pela conexão de VPC peering até a VPC B e, de lá, até o S3 VPC Interface Endpoint
6. O endpoint fornece acesso seguro e privado aos buckets S3 em us-east-1

Qualquer resposta do S3 (por exemplo, se você solicitou um objeto) volta pela conexão de VPC Peering até a instância EC2 na VPC A.

Diagrama conceitual da arquitetura

Esta solução contorna de forma elegante as limitações regionais da AWS ao:

• Aproveitar o VPC peering para criar conectividade entre regiões
• Usar a resolução DNS privada da PHZ para obter o IP privado do endpoint S3 regional correto
• Manter a segurança via VPC endpoints, em vez de roteamento pela internet
• Não exigir mudanças nas suas aplicações cliente — suas aplicações não precisam de nenhuma alteração (você não precisa informar uma região nem uma URL de endpoint) e podem simplesmente usar o nome do bucket

Considerações de custo: o VPC peering gera custos de transferência de dados [6], enquanto os Interface Endpoints geram cobrança por hora, além de taxas de processamento de dados [7]. Leve isso em conta nas suas decisões de arquitetura.

Impacto na latência: o tráfego entre regiões terá latência maior do que o acesso na mesma região. Se desempenho for crítico, avalie estratégias de replicação de buckets [8].

Trade-off de complexidade: essa configuração adiciona complexidade arquitetural. Avalie se os benefícios (custo e segurança intra-VPC) justificam o overhead operacional adicional.

Espero que este artigo tenha trazido insights valiosos. Se você quiser saber mais ou tiver interesse nos nossos serviços, não hesite em entrar em contato. Você pode falar com a gente aqui.

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