AWS ECS vs Kubernetes vs auto-hospedado: tres caminos para correr contenedores en 2026

AWS hoy vende, como mínimo, cuatro productos diferentes para correr contenedor en producción: ECS (con EC2 o con Fargate), EKS, App Runner y Lightsail Containers. No es redundancia de catálogo ni confusión interna — es respuesta directa al mercado. Cada uno cubre una franja distinta de quien está llegando a AWS con la misma pregunta básica: cómo subir un contenedor, mantenerlo vivo, exponerlo a internet, actualizarlo sin que se caiga, y dormir tranquilo.

ECS es la apuesta de AWS para quien no quiere Kubernetes. No es "Kubernetes más simple", es una alternativa propietaria a Kubernetes, escrita por los ingenieros de Amazon antes de que K8s se volviera consenso. EKS es Kubernetes gestionado, mismo de la estantería que GKE y AKS. Auto-hospedado es la salida de AWS entera — corres en cualquier servidor Linux, pagas solo el servidor, y te llevas tus contenedores contigo si el proveedor cambia de humor.

Los tres caminos resuelven el mismo problema con tradeoffs muy diferentes. Este post pone lado a lado lo que cada uno cobra, lo que cada uno amarra, y en qué contexto cada uno tiene sentido — sin fingir que existe un ganador uniforme.

AWS ECS: qué es exactamente

ECS es el orquestador propietario de Amazon. No es open-source, no corre fuera de AWS, no tiene implementación alternativa. Fue anunciado en 2014, antes de que Kubernetes ganara tracción, y desde entonces AWS invierte en él como la puerta de entrada "AWS-nativa, sin K8s" al mundo de contenedores.

El modelo conceptual es propio:

• Task definition en lugar de Pod. Es un archivo JSON describiendo el contenedor, recursos, puertos, variables de entorno, IAM role.
• Service en lugar de Deployment. Mantiene N tasks corriendo, hace health check, integra con Application Load Balancer.
• Cluster es solo un agrupamiento lógico — sin plano de control pagado. El control plane es gratuito (AWS lo gestiona internamente, no lo ves ni lo mantienes).
• Capacity provider define dónde las tasks corren: EC2 (gestionas instancias) o Fargate (serverless por vCPU/RAM/segundo).

La integración con el resto de AWS es el punto fuerte real. Task toma IAM role directo, sin sidecar de auth. Logs van a CloudWatch sin agente. Imágenes vienen de ECR sin configurar pull secret. ALB enruta tráfico a las tasks con service discovery automático. Todo eso con consola gráfica decente, CLI estable, y SDK en todos los lenguajes.

Comparado a K8s, ECS es deliberadamente simple. No tiene CRDs, no tiene operators, no tiene Helm charts, no tiene sidecar pattern formalizado, no tiene control de admisión. Tienes task, service, cluster — y se acabó. Para un equipo ya inmerso en AWS, esa simplicidad es el argumento.

AWS ECS: dónde duele

El lock-in es absoluto, y vale la pena nombrar eso primero. Task definition no corre fuera de AWS. ECR no es registry portable (hasta puedes tirar, pero la IAM amarra de vuelta). ALB es AWS-only. Service discovery vía Cloud Map es AWS-only. CloudWatch es AWS-only. No estás adoptando "una forma de correr contenedores" — estás adoptando una stack entera que solo existe ahí dentro. Migrar hacia afuera exige reescribir cada pieza.

El coste aparece en capas que nadie suma en la primera evaluación:

Fargate: US$0.04 por vCPU-hora + US$0.0044 por GB-hora. Una app modesta con 0.5 vCPU + 1 GB, corriendo 24×7, cuesta US$25/mes. Parece poco hasta que recuerdas que cada microservicio es una task, y que la producción típica tiene 8 a 15 microservicios + tasks de cola + cron jobs. Cinco aplicaciones pequeñas se vuelven tranquilo US$120 solo de Fargate.

