Análisis Detallado de Amazon ECS: Diseñando la Plataforma de Contenedores “Justa y Adecuada” Comparándola con GKE, AKS, Cloud Run y Container Apps

Introducción (Puntos Clave)

• La estrella de este artículo es Amazon Elastic Container Service (Amazon ECS).
  ECS es un servicio totalmente gestionado de orquestación de contenedores que facilita desplegar, gestionar y escalar aplicaciones en contenedores.
• ECS soporta tres tipos de lanzamiento / cómputo: EC2 / Fargate / ECS Anywhere, lo que te permite ejecutar cargas de trabajo de forma consistente en la nube, on-premise y en entornos de edge.
• En el mundo de GCP, GKE (Google Kubernetes Engine) cumple el rol de Kubernetes gestionado, y en Azure, AKS (Azure Kubernetes Service) ocupa la misma posición. Ambos son servicios que “ejecutan Kubernetes en sí de forma gestionada”.
• En un nivel de abstracción aún mayor, también tenemos las siguientes “plataformas serverless de ejecución de contenedores”:
  • AWS: App Runner
  • GCP: Cloud Run
  • Azure: Azure Container Apps
    Entender cómo se posicionan estas en relación con ECS es una parte importante de la historia.
• Este artículo está dirigido a:
  • Desarrolladores web/backend que quieren empezar a usar contenedores en producción
  • SREs e ingenieros de infraestructura que quieren aclarar las diferencias entre ECS / GKE / AKS
  • Tech leads y arquitectos que dudan sobre qué capa adoptar (ECS o App Runner / Cloud Run / Container Apps)
• Al final del artículo, el objetivo es que seas capaz de explicar con tus propias palabras cosas como:
  • “Para este caso de uso, ECS es la mejor opción.”
  • “Si queremos este nivel de abstracción, deberíamos usar App Runner / Cloud Run / Container Apps.”
  • “Si realmente necesitamos Kubernetes, deberíamos elegir GKE / AKS / EKS.”

1. ¿Qué es Amazon ECS? – Un orquestador “justo y adecuado” optimizado para AWS

1.1 Dónde encaja ECS

Amazon ECS es un servicio de orquestación de contenedores totalmente gestionado proporcionado por AWS. Actúa como una “torre de control” para colocar, escalar y monitorizar de forma eficiente aplicaciones en contenedores en AWS.

A grandes rasgos:

• ECS
  • Un orquestador cerrado, optimizado para AWS
  • Integración muy sencilla con IAM / VPC / ALB / CloudWatch, etc.
• EKS (como referencia)
  • Kubernetes gestionado (Kubernetes OSS) en AWS
  • Una opción cuando quieres un diseño “Kubernetes-nativo”
• GKE / AKS
  • Ambos son servicios de Kubernetes gestionado
  • Un mundo donde las APIs de Kubernetes y su ecosistema son las abstracciones principales

ECS no es Kubernetes, pero precisamente por eso tiene menos conceptos y es más simple, y para sistemas que son “solo AWS”, puedes considerar ECS como “el primer candidato a evaluar”.

1.2 Casos de uso principales de ECS

• Web APIs / backend (microservicios)
• Procesamiento batch / ejecución de jobs
• Workers que consumen colas (SQS / Kinesis, etc.)
• Servidores de juego / procesamiento en tiempo real
• Inferencia / preprocesamiento de machine learning

En otras palabras, ECS puede manejar prácticamente cualquier “contenedor que se ejecuta de forma continua o casi continua”.

2. Conceptos básicos de ECS: Cluster, Task Definition, Service

ECS está formado por un pequeño conjunto de bloques fundamentales. Una vez que te acostumbras a los términos, no es tan complicado.

2.1 Cluster

• Una “caja” lógica en la que se ejecutan contenedores
• Dentro de un cluster puedes tener:
  • Instancias EC2 (tipo de lanzamiento EC2)
  • Capacidad Fargate (tipo de lanzamiento Fargate)
  • Nodos on-prem registrados mediante ECS Anywhere

2.2 Task Definition

• Una plantilla para ejecutar contenedores que especifica:
  • qué imagen,
  • qué recursos, y
  • qué variables de entorno
    se van a usar.
• Una task definition puede contener varios contenedores (por ejemplo, un patrón sidecar).

2.3 Task

