{"slug": "vpc-cni-en-eks-como-dejar-de-pagar-nodos-que-no-usas", "title": "VPC CNI en EKS: cómo dejar de pagar nodos que no usás", "summary": "The article explains how AWS EKS clusters often waste money because nodes run out of assignable pod IP addresses before fully utilizing their CPU and memory resources. It describes how enabling **Prefix Delegation** in the Amazon VPC CNI plugin allows each Elastic Network Interface (ENI) to assign blocks of 16 IPs instead of single IPs, dramatically increasing the maximum pod capacity per node (e.g., from 29 to 434 pods on a m5.large). To realize cost savings, users must also manually configure the `kubelet` `--max-pods` setting (e.g., to 110) in Karpenter or the bootstrap script, as Kubernetes will otherwise reject new pods despite available IPs.", "body_md": "Si alguna vez miraste un nodo de EKS y viste algo como esto:\nCPU: 18%\nMemory: 22%\nPods: 29/29 ← 😐\nya viviste el problema del que va este post. Tus nodos tienen recursos para utilizar pero no podes schedulear más pods en ellos...\nLa buena noticia: hay una configuración llamada Prefix Delegation en AWS VPC CNI que amplia este techo, y bien configurada te puede bajar la factura de EC2 hasta un 75% sin tocar una sola línea de código de la app.\nVamos por partes.\nUn nodo de EKS es una instancia EC2. A esa EC2 se le atachan Elastic Network Interfaces (ENIs), que son las placas de red virtuales. Cada ENI tiene:\nEl plugin Amazon VPC CNI (que corre como un DaemonSet llamado aws-node\nen cada nodo) es el encargado de pedirle IPs a EC2 y dárselas a los pods cuando arrancan. Cada pod recibe una IP real y ruteable de la VPC, no una IP virtual dentro de EKS. Lo cual es la causa del problema: el número de pods queda atado a cuántas IPs aguanta la instancia.\nPara saber cuantos pods pueden schedulearse en un nodo puede usarse la siguiente formula:\nMaxPods x Nodo = ENIs × (IPs_por_ENI − 1) + 2\ndonde:\nENIs\n: cuántas placas virtuales atacha la instanciaIPs_por_ENI − 1\n: descontamos la IP primaria+ 2\n: dos pods con hostNetwork: true\nque no consumen IP de pod (típicamente kube-proxy\ny aws-node\n)Los límites de ENIs e IPs por instancia están en la doc oficial de tipos de instancia EC2. Aplicada a la familia M5:\nAnalizando la m5.large: 29 pods. Con 2 vCPU y 8 GiB de RAM, si tus pods piden 100m CPU y 256 MiB de RAM (apis simples), la cuenta da:\nY restando los pods de sistema (kube-proxy, aws-node, csi-drivers, coredns en algunos nodos), te quedan unos 24 slots útiles. Estás pagando 2 vCPUs y 8 GiB de RAM para correr aplicaciones que apenas usan la mitad del nodo.\nSi además estás utilizando escalado automático, tu controller al ver que no entran más pods, levanta otro nodo igual. Y otro. Y otro.\nAsí aumentan los costos de nuestras EC2.\nEste AWS VPC CNI plugin que analizamos anteriormente puede configurarse en otro modo de funcionamiento (Prefix Delegation).\nEn este modo, en lugar de pedirle a la EC2 una IP a la vez, el CNI puede pedirle prefijos /28. Es decir, bloques contiguos de 16 IPs. Cada \"slot\" de la ENI pasa de ser 1 IP a ser 16 IPs.\nEntonces, a partir de este cambio tenemos una fórmula nueva:\nMaxPods = ENIs × ((IPs_por_ENI − 1) × 16) + 2\nPara la misma m5.large ahora tendriamos: 3 × (9 × 16) + 2 = 434 pods teóricos\n.\nPero esto es más teórico que real. Debajo lo analizamos mejor.\nEs una variable de entorno en el addon vpc-cni\n:\n{\n\"env\": {\n\"ENABLE_PREFIX_DELEGATION\": \"true\",\n\"WARM_PREFIX_TARGET\": \"1\"\n}\n}\nAcá viene la trampa. Activar Prefix Delegation no es suficiente — hay que decirle al kubelet\nde cada nodo que use el límite nuevo (no lo detecta solo). Si no, vas a tener IPs disponibles pero Kubernetes va a seguir rechazando pods con un mensaje de error: \"Too many pods, 0/N nodes are available\".\nPara configurarlo:\nKarpenter por default usa --use-max-pods=false\ny un cap de 110 pods, pero no lo ajusta por instancia automáticamente. Hay que decirle explícitamente en el NodePool\n:\napiVersion: karpenter.sh/v1\nkind: NodePool\nmetadata:\nname: default\nspec:\ndisruption:\nconsolidationPolicy: WhenEmptyOrUnderutilized\nexpireAfter: Never\nlimits:\ncpu: \"50\"\ntemplate:\nspec:\nkubelet:\nmaxPods: 110 # 👈 el cambio\n¿Por qué Karpenter no lo hace solo? Porque el script max-pods-calculator.sh\nde AWS sigue usando la fórmula vieja (Secondary IP) y no entiende Prefix Delegation. Karpenter prefiere dejarte un default conservador y que vos decidas. Info en la doc de Karpenter NodeClass.\nHay que ajustar el bootstrap script:\n/etc/eks/bootstrap.sh my-cluster \\\n--use-max-pods false \\\n--kubelet-extra-args '--max-pods=110'\nAntes de poner el resultado de la nueva tabla, hay que tener en cuenta el siguiente thresholds de kubernetes:\nmin(110, 10*#cores)\nLa regla, validada por kubernetes, asegura que el promedio de procesos por core quede en un rango que el scheduler del kernel maneje bien.\nEntonces el nuevo calculo para pods por EC2 es el siguiente:\nmaxPods_real = min(kubelet_maxPods, EKS_cap, CNI_formula, 10 × cores)\nPara una m5.large entonces con PD: min(110, 250, 434, 20) = 20\n. Pero ahora tenemos menos. En este caso conviene dejar en: 110.\nReferencia: Kubernetes Scalability Thresholds (SIG Scalability).\nAhora revisando nuevamente las EC2:\nHay casos donde no ganás nada o incluso te complica la vida:\nLa regla práctica: PD es palanca para instancias chicas con pods chicos. Para instancias grandes con pods pesados, el problema ya es otro.\nCaso de analisis: cluster con ~200 pods de microservicios livianos (100m CPU / 256 MiB RAM cada uno).\nSin Prefix Delegation, con m5.large:\nCon Prefix Delegation, con m5.xlarge y maxPods=110:\nAhorro: ~55% sobre el costo de cómputo, siendo conservador. Se pueden disminuir más los costos usando instancias SPOT.\nEl networking de EKS tiene un techo que es invisible hasta que se analizan los costos. Prefix Delegation no es un cambio gigante, es una variable de entorno que te baja el costo de cómputo en ciertos casos de usos.\neni-max-pods.txt\n— tabla canónica de max pods por instanciaEste post nace de mi charla en AWS Community Day Argentina 2025. Si tenés dudas sobre cómo aplicar esto a tu cluster contactame en /in/blanco-lucas.", "url": "https://wpnews.pro/news/vpc-cni-en-eks-como-dejar-de-pagar-nodos-que-no-usas", "canonical_source": "https://dev.to/aws-builders/vpc-cni-en-eks-como-dejar-de-pagar-nodos-que-no-usas-3de0", "published_at": "2026-05-22 23:45:24+00:00", "updated_at": "2026-05-23 00:01:08.678529+00:00", "lang": "en", "topics": ["cloud-computing"], "entities": ["AWS", "EKS", "EC2", "VPC CNI", "Prefix Delegation", "Elastic Network Interfaces", "M5"], "alternates": {"html": "https://wpnews.pro/news/vpc-cni-en-eks-como-dejar-de-pagar-nodos-que-no-usas", "markdown": "https://wpnews.pro/news/vpc-cni-en-eks-como-dejar-de-pagar-nodos-que-no-usas.md", "text": "https://wpnews.pro/news/vpc-cni-en-eks-como-dejar-de-pagar-nodos-que-no-usas.txt", "jsonld": "https://wpnews.pro/news/vpc-cni-en-eks-como-dejar-de-pagar-nodos-que-no-usas.jsonld"}}