Acesso a Buckets S3 entre Regiões da AWS com VPC Peering

Um guia prático para entender por que acessar o S3 entre regiões exige mais do que VPC Interface Endpoints com DNS privado

Contexto

O que a AWS não conta é que isso não funciona sem adicionar um pouquinho 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.

Cenário

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

A arquitetura da solução

Componentes:

VPC B: uma VPC nova ou já existente em us-east-1, onde vamos colocar nosso S3 Interface Endpoint
VPC Peering Connection: a ponte entre as duas VPCs
Private Hosted Zone: DNS do Route53 para resolver os S3 Endpoints corretamente
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 pela rede de backbone da AWS (no nosso caso, em us-east-1)

Implementação passo a passo

Pré-requisitos

Passo 1: proteja seu S3 Endpoint

Passo 2: crie o S3 VPC Interface Endpoint

Desative o DNS privado
Anexe o security group VPC_B_S3_SG que você criou antes

Passo 3: estabeleça o VPC Peering

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

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

Dentro dessa PHZ, crie dois registros Alias A apontando para o Regional DNS name* 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 campo Record name vazio

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

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

Catch All — informe "*" no campo Record name

\* Um Regional DNS name é o nome sem especificação de availability zone.

O formato é assim:

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

E não us-east-1` a(que é um Zonal DNS name).

Um Zonal DNS name é útil em arquiteturas que isolam workloads por Availability Zone. Por exemplo, ele ajuda a reduzir custos de transferência de dados regional ao garantir que o tráfego permaneça na mesma AZ e Região da ENI do Interface Endpoint. Esse benefício, porém, vale apenas para acessos 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

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

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

Você consegue isso usando um destes métodos:

Um Internet Gateway ou NAT Gateway para acesso à internet
Um S3 Gateway Endpoint na VPC A (recomendado pelo custo)
Um S3 VPC Interface Endpoint na VPC A com DNS privado habilitado

A abordagem recomendada é ter um S3 Gateway Endpoint em cada VPC/Região onde você precisa acessar o S3, já que ele é gratuito — tanto na taxa por hora quanto no processamento de tráfego —, ao contrário das alternativas.

Configuração do AWS SDK para acesso ao S3 entre regiões

Opção 1: especifique Regional Endpoints

Exemplo para o JavaScript SDK V2:

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

JavaScript SDK v3: defina followRegionRedirects: true na configuração do seu cliente S3 [8]

Exemplo do JavaScript SDK v3:

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

Isso não vale para o JavaScript SDK V3, que não faz cache dessas informações. Cada requisição entre regiões pode sofrer latência de redirect. Para ter melhor desempenho quando você já conhece os padrões de acesso entre regiões, considere especificar diretamente a URL do regional endpoint.

O AWS CLI sabe lidar com esses redirects automaticamente e dispensa a região e a URL de endpoint para um bucket, desde que você tenha seguido o passo 6 acima.

Como tudo funciona em conjunto

A instância consulta o serviço S3 regional dela para descobrir onde o bucket está
Ao saber que o bucket está em us-east-1, ela consulta um DNS para obter os IPs dele em us-east-1
Sua Private Hosted Zone intercepta essa consulta DNS e a resolve para o IP privado do seu S3 Interface Endpoint na VPC B
O IP privado do seu S3 Interface Endpoint é devolvido para a EC2
A regra que você adicionou à tabela de rotas da subnet da EC2 na VPC A redireciona o tráfego dos IPs privados pela VPC peering connection até a VPC B e, de lá, até o S3 VPC Interface Endpoint
O endpoint oferece acesso seguro e privado a buckets S3 em us-east-1

Qualquer resposta do S3 (por exemplo, ao solicitar um objeto) volta pela VPC Peering connection até a instância EC2 na VPC A.

Diagrama conceitual da arquitetura

Por que essa abordagem funciona

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

Pontos de atenção

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, considere estratégias de replicação de bucket [6].

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

Chamada para ação

Referências

Você já implementou conectividade VPC entre regiões no seu ambiente AWS? Vou adorar conhecer suas experiências e as variações dessa abordagem que você descobriu.