Amazon ANS-C01: Redes de Contêineres e Serverless — 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 no EKS (CNI, rede de pods)

A rede de pods no Amazon EKS é dominada pelo plugin Amazon VPC CNI (amazon-vpc-cni-k8s), que atribui a cada pod um endereço IP da VPC e coloca o tráfego do pod diretamente na rede da VPC. Esse design oferece controle de segurança previsível no nível da VPC (security groups, NACLs) e roteamento de baixa latência, mas exige um planejamento cuidadoso da capacidade de endereços IP e ENIs, pois o número de endereços IPv4 secundários por ENI e o número de ENIs por tipo de instância são limitados pelo hardware. O daemonset aws-node gerencia as operações de alocação, anexação e desanexação de IPs; seu ConfigMap é editado com o kubectl para ajustar o comportamento (por exemplo, definir WARM_IP_TARGET, WARM_ENI_TARGET ou ENABLE_PREFIX_DELEGATION). Os modos de delegação de prefixo (prefix delegation) e ENI de pod reduzem o esgotamento de IPs por nó, permitindo que um nó aloque prefixos /28 inteiros para uma ENI (ENABLE_PREFIX_DELEGATION=true) ou atribuindo uma ENI dedicada por pod (útil para isolamento de alta segurança).

Alternativas ao Amazon VPC CNI, como Cilium (eBPF) ou Calico, podem oferecer diferentes trade-offs. O Cilium pode substituir o kube-proxy e implementar encaminhamento L3/L4 de alto desempenho usando eBPF, habilitar criptografia transparente entre nós (WireGuard ou IPsec) e reduzir a pressão por IPs no nível do nó usando abordagens de overlay ou mascaramento (masquerading). Com o Cilium, você ainda se integra ao roteamento da VPC para tráfego de saída (egress) e entrada (ingress), mas evita operações frequentes de anexação/desanexação de ENIs; isso é importante em cenários com altas taxas de rotatividade de pods (pod churn). Para contagens de conexão muito altas e comportamento L7 estrito, considere também o ajuste do modo do kube-proxy (IPVS) e as configurações do kernel do nó: ajuste conntrack_max, tcp_tw_recycle/tcp_tw_reuse e ip_local_port_range, e exponha-os via kubelet ou scripts de inicialização (init scripts) de daemonsets para evitar o esgotamento de portas efêmeras sob milhares de conexões gRPC concorrentes e de longa duração.

Modos de rede do ECS e integração do Lambda com a VPC

A rede de tarefas do ECS tem três modos principais: bridge, host e awsvpc. O modo awsvpc é o mais comparável à rede de pods do Kubernetes, pois anexa uma ENI a cada tarefa (ou grupo de tarefas) e atribui um IP privado e security groups diretamente à tarefa. Configure o awsvpc especificando awsvpcConfiguration com subnets e securityGroups nas chamadas de API RunTask ou CreateService. O Fargate impõe o uso do modo awsvpc e, portanto, fornece isolamento de rede no nível da tarefa e se integra ao AWS Cloud Map para descoberta de serviços (service discovery). Use o modo awsvpc quando precisar de filtragem de tráfego baseada em security groups por tarefa ou quando precisar expor o roteamento e as métricas padrão da VPC.

Funções Lambda que precisam de acesso à VPC são anexadas à VPC por meio de ENIs nas subnets e security groups configurados da função. Essas ENIs são criadas e gerenciadas pelo control plane do Lambda, mas o provisionamento de ENIs pode adicionar latência de cold-start e historicamente limitou o escalonamento rápido, a menos que mitigado com concorrência provisionada (provisioned concurrency) ou usando VPC endpoints (AWS PrivateLink) e uma arquitetura de subnets cuidadosamente projetada. Ao colocar muitas funções Lambda em uma VPC, garanta que as subnets tenham IPs disponíveis, use um NAT Gateway ou instâncias NAT para tráfego de saída (egress) conforme necessário e prefira VPC endpoints (endpoints com.amazonaws.* via AWS::EC2::VPCEndpoint) para evitar o roteamento de saída pela internet sempre que possível. Monitore a anexação/desanexação de ENIs usando o CloudWatch Logs e o VPC Flow Logs para observar o comportamento de escalonamento e solucionar problemas de throttling relacionados à concorrência.

App Mesh e descoberta de serviços

