ECS vs EKS: cómo elegir contenedores en AWS

Tu aplicación funciona en Docker en local. Ahora necesitas ejecutarla en producción en AWS. Tienes dos opciones principales: ECS (Elastic Container Service) y EKS (Elastic Kubernetes Service). Ambas ejecutan contenedores. Ambas escalan. Ambas se integran con el ecosistema AWS. Pero las similitudes terminan ahí.

ECS es el servicio propietario de AWS. EKS es Kubernetes gestionado por AWS. La diferencia no es solo técnica: afecta a la complejidad operativa, el coste del equipo, la portabilidad y las decisiones arquitectónicas que tomarás durante los próximos años.

Este artículo compara ambos servicios con datos reales, costes verificados y una recomendación honesta basada en el tamaño y las capacidades de tu equipo.

Qué es ECS y qué es EKS

ECS: el servicio nativo de AWS

ECS es un orquestador de contenedores desarrollado por AWS. No es Kubernetes. Es un servicio propietario con su propia API, su propio modelo de configuración y su propia abstracción de tareas y servicios.

Conceptos clave de ECS:

• Task Definition: La plantilla que describe tu contenedor. Imagen Docker, CPU, memoria, variables de entorno, puertos, volúmenes.
• Task: Una instancia en ejecución de una Task Definition. Equivale conceptualmente a un pod de Kubernetes, pero más simple.
• Service: Gestiona el ciclo de vida de las tareas. Mantiene N instancias corriendo, gestiona el health check, integra con load balancers.
• Cluster: El grupo lógico donde corren tus servicios.

EKS: Kubernetes gestionado

EKS es un servicio de Kubernetes gestionado. AWS se encarga del plano de control (API server, etcd, scheduler, controller manager). Tu equipo gestiona los nodos de trabajo (worker nodes) o usa Fargate para delegarlo.

Conceptos clave de EKS:

• Pod: La unidad mínima de despliegue. Uno o más contenedores que comparten red y almacenamiento.
• Deployment: Gestiona réplicas de pods. Define estrategias de actualización (rolling update, canary).
• Service: Expone pods internamente o externamente. Tipos: ClusterIP, NodePort, LoadBalancer.
• Ingress: Enrutamiento HTTP/HTTPS a servicios internos. Equivale parcialmente a API Gateway.
• Namespace: Aislamiento lógico dentro del cluster.
• Helm Charts: Paquetes de manifiestos Kubernetes. El equivalente a apt/npm para infraestructura.

La diferencia fundamental: complejidad operativa

ECS: simplicidad deliberada

ECS tiene una curva de aprendizaje significativamente menor. Un desarrollador que nunca ha usado contenedores en producción puede tener un servicio corriendo en ECS en una tarde. La razón es que ECS elimina las decisiones que Kubernetes te obliga a tomar:

• Networking: ECS con Fargate asigna una ENI (Elastic Network Interface) por tarea. Cada contenedor tiene su propia IP privada dentro de la VPC. Sin CNI plugins, sin service mesh obligatorio, sin kube-proxy.
• Escalado: ECS Application Auto Scaling escala servicios basándose en métricas de CloudWatch. Configuración: métrica objetivo, mínimo y máximo de tareas. Sin Horizontal Pod Autoscaler, sin configuración de metrics-server.
• Despliegues: ECS soporta rolling updates de forma nativa. Defines el porcentaje mínimo de tareas saludables y el porcentaje máximo. ECS gestiona el resto.
• Service discovery: AWS Cloud Map integrado. Cada servicio registra automáticamente sus instancias en Route 53 con registros SRV o A.

EKS: potencia con coste operativo

Kubernetes es un sistema operativo para la nube. Ofrece un nivel de control y flexibilidad que ECS no puede igualar. Pero ese control tiene un precio:

• Networking: Necesitas elegir e instalar un CNI plugin (AWS VPC CNI, Calico, Cilium). Configurar Network Policies para aislar tráfico entre pods. Gestionar el Ingress controller (ALB Ingress Controller, Nginx Ingress, Traefik).
• Escalado: Horizontal Pod Autoscaler requiere metrics-server. Cluster Autoscaler (o Karpenter) para escalar nodos. Vertical Pod Autoscaler para ajustar recursos. Tres componentes en lugar de uno.
• Despliegues: Rolling updates nativos, pero también canary deployments, blue-green y progressive delivery si instalas Argo Rollouts o Flagger. Más opciones, más configuración.
• Service mesh: Istio, Linkerd o AWS App Mesh si necesitas observabilidad, cifrado mTLS y control de tráfico entre servicios.

