Elegir dónde correr el código en AWS debería ser una decisión de arquitectura, pero en la práctica muchos equipos la resuelven por costumbre: “usamos lo mismo que en el proyecto anterior”. El problema es que EKS, ECS y Lambda resuelven problemas distintos, y elegir el que no corresponde se paga después en operación, en costo o en velocidad de entrega.
Esta guía compara las tres opciones de cómputo de AWS con criterios de decisión pensados para CTO y gerentes de tecnología, no solo para el equipo de infraestructura.
Las tres opciones en una frase
- AWS Lambda: cómputo serverless por eventos. Subes código, AWS lo ejecuta cuando algo sucede y cobra solo por el tiempo que corre. Sin servidores ni clústeres que administrar.
- Amazon ECS (Elastic Container Service): el orquestador de contenedores propio de AWS. Corre tus contenedores Docker como servicios de larga duración, con integración nativa al resto de AWS y menos piezas que configurar que Kubernetes.
- Amazon EKS (Elastic Kubernetes Service): Kubernetes administrado por AWS. Mismo motor de orquestación que usarías en cualquier nube o centro de datos propio, con el plano de control operado por AWS.
Los tres pueden correr con o sin servidores que administres directamente: Lambda siempre es serverless; ECS y EKS pueden operarse con instancias EC2 propias o con AWS Fargate, que elimina la gestión de servidores mientras conservas el modelo de contenedores.
Los criterios que realmente deciden
1. Tipo de carga de trabajo
Lambda encaja con procesos cortos y disparados por eventos: una API que responde en milisegundos, un archivo que llega y se procesa, una integración entre sistemas. Cada invocación de Lambda tiene un límite de 15 minutos de ejecución. ECS y EKS están hechos para servicios de larga duración —una API que atiende tráfico constante, un proceso con estado en memoria, un worker que corre de forma sostenida—, donde mantener el contenedor corriendo es más eficiente que reiniciar cómputo en cada evento.
2. Expertise del equipo
Este es el criterio que más se subestima. Kubernetes tiene una curva de aprendizaje real: conceptos como pods, deployments, services, ingress y namespaces no son intuitivos para un equipo que recién empieza. ECS usa el modelo mental de AWS —definiciones de tarea, servicios, clústeres— con menos conceptos nuevos que aprender. Si tu equipo ya opera Kubernetes en otro entorno (on-premise, otra nube), EKS aprovecha ese conocimiento. Si no, ECS suele ser más rápido de poner en producción con buenos resultados.
3. Portabilidad y lock-in operativo
Una aplicación en Kubernetes (EKS) usa APIs y manifiestos estándar que —con matices— funcionan igual en Google Cloud, Azure o un clúster propio. Eso importa si tu estrategia contempla multi-nube, si vienes de un entorno híbrido, o si la portabilidad es un requisito de negocio. ECS y Lambda son servicios propios de AWS: no hay problema si tu estrategia es “AWS como nube principal”, pero migrar esas cargas a otra nube implica más rediseño.
4. Control fino del entorno de ejecución
Lambda administra el entorno de ejecución por ti, con las limitaciones que eso implica (tiempo máximo, memoria configurable dentro de rangos, runtimes soportados). Los contenedores en ECS o EKS —sobre todo con instancias EC2 propias en vez de Fargate— dan control total sobre el sistema operativo, las librerías instaladas y el hardware (GPUs específicas, por ejemplo), algo relevante para cargas de cómputo intensivo o requisitos de compliance muy particulares.
5. Costo y modelo operativo (a alto nivel, sin tarifas)
Lambda cobra por invocación y tiempo de ejecución: sin tráfico, no hay costo de cómputo. Es eficiente para cargas intermitentes y caro relativo si un proceso corre de forma casi constante —ahí un contenedor corriendo sin pausa suele salir más eficiente—. ECS y EKS con Fargate cobran por los recursos de cómputo reservados mientras el contenedor corre, sin importar cuánto tráfico atienda; con EC2 propio, el costo depende de las instancias que mantengas encendidas. La forma correcta de comparar no es “cuál es más barato” en abstracto, sino modelar el patrón de tráfico real de cada carga.
Comparativa directa
| Criterio | AWS Lambda | Amazon ECS | Amazon EKS |
|---|---|---|---|
| Modelo | Serverless, por eventos | Contenedores administrados por AWS | Kubernetes administrado |
| Duración típica de la carga | Segundos a 15 minutos máx. | Servicios de larga duración | Servicios de larga duración |
| Curva de aprendizaje | Baja | Media | Alta |
| Portabilidad multi-nube | Baja (servicio propio de AWS) | Baja (servicio propio de AWS) | Alta (API estándar de Kubernetes) |
| Administración de servidores | Nunca | Opcional (Fargate la elimina) | Opcional (Fargate la elimina) |
| Control fino del entorno | Limitado | Alto (con EC2) | Alto (con EC2) |
| Mejor para | APIs event-driven, integraciones, automatizaciones, tareas programadas | Servicios AWS-first sin necesidad de portabilidad | Equipos con expertise Kubernetes o necesidad de portabilidad |
| Escalado a cero (sin tráfico = sin costo de cómputo) | Sí | No (con Fargate/EC2 sigue reservado) | No (con Fargate/EC2 sigue reservado) |
Árbol de decisión simplificado
- ¿La carga es corta y se dispara por un evento (archivo, mensaje, petición API puntual)? → Empieza por Lambda.
- ¿Es un servicio de larga duración y tu equipo ya sabe Kubernetes o necesitas portabilidad multi-nube? → EKS.
- ¿Es un servicio de larga duración, tu equipo es AWS-first y quieres el camino más simple? → ECS (con Fargate si además quieres evitar administrar servidores).
- ¿Tu arquitectura combina las tres cosas? → Es lo más común: Lambda para la parte event-driven, contenedores en ECS o EKS para los servicios centrales. No es una decisión de todo-o-nada. Y para conectar esas piezas entre sí sin acoplarlas, la mensajería se elige con SQS vs SNS vs EventBridge.
Cómo ayuda Caleidos
En Caleidos, como AWS Advanced Tier Services Partner, definimos esta arquitectura de cómputo como parte de nuestra práctica de Cloud Native Apps: evaluamos el patrón de carga real de cada componente, el expertise de tu equipo y los requisitos de portabilidad antes de recomendar Lambda, ECS o EKS —o la combinación de los tres—, y lo llevamos a producción con observabilidad y FinOps desde el día uno. Si ya operas Kubernetes o lo estás evaluando, profundizamos en Amazon EKS; si tu caso es serverless, en AWS Lambda.
¿Evaluando qué cómputo usar en tu próximo proyecto en AWS?
Conversemos sobre tu arquitectura: en 30 minutos te damos una recomendación concreta de si tu carga encaja mejor en Lambda, ECS o EKS.
