Amazon ANS-C01: Desempenho de Rede e Monitoramento — 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.

Rede otimizada e malha de baixa latência

A rede otimizada (enhanced networking) na AWS é o conjunto de recursos em nível de sistema operacional e hypervisor que aumentam significativamente a quantidade de pacotes por segundo, reduzem a latência e a sobrecarga de CPU, e expõem uma maior taxa de transferência por interface de rede virtual. As tecnologias primárias são o Elastic Network Adapter (ENA), que fornece rede de alto desempenho baseada em SR-IOV para a maioria das famílias de instâncias EC2 modernas, e o Elastic Fabric Adapter (EFA), que é um dispositivo do tipo RDMA com bypass de sistema operacional, projetado para HPC e cargas de trabalho MPI/libfabric fortemente acopladas. Para habilitar o ENA, você confirma que o tipo de instância suporta ENA e que a AMI Linux possui o driver ENA; programaticamente, você pode habilitá-lo ou consultá-lo com chamadas de API do EC2, como RunInstances com InterfaceType=efa quando necessário, ou ModifyInstanceAttribute para suporte a ena. O EFA é anexado criando uma interface de rede com InterfaceType=efa (aws ec2 create-network-interface --interface-type efa) ou iniciando instâncias com uma interface de rede habilitada para EFA; a instância deve executar um kernel compatível e o módulo de kernel libfabric/efa e, normalmente, ser colocada em um cluster placement group para obter a menor latência entre hosts e a maior largura de banda de bisseção.

Placement groups afetam o desempenho controlando o posicionamento da instância na malha de rede subjacente. Um cluster placement group posiciona as instâncias preferencialmente em um único rack ou em um domínio de rede de baixa latência para permitir a máxima largura de banda leste-oeste e latência consistente — isso é necessário para muitos casos de uso do EFA. Um spread placement group impõe a distribuição em nível de host para evitar falhas correlacionadas, mas não melhora a latência. Para cenários de alta taxa de transferência com picos de tráfego (bursty), a família da instância e a contagem de vCPUs definem as cotas de largura de banda de rede de base; por exemplo, certos tamanhos de instância anunciam até 25 Gbps ou 100 Gbps, mas o processamento de pacotes e as pilhas TCP podem se tornar gargalos sem ENA/EFA. Ao arquitetar para milhares de conexões TCP simultâneas (gRPC sobre TLS, por exemplo), escolha tipos de instância com alta capacidade de conexões simultâneas, habilite o ENA e prefira o NLB com target-type=ip para endereçamento direto de pods ao executar no EKS, a fim de evitar gargalos de node port.

Serviços e configurações chave para observabilidade e aplicação de políticas

O monitoramento da saúde da rede e o diagnóstico de gargalos dependem de uma combinação de VPC Flow Logs, métricas do CloudWatch, Traffic Mirroring e dos analisadores Reachability/Access. Os VPC Flow Logs fornecem metadados por fluxo (IP de origem/destino, portas, pacotes, bytes, ação) que você pode enviar para o CloudWatch Logs ou S3 e consultar com o CloudWatch Logs Insights para encontrar prefixos de alto volume ou os principais comunicadores (top talkers). Para inspeção em nível de pacote em tempo real, o Traffic Mirroring permite que você crie um destino de espelhamento (mirror target) e um filtro e, em seguida, crie sessões (aws ec2 create-traffic-mirror-target, aws ec2 create-traffic-mirror-session) para copiar o tráfego de ENIs para um appliance de inspeção executando no EC2 ou para parceiros do AWS Network Packet Broker.