Dato revelador: Según la encuesta de Datadog sobre contenedores en 2024, el 65% de las organizaciones que usan Kubernetes necesitan al menos un ingeniero dedicado a tiempo completo a la gestión del cluster. Con ECS, la gestión de la plataforma suele ser una responsabilidad parcial dentro del equipo de DevOps.

Modos de ejecución: EC2 vs Fargate

Tanto ECS como EKS soportan dos modos de ejecución para los contenedores:

Fargate: serverless para contenedores

Fargate elimina la gestión de servidores. AWS aprovisiona la capacidad de compute exacta para cada tarea o pod. No hay instancias EC2 que gestionar, parchear o escalar.

Ventajas:

• Cero gestión de nodos.
• Escalado a nivel de tarea/pod, no de instancia.
• Aislamiento por microVM (Firecracker): cada tarea corre en su propia microVM.
• Actualizaciones de SO automáticas por parte de AWS.

Limitaciones:

• No soporta GPUs (en ECS; EKS con Fargate tampoco las soporta).
• Sin acceso al sistema operativo subyacente.
• Límite de 4 vCPU y 30 GB de memoria por tarea en ECS, 16 vCPU y 120 GB en EKS.
• DaemonSets no están soportados en EKS con Fargate.
• Almacenamiento efímero limitado a 200 GB.

Coste: Fargate cobra por vCPU-hora y GB-hora. En general, es un 20-40% más caro que EC2 con la misma capacidad, pero eliminas la gestión de instancias.

EC2: control total

Ejecutas tus contenedores en instancias EC2 que tu equipo gestiona.

Ventajas:

• Acceso completo al SO: puedes instalar agentes, configurar kernel parameters, usar GPUs.
• Soporte para DaemonSets en EKS.
• Más económico para cargas predecibles (con Reserved Instances o Savings Plans).
• Sin límites de recursos por tarea más allá de la capacidad de la instancia.

Desventajas:

• Tu equipo gestiona parches de seguridad del SO.
• Necesitas configurar el escalado de nodos (Cluster Autoscaler o Karpenter en EKS, Capacity Providers en ECS).
• La utilización de recursos rara vez es del 100%: pagas por capacidad no utilizada.

Recomendación

• Equipos de 1-5 personas: Fargate. No puedes permitirte dedicar tiempo a gestionar nodos.
• Equipos de 5-15 personas con carga predecible: EC2 con Reserved Instances para la carga base, Fargate para picos.
• Más de 15 personas o requisitos especiales (GPU, DaemonSets): EC2 con gestión automatizada.

Comparativa de costes reales

Coste del plano de control

Este es un dato que muchos ignoran: ECS no cobra por el plano de control. EKS cobra 73 dolares al mes por cluster, independientemente del número de pods. Si necesitas múltiples clusters (desarrollo, staging, producción), son 219 dolares al mes solo en planos de control.

Escenario: aplicación con 10 servicios en Fargate

Escenario: aplicación con 50 servicios en EC2

A menor escala, la diferencia de costes favorece claramente a ECS. A mayor escala, el coste del plano de control de EKS se diluye y las herramientas del ecosistema Kubernetes pueden justificarse.

El coste oculto: el equipo

El coste más significativo no está en la factura de AWS. Está en el equipo:

• ECS: Un desarrollador con experiencia en AWS puede gestionar la plataforma como parte de sus responsabilidades. No necesita ser especialista en ECS.
• EKS: Kubernetes tiene una superficie de conocimiento enorme. RBAC, NetworkPolicies, Helm, Kustomize, Service Accounts, Pod Security Standards, Custom Resource Definitions. Un ingeniero senior de Kubernetes en Europa cobra entre 70.000 y 110.000 euros anuales. Ese es un coste que no aparece en la calculadora de AWS.

Cuándo elegir ECS

ECS es la opción correcta cuando:

• Tu equipo es pequeño (menos de 10 ingenieros) y no tiene experiencia previa con Kubernetes.
• Tu infraestructura es 100% AWS y no necesitas portabilidad entre nubes.
• Quieres minimizar la complejidad operativa. ECS requiere menos conocimiento especializado para operar.
• Tus aplicaciones son relativamente simples: APIs REST, workers, procesadores de colas. Sin necesidad de service mesh, CRDs o operadores personalizados.
• El presupuesto es limitado: Sin coste de plano de control, y el equipo existente puede gestionarlo.

