CV
Cloud14 min read9 views

AWS ECS vs Azure Container Instances: Cuándo Usar Cada Uno (Guía Completa 2026)

Si estás evaluando dónde correr tus contenedores en la nube, probablemente te has cruzado con AWS ECS (Elastic Container Service) y Azure Container Instances (ACI). Aunque ambos ejecutan contenedores, resuelven problemas muy diferentes y están diseñados para cargas de trabajo distintas.

En este artículo vamos a compararlos a fondo: arquitectura, precios, casos de uso, y ejemplos reales de despliegue para que sepas cuál elegir según tu escenario.

Contenedores en la nube — comparativa de servicios cloud

Fuente: Growtika — Unsplash

¿Qué es AWS ECS?

Amazon Elastic Container Service (ECS) es un servicio de orquestación de contenedores completamente administrado. Piensa en él como un "director de orquesta" que gestiona dónde, cuándo y cómo se ejecutan tus contenedores dentro de la infraestructura de AWS.

ECS ofrece dos modos de ejecución:

  • EC2 Launch Type: Tú gestionas las instancias EC2 donde corren los contenedores. Mayor control, pero más responsabilidad operativa.
  • Fargate Launch Type: Serverless. AWS gestiona toda la infraestructura subyacente. Solo defines CPU, memoria y tu imagen Docker.

Conceptos clave de ECS

ConceptoDescripción
ClusterAgrupación lógica de recursos donde corren tus servicios
Task DefinitionPlantilla JSON que define la imagen, CPU, memoria, puertos, variables de entorno
TaskInstancia en ejecución de un Task Definition (equivale a un pod en K8s)
ServiceMantiene N réplicas de una Task corriendo, con balanceo de carga y auto-scaling

¿Qué es Azure Container Instances (ACI)?

Azure Container Instances es la forma más rápida y simple de ejecutar un contenedor en Azure. No hay orquestación, no hay clusters, no hay servidores — solo subes tu imagen y corre.

ACI está diseñado para contenedores efímeros o cargas de trabajo simples que no necesitan la complejidad de un orquestador. Es el equivalente a "serverless para contenedores" en su forma más pura.

Conceptos clave de ACI

ConceptoDescripción
Container GroupUno o más contenedores que comparten ciclo de vida, red y almacenamiento (similar a un Pod)
Restart PolicyAlways, OnFailure, o Never — controla el comportamiento tras el término del proceso
vCPU / MemoryHasta 4 vCPUs y 16 GB por container group

Sala de servidores — infraestructura cloud

Fuente: Taylor Vick — Unsplash

Comparativa directa: ECS vs ACI

Esta es la tabla que necesitas para tomar una decisión rápida:

CaracterísticaAWS ECS (Fargate)Azure Container Instances
Tipo de servicioOrquestador de contenedoresEjecución directa de contenedores
ModeloServicios con réplicas, rolling updates, auto-scalingContainer groups efímeros o long-running
OrquestaciónSí (built-in)No (se integra con Azure Container Apps para eso)
Auto-scalingSí (Application Auto Scaling)No nativo (requiere Logic Apps o scripts externos)
Load BalancerIntegrado con ALB/NLBSolo IP pública o privada por container group
NetworkingVPC nativo, security groups, service discoveryVNet injection disponible, pero limitado
Máx. recursos16 vCPUs, 120 GB RAM por task4 vCPUs, 16 GB RAM por container group
Persistent storageEFS, EBSAzure Files (SMB mount)
GPU supportSí (con EC2 launch type)Sí (NVIDIA T4, V100)
Tiempo de arranque30-60 segundos5-30 segundos
Ideal paraMicroservicios en producción, APIs, workersBatch jobs, CI/CD tasks, dev/test, sidecars
ℹ️ Nota importante: La contraparte más directa de ECS en Azure no es ACI sino Azure Container Apps (construido sobre ACI + Kubernetes). ACI es más comparable a ECS + Fargate para tareas individuales (run-task), no para servicios con réplicas.

