O que é o Prefix Delegation do AWS VPC CNI?

O Prefix Delegation permite que uma ENI reserve um prefixo IPv4 /28 em vez de um único IP, aumentando significativamente o limite de pods por nó em tipos de instância menores.

Como o Cilium lida com ambientes de alta rotatividade?

Muito bem. Como o Cilium gerencia seu próprio estado em eBPF maps, ele pode lidar com milhares de atualizações de políticas de rede por segundo sem os travamentos de 'iptables-restore' observados em clusters Kubernetes padrão.

Posso usar o Cilium para resolver o esgotamento de IP da VPC?

Sim, usando o Cilium no modo 'Encapsulation' (VXLAN), os IPs dos Pods são completamente separados dos IPs da VPC, permitindo que você execute um cluster massivo em um CIDR de VPC muito pequeno.

Qual a principal vantagem do SGP?

Security Groups for Pods (SGP) permite que você use AWS IAM e firewalls de nível de VPC para Pods, o que é frequentemente mais fácil para equipes de conformidade corporativa auditarem do que políticas nativas do Kubernetes.

Existe uma diferença significativa de latência entre VPC CNI e Cilium?

No modo de roteamento nativo, o VPC CNI é ligeiramente mais rápido para throughput RAW de fluxo único, mas o Cilium vence em cenários do mundo real envolvendo muitas pequenas conexões e regras de política complexas.

Networking AWS EKS em 2026: Por Que Você Provavelmente Deveria Trocar o VPC CNI pelo Cilium

Em 2026, a escolha "padrão" para o networking no AWS EKS – o AWS VPC CNI – não é mais o rei incontestável para ambientes de alta escala e com foco em segurança. Embora a AWS tenha adicionado recursos essenciais como Prefix Delegation e Security Groups for Pods (SGP), essas continuam sendo "leaky abstractions" que conectam seus microsserviços às restrições legadas do plano de controle da VPC, enquanto o Cilium utiliza o eBPF para ignorar o gargalo da stack de Linux IPTables por completo. Este post argumenta que, a menos que você tenha um requisito regulatório estrito para políticas de rede baseadas em IAM nativas da AWS, o Cilium é a arquitetura superior para qualquer cluster EKS que exceda 100 nós ou que exija observability granular.

A Lacuna Arquitetural: IPAM vs. eBPF Data Planes

Para entender por que uma escolha é necessária, devemos analisar como esses plugins CNI lidam com o tráfego OSI da camada 3 e 4. O AWS VPC CNI (Amazon VPC Container Networking Interface) é um modelo de "Secondary IP". Ele aloca Elastic Network Interfaces (ENIs) para seus nós de worker EC2 e atribui endereços IPv4 privados secundários a essas ENIs. Cada Pod recebe um IP diretamente de sua sub-rede da VPC.

Em contrapartida, o Cilium (operando em modo chaining ou como uma substituição completa) foca no eBPF (Extended Berkeley Packet Filter) data plane. Enquanto o VPC CNI baseia-se nos antigos iptables ou ipvs dentro do kernel Linux—que escalam linearmente com o número de serviços—o Cilium usa programas eBPF para interceptar pacotes e roteá-los através de hash tables O(1). Se seu cluster tem mais de 5.000 Services, a latência de avaliação do iptables adiciona milissegundos mensuráveis a cada requisição; o Cilium não.

AWS VPC CNI: O Caso para a Integração Nativa

O principal argumento para o AWS VPC CNI é seu status de "first-class citizen". Como os Pods são nativos da VPC, eles são visíveis para todas as ferramentas da AWS. Você pode usar VPC Flow Logs para auditar o tráfego no nível do Pod sem instalar agentes extras. Mais importante, recursos introduzidos no final de 2023 e refinados ao longo de 2025, como o Prefix Delegation, mitigaram o problema de "esgotamento de IPs".

# Habilita Prefix Delegation para aumentar a densidade de Pods por nó
kubectl set env daemonset aws-node -n kube-system ENABLE_PREFIX_DELEGATION=true
# Isso permite que uma única ENI lide com um prefixo /28 em vez de um único IP,
# aumentando a densidade de pods em um m5.large de 29 para mais de 110 pods.

Security Groups for Pods (SGP) é o outro "killer feature". Ao definir um recurso personalizado SecurityGroupPolicy, você pode atribuir um AWS Security Group diretamente a um deployment. Isso é vital para ambientes onde um Pod precisa acessar uma instância RDS ou um banco de dados On-Premise via Direct Connect, e a equipe de segurança se recusa a whitelistar um range CIDR amplo. Você está efetivamente usando a AWS API como seu controlador de firewall.

Cilium: A Revolução eBPF no EKS

Se você está construindo para 2026, provavelmente está considerando o Isovalent Cilium (agora parte da Cisco). A mudança para o Cilium não é apenas sobre velocidade; é sobre o Hubble. O Hubble fornece observability com reconhecimento L7, algo que o VPC CNI simplesmente não consegue igualar. Os VPC Flow Logs mostrarão que 10.0.1.5 se comunicou com 10.0.1.10 na porta 80. O Hubble lhe dirá que service-frontend chamou service-checkout no path /api/v1/pay e recebeu um 403 Forbidden.

Sidecar-less Service Mesh

