EKS red privada: modo solo privado llega a AWS en 2026

AWS acaba de dar un paso que muchos esperaban hace rato: los clusters de EKS ahora pueden funcionar en modo completamente privado, sin ningún endpoint público. La actualización, confirmada en junio de 2026, permite que tanto el plano de control como los nodos vivan exclusivamente dentro de tu VPC, sin exponer nada a internet. Si administrás Kubernetes en entornos regulados o simplemente te hincharon las pelotas con auditorías de seguridad, esto cambia las reglas del juego.

Amazon EKS (Elastic Kubernetes Service) es el servicio gestionado de Kubernetes de AWS que te permite ejecutar clusters sin administrar el plano de control. EKS red privada es el modo de configuración en el que tanto el endpoint del servidor API como los nodos del cluster operan exclusivamente dentro de una VPC, sin puntos de acceso públicos a internet. Esta modalidad, que desde junio de 2026 es completamente soportada sin restricciones, elimina el vector de ataque más obvio en cualquier cluster: un endpoint de API expuesto.

¿Qué son los modos de punto de enlace del clúster en Amazon EKS?

Hasta hace poco, AWS te daba tres combinaciones para el acceso al servidor API de Kubernetes. La que faltaba —full private— ya está acá sin vueltas.

Los modos se basan en dos flags booleanos: endpointPublicAccess y endpointPrivateAccess. Combinándolos, definís cómo se llega al plano de control. El modo solo público es el default cuando creás un cluster (y sí, medio que no debería serlo en pleno 2026, pero bueh). El modo público+privado permite acceso desde internet y desde dentro de la VPC simultáneamente. Y el modo solo privado es la novedad que ahora funciona sin limitaciones: desactivás el endpoint público, dejás solo el privado, y el cluster es invisible desde afuera.

Según CloudNativeNow, AWS eliminó las restricciones que antes complicaban el modo completamente privado en ciertas regiones y tipos de cluster. Ahora es una opción de primera clase.

¿Cómo funciona el acceso privado al servidor API de Kubernetes en EKS?

Ponele que tenés un cluster productivo en una VPC y querés que nadie desde afuera pueda siquiera intentar autenticarse contra el API. Activás endpointPrivateAccess=true, y de repente el DNS del endpoint del cluster (*.eks.amazonaws.com) resuelve a una IP privada de tu VPC, no a una pública. Sobre eso hablamos en nuestra comparativa de CI/CD 2026.

El tráfico entre tus pods, tus nodos y el servidor API pasa por interfaces de red elásticas (ENIs) administradas por AWS que se crean en tus subredes, todo dentro de la VPC, todo privado, todo sin tocar internet. La resolución DNS es automática y cualquier herramienta que corra dentro de la VPC —kubectl desde una EC2, un operador, lo que sea— se comunica con el cluster sin salir.

Ahora bien, ¿qué pasa si también tenés usuarios que necesitan acceder desde afuera? Si desactivás el endpoint público (endpointPublicAccess=false), esos usuarios externos no pueden llegar. Para ese escenario necesitás un bastión, una VPN, o AWS Direct Connect. No es más complejo, es distinto.

¿Qué requisitos de VPC y subredes necesitás para red privada completa?

Acá es donde vi gente pegarse contra la pared más de una vez. El cluster y los nodos pueden estar en subredes distintas, pero tienen que estar en la misma VPC. Si creás el cluster en subred A y los nodos en subred B, funciona siempre que ambas estén en la misma VPC.

Si tus nodos están en subredes privadas (sin ruta a internet), obligatoriamente necesitás un NAT Gateway. Sin NAT, los nodos no pueden:

• Bajar imágenes de ECR (el registro de contenedores de AWS vive fuera de tu VPC).
• Hablar con otros servicios AWS como S3, CloudWatch o STS para asumir roles.
• Recibir actualizaciones de seguridad del sistema operativo de las instancias.

Con eksctl, configurarlo es un golazo. Un archivo YAML mínimo se ve así:

• privateNetworking: true en la sección del cluster.
• Subredes privadas definidas explícitamente con sus IDs.
• NAT Gateway configurado en una subred pública de la misma VPC.

La documentación de eksctl cubre los detalles finos, pero el punto es que no necesitás magia negra: es parámetro de configuración, no workaround.

¿Cómo configurar un clúster EKS con solo punto de enlace privado?

Si ya tenés un cluster corriendo y querés cerrarlo completamente, el orden importa. No podés simplemente apagar el endpoint público y esperar que todo siga funcionando. Más contexto en el análisis entre Jenkins y GitHub Actions.

El proceso correcto, según la guía de re:Post de AWS:

• Primero activás el endpoint privado si es que no lo tenías ya: aws eks update-cluster-config --name tu-cluster --resources-vpc-config endpointPrivateAccess=true.
• Verificás que la resolución DNS interna funciona desde dentro de la VPC. Podés usar nslookup contra el endpoint del cluster.
• Recién ahí desactivás el endpoint público: aws eks update-cluster-config --name tu-cluster --resources-vpc-config endpointPublicAccess=false.
• Esperás que la actualización se complete (puede tardar unos minutos) y validás que kubectl solo funciona desde dentro de la VPC.

¿Probaste desde afuera? No debería funcionar. Si funciona, algo hiciste mal. (Spoiler: probablemente no esperaste a que la actualización se complete, o tenés una VPN que no sabías que estaba activa.)

¿Cuándo conviene usar nodos en subredes privadas con EKS?

La respuesta corta: casi siempre que sea producción en serio.

Si estás en un equipo de plataforma en un banco, una fintech o una empresa de salud, probablemente ya tenés mandates de compliance que te obligan a que los nodos no tengan IPs públicas. Con el modo solo privado de EKS, cerrás el círculo: ni el plano de control ni los nodos tienen exposición.