O AWS App Mesh usa sidecars Envoy como data plane e fornece observabilidade L3–L7, modelagem de tráfego (traffic shaping), novas tentativas (retries) e controles de originação/terminação de TLS. Defina meshes, virtual nodes e virtual services por meio da API do App Mesh (CreateMesh, CreateVirtualNode, CreateVirtualService) ou do App Mesh controller para Kubernetes. O App Mesh suporta mTLS configurando o bloco TLS de um listener de VirtualNode com clientPolicy e uma autoridade de certificação (certificate authority), e você pode integrar com o AWS Certificate Manager (ACM) ou SDS para distribuição de certificados. No entanto, observe que os sidecars do App Mesh terminam e recriptografam o tráfego por design; se um requisito exigir que o tráfego da aplicação permaneça criptografado de ponta a ponta entre o cliente e o pod da aplicação (sem descriptografia no proxy de rede), você deve garantir que o TLS seja terminado apenas no pod e evitar terminá-lo no ingress da malha ou no load balancer.

A descoberta de serviços (service discovery) é comumente feita com Kubernetes Services e CoreDNS para EKS, com o Cloud Map (CreateService, RegisterInstance) para ambientes multiplataforma e com zonas hospedadas privadas (private hosted zones) do Route 53 para busca baseada em DNS. O AWS Cloud Map se integra diretamente com o ECS e o App Mesh, permitindo registros SRV ou A e verificações de saúde (health checks) orientadas por API. Para ambientes dinâmicos onde as instâncias escalam rapidamente, combine TTLs de DNS curtos e health checks do Cloud Map para evitar resolução de dados obsoletos (stale resolution); se você precisar de consistência imediata, use a API do control plane de uma service mesh para buscar os endpoints em vez de depender do cache de DNS.

Padrões de design e trade-offs

Ao projetar para gRPC em larga escala sobre TLS com mTLS, você deve decidir onde o TLS é encerrado. Encerrar o TLS no load balancer (ALB) permite descarregar os certificados para o ACM e simplifica a rotação de certificados, mas quebra a criptografia de ponta a ponta e não pode fornecer mTLS para os pods de backend, a menos que o backend restabeleça o TLS com as informações do certificado do cliente encaminhadas. Para um mTLS de ponta a ponta verdadeiro, onde os endpoints da aplicação autenticam os clientes diretamente, use um gateway de passthrough L4, como um Network Load Balancer, e deixe o pod/aplicação lidar com o TLS/mTLS. Combine o NLB target-type ip com a anotação do AWS Load Balancer Controller

undefined

para registrar os IPs dos pods diretamente; esse padrão escala bem porque o NLB é projetado para milhões de conexões e suporta sessões TCP/gRPC de longa duração sem encerrar o TLS.

Para ingress e roteamento baseado em caminho com terminação HTTPS, o Application Load Balancer é mais apropriado, pois ele suporta regras de host/caminho, redirecionamentos e integração com o WAF. Para preservar os IPs do cliente quando o ALB encerra o TLS, confie nos cabeçalhos X-Forwarded-For; os servidores web de backend devem consumir e registrar o X-Forwarded-For, e você deve habilitar os logs de acesso do ALB para verificação. Se você precisar do endereço de soquete real do cliente na camada do servidor (para software legado), use o NLB com o proxy protocol v2 e garanta que os serviços de backend suportem o proxy protocol.

A conectividade de serviços entre múltiplas contas AWS e VPCs escala de maneira diferente dependendo do padrão. O VPC peering é simples, mas tem um gerenciamento N^2; o Transit Gateway centraliza o roteamento e escala melhor para muitas VPCs com a segregação de tabelas de rotas; o AWS PrivateLink (Interface VPC Endpoints) fornece o modelo de acesso mais granular por serviço e ciente de identidade, porque você expõe um serviço de endpoint via NLB e os consumidores criam endpoints de interface em suas VPCs. Para serviços compartilhados entre múltiplas contas com controle de acesso rigoroso e onboarding escalável, prefira o PrivateLink porque ele isola o roteamento (sem alterações nas tabelas de rotas nas VPCs consumidoras) e usa security groups para controles refinados.

Armadilhas comuns e critérios de decisão

Uma armadilha recorrente é presumir que o mesmo modelo de rede se adapta a todos os workloads. Workloads com conexões stateful ou de longa duração (gRPC, bancos de dados) favorecem o passthrough de Camada 4 (L4) (NLB) com terminação TLS no nível do pod ou padrões hostPort/hostNetwork para evitar latência induzida por proxy; microsserviços HTTP que precisam de roteamento baseado em caminho, WAF ou terminação de WebSocket se beneficiam dos recursos do ALB e do App Mesh. Outro erro é não considerar os limites de ENI/IP ao escalar nós do EKS ou tarefas do ECS no modo awsvpc: sempre consulte a tabela de ENI e IP por ENI do tipo de instância EC2 e use prefix delegation ou overlays do Cilium quando precisar de alta densidade de pods.

