EKS con Terraform en 10 minutos: guía práctica 2026

En pocas palabras: Con un template de Terraform publicado en dev.to por el desarrollador Nishath, un solo comando terraform apply levanta un cluster EKS completo en AWS (VPC, subredes, NAT Gateway, IAM con IRSA, EBS CSI Driver y ECR) en 5 a 10 minutos, editando únicamente el archivo terraform.tfvars.

Un desarrollador publicó en dev.to un template de Terraform que levanta un cluster EKS completo (VPC, subredes públicas y privadas, NAT Gateway, IAM con IRSA, EBS CSI Driver y repositorios ECR) en 5 a 10 minutos con un solo comando. La configuración por proyecto se reduce a editar un único archivo, terraform.tfvars, sin tocar código.

EKS con Terraform es la combinación de Amazon Elastic Kubernetes Service con Infrastructure as Code para automatizar el despliegue de clusters de Kubernetes en AWS. El template documentado por Nishath en dev.to provisiona networking, IAM, el cluster y ECR en módulos separados, pensado para reutilizarse en distintos proyectos cambiando solo variables.

¿Qué recursos de AWS provisiona automáticamente este template de Terraform?

El template provisiona nueve categorías de infraestructura con un solo terraform apply: cluster EKS, VPC con subredes públicas y privadas, Internet Gateway más NAT Gateway, route tables, Network ACLs y Security Groups, Managed Node Groups con Auto Scaling, IAM Roles con OIDC Provider para IRSA, EBS CSI Driver, CloudWatch Log Groups y repositorios ECR.

Ponele que arrancás un proyecto de cero. En vez de ir clickeando en la consola de AWS creando VPC, después las subredes, después las IAM roles, después el node group (y rezando para no olvidarte de nada), corrés un comando y Terraform hace todo en el orden correcto, respetando las dependencias entre recursos.

• Kubernetes Cluster: Amazon EKS como control plane administrado.
• Networking: VPC custom con subredes públicas y privadas separadas.
• Acceso a internet: Internet Gateway para las públicas, NAT Gateway para que las privadas salgan sin exponerse.
• Compute: Managed Node Groups con Auto Scaling configurado por variables.
• Identidad: IAM Roles más OIDC Provider, la base de IRSA.
• Storage: Amazon EBS CSI Driver para volúmenes persistentes.
• Logging: CloudWatch Log Groups para los logs del cluster.
• Registro de contenedores: repositorios ECR, uno por servicio.

Todo queda como código versionable. Nada se toca a mano en la consola, lo cual (spoiler: no es un detalle menor) es justo lo que separa una infraestructura reproducible de una que solo un ingeniero recuerda cómo armar. Te puede servir nuestra cobertura de cómo funcionan las lifecycle rules en Terraform.

¿Cómo es la arquitectura de red del cluster EKS?

La arquitectura separa las subredes públicas, que exponen el Load Balancer, de las privadas, donde corren los worker nodes de Kubernetes. Esta separación mantiene los nodos fuera de acceso directo desde internet mientras solo expone los endpoints de aplicación necesarios.

El NAT Gateway es la pieza que permite que las cargas privadas salgan a internet (para bajar imágenes, hacer llamadas a APIs externas) sin tener IP pública asignada. El control plane de EKS administra Kubernetes por afuera de esa red, ECR guarda las imágenes de contenedores y CloudWatch centraliza los logs del cluster. IRSA conecta de forma segura los workloads con servicios de AWS, tema que desarrollamos más abajo porque es, según la propia fuente, “el desafío más interesante” de todo el proyecto.

¿Cómo configurar un proyecto nuevo modificando solo terraform.tfvars?

Configurar un proyecto nuevo implica editar únicamente el archivo terraform.tfvars: nombre del proyecto, nombre del cluster, región, tipo de instancia de los nodos, capacidad deseada y lista de repositorios ECR. No hace falta tocar ningún módulo de Terraform.