Precios: ¿Cuánto cuesta cada uno?

Ambos servicios cobran por recursos consumidos (vCPU y memoria), pero la estructura difiere significativamente.

Análisis de costos cloud

Fuente: Towfiqu barbhuiya — Unsplash

AWS ECS con Fargate (US East — N. Virginia)

RecursoPrecio por horaPrecio mensual (24/7)
vCPU$0.04048~$29.15
GB de memoria$0.004445~$3.20
Ephemeral storage (por GB adicional)$0.000111~$0.08

Ejemplo: Un task con 1 vCPU + 2 GB RAM corriendo 24/7 → ~$35.55/mes

Azure Container Instances (East US — Linux)

RecursoPrecio por horaPrecio mensual (24/7)
vCPU$0.0456~$32.81
GB de memoria$0.0050~$3.60

Ejemplo: Un container group con 1 vCPU + 2 GB RAM corriendo 24/7 → ~$40.01/mes

Resumen de costos

Escenario (1 vCPU + 2 GB, 24/7)AWS ECS FargateAzure ACIDiferencia
Costo mensual$35.55$40.01AWS es ~12% más barato
Con Savings Plan (1 año)~$22.50~$32.00AWS es ~30% más barato
Spot/Low-priority~$10.65 (Fargate Spot)~$16.00 (Spot containers)AWS es ~33% más barato
💡 Tip: Si usas ARM/Graviton2 en Fargate, obtienes ~20% de descuento adicional con rendimiento equivalente. Azure ACI no ofrece opción ARM por ahora.

Despliegue en AWS ECS con Fargate

Veamos cómo se ve un despliegue real de un microservicio en ECS usando AWS CLI y un Task Definition.

Task Definition (JSON)

json
1{
2  "family": "mi-api",
3  "networkMode": "awsvpc",
4  "requiresCompatibilities": ["FARGATE"],
5  "cpu": "512",
6  "memory": "1024",
7  "executionRoleArn": "arn:aws:iam::123456789:role/ecsTaskExecutionRole",
8  "containerDefinitions": [
9    {
10      "name": "api",
11      "image": "123456789.dkr.ecr.us-east-1.amazonaws.com/mi-api:latest",
12      "portMappings": [
13        {
14          "containerPort": 8080,
15          "protocol": "tcp"
16        }
17      ],
18      "environment": [
19        { "name": "SPRING_PROFILES_ACTIVE", "value": "prod" },
20        { "name": "DB_HOST", "value": "mi-rds.cluster-xxx.us-east-1.rds.amazonaws.com" }
21      ],
22      "logConfiguration": {
23        "logDriver": "awslogs",
24        "options": {
25          "awslogs-group": "/ecs/mi-api",
26          "awslogs-region": "us-east-1",
27          "awslogs-stream-prefix": "ecs"
28        }
29      }
30    }
31  ]
32}

Crear el servicio

bash
1# Registrar task definition
2aws ecs register-task-definition --cli-input-json file://task-def.json
3
4# Crear servicio con 3 réplicas y balanceo de carga
5aws ecs create-service \
6  --cluster mi-cluster \
7  --service-name mi-api-service \
8  --task-definition mi-api \
9  --desired-count 3 \
10  --launch-type FARGATE \
11  --network-configuration "awsvpcConfiguration={subnets=[subnet-abc123],securityGroups=[sg-abc123],assignPublicIp=ENABLED}" \
12  --load-balancers "targetGroupArn=arn:aws:elasticloadbalancing:us-east-1:123456789:targetgroup/mi-api-tg/abc123,containerName=api,containerPort=8080"

Código de configuración Docker

Fuente: Ian Taylor — Unsplash

Despliegue en Azure Container Instances

ACI es considerablemente más simple. Un solo comando puede tener tu contenedor corriendo.

Despliegue rápido con CLI

