Networking en AWS EKS en 2026: Por qué debería migrar de VPC CNI a Cilium

En 2026, la opción "por defecto" para el networking de AWS EKS —el AWS VPC CNI— ya no es el rey indiscutible para entornos de alta escala y seguridad prioritaria. Si bien AWS ha añadido características esenciales como Prefix Delegation y Security Groups for Pods (SGP), estas siguen siendo "abstracciones con fugas" que vinculan sus microservicios a las limitaciones heredadas del plano de control de la VPC. En cambio, Cilium aprovecha eBPF para evadir completamente el cuello de botella de la pila de IPTables de Linux. Esta publicación argumenta que, a menos que tenga un requisito regulatorio estricto para políticas de red basadas en IAM nativas de AWS, Cilium es la arquitectura superior para cualquier clúster EKS que supere los 100 nodos o que requiera observability granular.

La brecha arquitectónica: IPAM vs. Planos de datos eBPF

Para entender por qué es necesaria una elección, debemos analizar cómo estos plugins CNI manejan el tráfico de las capas 3 y 4 del modelo OSI. El AWS VPC CNI (Amazon VPC Container Networking Interface) es un modelo de "IP Secundaria". Asigna Elastic Network Interfaces (ENIs) a sus nodos worker EC2 y asigna direcciones IPv4 privadas secundarias a esas ENIs. Cada Pod obtiene una IP directamente de su subred de VPC.

En contraste, Cilium (operando en modo chaining o como un reemplazo completo) se enfoca en el plano de datos de eBPF (Extended Berkeley Packet Filter). Mientras que VPC CNI se basa en los envejecidos iptables o ipvs dentro del kernel de Linux —que escalan linealmente con el número de servicios—, Cilium utiliza programas eBPF para interceptar paquetes y enrutarlos a través de tablas hash O(1). Si su clúster tiene más de 5,000 Services, la latencia de evaluación de iptables añade milisegundos medibles a cada solicitud; Cilium no.

AWS VPC CNI: El caso de la integración nativa

El argumento principal para el AWS VPC CNI es su estatus de "ciudadano de primera clase". Dado que los Pods son nativos de la VPC, son visibles para todas las herramientas de AWS. Puede usar VPC Flow Logs para auditar el tráfico a nivel de Pod sin instalar agentes adicionales. Más importante aún, las características introducidas a finales de 2023 y refinadas hasta 2025, como Prefix Delegation, han mitigado el problema del "agotamiento de IP".

# Habilitar Prefix Delegation para aumentar la densidad de Pods por nodo
kubectl set env daemonset aws-node -n kube-system ENABLE_PREFIX_DELEGATION=true
# Esto permite que una sola ENI maneje un prefijo /28 en lugar de una sola IP,
# aumentando la densidad de Pods en un m5.large de 29 a más de 110 Pods.

Security Groups for Pods (SGP) es la otra "característica estrella". Al definir un recurso personalizado SecurityGroupPolicy, puede asignar un Security Group de AWS directamente a un despliegue. Esto es vital para entornos donde un Pod necesita acceder a una instancia RDS o a una base de datos On-Premise a través de Direct Connect, y el equipo de seguridad se niega a incluir en la lista blanca un amplio rango CIDR. Básicamente, está utilizando la API de AWS como su controlador de firewall.

Cilium: La revolución eBPF en EKS

Si está construyendo para 2026, es probable que esté considerando Isovalent Cilium (ahora parte de Cisco). El cambio hacia Cilium no es solo una cuestión de velocidad; se trata de Hubble. Hubble proporciona observability consciente de la Capa 7 que el VPC CNI simplemente no puede igualar. Los VPC Flow Logs le mostrarán que 10.0.1.5 se comunicó con 10.0.1.10 en el puerto 80. Hubble le dirá que service-frontend llamó a service-checkout en la ruta /api/v1/pay y recibió un 403 Forbidden.

Service Mesh sin sidecars

Con Cilium, puede implementar mutual TLS (mTLS) y traffic management sin la sobrecarga de los sidecars de Istio o Linkerd. Al mover la lógica a la capa eBPF, reduce el consumo de memoria en aproximadamente 30-40 MB por Pod. Para un clúster con 1,000 Pods, eso es 40 GB de "impuesto de sidecar" recuperados. Para inmersiones más profundas sobre la optimización de estos costos, consulte nuestra guía sobre optimización de costos de computación EKS.

Calico: Cuando Multi-Cloud es la única métrica