Ejemplo real: startup SaaS con 8 microservicios

Una startup con 5 desarrolladores, 8 microservicios en Node.js, base de datos en RDS. Tráfico variable con picos de 3x en horario laboral europeo.

Solución ECS + Fargate:

• 8 servicios en Fargate con auto-scaling.
• ALB con path-based routing.
• Service discovery con Cloud Map para comunicación entre servicios.
• CI/CD con GitHub Actions que despliega nuevas versiones con rolling update.
• Coste total de infraestructura: ~350 dolares/mes.
• Tiempo de setup inicial: 2-3 días.

Cuándo elegir EKS

EKS es la opción correcta cuando:

• Tu equipo tiene experiencia con Kubernetes y ya domina el ecosistema (Helm, kubectl, manifiestos YAML).
• Necesitas portabilidad multi-cloud: Kubernetes es el estándar de facto. Una aplicación que corre en EKS puede migrar a GKE o AKS con cambios mínimos en la capa de infraestructura.
• Necesitas el ecosistema de Kubernetes: Service mesh (Istio/Linkerd), GitOps (ArgoCD/Flux), progressive delivery (Argo Rollouts), operadores personalizados, Custom Resource Definitions.
• Tienes más de 20-30 microservicios: La capacidad de Kubernetes para gestionar aplicaciones complejas con namespaces, RBAC granular y herramientas de observabilidad justifica la complejidad adicional.
• Necesitas herramientas específicas: Prometheus + Grafana para monitoring, Cert-Manager para certificados, External-DNS para gestión automática de DNS.

Ejemplo real: plataforma fintech con 45 microservicios

Una fintech con 25 ingenieros, 45 microservicios en Java y Go, requisitos de compliance SOC 2, despliegues canary obligatorios.

Solución EKS + EC2:

• 3 clusters EKS (dev, staging, prod).
• Nodos EC2 gestionados con Karpenter para escalado automático.
• Istio como service mesh para mTLS entre servicios y observabilidad.
• ArgoCD para GitOps: todo cambio de infraestructura pasa por pull request.
• Argo Rollouts para canary deployments con rollback automático.
• Prometheus + Grafana para monitoring centralizado.
• Coste total de infraestructura: ~3.500 dolares/mes.
• Tiempo de setup inicial: 3-4 semanas.

Fargate como terreno común

Tanto ECS como EKS soportan Fargate, y esta opción merece atención especial porque elimina la principal diferencia práctica entre ambos: la gestión de nodos.

Con Fargate en EKS, no necesitas gestionar nodos EC2, no necesitas Cluster Autoscaler ni Karpenter, y el escalado es a nivel de pod. Sigues teniendo el ecosistema Kubernetes completo, pero sin la carga operativa de gestionar la capa de compute.

Limitación importante: EKS con Fargate no soporta DaemonSets, volúmenes persistentes EBS (solo EFS), ni GPUs. Si necesitas alguno de estos, necesitas nodos EC2.

La migración entre ECS y EKS

De ECS a EKS

La migración es factible pero no trivial. Los cambios principales:

1. Task Definitions a manifiestos Kubernetes: Las Task Definitions de ECS deben convertirse en Deployments, Services e Ingress de Kubernetes. Las herramientas de mapeo automático son limitadas.
2. IAM Roles for Tasks a IRSA: ECS usa IAM Roles for Tasks directamente. EKS usa IAM Roles for Service Accounts (IRSA), que requiere configuración adicional con OIDC.
3. Service Discovery: Cloud Map a Kubernetes Services. El modelo de DNS es diferente.
4. Load Balancing: ALB Target Groups a Kubernetes Ingress con AWS Load Balancer Controller.

Estimación de esfuerzo: Para una aplicación con 10-15 servicios, la migración suele requerir 4-8 semanas de trabajo de un equipo de 2-3 personas con experiencia en ambas plataformas.

De EKS a ECS

Menos común, pero sucede cuando equipos concluyen que Kubernetes es excesivo para sus necesidades. El proceso es similar pero en sentido inverso. La simplificación suele ser bienvenida, pero requiere reemplazar las herramientas del ecosistema Kubernetes (ArgoCD, Prometheus, etc.) con equivalentes de AWS.

Alternativas que no son ECS ni EKS