Los casos donde realmente rinde:

• Entornos que procesan datos sensibles donde una IP pública en un nodo de Kubernetes es motivo de auditoría fallida.
• Clusters que solo reciben tráfico interno desde otras cargas dentro de la misma VPC o vía VPC Peering / Transit Gateway.
• Arquitecturas con Service Mesh donde todo el tráfico de entrada pasa por un API Gateway externo y los nodos no necesitan estar expuestos.
• Equipos que usan eksctl con privateNetworking: true y quieren infraestructura como código desde el día uno, sin parches manuales después.

Eso sí, ojo con los costos. Un NAT Gateway en una AZ de AWS anda en USD 32/mes más tráfico procesado. Si tenés multi-AZ, multiplicalo. Para un cluster chico, el costo de networking puede ser mayor que el de las instancias (lo vi pasar, no es chiste).

¿Qué errores comunes se cometen al implementar redes privadas en EKS?

Después de años viendo gente tropezar con la misma piedra, estos son los hits del desastre:

Creer que los nodos deben estar en las mismas subredes que el clúster

No. El clúster especifica subredes para las ENIs del plano de control; los nodos pueden vivir en subredes completamente distintas. Tienen que estar en la misma VPC, eso sí. Si los ponés en distinta VPC, no se ven, y kubectl te va a devolver errores crípticos hasta que te des cuenta. Ya lo cubrimos antes en la guía de hreflang para SEO internacional.

Pensar que acceso privado elimina todo acceso público automáticamente

El flag endpointPrivateAccess=true habilita el acceso privado. No deshabilita el público. Si querés modo solo privado, tenés que poner explícitamente endpointPublicAccess=false. Mantener ambos activos tiene sentido durante migraciones, pero dejarlo así en producción sin darte cuenta es un agujero de seguridad esperando a ser encontrado.

No configurar NAT Gateway para nodos en subredes privadas

Tus nodos necesitan salir a internet para cosas básicas. Bajar imágenes, resolver dependencias, mandar logs. Sin NAT, se quedan aislados, y el cluster simplemente no arranca o los pods se quedan en ImagePullBackOff. ¿Alguien lo documenta en los primeros 10 minutos de debugging? No.

Tocar las ENIs administradas por EKS

Las interfaces de red que EKS crea en tus subredes para el acceso privado son administradas. Si las movés, las borrás o cambiás sus grupos de seguridad manualmente, el plano de control deja de ser accesible. Y AWS no te manda un cartelito de advertencia —simplemente el cluster deja de responder.

Preguntas Frecuentes

¿Qué modos de red tiene Amazon EKS?

Tres: solo público (endpoint accesible desde internet), público+privado (accesible desde internet y desde la VPC), y solo privado (exclusivamente dentro de la VPC). El modo privado completo es la novedad que AWS consolidó sin restricciones en junio de 2026.

¿Cómo activar el acceso privado al servidor API de EKS?

Con el comando aws eks update-cluster-config --resources-vpc-config endpointPrivateAccess=true. Si querés modo solo privado, primero activá el acceso privado, verificá que funcione, y recién después desactivá el público con endpointPublicAccess=false. Relacionado: cómo ejecutar agentes sin API.

¿Puedo usar solo puntos de enlace privados en mi clúster EKS?

Sí, desde junio de 2026 es completamente soportado. Configurás endpointPublicAccess=false y endpointPrivateAccess=true. El clúster opera sin ningún endpoint público, con todo el tráfico del API confinado a tu VPC.

¿Qué restricciones de CIDR existen para puntos de enlace públicos de EKS?

El endpoint público de EKS asigna una IP pública de un pool de AWS. No podés elegir el rango CIDR manualmente ni restringirlo a IPs específicas con Security Groups del endpoint. Para control de acceso fino necesitás usar las reglas de autenticación de Kubernetes (RBAC + aws-auth ConfigMap) o poner un proxy delante.

¿Cómo conecto los nodos en subred privada al plano de control de EKS?

Con endpointPrivateAccess=true, EKS despliega ENIs administradas en las subredes que especificaste al crear el clúster. Los nodos, estén en la misma subred o en otras de la misma VPC, resuelven el DNS del endpoint a una IP privada y se comunican por ahí sin tocar internet.

Conclusión

La movida de AWS no es revolucionaria en el sentido técnico —el mode privado ya existía con limitaciones— pero sí es un reconocimiento de que la gran mayoría de los clusters productivos deberían estar completamente aislados de internet. Lo que antes requería configuraciones trabajosas o workarounds ahora es un parámetro de configuración estándar.

Si estás levantando un cluster nuevo en 2026, mi recomendación es que arranques con modo privado desde el día uno. Es más fácil cerrar un cluster que ya nació privado que migrar uno público después, cuando tenés equipos acostumbrados a conectarse desde cualquier lado y CI/CD pipelines que asumen conectividad pública. Para entornos de desarrollo y pruebas, el modo público+z privado sigue siendo práctico. Para producción que maneja datos reales, el modo solo privado es la respuesta correcta.

Y si estás evaluando dónde correr Kubernetes en infraestructura regional con buen soporte y latencia baja para Latinoamérica, opciones como donweb.com ofrecen cloud y servidores gestionados que pueden complementar o sustituir según el caso. Lo importante es que elijas conociendo los trade-offs, no por inercia.

Fuentes

• CloudNativeNow – AWS Stretches Elastic Kubernetes Service to Full Private Networking
• AWS re:Post – Arquitectura de red del clúster de EKS
• AWS re:Post – Acceso seguro a la API del clúster de EKS en una VPC
• AWS Docs – Configuración de subredes de VPC en eksctl