El ejemplo que muestra la fuente original define un proyecto llamado “revenuepilot” en la región ap-south-1, con instancias t3.medium, capacidad deseada de 2 nodos y tres repositorios ECR (frontend, backend, ai-service). Cambiás esos valores, guardás el archivo y ya tenés la base para un cluster distinto. Sin copiar y pegar módulos, sin duplicar código, sin mantener diez repositorios de Terraform casi idénticos. Lo explicamos a fondo en si estás dando tus primeros pasos con Terraform en AWS.

¿Cuáles son los pasos para desplegar el cluster con terraform apply?

El despliegue sigue cuatro comandos en secuencia: terraform init para inicializar los providers, terraform plan para revisar qué se va a crear, terraform apply para crear los recursos y después aws eks update-kubeconfig para poder operar el cluster con kubectl.

• terraform init: descarga providers y módulos necesarios.
• terraform plan: muestra el plan de infraestructura antes de aplicar nada.
• terraform apply: crea todas las dependencias en el orden correcto.
• aws eks update-kubeconfig –region ap-south-1 –name revenuepilot-eks: actualiza el kubeconfig local.
• kubectl get nodes: confirma que el cluster está arriba.

La salida de ejemplo que documenta la fuente muestra dos nodos en estado Ready a los 4 minutos de creados, identificados como ip-10-0-1-101.ap-south-1.compute.internal e ip-10-0-2-134.ap-south-1.compute.internal. Ese es el momento en que, técnicamente, el cluster está vivo y listo para recibir workloads.

¿Por qué da error AccessDenied ec2:CreateVolume en EKS?

El error AccessDenied: Not authorized to perform ec2:CreateVolume aparece cuando el EBS CSI Driver intenta crear un volumen persistente sin tener las credenciales de AWS necesarias. El origen no es un problema de Kubernetes: es un problema de IAM.

¿Y qué pasó cuando el autor probó levantar una PersistentVolumeClaim después de que la infraestructura se había desplegado sin errores? Falló. El EBS CSI Driver corre dentro de Kubernetes pero necesita hablar con la API de EC2 para crear volúmenes, y usar los permisos IAM del nodo funciona pero no se recomienda, porque expone ese permiso a cualquier pod que corra en ese nodo. En prepararte para la certificación Terraform Associate profundizamos sobre esto.

¿Qué es IRSA y cómo soluciona los problemas de permisos entre Kubernetes y AWS?

IRSA (IAM Roles for Service Accounts) es un mecanismo de AWS que asocia un rol de IAM a una service account de Kubernetes, en vez de darle permisos de AWS a nivel de nodo. Según la documentación oficial de Amazon EKS, esto permite aplicar el principio de menor privilegio: solo los pods que usan esa service account acceden a esos permisos puntuales.

La solución al error de EBS involucró tres recursos de Terraform, en este orden: habilitar el OIDC Provider del cluster, crear un IAM Role de confianza vinculado a ese OIDC provider, y asociar ese role a la service account de Kubernetes que usa el CSI Driver. Terraform maneja la relación de confianza (trust relationship) de forma automática una vez que están esos tres recursos definidos. Después de aplicar esa configuración, el CSI Driver autenticó correctamente, las PersistentVolumeClaims quedaron bound y los volúmenes EBS se crearon de forma dinámica.

La documentación de AWS agrega otro beneficio de IRSA que no es solo seguridad: auditabilidad. Los eventos de acceso quedan disponibles en AWS CloudTrail, algo que con permisos compartidos a nivel de nodo es prácticamente imposible de rastrear con precisión.

Aspecto	Sin IRSA	Con IRSA
Alcance de permisos	Compartido por todos los pods del nodo	Específico por service account
Superficie de riesgo	Mayor (blast radius amplio)	Menor (permisos acotados por workload)
Auditoría	Difícil de rastrear por pod	Trazable vía AWS CloudTrail
Casos de uso típicos	No recomendado en producción	S3, Secrets Manager, DynamoDB, SQS, EBS

¿Qué buenas prácticas de arquitectura sigue este template de Terraform?

El template organiza cada servicio de AWS en un módulo separado (networking, iam, eks, ecr), lo que facilita mantenimiento, reutilización entre repositorios y separación clara de responsabilidades. Esa modularidad es la que permite, según el propio autor, extender después con RDS, EFS, ALB Controller o Secrets Manager sin reescribir lo existente.