• El grupo de contenedores en ejecución creado a partir de una task definition.
• Si vienes del mundo Kubernetes, puedes pensar que “una task ≈ un Pod” para hacerte una idea.

2.4 Service

• Un mecanismo para decir “mantén al menos N copias de esta task ejecutándose en todo momento”.
• Cuando creas un service, ECS se encarga automáticamente de:
  • health checks y reinicios de las tasks
  • autoescalado (ECS Service Auto Scaling)
  • integración con ALB / NLB (registro en target groups)

Si entiendes estas cuatro piezas, podrás leer la mayoría de arquitecturas básicas de ECS sin perderte.

3. Tipos de lanzamiento de ECS y posicionamiento frente a servicios similares

3.1 Los tres tipos de lanzamiento: EC2 / Fargate / Anywhere

Hay tres formas principales (tipos de lanzamiento) de ejecutar contenedores con ECS:

1. Tipo de lanzamiento EC2
   • Ejecuta contenedores en un grupo de instancias EC2 que tú mismo gestionas.
   • Adecuado cuando quieres ajustar profundamente el sistema operativo, middleware, disposición de discos, etc.
2. Tipo de lanzamiento Fargate
   • Un motor de cómputo serverless donde puedes ejecutar contenedores simplemente especificando vCPU y memoria, sin pensar en instancias EC2.
   • Te libera del parcheo, escalado y gestión de capacidad de las instancias, pero el coste por unidad suele ser algo mayor que EC2.
3. ECS Anywhere
   • Una forma de registrar nodos on-prem y de otras nubes en un cluster de ECS y gestionarlos con el mismo plano de control que en AWS.

Dicho de forma simple:

• Si quieres minimizar la gestión de infraestructura → Fargate
• Si tienes requisitos estrictos de coste o de personalización → EC2
• Si quieres gestión unificada en entornos híbridos / edge → ECS Anywhere

3.2 Posicionamiento frente a servicios basados en Kubernetes (ECS vs GKE / AKS)

• ECS
  • Orquestador propio de AWS con relativamente pocos conceptos que aprender.
• GKE (GCP) / AKS (Azure)
  • Ambos son Kubernetes gestionado. Puedes aprovechar completamente las APIs de Kubernetes, manifests, Helm y otras herramientas del ecosistema OSS.

Si tu equipo es fuerte en Kubernetes, puede ser más eficiente, en términos de aprendizaje, estandarizar en:

• AWS: EKS
• GCP: GKE
• Azure: AKS

Por otro lado, si tus sistemas están principalmente en AWS y no te importa especialmente “Kubernetes como tal”, ECS suele ser la opción más sencilla.

3.3 Comparación con servicios serverless de contenedores de nivel más alto

Un nivel por encima de ECS tenemos:

• AWS App Runner: Servicio de aplicaciones en contenedores totalmente gestionado que construye, despliega y escala a partir de código fuente o imágenes de contenedor.
• GCP Cloud Run: Plataforma serverless para contenedores HTTP o dirigidos por eventos. Excelente para escalar a cero.
• Azure Container Apps: Plataforma serverless de ejecución de contenedores. Escala según tráfico HTTP, eventos o carga de CPU/memoria utilizando escaladores basados en KEDA.

Estos servicios son más parecidos a un PaaS. Como guía general:

• Si quieres tocar lo mínimo la infraestructura y los clusters → App Runner / Cloud Run / Container Apps
• Si necesitas VPC, ALB, control de red detallado o manejo personalizado de jobs → ECS / GKE / AKS

Esta distinción ayuda a mantener las ideas ordenadas.

4. Ejemplos de arquitectura con ECS: Web APIs, batch, workers dirigidos por eventos

Veamos brevemente tres patrones representativos de ECS para ayudarte a visualizar cómo se usa.

4.1 Una Web API sencilla en Fargate

• Construye un ALB + cluster ECS (Fargate) dentro de una VPC.
• Flujo de tráfico: ALB → servicio ECS (varias tasks).
• La task definition incluye:
  • Imagen Docker (extraída desde ECR)
  • Recursos como 0.25 vCPU / 0.5 GB
  • Variables de entorno (por ejemplo información de conexión a BD desde Secrets Manager)