O monitoramento e a depuração exigem múltiplas fontes: VPC Flow Logs e métricas de ENI para ver o tráfego de saída/entrada (egress/ingress), métricas do CloudWatch para AWS Load Balancers (ActiveFlowCount, ProcessedBytes) e telemetria no nível da aplicação do Envoy/App Mesh ou do agente AWS X-Ray. Para Lambda e Fargate, lembre-se de que os cold starts associados a operações de ENI podem ser mitigados com concorrência provisionada ou rearquitetando os padrões de acesso para usar VPC endpoints e PrivateLink, para que as funções não precisem de uma saída (egress) ampla.

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

Empresa: Acme Payments Inc. Desafio: A Acme Payments executa um serviço gRPC no Amazon EKS que deve suportar milhares de conexões TLS simultâneas na porta TCP 443, usar mutual TLS (mTLS) para que o certificado do cliente seja validado pelo serviço de backend e permitir que o cluster EKS autoescale via Cluster Autoscaler e HPA sem interromper a conectividade ou exigir terminação TLS no load balancer.

Abordagem numerada:

Implante o serviço com TLS no nível do pod e autenticação mútua implementada na aplicação ou em um sidecar que não termine o TLS ponta a ponta para clientes externos. Armazene os certificados de servidor/cliente no AWS Secrets Manager e monte-os via CSI secrets store do Kubernetes ou use um mecanismo de distribuição de certificados que funcione com o ciclo de vida do pod.
Use o AWS Load Balancer Controller para criar um Network Load Balancer anotando o Service (service.beta.kubernetes.io/aws-load-balancer-type: “nlb”) e defina o tipo de destino (target) como IP (service.beta.kubernetes.io/aws-load-balancer-target-type: “ip”), depois crie um listener TCP na porta 443. Isso garante que o NLB realize o passthrough de Camada 4 (L4) e não termine o TLS.
Configure o target group do NLB com o protocolo TCP e registre os IPs dos pods dinamicamente (o Load Balancer Controller chamará CreateTargetGroup e RegisterTargets). Garanta que as verificações de saúde (health checks) estejam configuradas para TCP ou para uma sonda de saúde (health probe) personalizada baseada em TCP em um intervalo curto, para que os destinos (targets) sejam marcados como saudáveis rapidamente durante o autoescalamento (aws elbv2 create-target-group –protocol TCP –port 443 –target-type ip; aws elbv2 create-listener –protocol TCP –port 443 …).
Ajuste o Amazon VPC CNI para suportar alta densidade de pods e reduzir a rotatividade de ENIs: habilite o prefix delegation se for compatível (defina ENABLE_PREFIX_DELEGATION=true no ConfigMap aws-node), configure WARM_IP_TARGET para manter endereços sobressalentes e monitore as métricas do aws-node (logs do daemonset kube-system e métricas personalizadas do CloudWatch). Se os limites de IP no nível do nó forem uma preocupação, considere o Cilium com eBPF para maior densidade de pods e redução de operações de ENI.
Escale o cluster com segurança: garanta que o Cluster Autoscaler tenha as tags e permissões de IAM adequadas para o grupo de nós, defina PodDisruptionBudgets e verifique se as verificações de saúde do target group e a drenagem de conexões (connection draining) do NLB estão configuradas para evitar a queda de conexões gRPC de longa duração durante a redução de escala (scale-down).
Garanta a rotação e a confiança dos certificados: automatize a rotação de certificados com o ACM Private CA ou o Secrets Manager e garanta que os pods recuperem os pacotes de confiança (trust bundles) atualizados sem exigir reconfiguração do NLB. Use probes de readiness/liveness do Kubernetes que reflitam a prontidão do handshake mTLS.

Justificativa da AWS: Um Network Load Balancer no modo de destino (target) IP preserva o TLS até o pod (criptografia real de ponta a ponta) e suporta milhões de conexões TCP persistentes, tornando-o apropriado para milhares de sessões gRPC simultâneas. O registro direto dos IPs dos pods evita a complexidade do registro de destino (target) por instância ou hostPort por nó e funciona de forma integrada com o Cluster Autoscaler/HPA, pois o AWS Load Balancer Controller registrará e desregistrará os IPs dos pods à medida que eles escalam. Ajustar o VPC CNI ou adotar um plano de dados baseado em eBPF previne o esgotamento de IPs e reduz a latência de anexação/desanexação de ENIs, o que é essencial para um autoescalamento rápido e para workloads com alto número de conexões. Armazenar e entregar os artefatos de mTLS via Secrets Manager ou um provedor CSI torna o ciclo de vida dos certificados gerenciável sem precisar alterar o load balancer.

← Automação · Todos os domínios

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