CloudWatch Logs: US$0.50 por GB ingerido + US$0.03 por GB almacenado por mes. Una app que loga 5 GB/mes deja US$2.65. Multiplicado por diez servicios, US$26/mes solo de log. Y es la opción "barata" — si activas Insights para hacer queries serias, dobla.

Egress: US$0.09 por GB después de los primeros 100 GB gratis. Una app sirviendo 500 GB de tráfico de salida por mes paga US$36. Streaming de vídeo, descargas de imagen, API pública pesada: el egress se vuelve el item mayor de la factura, frecuentemente pasando del compute.

Red: VPC es gratuita, pero NAT Gateway cuesta US$0.045/hora — US$32/mes fijo — solo para existir, más US$0.045 por GB procesado. Necesitas NAT para cualquier task en subnet privada que llame internet (actualizar paquete, hablar con API externa, mandar email vía SES). En producción con alta disponibilidad, la recomendación es NAT en dos zonas — dos NAT Gateways, US$64/mes baseline antes de cualquier tráfico.

Application Load Balancer: US$0.0225/hora (US$16/mes fijo) + US$0.008 por LCU-hora. Para una app con tráfico moderado, US$25/mes es realista.

Suma realista para una operación pequeña con cinco apps en Fargate, ALB compartido, NAT en una zona sola, logs moderados: US$200 a US$300/mes. Crece linear con el número de tasks. No es caro para los estándares enterprise, pero es múltiplas veces el coste equivalente en VPS dedicado.

AWS ECS: quién lo usa y ama con razón

Existe un perfil claro para quien ECS es la respuesta correcta, y lo recomendamos sin reservas para esos casos:

• Empresa que ya es 100% AWS, con equipo entrenado en la consola y en las IAM policies. Añadir ECS es incremental — no requiere aprender herramienta nueva fuera de la burbuja.
• Workloads de burst, scheduled jobs, ETLs nocturnos. Fargate brilla cuando quieres 50 tasks corriendo por 12 minutos al día y cero el resto del tiempo. Pagar por segundo es honesto.
• Cumplimiento que exige AWS específica (FedRAMP High, contratos federales americanos, ciertas configuraciones HIPAA con BAA AWS). Cuando la auditoría pide AWS, ECS te entrega el camino más corto sin instalar K8s encima.
• Equipo que prioriza zero-ops sobre coste y portabilidad. Si no tienes a nadie para mantener una instancia EC2, Fargate es genuinamente menos trabajo — nunca ves una máquina, nunca parcheas kernel, nunca apareces para hablar de saturación de disco.

Kubernetes: qué es exactamente

La audiencia conoce K8s, así que el resumen aquí es corto. Estándar de hecho para orquestación desde alrededor de 2018, con ecosistema CNCF gigante (cert-manager, ingress controllers, operators para prácticamente cualquier base). API consistente entre clouds, lo que vuelve multi-cloud genuinamente viable (caro, pero viable). Curva de aprendizaje bien documentada — 300+ líneas de manifiesto para colocar un hello world con TLS al aire.

Modelos de operación:

• Gestionado (EKS, GKE, AKS): proveedor mantiene el plano de control. Cobra cerca de US$73/mes por cluster en las tres grandes. Más NAT, ALB, observabilidad, registry. Equipo típico mínimo: 2 SREs.
• Self-managed con k3s, kubeadm, kops, Rancher: instalas en VMs o bare metal. Sin coste de plano de control, pero te vuelves el equipo de plataforma. Equipo mínimo: 1 SRE muy bueno o 2 medianos.

Kubernetes: dónde duele

Ya cubrimos a fondo en Kubernetes es overkill: cuando no lo necesitas. Resumen directo:

• Coste operacional: 1 a 2 SREs dedicados, US$5-8k/mes cada uno. Ese es el item mayor de la cuenta — multiplica por doce meses y el cluster pasó la casa de US$100k/año solo en personas.
• Curva: 6+ meses para un equipo productivo de hecho (no "entrega manifiesto", y sí "depura problema a las tres de la mañana sin destruir producción").
• Stack alrededor: cert-manager, ingress controller, operador de métricas, agente de logs, malla de servicios si la hay — cada uno con versión propia, política de actualización propia, modelo de fallo propio.
• Manifiestos largos: "hello world" con namespace + deployment + service + ingress + cert + RBAC queda en 300 líneas. Helm reduce duplicación pero añade una capa conceptual.

Kubernetes: quién lo usa y lo justifica

Los perfiles en que K8s es la elección obvia, sin ironía:

• Empresa Series B+ con equipo de plataforma de 3 o más personas dedicadas. La escala humana sostiene la complejidad.
• Multi-cloud o neutralidad de proveedor como requisito real (no como aspiración de slide). Vas efectivamente a correr en dos clouds, y K8s es la única abstracción madura que cubre las dos.
• Workloads que dependen de operadores específicos maduros: operador de Postgres con replicación, operador de Kafka con balanceo, operador de Cassandra con bootstrap. Reescribir eso "a mano" cuesta más que el cluster.
• Cumplimiento nominal — algunos frameworks listan Kubernetes por nombre en controles. Si tu auditor necesita apuntar a un certificado SOC2 que dice "Kubernetes 1.28", la herramienta tiene que llamarse Kubernetes.
• Operación por encima de 50 servidores en producción sostenida. En ese tamaño, el ecosistema CNCF te da herramientas que tendrías que construir desde cero en alternativas menores.

Auto-hospedado moderno

La tercera opción es lo que cambió en los últimos dos años. Auto-hospedado dejó de ser "Docker Compose en un servidor con suerte" y se volvió una categoría con productos serios — HeroCtl es uno de ellos, pero Coolify, Dokploy, Caprover y otros también ocupan el espacio.

La propuesta común:

• Un binario (o imagen Docker simple) instalado en N servidores Linux con Docker.
• Plano de control replicado, con elección automática de coordinador. Pierdes un servidor, el cluster sigue.
• Router embebido, certificados Let's Encrypt automáticos.
• Sin dependencia de proveedor cloud — corre en cualquier VPS, cualquier bare metal, cualquier mezcla.
• Modelo comercial honesto: Community gratuito permanente sin feature gate artificial, Business pagado publicado para quien necesita SSO/auditoría/SLA, Enterprise para contratos con escrow y soporte 24×7.

El coste se reduce a dos líneas: las VPS y el tiempo del dev part-time que cuida de eso. Tres droplets de US$24/mes cada uno en DigitalOcean — US$72/mes — sostienen una operación que en ECS quedaría entre US$300 y US$600.

Auto-hospedado: dónde duele

Honestidad vale más que folleto. Donde auto-hospedado no es la respuesta:

• Eres responsable de todo. Sin soporte AWS para llamar cuando se complique. Comunidad activa ayuda, y el soporte pagado Business existe — pero la primera línea de defensa eres tú leyendo el log.
• Franja de escala saludable: 1 a 500 servidores. Por encima de eso, herramental específico de Kubernetes aún gana. No es defecto del producto — es donde la CNCF gastó diez años puliendo cosas que nadie más tiene.
• Cumplimiento enterprise específico. Si tu auditor necesita que el orquestador aparezca en una lista pre-aprobada de proveedores, y esa lista lista AWS/Azure/GCP/K8s, auto-hospedado nuevo te excluye por defecto.
• Integraciones nativas AWS: Cognito como auth, S3 con IAM directo en la task, RDS con IAM auth — todo eso se puede adaptar, pero la adaptación es trabajo extra. En ECS funciona sin pensar.

Lado a lado: doce criterios sin matiz

La tabla abajo es la versión honesta de la decisión.

La columna que importa varía por contexto, y es exactamente ese el punto: no existe ganador uniforme.

Decisión por contexto

Traducción práctica de las tablas en recomendación directa. Si tu escenario cae en uno de esos cinco, la respuesta es la indicada — sin floritura.

