Amazon ANS-C01: Conectividade Híbrida: VPN e Direct Connect — Guia de estudos

By Laurynas Brazys · 3 August 2026 · #amazon #ans-c01 #certification #exam-prep #study-guide

Faz parte do AWS Advanced Networking Specialty ANS-C01 — Guia de estudos. Pratique com respostas verificadas no centro de exames da Amazon, ou faça testes cronometrados no ExamRoll.io.

Padrões de design e trade-offs

Escolha uma arquitetura ativo-ativo para alta taxa de transferência (throughput) e baixo tempo de failover, posicionando duas conexões do Direct Connect em locais diferentes, anunciando prefixos idênticos com BGP e usando LAG para agregação de links (link bundling) dentro de um site. A arquitetura ativo-ativo com BGP multipath oferece desempenho superior e compartilhamento de carga (load sharing) real; no entanto, isso exige roteamento simétrico, BGP on-premise compatível e um ajuste cuidadoso do AS-path e do local-preference. Use a Site-to-Site VPN como um backup ativo-passivo automático, pois os túneis IPsec são resilientes e globalmente acessíveis, mas espere maior jitter, menor taxa de transferência e tempos de failover mais longos em comparação com o Direct Connect. Onde a conectividade determinística e de baixa latência é obrigatória, uma segunda conexão DX é preferível, apesar do custo mais alto.

Para requisitos de TLS no nível da aplicação, as escolhas de design dependem se o load balancer tem permissão para ver o tráfego descriptografado. Se for necessário TLS mútuo de ponta a ponta (end-to-end), termine o TLS no backend usando um NLB em modo passthrough de TCP/TLS e deixe que os pods do Kubernetes Ingress lidem com o mTLS; use o tipo de destino (target type) ip para o EKS para que os pods possam escalar e o Cluster Autoscaler possa adicionar nós sem alterar a configuração do NLB, e habilite o proxy protocol v2 se você precisar do endereço IP de origem original do cliente no pod. Se a terminação de TLS no ALB for aceitável, use um ALB com um listener HTTPS, configure os certificados no ACM, habilite o HTTP/2 para suporte a gRPC e utilize o X-Forwarded-For para obter os IPs dos clientes; o ALB oferece roteamento baseado em caminho (path-based routing) para múltiplos target groups para despacho baseado em URL.

Para conectividade multi-account e multi-VPC onde segurança granular e escala são necessárias, um padrão hub-and-spoke com um Transit Gateway e um Direct Connect Gateway centralizado oferece a melhor escala. Anexe a VPC de cada unidade de negócio a um Transit Gateway (TGW) e associe o TGW a um Direct Connect Gateway por meio de uma VIF de trânsito (transit VIF). Use as tabelas de rotas (route tables) do TGW para impor a segregação e use políticas no nível de recurso, Security Groups e Network ACLs para controles granulares. O trade-off é a complexidade operacional no gerenciamento das tabelas de rotas do TGW e a necessidade de projetar cuidadosamente os limites das contas e do IAM.

Armadilhas comuns e critérios de decisão

Um erro frequente é depender de uma única VIF por VPC sem considerar os limites de VIF e a complexidade operacional à medida que o número de VPCs aumenta; use o Direct Connect Gateway e transit VIFs quando você prevê muitas VPCs ou múltiplas Regiões. Outra armadilha comum é presumir que a VPN e o Direct Connect se comportam de forma idêntica: as renovações de chaves do IPsec (rekeys), as implicações de MTU e as diferenças de throughput por túnel significam que a VPN é um backup confiável, mas não um equivalente em desempenho. Configurar incorretamente a terminação TLS e as expectativas de IP do cliente downstream é outra fonte de erros — escolha o modo passthrough do NLB para um verdadeiro TLS de ponta a ponta com mTLS, ou a terminação no ALB com processamento do cabeçalho X-Forwarded-For se o edge puder terminar o TLS.