bash
1# Crear un container group con una API Spring Boot
2az container create \
3  --resource-group mi-rg \
4  --name mi-api \
5  --image miregistro.azurecr.io/mi-api:latest \
6  --cpu 1 \
7  --memory 2 \
8  --ports 8080 \
9  --ip-address Public \
10  --registry-login-server miregistro.azurecr.io \
11  --registry-username miregistro \
12  --registry-password $ACR_PASSWORD \
13  --environment-variables \
14    SPRING_PROFILES_ACTIVE=prod \
15    DB_HOST=mi-db.postgres.database.azure.com \
16  --restart-policy Always
17
18# Verificar estado
19az container show --resource-group mi-rg --name mi-api --query "{Status:instanceView.state,IP:ipAddress.ip,FQDN:ipAddress.fqdn}" --output table

Despliegue con YAML (múltiples contenedores)

yaml
1apiVersion: "2021-09-01"
2name: mi-api-group
3location: eastus
4properties:
5  osType: Linux
6  restartPolicy: Always
7  ipAddress:
8    type: Public
9    ports:
10      - protocol: TCP
11        port: 8080
12  containers:
13    - name: api
14      properties:
15        image: miregistro.azurecr.io/mi-api:latest
16        resources:
17          requests:
18            cpu: 1
19            memoryInGb: 2
20        ports:
21          - port: 8080
22        environmentVariables:
23          - name: SPRING_PROFILES_ACTIVE
24            value: prod
25          - name: DB_PASSWORD
26            secureValue: "mi-password-secreto"
27    - name: sidecar-logger
28      properties:
29        image: fluent/fluentd:v1.17
30        resources:
31          requests:
32            cpu: 0.5
33            memoryInGb: 0.5
bash
1# Desplegar desde el YAML
2az container create --resource-group mi-rg --file deploy-aci.yaml

¿Cuándo usar cada uno?

Usa AWS ECS (Fargate) cuando:

  • Necesitas microservicios en producción con auto-scaling, rolling updates y health checks
  • Requieres balanceo de carga con ALB/NLB para distribuir tráfico entre réplicas
  • Tu aplicación necesita alta disponibilidad con despliegue multi-AZ automático
  • Tienes workflows CI/CD maduros que necesitan blue/green deployments o canary releases
  • El costo a largo plazo importa — Fargate con Savings Plans + Graviton2 es significativamente más barato
  • Necesitas más de 4 vCPUs o 16 GB RAM por tarea

Usa Azure Container Instances cuando:

  • Necesitas ejecutar un contenedor rápido sin configurar infraestructura (dev, testing, demos)
  • Batch processing: tareas que corren, procesan datos y terminan
  • CI/CD runners: agentes de build que se crean y destruyen por pipeline
  • Sidecars y complementos: contenedores auxiliares que acompañan a servicios principales
  • Event-driven workloads: disparados por Azure Functions o Logic Apps
  • Arranque ultra-rápido importa: ACI inicia en 5-30 segundos vs 30-60 de Fargate

Arquitectura cloud — vista global de infraestructura

Fuente: NASA — Unsplash

Patrones de arquitectura recomendados

Patrón 1: API REST en producción → ECS Fargate

bash
1# Estructura típica
2Internet → ALB → ECS Service (3 réplicas) → RDS/DynamoDB
34              Auto Scaling (CPU > 70%)
5              Blue/Green Deploy via CodeDeploy

Para una API Spring Boot o Node.js que recibe tráfico constante, ECS con Fargate te da réplicas, health checks automáticos, y deploys sin downtime.

Patrón 2: Procesamiento batch nocturno → ACI

bash
1# Flujo típico
2Azure Function (timer: 0 2 * * *) → Crea ACI → Procesa datos → Termina → Se destruye
34                                              Azure Blob Storage

Para un job que procesa CSVs o genera reportes cada noche, ACI es perfecto: se crea, ejecuta, y se destruye. Solo pagas los minutos que corrió.

Patrón 3: Microservicios con orquestación en Azure → Container Apps (no ACI solo)