Los desarrolladores pueden centrarse en el Dockerfile y el código de la aplicación, y el despliegue puede ser tan sencillo como ejecutar ecs deploy desde CI/CD.

4.2 Procesamiento batch / de jobs

• En un cluster ECS compartido, puedes ejecutar:
  • Un servicio web de larga duración como un ECS service
  • Jobs batch como scheduled tasks (EventBridge + RunTask)
• Por ejemplo, “cada hora, descargar un archivo de S3, ejecutar un ETL y cargarlo a RDS” puede modelarse como una task puntual de ECS.

En GCP, los equivalentes serían GKE Jobs o Cloud Run Jobs; en Azure, Jobs en AKS o Container Apps desempeñan roles similares.

4.3 Workers dirigidos por eventos (SQS / Kinesis)

• Ejecuta workers en ECS que hacen polling a una cola SQS y:
  • usan Service Auto Scaling para aumentar/disminuir el número de tasks en función del número de mensajes.
• En GCP, puedes hacer cosas similares con Cloud Run + Pub/Sub (push) o GKE + suscripciones a Pub/Sub; en Azure, con Container Apps + Event Hub / Service Bus, etc.

5. Ejemplo sencillo de Task Definition (solo para hacerse una idea)

Los detalles varían según el entorno, pero aquí tienes un ejemplo aproximado de task definition para Fargate:

{
  "family": "sample-api",
  "networkMode": "awsvpc",
  "requiresCompatibilities": ["FARGATE"],
  "cpu": "256",
  "memory": "512",
  "executionRoleArn": "arn:aws:iam::123456789012:role/ecsTaskExecutionRole",
  "taskRoleArn": "arn:aws:iam::123456789012:role/app-task-role",
  "containerDefinitions": [
    {
      "name": "app",
      "image": "123456789012.dkr.ecr.ap-northeast-1.amazonaws.com/sample-api:latest",
      "portMappings": [{ "containerPort": 8080 }],
      "essential": true,
      "environment": [
        { "name": "APP_ENV", "value": "prod" }
      ],
      "logConfiguration": {
        "logDriver": "awslogs",
        "options": {
          "awslogs-group": "/ecs/sample-api",
          "awslogs-region": "ap-northeast-1",
          "awslogs-stream-prefix": "app"
        }
      }
    }
  ]
}

• Los permisos IAM de la aplicación se adjuntan mediante taskRoleArn.
• Los logs se envían a CloudWatch Logs.
• En el target group del ALB, configuras el puerto 8080.

A partir de esta task definition, creas un ECS service y le indicas algo como “mantén al menos dos tasks en ejecución”, y ECS se encargará de reemplazos en caso de fallo y durante el escalado.

6. Redes y seguridad: VPC, IAM, logging

6.1 VPC con ALB/NLB

ECS (especialmente Fargate) está diseñado con la suposición de que se ejecuta dentro de una VPC.

• Tráfico: ALB/NLB → servicio ECS (modo awsvpc)
• Los security groups controlan los flujos.
• Las tasks se colocan en subnets privadas, y el acceso desde internet llega a través de un ALB en subnets públicas.

En GKE, normalmente harías esto con clusters VPC-nativos y load balancers internos/externos; en AKS, con integración en VNet y Azure Load Balancer / Application Gateway. La idea central es muy similar entre nubes.

6.2 IAM Roles y Task Roles

• En ECS, puedes asignar un IAM role a cada task (task role).
• Por ejemplo, si una app solo necesita acceso de lectura a S3:
  • Creas un role con solo s3:GetObject y se lo asignas a la task.
  • No otorgas ese permiso a las instancias EC2 ni a otros recursos.
  • Esto implementa un diseño de mínimo privilegio donde “solo esta app puede leer de S3”.

En GCP, piensa en Workload Identity + service accounts; en Azure, en managed identities.

6.3 Logs y métricas

• Normalmente, los logs de la aplicación se envían a CloudWatch Logs.
• El uso de CPU y memoria se recopila automáticamente como métricas de CloudWatch y puede usarse para:
  • disparadores de autoescalado
  • alarmas
  • dashboards

En GKE, los equivalentes son Cloud Logging y Cloud Monitoring; en AKS, Log Analytics y Azure Monitor. En todas las nubes, el patrón es el mismo: enviar logs y métricas de contenedores a un servicio gestionado de monitorización.

