EKS o ECS: cómo elegir sin convertir tu plataforma en un problema operativo

Elegir entre EKS y ECS no debería empezar preguntando si Kubernetes es “mejor” o si ECS es “más simple”. Esa forma de plantearlo suele esconder la cuestión importante:

qué carga operativa puede sostener tu equipo sin que la plataforma se convierta en una fuente de fricción.

Para una startup o una pyme con AWS en producción, la decisión afecta a despliegues, observabilidad, costes, seguridad, contratación e incidentes. Puedes escoger EKS con motivos razonables y terminar con un clúster que nadie quiere tocar. Y puedes escoger ECS por pragmatismo y construir una base sólida durante años.

La pregunta no es qué herramienta parece más madura. Es qué complejidad necesitas de verdad y quién va a operarla.

Primero: qué problema estás intentando resolver

Antes de comparar servicios, separa las necesidades que suelen mezclarse:

ejecutar servicios web y workers en contenedores;
estandarizar despliegues;
mejorar autoscaling;
dar autonomía a varios equipos;
adoptar GitOps;
usar operadores o patrones propios de Kubernetes;
reducir dependencia de una persona;
crear una plataforma común para cargas de trabajo distintas.

Si el problema es “queremos desplegar contenedores en AWS con menos carga de infraestructura”, ECS con Fargate puede ser una respuesta muy sensata.

Si el problema es “necesitamos un ecosistema Kubernetes real, con patrones Kubernetes-native, GitOps maduro, operadores, políticas y una plataforma compartida para varios equipos”, EKS empieza a tener más sentido.

Lo arriesgado es elegir EKS porque “Kubernetes es el estándar”, o ECS porque “Kubernetes parece demasiado”. Ambas frases son atajos. En infraestructura, los atajos suelen pasar factura más tarde.

Cuándo ECS/Fargate suele encajar bien

Amazon ECS es un servicio gestionado de orquestación de contenedores para desplegar, gestionar y escalar aplicaciones contenedorizadas en AWS. Puede usarse con distintas opciones de capacidad, pero muchos equipos miran primero Fargate porque reduce la necesidad de gestionar servidores o clústeres de instancias EC2.

Eso no significa que Fargate elimine la operación. Sigues necesitando despliegues fiables, logs útiles, métricas, alertas, rollback, límites de recursos, seguridad y responsabilidad clara sobre cada servicio. Pero sí reduce piezas que el equipo tiene que mantener directamente.

ECS/Fargate suele encajar cuando:

el equipo es pequeño o mediano y no tiene una función de plataforma dedicada;
la mayoría de cargas son APIs, servicios web, workers o jobs relativamente directos;
el producto vive claramente dentro de AWS;
se valora más la simplicidad operativa que el control fino;
el equipo quiere desplegar contenedores sin introducir todo el modelo mental de Kubernetes;
la prioridad es reducir superficie de mantenimiento.

Eso no convierte ECS en una opción “básica”. A veces elegir ECS es una decisión senior porque evita introducir complejidad antes de que el equipo pueda absorberla.

Para muchos equipos, madurar no significa adoptar Kubernetes. Significa tener despliegues predecibles, responsabilidad clara, observabilidad suficiente y costes entendibles. Eso puede lograrse sin Kubernetes.

Cuándo EKS empieza a tener sentido

Amazon EKS es Kubernetes gestionado por AWS. En EKS estándar, AWS gestiona el plano de control; aun así, el equipo sigue operando buena parte de la plataforma.

Hay que decidir y mantener nodos, add-ons, políticas, red, permisos, observabilidad, upgrades, autoscaling, límites, seguridad, costes y diagnóstico. Opciones como EKS Auto Mode pueden reducir parte de esa carga, pero no sustituyen el criterio operativo ni la responsabilidad sobre la plataforma.

EKS empieza a tener sentido cuando hay una necesidad real de Kubernetes, no solo una preferencia estética:

varios equipos necesitan una plataforma común con convenciones claras;
ya existe conocimiento Kubernetes suficiente dentro del equipo;
se quieren usar operadores, CRDs o herramientas muy integradas con Kubernetes;
hay un enfoque GitOps maduro, o se quiere construir uno con disciplina;
las cargas de trabajo son más variadas que una colección de servicios web estándar;
se busca portabilidad de patrones, sabiendo que la portabilidad total rara vez es gratis;
alguien es responsable de mantener la plataforma después del primer despliegue.

La última condición pesa mucho. EKS no debería entrar en producción como “algo que montó una persona y luego ya veremos”. Si nadie sabe quién planifica upgrades, revisa políticas, diagnostica capacidad o responde cuando falla un despliegue, el problema no es Kubernetes. Es operación.

El coste no es solo la factura de AWS

Comparar ECS y EKS solo por precio de servicio se queda corto.

En ECS, el modelo de costes depende de la capacidad elegida. Con Fargate, el coste depende de los recursos solicitados o usados según el modelo del servicio. Con EC2, entran en juego las instancias y recursos subyacentes.

En EKS, además de los recursos usados por las aplicaciones, hay costes asociados al clúster y a algunas decisiones de operación. Si se publican precios concretos, deben verificarse siempre contra AWS Pricing en ese momento.