O CloudWatch expõe as métricas relevantes para diferentes camadas: métricas de instância EC2 como NetworkIn/NetworkOut e NetworkPacketsIn/NetworkPacketsOut, métricas do Application Load Balancer em AWS/ApplicationELB como RequestCount, ActiveConnectionCount e ClientTLSNegotiationErrorCount, métricas do Network Load Balancer em AWS/NetworkELB como ProcessedBytes e NewFlowCount, e métricas do AWS/DirectConnect para a interface virtual como BytesIn/BytesOut. Use os CloudWatch Alarms e o Contributor Insights sobre os flow logs para detectar fluxos que estão saturando a rede. Para validação de caminhos e configurações, o Reachability Analyzer (através da API do EC2 StartNetworkInsightsAnalysis / CreateNetworkInsightsPath) permite modelar e testar caminhos de pacotes de ponta a ponta através de tabelas de rotas, NACLs, security groups e anexos de VPN/Direct Connect, enquanto o Network Access Analyzer ajuda a detectar caminhos de acesso à rede não intencionais em suas VPCs e na AWS Organizations.

Padrões de design e trade-offs em torno de balanceamento de carga e acesso seguro

Quando você precisa de TLS de ponta a ponta (end-to-end) com TLS mútuo no backend e, ao mesmo tempo, suportar milhares de conexões gRPC, um Network Load Balancer em modo TCP é o padrão preferido. Um NLB preserva o IP de origem do cliente por padrão e pode ser criado pelo AWS Load Balancer Controller para serviços do EKS usando anotações como

undefined

e target-type=ip para enviar tráfego diretamente para os IPs dos pods. Usar o modo TCP passthrough na porta 443 significa que o pod do backend encerra o TLS mútuo (verificação de certificados do cliente e do servidor), de modo que o tráfego nunca é descriptografado no balanceador de carga, preservando a autenticação de duas vias. Este padrão escala bem o número de conexões porque o NLB é projetado para milhões de conexões simultâneas e baixo overhead por conexão.

Para arquiteturas que exigem o encerramento do TLS no balanceador de carga e roteamento baseado em caminho (path-based routing) para múltiplos grupos de destino (target groups), o Application Load Balancer é a escolha certa porque ele suporta HTTP/2 e gRPC, roteamento baseado em caminho e regras baseadas em host. Para fornecer logs precisos do IP do cliente quando o ALB encerra o TLS, garanta que a aplicação de backend analise (parse) os cabeçalhos X-Forwarded-For (o ALB os injeta automaticamente) ou use o protocolo PROXY com o NLB se precisar da preservação do IP de origem na camada TCP. Se você usa o Global Accelerator para fornecer IPs de front-end anycast estáticos e quer impedir que os clientes contornem o acelerador e acessem a URL do ALB diretamente, restrinja o security group do ALB para aceitar tráfego de entrada apenas dos IPs estáticos do acelerador (os dois endereços estáticos atribuídos ao acelerador) para que o acesso direto pela internet seja negado.

Para serviços compartilhados multi-contas com controles rigorosos por unidade de negócio e necessidade de escala, o AWS PrivateLink (VPC Endpoint Services apoiados por NLBs internos) é frequentemente o padrão mais seguro e escalável. A VPC de serviços compartilhados publica serviços por meio de endpoints do Network Load Balancer (aws ec2 create-network-interface com target groups) e os expõe como um VPC Endpoint Service. As contas consumidoras criam endpoints de interface em suas VPCs que se conectam ao NLB do provedor; o provedor controla o acesso por meio de políticas de endpoint e security groups, e o tráfego nunca atravessa um plano de roteamento centralizado. O Transit Gateway é apropriado quando você precisa de visibilidade total de roteamento e conectividade transitiva, mas ele centraliza o roteamento e é menos granular para o controle de acesso por serviço do que o PrivateLink.

Armadilhas comuns e critérios de decisão