"Ya estamos en AWS, equipo pequeño, contratos exigen AWS." ECS Fargate. El lock-in ya es hecho consumado, y Fargate elimina el trabajo de gestionar instancia. Cambias coste previsible por zero-ops, que es el tradeoff correcto cuando el equipo tiene pocos brazos y no puede parar para parchear kernel.

"Multi-cloud strategy o cumplimiento exige neutralidad entre proveedores." Kubernetes. Si el equipo es fuerte, k3s self-managed en VMs reduce drásticamente el coste del plano de control. Si el equipo es mediano, EKS gestionado en una cloud principal y equivalente en la otra. No pagues el coste de K8s sin el requisito real — el requisito real existe y la herramienta encaja.

"Startup early stage, costes duelen, equipo no es especialista AWS." Auto-hospedado. HeroCtl, Coolify, Dokploy — el segmento maduró. Tres droplets, un dev part-time, US$80/mes de infra, y te quedas con la operación entera bajo control. Cuando el producto gane tracción y la empresa quede grande, se puede reevaluar — pero llegar hasta ahí costando US$80/mes es la diferencia entre cerrar runway y no cerrar.

"Big enterprise, cumplimiento lista K8s nominalmente, equipo de plataforma con 5+ personas." EKS gestionado. El coste del plano de control desaparece en el presupuesto, el equipo absorbe la complejidad, y la auditoría queda satisfecha. Ese es el caso canónico de K8s — no intentes ahorrar aquí.

"Solo dev experimentando, side project, MVP." Render o Railway en la nube hospedada (paga solo lo que usa, cero ops), o Coolify en un VPS de US$5. No montes cluster para un proyecto que puede morir en tres meses. Cuando pase de US$1k MRR y quede claro que va a sobrevivir, migra a HeroCtl o Dokploy en un cluster de tres VPS.

Migrar de ECS al auto-hospedado: camino práctico

Para quien ya está en ECS y quiere reducir cuenta, el mapeo conceptual es más simple de lo que parece. Las primitivas baten casi uno-a-uno:

Camino práctico para una app simple:

1. Levanta tres VPS Linux con Docker. Instala el orquestador en uno de los tres (curl -sSL get.heroctl.com/install.sh | sh). Los otros dos entran como agentes — comando único para cada uno.
2. Toma la task definition en JSON. Mapea: contenedor, recursos, puertos, variables de entorno, secretos. Se vuelve un archivo de configuración de ~50 líneas.
3. Envía vía CLI. El cluster decide dónde correr, abre puerto, registra en el router, emite certificado Let's Encrypt, empieza a servir.
4. Apunta el DNS del dominio al IP del servidor coordinador (o a un Load Balancer DNS-based si tiene más de una región).
5. Prueba en staging por una semana. Si está ok, repite para producción y descomisiona ECS.

Tiempo medio por app simple: 1 a 3 horas, incluyendo el test. Apps con dependencia fuerte de IAM/Cognito/SQS toman más — necesitas adaptar la llamada AWS para que vaya vía SDK + clave (en lugar de IAM role implícito). Apps stateless de HTTP son casi mecánicas.

Ahorro anual típico en scale-up modesto (15 microservicios, 1 ALB, NAT en una zona, logs moderados): US$10.000 a US$30.000 que salen de la factura AWS y se vuelven salario o marketing. El componente humano también cambia — dejas de necesitar un especialista AWS dedicado.

Preguntas que aparecen

¿Puedo usar ECS Fargate sin ALB para ahorrar? Técnicamente sí, exponiendo la task con IP público — pero pierdes TLS automático, balanceo de carga, health check en capa 7, y service discovery. Para producción real eso no es un ahorro, es deuda. Vale solo para workloads internos sin ingress (jobs de cola, ETLs).

¿EKS Anywhere es viable fuera de AWS? Existe y funciona, pero el coste de licencia es caro y la integración con el ecosistema AWS es parcial — ganas el nombre "EKS" sin ganar la integración nativa. Para correr K8s fuera de AWS, k3s o kubeadm tienen mejor relación coste/beneficio en la práctica.