Com o Cilium, você pode implementar mutual TLS (mTLS) e gerenciamento de tráfego sem a sobrecarga de sidecars como Istio ou Linkerd. Ao mover a lógica para a camada eBPF, você reduz o consumo de memória em aproximadamente 30-40MB por Pod. Para um cluster com 1.000 Pods, isso representa 40GB de "sidecar tax" recuperados. Para análises mais aprofundadas sobre como otimizar esses custos, consulte nosso guia sobre otimizando custos de computação EKS.

Calico: Quando Multi-Cloud é a Única Métrica

O Calico da Tigera continua sendo uma ferramenta poderosa, especialmente para aqueles que executam ambientes híbridos (EKS + OpenShift/K8s upstream On-premise). A força do Calico é o seu motor de Global Network Policy. Se você precisa de um único arquivo YAML que dita a política de segurança em um cluster AWS EKS e um cluster bare-metal em uma instalação de Colocation, o Calico é a ferramenta. No entanto, em um ambiente apenas AWS, o modo baseado em iptables do Calico parece cada vez mais datado em comparação com o desempenho eBPF do Cilium, embora o Calico agora também ofereça uma opção de eBPF dataplane.

Comparação de Desempenho: Throughput e Latência

Em nossos testes de laboratório com netperf em instâncias c6i.4xlarge, a diferença fica clara em alta concorrência:

AWS VPC CNI: Desempenho de linha de base. Taxa de linha de 25Gbps alcançável, mas picos de CPU no nó durante lookups de conntrack para tráfego de pequenos pacotes de alta velocidade.
Cilium (Direct Routing): Utilização de CPU 10-15% menor do que o VPC CNI no mesmo throughput. Redução drástica da latência de cauda (p99) porque evita a travessia de iptables.
Calico (Padrão): Overhead semelhante ao VPC CNI, mas o gerenciamento da BGP mesh se torna um gargalo quando a contagem de nós excede 500 nós, a menos que se use Route Reflectors.

A Armadilha do "Prefix Delegation"

Muitos engenheiros habilitam o Prefix Delegation no VPC CNI pensando que ele resolve todos os problemas de IP. Não resolve. Quando um nó inicia, ele pré-aloca um prefixo da VPC. Se você tem muitos nós pequenos (por exemplo, t3.medium) em uma sub-rede pequena (por exemplo, /24), você pode "ficar sem" IPs na sub-rede porque os nós estão "monopolizando" blocos /28 que ainda nem estão usando. O Cilium, quando usado com o overlay mode (Geneve/VXLAN), desvincula completamente os IPs dos Pods do CIDR da VPC, permitindo que você execute 10.000 Pods em uma única sub-rede VPC /24. Esta é uma vantagem arquitetural enorme para ambientes empresariais legados "com falta de IP".

Implicações de Custos para 2026

O AWS VPC CNI é "gratuito", mas forza você a usar tipos de instância maiores ou maior consumo de IP, o que pode levar a custos caros de VPC peering ou Transit Gateway se você precisar de mais sub-redes. O Cilium (Open Source) é gratuito, mas a versão Enterprise (com conformidade FIPS e detecção avançada de ameaças) pode custar mais de US$ 2.000 por nó por ano. No entanto, os ganhos de eficiência geralmente compensam isso. Ao reduzir o overhead de CPU do kube-proxy e remover sidecars, vimos clientes reduzirem sua conta EC2 em 15-20% apenas migrando para o Cilium eBPF.

Snippet de Configuração: Cilium com Chaining do VPC CNI

Se você deseja o melhor dos dois mundos - networking nativo da AWS para alguns pods e segurança do Cilium para outros - você usa o Chaining Mode. Isso permite que a AWS gerencie o IP, mas o Cilium gerencie a política.

# cilium-config-values.yaml
cni:
  chainingMode: aws-cni
enableIPv4Masquerade: false
tunnel: disabled
endpointRoutes:
  enabled: true
# Esta configuração preserva o modelo "ENI-por-Pod" enquanto habilita
# observability do Hubble e políticas de rede eBPF.

Matriz de Decisão

Escolha AWS VPC CNI se:

Você é uma equipe pequena (menos de 5 engenheiros) e deseja a menor sobrecarga operacional.
Você usa os AWS Security Groups como seu principal mecanismo de firewall.
Você não tem restrições de endereços IP em sua VPC.

Escolha Cilium se:

Você está operando em "Escala EKS" (mais de 200 nós).
Você exige visibilidade L7 (métodos HTTP, headers) para solução de problemas.
Você está com restrição de IP e precisa de uma rede overlay.
Você quer eliminar o Overhead de Latência/CPU do kube-proxy e iptables.

Veredito Final

Para um cluster EKS de nível de produção em 2026, o Cilium é o default correto. O AWS VPC CNI é um fallback robusto, mas sua dependência do plano de controle da VPC para cada alocação de IP e sua falta de observability profunda o tornam um gargalo para equipes modernas de DevOps. Se você está começando um novo projeto greenfield no EKS, implante o Cilium em seu modo "Native Routing" com eBPF habilitado. A curva de aprendizado inicial é mais íngreme, mas o desempenho e as capacidades de solução de problemas estão anos-luz à frente da concorrência legada.

Precisa de ajuda para refatorar sua rede de pods ou migrar seu CNI sem downtime? Explore nossos serviços avançados de engenharia de plataforma AWS em techleague.io para ter sua infraestrutura funcionando com eficiência máxima.