Calico de Tigera sigue siendo una potencia, particularmente para aquellos que ejecutan entornos híbridos (EKS + OpenShift/K8s On-prem). La fortaleza de Calico es su motor de Global Network Policy. Si necesita un solo archivo YAML que dicte la política de seguridad en un clúster AWS EKS y un clúster bare-metal en una instalación de Colocation, Calico es la herramienta. Sin embargo, en un entorno solo de AWS, el modo basado en iptables de Calico se siente cada vez más obsoleto en comparación con el rendimiento eBPF de Cilium, aunque Calico ahora ofrece una opción de plano de datos basado en eBPF.

Comparación de rendimiento: throughput y latencia

En nuestras pruebas de laboratorio con netperf en instancias c6i.4xlarge, la diferencia se vuelve clara a alta concurrencia:

• AWS VPC CNI: Rendimiento base. Tasa de línea de 25 Gbps alcanzable, pero picos de CPU en el nodo durante las búsquedas de conntrack para tráfico de pequeños paquetes de alta velocidad.
• Cilium (Direct Routing): 10-15% menos de utilización de CPU que VPC CNI al mismo throughput. Reducción drástica en la tail latency (p99) porque evita el recorrido de iptables.
• Calico (Estándar): Similar a la sobrecarga de VPC CNI, pero la gestión de la malla BGP se convierte en un cuello de botella a medida que el número de nodos supera los 500, a menos que se utilicen Route Reflectors.

La trampa de "Prefix Delegation"

Muchos ingenieros habilitan Prefix Delegation en VPC CNI pensando que resuelve todos los problemas de IP. No es así. Cuando un nodo arranca, preasigna un prefijo de la VPC. Si tiene muchos nodos pequeños (por ejemplo, t3.medium) en una subred pequeña (por ejemplo, /24), puede "quedarse sin" IPs en la subred porque los nodos están "acaparando" bloques /28 que ni siquiera están usando todavía. Cilium, cuando se usa con el modo overlay (Geneve/VXLAN), desacopla completamente las IP de los Pods del CIDR de la VPC, lo que le permite ejecutar 10,000 Pods en una sola subred VPC /24. Esta es una ventaja arquitectónica masiva para entornos empresariales legados "con escasez de IP".

Implicaciones de costos para 2026

El AWS VPC CNI es "gratis", pero lo obliga a usar tipos de instancias más grandes o a un mayor consumo de IP, lo que puede conducir a costosos VPC peering o costos de Transit Gateway si necesita más subredes. Cilium (Open Source) es gratis, pero la versión Enterprise (con cumplimiento FIPS y advanced threat detection) puede costar más de $2,000 por nodo al año. Sin embargo, las ganancias de eficiencia suelen compensarlo. Al reducir la sobrecarga de CPU de kube-proxy y eliminar sidecars, hemos visto a clientes reducir su factura de EC2 en un 15-20% solo migrando a Cilium eBPF.

Fragmento de configuración: Cilium con VPC CNI Chaining

Si desea lo mejor de ambos mundos —networking nativo de AWS para algunos pods y seguridad de Cilium para otros—, utilice el Modo Chaining. Esto permite que AWS administre la IP, pero Cilium la política.

# cilium-config-values.yaml
cni:
  chainingMode: aws-cni
enableIPv4Masquerade: false
tunnel: disabled
endpointRoutes:
  enabled: true
# Esta configuración preserva el modelo "ENI-por-Pod" mientras habilita
# la observability de Hubble y las políticas de red de eBPF.

Matriz de decisión

Elija AWS VPC CNI si:

• Es un equipo pequeño (menos de 5 ingenieros) y desea la menor sobrecarga operativa.
• Utiliza los Security Groups de AWS como su mecanismo principal de firewalling.
• No tiene restricciones de direcciones IP en su VPC.

Elija Cilium si:

• Está operando a "Escala EKS" (más de 200 nodos).
• Requiere visibilidad de la Capa 7 (métodos HTTP, encabezados) para la resolución de problemas.
• Tiene restricciones de IP y necesita una red overlay.
• Quiere eliminar la sobrecarga de CPU/latencia de kube-proxy e iptables.

Veredicto final

Para un clúster EKS de grado de producción en 2026, Cilium es la opción por defecto correcta. El AWS VPC CNI es un fallback robusto, pero su dependencia del plano de control de la VPC para cada asignación de IP y su falta de observability profunda lo convierten en un cuello de botella para los equipos DevOps modernos. Si está comenzando un nuevo proyecto greenfield en EKS, despliegue Cilium en su modo "Native Routing" con eBPF habilitado. La curva de aprendizaje inicial es más pronunciada, pero las capacidades de rendimiento y resolución de problemas están muy por delante de la competencia heredada.

¿Necesita ayuda para refactorizar el networking de sus pods o migrar su CNI sin tiempo de inactividad? Explore nuestros servicios avanzados de platform engineering de AWS en techleague.io para que su infraestructura funcione con la máxima eficiencia.