bash
1# Si necesitas el equivalente a ECS en Azure:
2Internet → Azure Container Apps (basado en ACI + KEDA + Envoy)
34         Auto-scaling, Revisions, Dapr integration, Ingress built-in
⚠️ Error común: Usar ACI solo para microservicios en producción. ACI no tiene auto-scaling, service discovery, ni rolling updates nativos. Si necesitas eso en Azure, usa Azure Container Apps o AKS.

Terraform: Infraestructura como código para ambos

Si gestionas infraestructura con Terraform, así se ven ambos servicios:

ECS Fargate con Terraform

bash
1resource "aws_ecs_service" "api" {
2  name            = "mi-api"
3  cluster         = aws_ecs_cluster.main.id
4  task_definition = aws_ecs_task_definition.api.arn
5  desired_count   = 3
6  launch_type     = "FARGATE"
7
8  network_configuration {
9    subnets          = var.private_subnets
10    security_groups  = [aws_security_group.ecs.id]
11    assign_public_ip = false
12  }
13
14  load_balancer {
15    target_group_arn = aws_lb_target_group.api.arn
16    container_name   = "api"
17    container_port   = 8080
18  }
19
20  deployment_controller {
21    type = "CODE_DEPLOY" # Blue/Green
22  }
23}

ACI con Terraform

bash
1resource "azurerm_container_group" "api" {
2  name                = "mi-api"
3  location            = azurerm_resource_group.main.location
4  resource_group_name = azurerm_resource_group.main.name
5  os_type             = "Linux"
6  restart_policy      = "Always"
7  ip_address_type     = "Public"
8
9  container {
10    name   = "api"
11    image  = "miregistro.azurecr.io/mi-api:latest"
12    cpu    = 1
13    memory = 2
14
15    ports {
16      port     = 8080
17      protocol = "TCP"
18    }
19
20    environment_variables = {
21      SPRING_PROFILES_ACTIVE = "prod"
22    }
23  }
24
25  image_registry_credential {
26    server   = "miregistro.azurecr.io"
27    username = var.acr_username
28    password = var.acr_password
29  }
30}

Veredicto final

EscenarioGanadorPor qué
Microservicios en producciónAWS ECSOrquestación completa, auto-scaling, blue/green deploys
Batch jobs / tareas efímerasAzure ACIArranque en segundos, sin infraestructura, pay-per-second
Costo a largo plazoAWS ECSSavings Plans + Graviton2 = hasta 50% más barato
Time-to-deploy más rápidoAzure ACIUn solo comando, sin clusters ni task definitions
Multi-container podsEmpateAmbos soportan sidecars en el mismo grupo/task
Integración con ecosistemaDependeECS con AWS nativo; ACI con Azure Functions, Logic Apps
GPU / ML workloadsAzure ACISoporte GPU más accesible sin gestionar EC2
💡 Regla de oro: Si necesitas que tu contenedor "viva" 24/7 con réplicas, scaling y balanceo → ECS. Si necesitas que tu contenedor "haga algo y muera" → ACI. Si necesitas el equivalente completo de ECS en Azure → usa Azure Container Apps, no ACI solo.

Conclusión

AWS ECS y Azure Container Instances no son competidores directos — son herramientas para problemas diferentes. ECS es un orquestador completo para cargas de trabajo de producción; ACI es una forma rápida y ligera de ejecutar contenedores sin infraestructura.

La verdadera comparación debería ser ECS vs Azure Container Apps para microservicios, y ECS run-task vs ACI para tareas efímeras. Conocer esta distinción te ahorrará horas de frustración y cientos de dólares en costos mal dimensionados.

¿Ya usas alguno de estos servicios? Cuéntanos tu experiencia en los comentarios.

Share:
CV

Cristhian Villegas

Software Engineer specializing in Java, Spring Boot, Angular & AWS. Building scalable distributed systems with clean architecture.

Comments

Sign in to leave a comment

No comments yet. Be the first!

Related Articles