Finalmente, monitoramento e visibilidade são essenciais. Habilite as métricas do CloudWatch para o Direct Connect (ConnectionBpsEgress/Ingress), os flow logs para visibilidade da VPC e use os alarmes do CloudWatch para acionar automação para desviar o tráfego ou notificar os engenheiros de rede. Para atribuição forense de tráfego quando várias unidades de negócio compartilham a largura de banda em um LAG, correlacione as estatísticas da VIF e os flow logs da VPC e considere controles de largura de banda por VPC no edge para evitar problemas de “vizinho barulhento” (noisy neighbor).

Problema Prático: Cenário de Caso de Uso

Empresa: Meridian Medical Analytics. Desafio: A Meridian opera uma frota global de dispositivos de imagem médica que usam gRPC sobre a porta TCP 443 para enviar streams criptografados de alto volume para um backend hospedado em um cluster Amazon EKS em us-east-1. Os dispositivos exigem mutual TLS para autenticação de cliente bidirecional e milhares de conexões simultâneas e de longa duração. O cluster EKS escala automaticamente com o Cluster Autoscaler e o HPA. A Meridian precisa de latência baixa e determinística a partir de seu datacenter principal e failover automático para a VPN na nuvem.

Abordagem:

1. Provisione um Network Load Balancer (NLB) na frente do serviço EKS com listeners TCP na porta 443 e o tipo de destino (target type) definido como IP para que os endpoints dos pods possam ser alvos diretamente; configure o NLB para passthrough de TLS (não termine o TLS no NLB) para que o mutual TLS seja negociado com os pods do backend. Use aws elbv2 create-load-balancer e create-listener para configurar o NLB e os target groups.
2. Configure os contêineres dos pods do EKS (Ingress ou sidecar) para terminar o mutual TLS usando certificados de servidor e cliente de uma CA privada (ACM Private CA para emitir certificados de servidor; certificados de cliente provisionados nos dispositivos). Garanta que os pods suportem gRPC sobre HTTP/2 e escalem via HPA e Cluster Autoscaler; use um atraso de cancelamento de registro do target group (deregistration delay) ajustado para conexões de longa duração.
3. Para a conectividade on-premise, provisione uma conexão dedicada do Direct Connect (create-connection) agregada com um LAG se houver múltiplos circuitos físicos disponíveis, e crie uma interface virtual privada (private virtual interface) (create-private-virtual-interface) para um Direct Connect Gateway anexado ao seu Transit Gateway para roteamento para a VPC do EKS. Habilite o MACsec no provisionamento se a operadora e a localidade o suportarem para proteger o transporte da camada 2.
4. Implemente uma Site-to-Site VPN (aws ec2 create-vpn-connection para um Transit Gateway) como um caminho de failover automático; controle o failover com atributos BGP, preferindo o Direct Connect (local-preference mais alto) e deixando a VPN herdar uma preferência mais baixa. Use BFD onde suportado para detecção mais rápida de falhas no caminho. Monitore as métricas do Direct Connect e da VPN no CloudWatch e configure alarmes para acionar mudanças de engenharia de tráfego ou notificações.

Justificativa da AWS: O passthrough TCP do NLB preserva o mutual TLS de ponta a ponta, de modo que os certificados de cliente do dispositivo são validados pelos pods do backend, o que satisfaz o requisito de que o tráfego não seja descriptografado no edge. O tipo de destino (target type) IP e o suporte do NLB escalam para milhares de conexões simultâneas e de longa duração, preservando o IP do cliente com o proxy protocol ou lendo o IP do cliente da sessão TLS, se necessário. O Direct Connect fornece conectividade determinística e de alta largura de banda para us-east-1 com LAG para capacidade e MACsec para criptografia do link físico; a Site-to-Site VPN fornece um caminho de backup criptografado e globalmente alcançável com failover mediado por BGP. Este design equilibra segurança, desempenho e escalabilidade, alinhando-se com as melhores práticas de configuração do AWS Direct Connect e VPN.

← Design de VPC e Redes Avançadas · Todos os domínios · Transit Gateway e Topologia de Rede →

Pratique estas questões → · Prática cronometrada no ExamRoll.io →

Navegar Amazon →