7. CI/CD y estrategias de despliegue: ECR / CodePipeline vs GCP / Azure

7.1 Pipeline típico de despliegue en ECS

1. git push
2. El CI (GitHub Actions / CodeBuild, etc.) construye la imagen de contenedor
3. Se hace push de la imagen a Amazon ECR
4. Se llama a aws ecs update-service para cambiar la revisión de la task definition
5. El ECS service realiza un despliegue rolling (reemplazando tasks manteniendo la capacidad mínima)

Con AWS CodePipeline / CodeDeploy es relativamente sencillo configurar blue/green deployments y entregas canary.

7.2 En GCP / Azure

• GCP: Cloud Build construye → Artifact Registry → despliegue a GKE / Cloud Run. Con Cloud Deploy, puedes orquestar entregas progresivas a través de varios entornos.
• Azure: Azure DevOps / GitHub Actions → Azure Container Registry → despliegue a AKS / Container Apps.

En todos los casos, el patrón de fondo es el mismo: “push al registry → aplicar nueva versión en el orquestador”.

8. Costes y escalado: Fargate vs EC2 y diferencias con GKE/AKS

8.1 Trade-offs entre Fargate y EC2

• Fargate
  • Sin gestión de instancias.
  • Buena opción para un número pequeño de servicios, cargas impredecibles o entornos de desarrollo que quieres apagar por la noche.
• EC2
  • Gestionas tú mismo el tamaño, número y ciclo de vida de las instancias.
  • Para cargas de larga duración y gran escala, a menudo puedes optimizar costes de forma más agresiva con Reserved Instances o Savings Plans.

En GKE hay una división similar entre:

• Modo estándar + nodos autogestionados, y
• Modo Autopilot (más cercano a serverless)

AKS también ofrece nodos virtuales y opciones serverless. En cualquier nube, la cuestión central es dónde colocar el deslizador entre “facilidad de gestión de infra” y “coste por unidad”.

8.2 Estrategias de escalado

• ECS Service Auto Scaling
  • Ajusta automáticamente el número de tasks según uso de CPU/memoria, número de peticiones en ALB, longitud de colas SQS, etc.
• GKE / AKS
  • HPA (Horizontal Pod Autoscaler) y Cluster Autoscaler para ajustar el número de Pods y de nodos.
• App Runner / Cloud Run / Container Apps
  • Escalan de forma completamente serverless según el ritmo de peticiones, eventos o presión de CPU/memoria, a veces hasta cero cuando están inactivos.

Cuando eliges ECS, es importante diseñar qué tan fino quieres que sea el escalado a nivel de contenedor, para equilibrar coste y rendimiento.

9. ¿Quién se beneficia y cómo? – Por tipo de lector

9.1 Desarrolladores de aplicaciones (Web APIs / backend)

• Si ya construyes apps con Docker pero sientes que Kubernetes es demasiado pesado,
  ECS (Fargate) + ALB es muy accesible.
• Una vez que aprendas task definitions, podrás:
  • desplegar imágenes Docker existentes directamente en ECS, y
  • conectar rápidamente logging, métricas, escalado e integración con WAF.

9.2 SREs / Ingenieros de infraestructura

• En una organización centrada en AWS, puedes combinar:
  • ECS + Fargate / EC2
  • IAM / VPC / CloudWatch / X-Ray / WAF
    para construir una plantilla estándar de plataforma de aplicaciones en contenedores.
• Como opción que no te compromete completamente con Kubernetes, ECS ofrece una alternativa muy equilibrada.

9.3 Tech leads / Arquitectos

• Con el multi-cloud en mente, necesitas un “mapa interno de capas de orquestación” como:
  • AWS: ECS o EKS
  • GCP: GKE o Cloud Run
  • Azure: AKS o Container Apps
• Una vez que entiendes ECS como una pieza de ese mapa, es más sencillo comparar nubes con calma en términos de “¿a qué capa corresponde este servicio?”.

10. Checklist de diseño (qué dejar definido en las primeras 1–2 semanas)

1. Decidir qué capa usar
   • ¿ECS? ¿O subir un nivel a App Runner / Cloud Run / Container Apps?
2. Elegir el tipo de lanzamiento
   • ¿Cuál será el principal: Fargate / EC2 / Anywhere?
