← AWS Solutions Architect Professional: decisões complexas
17 / 24 · 75 MIN

Transit Gateway e inspeção de tráfego

Segue um pacote nos dois sentidos e demonstra segmentação e inspeção antes do handover.

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.
NA PRÁTICA

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

Leva esta ideia contigo

Valida o caminho escolhido pelo pacote, nos dois sentidos, contra os requisitos de conectividade e segmentação.

Criar conta

Referência: How Transit Gateway works · SAP-C02

AWS é uma marca comercial da Amazon.com, Inc. ou das suas afiliadas. A dr.pt é uma plataforma de preparação independente e não está afiliada, associada, patrocinada, autorizada nem aprovada por AWS. Os conteúdos e as perguntas são originais, não são perguntas oficiais de exame, e concluir os nossos testes não atribui nem garante qualquer certificação. Os nomes são usados apenas para identificar o tema. Todas as outras marcas pertencem aos respetivos titulares.