• Configuración parametrizada: región, nombre del cluster, tipo de instancia, escalado de nodos, nombres de repositorios y rangos CIDR viven todos en variables.
• Tagging consistente: cada recurso recibe tags de Project, Environment y ManagedBy = "Terraform", útiles para cost tracking.
• Separación de roles IAM: hay roles distintos para el control plane de EKS, para los worker nodes y para los workloads vía IRSA.

El repositorio completo está publicado en GitHub, en devops-starter-kit, con los cuatro módulos organizados en carpetas separadas.

Errores comunes al desplegar EKS con Terraform

• Asumir que los permisos de nodo alcanzan para todo: funciona al principio, pero cuando el CSI Driver necesita crear volúmenes falla con AccessDenied. La solución es IRSA, no ampliar el rol del nodo.
• No revisar el plan antes de aplicar: saltar terraform plan y correr apply directo es la forma más rápida de crear recursos que no necesitás o de sobreescribir algo sin darte cuenta.
• Copiar y pegar módulos entre proyectos: en vez de mantener un template parametrizado, terminás con diez versiones ligeramente distintas del mismo código, cada una con su propio bug.
• No taguear los recursos: sin tags de Project y Environment, rastrear costos por proyecto en la factura de AWS se vuelve una tarea manual.

Un criterio práctico antes de dar por confiable cualquier despliegue de este tipo: correr terraform plan en un entorno de staging, revisar que los IAM roles generados tengan el alcance mínimo esperado, y confirmar con kubectl describe pvc que los volúmenes efectivamente quedan en estado Bound antes de mover el proyecto a producción. Esto es una propuesta de verificación editorial, no algo que la fuente haya probado ni que nosotros hayamos ejecutado. Más contexto en desplegar EKS en entornos air-gapped.

Preguntas Frecuentes

¿Cuánto tarda en desplegarse un cluster EKS con Terraform?

Entre 5 y 10 minutos según la fuente original del template. Ese tiempo cubre la creación de VPC, subredes, NAT Gateway, IAM, el cluster EKS y los node groups en un solo terraform apply.

¿Qué archivo hay que editar para configurar un proyecto nuevo?

Solo terraform.tfvars. Ahí se definen el nombre del proyecto, la región, el tipo de instancia de los nodos, la capacidad deseada y los repositorios ECR, sin tocar código Terraform.

¿Por qué falla la creación de volúmenes EBS en EKS?

Falla porque el EBS CSI Driver no tiene las credenciales de IAM necesarias para llamar a ec2:CreateVolume. El error típico es AccessDenied: Not authorized to perform ec2:CreateVolume, y se resuelve configurando IRSA en vez de ampliar los permisos del nodo.

¿Qué es IRSA en Kubernetes?

IRSA (IAM Roles for Service Accounts) es la forma de asociar un rol de IAM de AWS a una service account de Kubernetes específica, en vez de compartir permisos a nivel de nodo. Según AWS, elimina la necesidad de soluciones de terceros como kiam o kube2iam.

¿Qué recursos de AWS crea Terraform al desplegar EKS?

Crea el cluster EKS, una VPC con subredes públicas y privadas, Internet Gateway, NAT Gateway, security groups, node groups con Auto Scaling, IAM roles con OIDC provider, EBS CSI Driver, CloudWatch Log Groups y repositorios ECR.

Conclusión

Lo que muestra este template no es una técnica nueva: EKS, Terraform e IRSA existen hace años. Lo que aporta es un ejemplo concreto y reproducible de cómo encadenar esas piezas sin perder días en la consola de AWS ni pisar el error clásico de permisos con el EBS CSI Driver.

Si estás por levantar tu propio cluster, el punto de partida razonable es clonar un módulo parecido, ajustar terraform.tfvars a tu proyecto y validar con terraform plan antes de aplicar nada en una cuenta productiva. Ojo con dar por sentado que los permisos de nodo alcanzan para todo: ahí es donde la mayoría se traba.

Fuentes

• Build a Production-Ready Kubernetes Infrastructure on AWS with Terraform – dev.to
• devops-starter-kit – repositorio de módulos Terraform en GitHub
• IAM roles for service accounts – documentación oficial de Amazon EKS