S3: endpoint de gateway ou de interface para acesso a partir da rede local

Dois tipos de endpoint S3 parecem intercambiáveis numa revisão de design e comportam-se de forma totalmente diferente assim que o cliente fica fora do local. Um endpoint de gateway é uma integração com a tabela de rotas dentro de uma VPC, por isso um pedido de uma VPN do local nunca chega lá como destino privado. Um endpoint de interface coloca endereços privados em interfaces de rede, algo que um caminho híbrido consegue realmente alcançar. Tudo o que se segue depende de qual dos dois escolheu.

Decida pela entrada de rede, não pelo nome do serviço

Comece por onde o tráfego nasce, porque é essa a pergunta a que o tipo de endpoint responde. Uma carga de trabalho num contexto de VPC suportado pode usar um endpoint de gateway e nunca precisa de um endereço privado próprio. Uma carga de trabalho no local precisa de um endereço privado para o qual possa encaminhar, e é isso que um endpoint de interface fornece. Se um design misturar os dois, ambos os tipos de endpoint podem coexistir numa mesma VPC, e isso é uma disposição normal e não uma duplicação.

Misturá-los não é o problema. Assumir que um tipo cobre o outro é que é.

Classifique o cliente antes de escolher seja o que for. Um espaço de trabalho dentro da VPC, um contentor atrás de um gateway NAT e uma aplicação num escritório de filial são três origens diferentes, e só a última impõe a entrada híbrida. Escreva essa classificação ao lado do inventário de endpoints para que o próximo revisor veja porque existe cada endpoint.

O que o caminho de interface exige de ponta a ponta

Um endpoint de interface concede alcançabilidade a endereços privados, e a alcançabilidade é apenas um de quatro requisitos. A rede local precisa de uma rota para esses endereços, o lado da VPC precisa de um caminho de retorno, o grupo de segurança do endpoint tem de admitir o intervalo de origem, e qualquer equipamento de inspeção entre os dois tem de permitir o fluxo. Uma rota para qualquer instância na VPC não prova nenhum dos quatro.

Trabalhe da extremidade distante para trás. Confirme que as interfaces de rede do endpoint existem nas sub-redes esperadas, e depois confirme que o grupo de segurança admite o intervalo local real e não um marcador. Depois verifique se o túnel ou o circuito transporta o caminho de retorno no mesmo sentido. A inspeção é o passo que as pessoas saltam, porque um equipamento intermédio que permite a ligação pode ainda descartar um corpo de resposta maior, e isso parece um problema de débito e não de política.

Teste com a operação autorizada mais pequena disponível em vez de um download grande. A falha aparece mais cedo e com menos tráfego a justificar.

O DNS segue a origem da consulta, não a VPC

Um endpoint que existe não redireciona nada por si próprio. A aplicação recebe o nome que o seu resolver devolveu, e o resolver responde conforme a vista que lhe é permitido ver. Uma instância dentro da VPC e um portátil no escritório fazem duas perguntas diferentes e ambos podem obter respostas corretas mas diferentes. Verificar uma e concluir sobre a outra é a forma como um teste aprovado se torna uma implantação falhada.

Leia a definição de DNS privado do endpoint como parte do design, não como uma caixa a ativar depois do arranque.

Se o resolver do escritório tem de ver a vista da VPC, esse caminho tem de ser construído de propósito, normalmente através de um endpoint de resolver de entrada. Consulte a partir do contexto da própria aplicação e anote qual resolver respondeu. Um resultado recolhido num anfitrião bastião dentro da VPC descreve a vista do bastião e nada mais.

A permissão é separada da alcançabilidade

Um endpoint alcançável devolve erros para pedidos que o principal não tem permissão de fazer, e esse erro significa que o sistema funciona como projetado. A política de identidade, a política de bucket e qualquer política de endpoint são avaliadas nas suas próprias camadas. O acesso de rede nunca concedeu uma permissão.

Aceite o design com dois resultados: uma chamada autorizada inofensiva que tem sucesso, e uma recusa esperada para uma identidade ou bucket excluído.

aws ec2 describe-vpc-endpoints --filters Name=vpc-id,Values=vpc-0123456789abcdef0
dig +short s3.us-west-2.amazonaws.com @10.0.0.2

Registe o nome do endpoint, o destino resolvido e o contexto de política ao lado de cada resultado, porque uma alteração posterior de DNS pode invalidar toda a conclusão. Compare o custo atual e o peso operacional dos dois tipos de endpoint antes de aprovisionar seja o que for. Um endpoint de interface compra uma entrada privada híbrida, não é um requisito universal, e o caminho de gateway continua muitas vezes a ser a melhor resposta para cargas de trabalho dentro da VPC. A escolha é por cliente e mantém-se revisível.