¿Migrar de ECS a auto-hospedado, cuánto tarda en lo realista? Apps simples: 1-3 horas cada una. Operación entera con 10-15 servicios: 2 a 4 semanas si lo vas a hacer con cuidado, con tests en staging. El cuello de botella suele ser las dependencias de servicios AWS-específicos (SQS, SNS, Cognito), no el orquestador en sí.

¿Mantener los dos (ECS + auto-hospedado en paralelo) tiene sentido? Tiene, durante la migración y a veces permanente. Workloads que dependen fuertemente de IAM nativo (acceso directo a S3 sin claves, por ejemplo) pueden quedarse en ECS. El resto va al cluster auto-hospedado. Enrutamiento por DNS resuelve la división de tráfico.

¿Cumplimiento que exige AWS, puedo usar HeroCtl en EC2? Puedes. HeroCtl corre en cualquier VPS Linux con Docker — incluyendo instancias EC2. Pierdes la ventaja de portabilidad total, pero mantienes el modelo operacional simple y el coste previsible. Es una buena opción para equipos que necesitan quedarse dentro de AWS por contrato pero quieren huir de la complejidad nativa.

¿ECS App Runner es alternativa buena? App Runner es la oferta de AWS para "Heroku encima de ECS". Funciona para apps muy simples (una imagen, un puerto, build automático del Git). Cobra más que Fargate equivalente y tiene menos control. Para MVP de fin de semana, es razonable. Para producción seria, ECS directo con Fargate da más flexibilidad por el mismo dinero.

¿GKE Autopilot vs Fargate vs HeroCtl? GKE Autopilot y Fargate ocupan el mismo nicho conceptual: serverless por pod/task, no ves el nodo. GKE Autopilot es generalmente más barato para workloads estables, y más caro para burst. Ambos tienen lock-in fuerte. HeroCtl ataca el problema por otro lado — ves el servidor a propósito, lo pagas entero, y el orquestador distribuye las cargas. Para workload estable de larga duración, sale más barato. Para workload de burst extremo, serverless gana.

Cierre

No existe un camino que gane en los doce criterios de la tabla. ECS gana en integración AWS, pierde en portabilidad. Kubernetes gana en ecosistema, pierde en simplicidad. Auto-hospedado gana en coste y claridad, pierde en herramental específico de escala extrema.

La elección correcta depende de tu equipo, de tu cumplimiento, de tus contratos, y de la etapa de la empresa. La elección equivocada es no hacer la cuenta — adoptar ECS porque "es el estándar AWS" sin sumar Fargate + ALB + NAT + CloudWatch + egress; adoptar Kubernetes porque "es lo que está de moda" sin tener los 2 SREs; o quedarse en auto-hospedado casero frágil cuando la operación ya pasó de 50 servidores y el ecosistema CNCF pasó a justificar.

Si estás revisando la stack de orquestación de contenedores en 2026, la recomendación práctica es simple: mide el coste real de los doce meses anteriores, identifica en cuál de los cinco perfiles tu equipo encaja, y decide. Si el perfil es "startup early, equipo pequeño, coste duele", el camino de menor riesgo es experimentar auto-hospedado en paralelo durante un mes, antes de migrar.

Para empezar:

curl -sSL get.heroctl.com/install.sh | sh

Tres VPS Linux, diez minutos por servidor, y tienes cluster con plano de control replicado, router integrado, certificados automáticos. A partir de ahí, es cuestión de mover servicio por servicio de la factura AWS al cluster propio.

Lecturas relacionadas: Kubernetes es overkill: cuando no lo necesitas explica con más detalle cuándo el coloso no encaja; k3s vs HeroCtl: cuándo cada uno tiene sentido compara las dos alternativas livianas dentro de la categoría auto-hospedado.

Orquestación de contenedores es una decisión de largo plazo. Hazla por la cuenta correcta, no por la inercia.