Gateway S3 ou endpoint de interface para um cliente local?

Alcançar o S3 a partir de uma rede de escritório por uma VPN de site não é um problema de roteamento que uma rota estática resolva sozinha. Um endpoint de gateway é anexado às tabelas de rotas e atende as solicitações que se originam dentro da VPC. Um endpoint de interface coloca interfaces de rede elásticas com endereços privados nas suas sub-redes, e esses endereços são alcançáveis a partir do local por VPN ou Direct Connect. Onde a solicitação começa decide qual dos dois você realmente precisa, e o trabalho de DNS, grupo de segurança e política decorre dessa resposta.

Separe os tipos de endpoint por onde a solicitação começa

Um endpoint de gateway aparece como uma entrada na tabela de rotas que aponta para uma lista de prefixos gerenciada. Ele não tem interface de rede, nem grupo de segurança, nem endereço privado próprio, e é exatamente por isso que um host local não consegue rotear para ele: não há nada do outro lado para onde rotear. O tráfego de dentro da VPC chega ao S3 porque a tabela de rotas da sub-rede envia esse prefixo para o endpoint. O tráfego de qualquer outro lugar não tem essa entrada a seguir.

Um endpoint de interface é um conjunto de interfaces de rede nas sub-redes que você escolher, cada uma com um endereço privado dessa sub-rede e um grupo de segurança anexado. É a forma que um cliente híbrido pode usar, porque é um destino comum para o qual o seu túnel pode transportar pacotes. Também significa que o endpoint consome endereços na sub-rede e pode esgotá-los.

aws ec2 describe-vpc-endpoints --query "VpcEndpoints[].{Id:VpcEndpointId,Type:VpcEndpointType,Service:ServiceName,State:State}" --output table

Leia a coluna Type em vez do nome. Uma única VPC costuma conter os dois tipos para o mesmo serviço, e a entrada de que sua aplicação local precisa é a de interface.

Construa o caminho até o endereço de interface antes de testar o S3

Três coisas precisam ser verdadeiras ao mesmo tempo: o roteador local tem uma rota para a sub-rede do endpoint, o caminho de volta dessa sub-rede alcança a rede do cliente, e o grupo de segurança do endpoint admite a faixa de origem do cliente. A ACL de rede da sub-rede ainda pode descartar o pacote depois que as três se cumprem, então verifique-a como quarto item e não como pensamento tardio.

Uma rota que funciona até alguma instância EC2 na VPC não prova nada disso. Ela mostra que o túnel está no ar, que é a única parte do caminho que você já sabia. Prove o endereço do endpoint separadamente e depois prove que o nome resolve para ele.

ip route get 10.60.4.37
nc -vz 10.60.4.37 443
openssl s_client -connect 10.60.4.37:443 -servername bucket.vpce-0123456789abcdef0-abc123.s3.us-east-1.vpce.amazonaws.com </dev/null

O primeiro comando mostra qual interface o cliente usaria. O segundo prova um aperto de mão TCP. O terceiro prova que o TLS se completa com um certificado válido para o nome do endpoint, e essa é a verificação que pega um endereço errado antes de você culpar as permissões.

Decida qual resposta DNS a aplicação recebe

A existência de um endpoint de interface na VPC não redireciona um SDK local por si só. O cliente usa ou o nome específico do endpoint que a AWS publica para esse endpoint, ou uma zona hospedada privada que você deliberadamente tornou resolvível a partir do escritório.

Para a resolução híbrida, o resolvedor local precisa de um caminho suportado para a visão de DNS da VPC, normalmente por um endpoint de entrada do Resolver. Ativar o DNS privado sem entender quais fontes de consulta ele afeta é como uma busca começa a retornar um endereço que o escritório não alcança. A configuração muda as respostas para consultas que chegam pelo resolvedor da VPC, não para todo cliente em qualquer lugar.

dig +short bucket.vpce-0123456789abcdef0-abc123.s3.us-east-1.vpce.amazonaws.com
aws s3api head-bucket --bucket example-artifacts --endpoint-url https://bucket.vpce-0123456789abcdef0-abc123.s3.us-east-1.vpce.amazonaws.com

Execute os dois no host da aplicação, não em uma máquina de salto dentro da VPC. O resolvedor que responde ali é o que sua carga de trabalho usa, e uma resposta diferente de outro host é a fonte de confusão mais comum neste desenho.

Alcançabilidade não é autorização

Uma solicitação que chega ao endpoint ainda precisa de um principal autorizado e de uma permissão de bucket aplicável. Uma política de endpoint pode restringir o que o endpoint permite, e uma política de bucket pode restringir ainda mais. Alcançar a interface não diz nada sobre quais objetos o chamador pode ler.

Teste as duas direções: uma chamada autorizada e inofensiva contra o bucket pretendido, e uma chamada que se espera ser negada para uma identidade ou recurso fora da política. Guarde o nome do endpoint, o endereço resolvido e o contexto de política junto com o resultado para que a próxima pessoa possa reproduzi-lo. Uma negação que nomeia o tipo de política economiza uma hora de suposições.

Por fim, avalie o custo das duas opções antes de provisionar. Um endpoint de interface é cobrado por hora de interface e por gigabyte, enquanto um endpoint de gateway não é, e essa diferença decide a questão para muitas cargas de baixo volume que só precisam de acesso pelo lado da VPC.