En producción, ECS vs EKS rara vez se decide con una tabla de features.
Se decide cuando tienes que desplegar un cambio un viernes.
Cuando un cronjob se ejecuta más veces de lo esperado.
Cuando AWS empieza a responder Rate exceeded.
Cuando tienes que actualizar cientos de nodos.
Cuando un equipo de desarrollo necesita moverse rápido sin entender cada pieza de la plataforma.
En teoría, la comparación es sencilla:
- ECS es más simple y más integrado con AWS
- EKS es Kubernetes administrado
- Kubernetes es más portable
- ECS tiene menos superficie operacional
Todo eso es cierto.
Pero también es incompleto.
La pregunta real no es cuál tiene más features.
La pregunta real es: ¿qué tipo de problemas quieres operar todos los días?
ECS se siente más cerca de AWS
ECS tiene una cualidad que en producción pesa mucho: se siente como parte natural de AWS.
Defines servicios, tareas, roles, security groups, load balancers, logs, autoscaling, secrets y permisos desde infraestructura. Si usas Terraform, Pulumi, CloudFormation o CDK, gran parte del sistema vive en el mismo lugar mental.
También puedes manejar los despliegues con herramientas como ecspresso, que hacen que ECS sea bastante cómodo sin tener que construir una plataforma enorme alrededor.
En muchos equipos que ya viven dentro de AWS, el resultado práctico es que el equipo de desarrollo puede avanzar más rápido.
No porque ECS sea mágico.
Sino porque hay menos conceptos intermedios entre “quiero correr este servicio” y “el servicio está corriendo”.
No tienes que explicar namespaces, service accounts, ingress controllers, CRDs, Helm charts, admission controllers, node groups, taints, tolerations, kubectl, contexts, kubeconfigs y el pequeño universo de YAML que aparece alrededor de Kubernetes.
Eso no significa que ECS no tenga complejidad.
Significa que mucha de esa complejidad se queda dentro de AWS y se expresa con recursos que el equipo probablemente ya está usando.
EKS abre más puertas
EKS, por otro lado, te da Kubernetes.
Y Kubernetes es una plataforma enorme.
Eso puede ser una ventaja real.
Puedes usar operadores, service meshes, controllers, autoscalers más sofisticados, runtimes distintos, patrones multi-cloud, herramientas estándar de observabilidad, políticas con admission controllers, GitOps, workloads más diversos y un ecosistema que no depende solo de AWS.
Cuando necesitas esa flexibilidad, EKS puede sentirse mucho más robusto.
No porque ECS sea débil, sino porque Kubernetes te deja construir una plataforma mucho más rica encima.
El problema es que esa riqueza no llega gratis.
Cada cosa que agregas al cluster también se vuelve algo que alguien tiene que entender, actualizar, monitorear y depurar cuando falla.
En EKS no solo corres aplicaciones.
Corres una plataforma.
Los upgrades no se sienten igual
Una de las diferencias más grandes aparece con el tiempo.
En ECS no estás pensando en actualizar el cluster de la misma forma.
Con Fargate, AWS se encarga de mucho de ese trabajo. Existen eventos como el task patching, donde AWS reemplaza tareas periódicamente para aplicar actualizaciones de plataforma o seguridad. Eso puede causar movimiento en tus tasks, y necesitas readiness, health checks y despliegues bien configurados, pero no estás planeando una actualización completa de nodos como parte normal de tu vida.
En EKS, los upgrades son otra historia.
Actualizar Kubernetes puede sentirse como un ritual complejo:
- revisar compatibilidad de la versión
- actualizar el control plane
- actualizar add-ons como VPC CNI, CoreDNS y kube-proxy
- revisar CRDs y controllers
- validar Helm charts
- actualizar node groups
- drenar nodos
- cuidar PodDisruptionBudgets
- revisar workloads que dependen de APIs deprecadas
- monitorear que el autoscaling no haga algo raro en medio del proceso
Si tienes pocos nodos, es manejable.
Si tienes cientos y cientos, deja de ser una tarea que simplemente puedes lanzar y olvidar.
AWS ha ido mejorando la experiencia. EKS Auto Mode reduce parte del trabajo pesado y cambia bastante la conversación sobre administración de nodos.
Pero aun así, no creo que un upgrade de EKS sea algo que puedas dejar corriendo en background mientras te vas por café.
No si producción importa.
Cronjobs: donde ECS muestra sus bordes
ECS no tiene CronJob como Kubernetes.
Si quieres tareas programadas, normalmente terminas usando EventBridge Scheduler o EventBridge Rules para lanzar RunTask.
Esto funciona.
Pero introduce otra frontera operacional.
Ya no estás operando solo ECS. También estás operando la integración entre EventBridge, IAM, ECS, networking, quotas y la API de RunTask.
Y ahí aparecen fallas muy reales.
Alguna vez tuve un bug donde se lanzaron como 15 cronjobs al mismo tiempo. No eran trabajos pesados por separado, pero juntos chocaron contra límites y errores de AWS.
Algunos RunTask fallaron con respuestas como:
Service unavailableRate exceededThrottling Exception
Ese tipo de incidente es un buen recordatorio: serverless o managed no significa que no existan límites.
Solo significa que los límites viven en otro lugar.
En Kubernetes, un CronJob vive dentro del cluster. Puedes controlar concurrency policy, deadlines, retries, history limits y observar el comportamiento con las mismas herramientas del cluster.
En ECS, tienes que diseñar esa parte explícitamente:
- retries con backoff
- límites de concurrencia
- idempotencia del job
- alertas por fallos de
RunTask - DLQs si el flujo lo necesita
- quotas revisadas antes de crecer
- separación entre schedules críticos y no críticos
El error común es pensar que EventBridge más ECS equivale exactamente a un CronJob de Kubernetes.
No equivale.
Se puede operar bien, pero necesitas tratarlo como una integración distribuida, no como un feature nativo de ECS.
Permisos: simple no significa fácil
En ECS, casi todo se maneja desde infraestructura:
- task roles
- execution roles
- IAM policies
- security groups
- secrets
- log groups
- load balancers
- target groups
Eso suele ser una ventaja enorme.
El modelo mental está más cerca de AWS: este task necesita leer este secret, escribir en este bucket, publicar en esta cola y hablar con esta base de datos.
El problema es que IAM sigue siendo IAM.
Puedes equivocarte con permisos demasiado amplios.
Puedes mezclar el execution role con el task role.
Puedes olvidar permisos para traer imágenes o escribir logs.
Puedes romper un despliegue porque el task no puede leer un secret.
Puedes tener networking correcto en la aplicación pero incorrecto en los security groups.
ECS reduce capas, pero no elimina responsabilidad.
En EKS, el modelo se vuelve más amplio.
Tienes IAM, pero también RBAC de Kubernetes, service accounts, IRSA o EKS Pod Identity, namespaces, policies, admission controllers y secretos dentro del cluster.
Eso puede darte más control.
También te da más lugares donde equivocarte.
Un pod puede tener permisos correctos en Kubernetes pero no en AWS.
O permisos correctos en AWS pero no en Kubernetes.
O acceso a red bloqueado por una NetworkPolicy.
O un chart que crea recursos con permisos más amplios de lo que pensabas.
EKS no es solo “meter YAMLs”.
Es construir una capa completa de configuration management: conexión al cluster, credenciales, permisos, templates, validaciones, drift detection, GitOps o pipelines capaces de aplicar cambios sin depender de que alguien tenga el contexto correcto en su máquina.
Y cuando metes CI/CD, esa capa también necesita sus propios workflows, pruebas, accesos y networking.
Si corres EKS en nodos privados, conectar tu CI/CD al cluster de forma segura y mantenible ya es un tema por sí solo.
Eso es poderoso.
Pero también es trabajo.
Los errores comunes no son los mismos
En ECS, los problemas comunes suelen vivir alrededor de integración con AWS:
- tasks que no arrancan porque falta un permiso en el execution role
- imágenes que no se pueden descargar desde ECR
- secrets mal referenciados
- health checks demasiado agresivos
- target groups que matan tasks antes de que estén listas
- problemas de ENIs o límites de networking en Fargate
- autoscaling basado en una métrica que no representa carga real
- schedules que lanzan demasiadas tareas al mismo tiempo
- cuotas de
RunTask, API throttling o capacidad insuficiente
En EKS, los problemas comunes suelen vivir alrededor de la plataforma:
- nodos que no drenan bien por PodDisruptionBudgets mal definidos
- workloads sin requests y limits razonables
- HPA reaccionando tarde o escalando por la métrica equivocada
- IP exhaustion con el VPC CNI
- add-ons desactualizados
- charts con valores copiados sin entender el impacto
- CRDs que bloquean upgrades
- controllers que fallan y afectan a muchos servicios
- permisos divididos entre Kubernetes y AWS
- pipelines que necesitan acceso privado al cluster
- demasiada lógica escondida en YAMLs o Helm templates
La diferencia no es que uno falle y el otro no.
La diferencia es dónde tienes que mirar cuando algo falla.
Velocidad vs superficie operacional
ECS permite que muchos equipos se muevan rápido porque reduce la cantidad de plataforma que deben entender.
Para servicios web comunes, workers, APIs, jobs pequeños y equipos muy metidos en AWS, ECS con Fargate puede ser una gran decisión.
Te obliga a resolver menos cosas.
Y eso, en producción, es una virtud.
EKS se vuelve más atractivo cuando necesitas más que correr contenedores:
- workloads heterogéneos
- ecosistema Kubernetes
- operadores
- patrones de plataforma más avanzados
- más control sobre scheduling
- portabilidad organizacional
- una plataforma interna compartida por muchos equipos
Pero EKS requiere un equipo en constante monitoreo.
No necesariamente un ejército, pero sí ownership real.
Alguien tiene que cuidar upgrades.
Alguien tiene que entender nodos.
Alguien tiene que revisar add-ons.
Alguien tiene que observar el cluster, no solo las aplicaciones.
Alguien tiene que mantener el paved road para que los developers no terminen peleando con Kubernetes todos los días.
Sin eso, EKS puede convertirse en una forma elegante de distribuir complejidad a todos los equipos.
Entonces, cuál elegir
Si la pregunta es “¿cuál es mejor?”, creo que la respuesta honesta es: depende de qué estás dispuesto a operar.
ECS es una buena opción cuando quieres que AWS absorba más complejidad y tu prioridad es mover servicios a producción con menos plataforma alrededor.
EKS es una buena opción cuando Kubernetes es parte de la estrategia, no solo una forma sofisticada de correr contenedores.
La trampa es elegir EKS porque parece más robusto sin aceptar el costo operacional.
La otra trampa es elegir ECS pensando que por ser más simple ya no necesitas diseño operacional.
Ambas cosas fallan.
ECS también necesita buenas prácticas: límites, retries, idempotencia, health checks, observabilidad, IAM cuidadoso y cuotas revisadas.
EKS también necesita humildad: upgrades planeados, ownership claro, automatización, políticas, documentación viva y una plataforma que no obligue a cada developer a convertirse en experto de Kubernetes.
Al final, la decisión rara vez es solo técnica.
También se trata del equipo, del producto, de la madurez operacional y del tipo de problemas que estás dispuesto a cargar todos los días.
Porque a producción no le importa qué orquestador elegiste.
Solo le importa si alguien sabe cómo operarlo.