APRENDER. PRATICAR. EVOLUIR.1. Começar pela relação entre consumidor e serviço
Uma equipa de aplicações precisa de consultar posições num serviço de outro departamento. Antes de escolher um endpoint, regista quem inicia a ligação, o protocolo, a localização do destino e o âmbito de acesso pretendido. Um gateway endpoint para S3 ou DynamoDB altera o encaminhamento através de prefixos do serviço; não cria uma passagem geral para redes de parceiros. Um interface endpoint disponibiliza interfaces privadas para um serviço compatível. Para certos recursos partilhados existe também o resource endpoint, sem exigir um NLB. A escolha depende do recurso e das funcionalidades suportadas, não apenas do nome PrivateLink. No desenho do projeto, mostra o caminho concreto de cada consumidor e os controlos da aplicação. Uma ligação privada não prova que o utilizador pode consultar todas as posições.
2. Seguir DNS e rotas separadamente
Um nome que resolve para um endereço privado ainda precisa de um caminho utilizável. Os nomes específicos de interface endpoints podem ser resolvidos publicamente e devolver endereços privados; isso não torna o serviço acessível pela Internet. Com private DNS e os atributos DNS necessários da VPC, o nome habitual do serviço pode apontar para as interfaces do endpoint. Para consumidores on-premises, identifica explicitamente a resolução através de Resolver e a conectividade aos endereços devolvidos. No caso S3 com os dois tipos de endpoint, a opção de private DNS apenas para consultas recebidas pelo inbound Resolver permite separar o caminho híbrido do caminho local pelo gateway. Confirma também a compatibilidade dos tipos de registos e das famílias IP. Testar um nome alternativo não prova o caminho usado pelo SDK em produção.
3. Distinguir entrada no serviço de autorização da operação
Num endpoint service partilhado, a lista de principals permitidos e a aceitação das ligações controlam a entrada de consumidores. Uma permissão ampla com aceitação automática pode admitir contas que o projeto não pretendia servir. Retirar um principal da lista não termina ligações de endpoints anteriormente aceites. Por isso, uma revogação exige um plano explícito para consumidores existentes e para o controlo aplicacional. Nos serviços AWS que suportam endpoint policies, estas acrescentam restrições ao caminho; não substituem políticas de identidade ou do recurso. Não atribuas a uma policy de endpoint a capacidade de autorizar operações de uma aplicação de terceiros. Na aceitação, inclui uma operação permitida, uma proibida e uma tentativa proveniente de um consumidor que já tinha acesso antes da mudança.
4. Demonstrar redundância do caminho efetivo
Duas interfaces do consumidor não demonstram, por si só, duas cópias saudáveis do serviço. Relaciona as AZs do endpoint, os NLBs e os targets que processam a operação. Entre contas, usa AZ IDs para comparar localizações físicas, pois os nomes das zonas podem diferir. Um nome zonal restringe a escolha do cliente; um nome regional não garante recuperação de sessões já estabelecidas. Se houver vários NLBs associados ao mesmo serviço, mantém contratos equivalentes de listeners e targets. Para acesso entre regiões, confirma permissões e regiões suportadas. O failover entre AZs gerido por PrivateLink não constitui recuperação automática para outra região. O ensaio deve medir sucesso aplicacional após falha e reconexão, incluindo o tempo tolerado pelo negócio, sem confundir disponibilidade de rede com confirmação de uma instrução.
5. Preparar mudanças de DNS, endereços e políticas
A propriedade de um private DNS name do fornecedor é demonstrada através de um registo TXT público. A prova de propriedade e a resolução privada do consumidor têm funções diferentes. Antes do cutover, confirma o estado de verificação, a resposta dos servidores autoritativos e o nome realmente utilizado pela aplicação. Uma alteração de permissões, DNS ou rotas pode afetar consumidores novos e existentes de formas distintas. Ao introduzir um gateway endpoint S3, considera a interrupção de ligações TCP e testa reconexão sem duplicar operações. Se uma bucket policy passa a exigir um endpoint específico, inclui no ensaio ferramentas administrativas e integrações, não apenas o batch principal. Prepara o regresso ao caminho anterior com os responsáveis pelas políticas, evitando um rollback de rede que continue bloqueado pela autorização.
6. Entregar evidência útil à produção
A entrega à equipa RUN deve permitir distinguir falha de resolução, de transporte e de autorização. Regista o nome consultado, os endereços devolvidos, o endpoint e a AZ utilizados, a identidade da aplicação e o resultado da operação. Não guardes segredos ou dados de clientes no material de treino. Num exercício fictício, um parceiro novo é recusado após a mudança, mas um endpoint já aceite continua operacional: esta observação é coerente com uma alteração da admissão e não prova revogação completa. O modelo local abaixo torna essa distinção visível com estados fornecidos. Não interpreta IAM, não cria endpoints e não termina ligações. O responsável de produção deve conhecer os testes negativos, o proprietário de cada controlo e o procedimento autorizado para retirar um consumidor existente.
def can_create(principal, allowed):
return principal in allowed or "*" in allowed
def accepted_connection(endpoint, accepted):
return endpoint in accepted
allowed = {"partner-a"}
accepted = {"endpoint-old"}
assert can_create("partner-a", allowed)
assert not can_create("partner-b", allowed)
allowed.remove("partner-a")
assert not can_create("partner-a", allowed)
assert accepted_connection("endpoint-old", accepted)
accepted.remove("endpoint-old") # supplied state after a separate removal, not an AWS call
assert not accepted_connection("endpoint-old", accepted)
print("five admission-state checks passed; no endpoint access changed")
Exemplo fictício: a equipa de fundos retira a conta de um fornecedor da lista de principals. Uma tentativa de criar outro endpoint é recusada, mas o consumidor anterior ainda consulta posições. A equipa identifica a ligação já aceite e valida o procedimento de revogação com o owner do serviço, incluindo autorização aplicacional e teste negativo.
Armadilhas comuns
Tratar endereços privados como autorização; usar um gateway endpoint a partir de outra rede; assumir que retirar uma permissão elimina consumidores já aceites; confundir failover entre AZs com DR regional.
Tópicos relacionados: DNS híbrido · Políticas e identidade · Mudança e entrega a RUN
Aceita o caminho completo e testa o ciclo de vida de consumidores novos e existentes.
Referência: Gateway endpoints · ANS-C01