Um erro frequente é presumir que a largura de banda anunciada da instância é ilimitada; as famílias e os tamanhos de instância estabelecem limites rígidos de rede, e o escalonamento deve considerar a divisão entre ENIs e o posicionamento em cluster placement groups para um desempenho consistente. Outra armadilha é depender apenas do CloudWatch NetworkIn/NetworkOut sem correlacionar os VPC Flow Logs para atribuir o tráfego a uma VPC, sub-rede ou unidade de negócio específica; os Flow Logs e o Traffic Mirroring são necessários para isolar qual interface virtual ou aplicação está causando a saturação do Direct Connect. Evite também terminar o TLS no ALB quando o TLS mútuo é exigido de ponta a ponta — se a política exigir que o backend veja o certificado do cliente, escolha o passthrough de TLS com um NLB ou realize a ponte de TLS (TLS bridging) com a validação adequada de certificados, mas seja explícito sobre onde a confiança é estabelecida.

Ao diagnosticar saturação intermitente em links físicos compartilhados como o Direct Connect, correlacione métricas entre as camadas: métricas do AWS/DirectConnect para interfaces virtuais, VPC Flow Logs para contagem de bytes por sub-rede/ENI e métricas Network* do EC2 para o comportamento no nível da instância. Use o Reachability Analyzer para validar se o roteamento assimétrico ou a propagação incorreta de rotas está causando problemas no caminho de retorno, e use o Traffic Mirroring para capturar dumps de pacotes para uma inspeção profunda de protocolo.

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

A AcmeIoT enfrenta um problema em que máquinas de venda automática (vending machines) em todo o mundo precisam se conectar via gRPC com TLS mútuo a um backend hospedado no EKS, as conexões devem chegar a milhares, o serviço deve permanecer criptografado de ponta a ponta e os pods do backend escalam dinamicamente com o Cluster Autoscaler e o HPA.

Crie um AWS LoadBalancer do tipo Network Load Balancer para o serviço Kubernetes, usando o AWS Load Balancer Controller e anotações para especificar o NLB e target-type=ip (

undefined

). Configure um listener TCP na porta 443 para que o NLB realize o passthrough de TCP puro; não configure certificados TLS no NLB.

Implemente a terminação e validação de TLS mútuo nos pods da aplicação. Cada pod deve apresentar um certificado de servidor e validar os certificados do cliente, usando um processo de rotação de certificados de curta duração integrado com o AWS Secrets Manager ou o SSM Parameter Store. Garanta que os IPs dos pods sejam alcançáveis usando target-type ip e que as verificações de saúde (health checks) sejam TCP ou gRPC configuradas no target group.
Garanta uma alta escala de conexões escolhendo instâncias com suporte a ENA e largura de banda de rede suficiente, habilite o ENA (confirme com o driver ENA na AMI e use

undefined

para habilitar o ena-support quando necessário) e implante os pods em vários nós com o Cluster Autoscaler escalando os nós com base nas solicitações dos pods. Use placement groups para clusters fortemente acoplados que necessitam de latência consistente e implante um número suficiente de nós entre as AZs.

Monitore e valide usando o CloudWatch e os VPC Flow Logs. Crie métricas e alarmes do CloudWatch para NLB ActiveFlowCount/NewFlowCount e EC2 NetworkIn/Out dos workers do EKS. Use os VPC Flow Logs para identificar quaisquer “top-talkers” e o Reachability Analyzer (

undefined

) para validar os caminhos de roteamento durante eventos de autoscaling. Se precisar de depuração no nível de pacote, crie sessões de Traffic Mirroring para uma instância de inspeção.

Justificativa da AWS: um Network Load Balancer em modo TCP preserva o IP de origem, suporta um número massivo de conexões simultâneas e permite TLS de ponta a ponta porque não termina o TLS. O target-type ip com o AWS Load Balancer Controller se integra com a semântica de autoscaling do EKS, de modo que novos IPs de pods são registrados como targets dinamicamente. O ENA e o dimensionamento adequado da instância fornecem a capacidade de rede bruta para lidar com milhares de conexões TLS simultâneas sem esgotar a CPU do host, e a combinação de CloudWatch, VPC Flow Logs, Reachability Analyzer e Traffic Mirroring fornece a observabilidade necessária para detectar e remediar problemas de saturação ou roteamento.

← Entrega de Conteúdo e Redes de Borda · Todos os domínios · Automação →

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