3. Diseño de clusters
   • ¿Separarás clusters por prod / staging / dev? ¿Cómo encaja esto con la separación de cuentas y VPC?
4. Diseño de task roles
   • Para cada app, ¿qué recursos de AWS necesita y qué acciones (p. ej. solo S3 GetObject, solo DynamoDB PutItem)?
5. Diseño de red y ALB/NLB
   • Uso de subnets públicas/privadas, si se expone o no a internet, integración con WAF.
6. Logs, métricas y tracing
   • Nombres y retención para grupos de CloudWatch Logs, alarmas de métricas, X-Ray u otras herramientas APM.
7. Estrategia de despliegue
   • ¿Rolling, blue/green o canary?
8. Políticas de escalado
   • ¿Basadas en CPU/memoria, o en métricas de negocio como longitud de cola o tasa de peticiones?
9. Seguridad y política de actualizaciones
   • Actualizaciones de la imagen base, análisis de vulnerabilidades, políticas de ciclo de vida en ECR.
10. Alineación con la estrategia multi-cloud futura
    • Si más adelante quieres pasar a un stack basado en Kubernetes, ¿qué partes migrarían de ECS a EKS/GKE/AKS aproximadamente?

11. Tres pasos que puedes empezar hoy

1. Elige una aplicación en contenedor existente
   • Selecciona una app pequeña y dibuja en papel “¿cómo sería ejecutarla en ECS (Fargate)?”
2. Escribe una task definition
   • Usando la consola o el CLI, crea una task definition que incluya una imagen de ECR, puerto, variables de entorno y la configuración de logging.
3. Construye tu propia tabla de correspondencias con GKE / AKS / Cloud Run / Container Apps
   • Haz tu propio mapeo, por ejemplo: “cluster de ECS ≒ cluster de GKE”, “task ≒ Pod”, “service ≒ Deployment + Service”, “Fargate ≒ algo parecido a GKE Autopilot”, etc.
     Esto hará que te confundas mucho menos al cambiar entre nubes.

12. Conclusión: ECS es el primer candidato para una “plataforma de contenedores AWS-nativa”

Como hemos visto, Amazon ECS es:

• Un orquestador totalmente gestionado, profundamente integrado con AWS, y
• A través de EC2 / Fargate / Anywhere, puede manejar:
  • IaaS tradicional,
  • contenedores serverless, y
  • cargas de trabajo híbridas / de edge
    bajo un único plano de control.

Mientras tanto, los mundos basados en Kubernetes como GKE / AKS / EKS y los mundos serverless como App Runner / Cloud Run / Container Apps también tienen sus propios puntos fuertes. Las preguntas importantes son:

• “¿Qué parte de las operaciones queremos asumir nosotros mismos?”
• “¿Qué grado de lock-in de proveedor estamos dispuestos a aceptar?”
• “¿En qué capa es más fuerte nuestro equipo?”

Si respondes a eso con honestidad y luego dibujas un “mapa de capas” que incluya ECS y el resto de servicios, estarás en mucha mejor posición para elegir con criterio.

Cuando pases a otros servicios de AWS, intenta preguntarte “¿a qué se parece esto en GCP? ¿en Azure?” mientras lees. Ese hábito fomentará una forma de pensar cross-cloud que funciona muy bien en la era multi-cloud.

Por ahora, tómate un momento para reconocer que has llegado hasta aquí. Quizá apetezca una taza de té mientras piensas tranquilamente: “Para nuestro equipo, ¿hasta qué peldaño de la escalera de abstracción queremos subir?” y reflexionas sobre dónde encajan ECS y el resto de servicios en esa imagen.

Referencias (solo títulos)

• What Is Amazon Elastic Container Service?
• Tipos de lanzamiento y capacity providers en Amazon ECS
  • Launch types / Capacity providers
• Descripción / página de producto de Google Kubernetes Engine
  • Overview / Product Page
• ¿Qué es Azure Kubernetes Service (AKS)? / Conceptos básicos
  • What Is AKS / Core concepts
• What Is AWS App Runner?
• Documentación / página de producto de Cloud Run
  • Documentation / Product Page
• Descripción general / documentación de Azure Container Apps
  • Overview / Docs hub

※ Para precios concretos, límites y las funciones más recientes, consulta siempre la documentación oficial y las páginas de precios de cada proveedor cloud.