Antes de elegir entre ECS y EKS, considera si realmente necesitas un orquestador de contenedores:

• AWS App Runner: Servicio completamente gestionado para aplicaciones web. Subes tu código o imagen Docker, AWS se encarga de todo. Ideal para APIs simples sin requisitos de networking complejos. Coste similar a Fargate.
• AWS Lambda: Si tus servicios son funciones sin estado que responden a eventos, Lambda puede ser suficiente. Sin contenedores que gestionar.
• EC2 directo con Docker Compose: Para aplicaciones simples con 1-3 contenedores, Docker Compose en una instancia EC2 puede ser la solución más práctica. Sin orquestador, sin complejidad.

Logging y monitoring: diferencias prácticas

Logging en ECS

ECS integra nativamente con CloudWatch Logs. Cada tarea envía stdout y stderr directamente a CloudWatch sin configuración adicional más allá del log driver awslogs en la Task Definition. Puedes usar también Firelens (basado en Fluent Bit) para enviar logs a destinos alternativos como Elasticsearch, Datadog o S3.

Configuración típica en Task Definition:

{
  "logConfiguration": {
    "logDriver": "awslogs",
    "options": {
      "awslogs-group": "/ecs/mi-servicio",
      "awslogs-region": "eu-west-1",
      "awslogs-stream-prefix": "ecs"
    }
  }
}

Logging en EKS

Kubernetes no tiene un sistema de logging integrado. Necesitas instalar y gestionar tu propia stack de logging:

• Fluent Bit / Fluentd como DaemonSet para recopilar logs de todos los pods.
• Destino: CloudWatch Logs, Elasticsearch/OpenSearch, Loki, o una combinación.
• Configuración: Filtrado, enriquecimiento (añadir metadata de Kubernetes como namespace, pod name, labels), parsing.

La stack de logging en EKS es más flexible pero también más compleja. Un DaemonSet de Fluent Bit mal configurado puede perder logs o consumir recursos excesivos.

Monitoring

Para ECS, CloudWatch Container Insights proporciona métricas a nivel de cluster, servicio y tarea sin configuración adicional (solo activación). Coste: 0,03 dolares por métrica personalizada al mes.

Para EKS, la opción nativa es también Container Insights, pero la mayoría de equipos prefieren Prometheus + Grafana por su integración natural con el ecosistema Kubernetes. Esto implica instalar y gestionar componentes adicionales dentro del cluster.

Seguridad: diferencias clave

IAM en ECS

ECS usa IAM Roles for Tasks directamente. Cada Task Definition referencia un Task Role que define qué permisos tiene el contenedor. La configuración es simple y directa.

IAM en EKS

EKS usa IAM Roles for Service Accounts (IRSA). La configuración requiere:

1. Crear un proveedor OIDC en IAM para el cluster EKS.
2. Crear un IAM Role con una trust policy que referencia el Service Account de Kubernetes.
3. Anotar el Service Account con el ARN del IAM Role.

Es más complejo pero permite asignación granular de permisos por pod, no solo por nodo.

Network Policies

ECS no tiene equivalente directo a Network Policies de Kubernetes. La segmentación de red se hace con Security Groups a nivel de tarea. Cada tarea con Fargate tiene su propia ENI y puede tener su propio Security Group.

EKS con Network Policies (requiere un CNI que las soporte, como Calico o Cilium) permite definir reglas de tráfico a nivel de pod basadas en labels. Esto da un nivel de granularidad que ECS no puede igualar para arquitecturas con muchos microservicios.

La decisión en una tabla

Conclusión

La elección entre ECS y EKS no es una decisión técnica aislada. Es una decisión que afecta a la contratación, la formación del equipo, los costes operativos y la velocidad de entrega durante los próximos años.

Si tu equipo es pequeño, tu infraestructura es AWS y tu prioridad es entregar producto, ECS con Fargate es probablemente la decisión correcta. Si tu equipo tiene experiencia en Kubernetes, necesitas portabilidad o tu aplicación es lo suficientemente compleja para justificar el ecosistema, EKS es la opción adecuada.

No elijas Kubernetes porque es popular. No elijas ECS porque es simple. Elige la plataforma que tu equipo puede operar de forma sostenible.

En NERVICO ayudamos a equipos a tomar esta decisión con una evaluación objetiva de su contexto técnico y organizativo. Solicita una auditoría gratuita y analizamos tu caso concreto.