Separar associação, propagação e rota da subnet
Desenha primeiro o attachment pelo qual o pacote entra no Transit Gateway. A tabela associada a esse attachment determina a procura da rota de destino. Propagação tem outro papel: instala rotas de um attachment em uma ou mais tabelas. Um attachment associa-se a uma tabela, embora possa propagar para várias. Não confundas uma rota visível na tabela de serviços partilhados com a tabela efetivamente usada pelo tráfego de produção. Confirma também a rota na subnet da aplicação para o Transit Gateway e o percurso de retorno. No exercício fictício, um fluxo de posições entra por PROD, associado à tabela isolada. O destino existe apenas na tabela de serviços; a captura e as tabelas devem explicar a falha antes de abrir permissões. O facto de dois attachments estarem Available não demonstra que o caminho completo foi configurado.
Ler a preferência sem perder o requisito de inspeção
A procura seleciona a rota mais específica para o destino. Para o mesmo prefixo, uma rota estática prevalece sobre uma propagada. No modelo original, 172.22.0.0/16 segue para inspeção, mas 172.22.44.0/24 segue diretamente para o destino. Um pacote para 172.22.44.19 usa a segunda rota e pode contornar a inspeção pretendida. Um teste funcional bem sucedido não valida o controlo de segurança. Compara a rota escolhida, registos do ponto de inspeção e testes negativos acordados. Uma rota blackhole elimina tráfego que corresponda à rota selecionada; não é uma garantia de bloqueio de qualquer exceção mais específica. Regista prefixo, origem da rota, next hop e tabela em cada decisão. Evita tratar a preferência entre tipos de attachment como se anulasse primeiro a correspondência mais específica.
Garantir cobertura por zona e consistência do fluxo
Os recursos de uma zona precisam de um attachment VPC com subnet nessa zona para alcançar o Transit Gateway. Adicionar uma terceira zona à aplicação sem rever o attachment pode produzir falhas apenas nas instâncias novas. A rota da subnet, por si só, não cria essa cobertura. Em inspeção stateful numa VPC de appliances, appliance mode mantém a zona escolhida para esse attachment durante o fluxo; o desenho ainda precisa de encaminhamento coerente nos dois sentidos e de preservar o estado no appliance correto. Não assumes que ativar uma opção preenche rotas em falta ou corrige qualquer assimetria. O ensaio deve registar origem, destino, portas, zona e caminho de ida e volta. Inclui tráfego entre zonas e a condição de falha planeada. Uma única ligação saudável numa zona não demonstra a cobertura do deployment completo.
Escolher o attachment e provar os limites
Peering direto entre Transit Gateways exige aceitação e rotas estáticas para encaminhar tráfego pelo peer; não assume propagação dinâmica automática. CIDRs sobrepostos entre VPCs também não ficam resolvidos por adicionar um attachment. Identifica a colisão e revê endereçamento ou uma integração compatível, sem anunciar conectividade geral inexistente. A documentação atual permite integrar AWS Network Firewall através de um network function attachment gerido, reduzindo a gestão manual de uma VPC de inspeção. Esta opção tem requisitos próprios; não a apresentes como suporte genérico para qualquer firewall de terceiros. Em ambos os desenhos, confirma as rotas efetivas que levam o tráfego à inspeção. Para o PM, o resultado deve ser uma matriz de fluxos permitidos e negados, owners das tabelas, evidência por zona e um plano de alteração reversível. Um desenho centralizado continua a precisar de validação por consumidor.
from ipaddress import ip_address, ip_network
routes = [('172.22.0.0/16', 'inspection'), ('172.22.44.0/24', 'direct')]
destination = ip_address('172.22.44.19')
matches = [(ip_network(prefix).prefixlen, target) for prefix, target in routes if destination in ip_network(prefix)]
selected_target = max(matches)[1] # direct
# Teaching model: longest-prefix selection only, not all AWS route priorities.Num banco fictício, a aplicação de posições comunica com um serviço central, mas não aparecem registos no ponto de inspeção. A equipa identifica uma rota /24 que prevalece sobre a /16 de inspeção e revê a exceção com segurança e redes antes de repetir os testes.
Armadilhas comuns
Olhar para a tabela errada; confundir propagação com associação; esquecer retorno ou zona; tratar conectividade como prova de inspeção.
Tópicos relacionados: DNS híbrido e autoridade entre contas
Valida o caminho escolhido pelo pacote, nos dois sentidos, contra os requisitos de conectividade e segmentação.
Referência: How Transit Gateway works · SAP-C02