Pero incluso una tabla de precios perfecta dejaría fuera una parte importante: el coste operativo del equipo.

Ahí aparecen preguntas más incómodas:

¿cuánto tiempo se pierde diagnosticando despliegues?
¿quién entiende realmente el autoscaling?
¿cuánta capacidad queda infrautilizada por miedo a tocar límites?
¿cuánto cuestan unos logs o métricas mal diseñados?
¿qué ocurre si la única persona que entiende la plataforma se va de vacaciones?
¿cuántas decisiones se aplazan porque nadie quiere tocar producción?

ECS/Fargate puede reducir carga operativa cuando el caso encaja. EKS puede justificar su complejidad si habilita capacidades que el equipo necesita de verdad. Ninguna opción arregla por sí sola una plataforma sin responsabilidad operativa.

Una tabla rápida para orientar la decisión

Si tu situación se parece a esto...	Mira primero...	Por qué
Equipo pequeño, servicios directos, foco en AWS y poca capacidad de plataforma	ECS/Fargate	Menos piezas que operar y buena integración con AWS
Varios equipos desplegando cargas distintas con necesidad de estándares comunes	EKS	Kubernetes puede aportar una capa común si hay responsabilidad suficiente
El objetivo es contenerizar una aplicación existente	ECS/Fargate	Kubernetes puede añadir más complejidad de la necesaria
Necesitas operadores, CRDs, GitOps maduro o tooling Kubernetes-native	EKS	El ecosistema Kubernetes empieza a aportar valor real
Nadie sabe explicar los despliegues actuales ni el autoscaling	Ninguna migración todavía	Primero hay que aclarar operación, observabilidad y responsabilidad
La plataforma depende de una sola persona	Revisión antes de elegir	Cambiar de herramienta puede esconder el problema, no resolverlo

La tabla no sustituye una revisión técnica. Sirve para evitar una trampa habitual: decidir por herramienta cuando todavía no se ha definido el modelo operativo.

Señales de que la decisión actual ya es un problema operativo

A veces el debate no es “EKS o ECS”. Es “la plataforma actual necesita una revisión”.

Algunas señales:

nadie sabe explicar por qué escala o no escala un servicio;
los despliegues dependen de una persona concreta;
hay servicios o clústeres sin responsable claro;
la observabilidad no distingue entre fallo de aplicación, capacidad, red o despliegue;
el equipo evita tocar configuración por miedo a romper producción;
los costes suben y la conversación se queda en “AWS es caro”;
se eligió Kubernetes por moda, presión externa o inercia;
se eligió ECS sin revisar si el equipo ya necesita patrones más avanzados;
cada nuevo servicio requiere decisiones manuales distintas.

Cuando aparecen estas señales, migrar directamente de ECS a EKS —o de EKS a ECS— puede ser prematuro. Antes conviene entender qué parte del problema es arquitectura, qué parte es operación y qué parte es falta de responsabilidad clara.

Cinco preguntas antes de decidir

Antes de comprometerte con una plataforma de contenedores, responde con honestidad:

¿Cuántas personas pueden operar esto sin depender de una sola?
Si la respuesta real es “una”, la plataforma ya tiene un riesgo organizativo.
¿Qué necesitamos que Kubernetes resuelva que ECS no resuelve razonablemente?
Si no hay una respuesta concreta, quizá EKS todavía no es necesario.
¿Tenemos observabilidad suficiente para diagnosticar despliegues, capacidad y errores?
Sin visibilidad, cualquier plataforma se vuelve opaca.
¿Nuestro CI/CD y rollback están claros?
Cambiar de orquestador no compensa un release path frágil.
¿Esta decisión seguirá siendo mantenible dentro de 12-18 meses?
No hace falta predecir todo el roadmap, pero sí evitar una plataforma que solo funciona mientras una persona la empuja.

Estas preguntas aterrizan la decisión donde importa: cuándo Kubernetes ayuda, cuándo ECS simplifica y qué tradeoffs operativos o de coste merece la pena aceptar.

Elige la carga operativa que puedes sostener

ECS y EKS no son escalones universales de madurez. Son herramientas distintas para contextos distintos.

ECS/Fargate puede ser una base excelente si quieres ejecutar contenedores en AWS con menos carga de infraestructura y no necesitas todo el ecosistema Kubernetes.

EKS puede ser la mejor decisión cuando Kubernetes aporta capacidades reales, hay madurez suficiente para operarlo y existe responsabilidad clara sobre la plataforma.

Lo que conviene evitar es elegir por imagen: EKS porque suena más sofisticado, o ECS porque parece menos intimidante. En ambos casos, la factura llega después en forma de despliegues frágiles, costes difíciles de explicar, upgrades pendientes o configuraciones que nadie quiere tocar.

Si tu equipo ya está en ECS o EKS y la decisión empieza a generar dudas, una revisión corta de plataforma puede ayudar a separar problemas de arquitectura, operación y coste antes de rediseñar nada. En AstralDeploy trabajamos este tipo de decisiones desde una perspectiva de Platform Engineering en AWS: menos dogma y más claridad sobre qué puede operar el equipo con confianza.