Lambda vs Fargate: ¿cuál usar y cuándo?

El problema que ambos resuelven

Antes de Lambda y Fargate, "correr código en la nube" significaba administrar servidores: elegir el tamaño de instancia, parchear el sistema operativo, configurar autoscaling, decidir cuántas instancias dejar prendidas a las 3am por si acaso. Ese trabajo no es difícil técnicamente — es tedioso, constante, y no tiene nada que ver con el problema de negocio que en realidad querías resolver.

AWS respondió con dos productos que remueven ese trabajo de formas distintas, y ahí es donde empieza la confusión. Lambda no es "una versión más barata de un servidor" — es un modelo de ejecución completamente distinto: no hay servidor que tú administres ni que exista permanentemente, solo código que se ejecuta cuando algo lo dispara y desaparece al terminar. Fargate tampoco es "una versión más fácil de EC2" — sigue siendo un contenedor persistente con su propio ciclo de vida, solo que AWS administra la capa de infraestructura (el host físico) por ti.

La pregunta real no es "¿cuál es mejor?" — es qué tipo de carga de trabajo tienes. Y ahí es donde la mayoría de los equipos se equivocan: fuerzan Lambda en procesos que deberían ser un servicio persistente, o pagan por un contenedor de Fargate corriendo 24/7 para atender tres requests al día.

El mecanismo real detrás de cada uno

Lambda ejecuta tu código dentro de un execution environment — una micro-VM (Firecracker, la misma tecnología detrás de Fargate por debajo) que AWS crea, inicializa, ejecuta, y eventualmente destruye o reutiliza. La primera vez que se invoca tu función (o cuando AWS necesita escalar a más concurrencia de la que ya tiene "caliente"), pasa por un cold start: descomprimir tu paquete de código, inicializar el runtime, correr cualquier código fuera del handler (imports, conexiones globales). Eso puede tomar desde cientos de milisegundos hasta varios segundos dependiendo del runtime y el tamaño del paquete. Las invocaciones subsecuentes, si llegan mientras ese environment sigue "caliente", se saltan todo eso — por eso Lambda puede sentirse instantáneo en producción bajo tráfico constante y lento en tu primera prueba.

El límite de 15 minutos no es arbitrario — es una decisión de diseño para mantener el modelo de facturación y el pool de recursos predecibles. AWS no te deja subir ese límite ni pagando más; si tu proceso lo necesita, Lambda literalmente no es la herramienta correcta, no es un problema de configuración.

Fargate, en cambio, corre tu contenedor como una task de ECS (o un pod de EKS) sobre infraestructura que AWS administra pero que tú sigues describiendo: cuánta CPU, cuánta memoria, qué imagen de Docker. No hay un "cold start" en el mismo sentido — hay un tiempo de arranque de la task (descargar la imagen, provisionar la interfaz de red en modo awsvpc) que típicamente toma de 30 segundos a un par de minutos, pero una vez arriba, la task sigue corriendo indefinidamente hasta que tú la detengas. No hay límite de tiempo de ejecución porque conceptualmente es un servicio, no un evento.

# Lambda: cada invocación es efímera, facturada por duración real (ms) x memoria asignada
aws lambda invoke --function-name procesar-golpe --payload '{"sensor_id": 42}' out.json

# Fargate: la task sigue corriendo hasta que la detengas explícitamente
aws ecs run-task --cluster studioengine --task-definition inference-worker --count 1

Más allá de los 15 minutos: cómo decidir de verdad

La infografía simplifica la decisión a una pregunta de tiempo, y como primer filtro está bien — pero en la práctica hay al menos tres factores más que pesan tanto o más:

Sensibilidad a la latencia. Si tu función atiende requests de usuario en tiempo real y un cold start ocasional de 1-2 segundos es inaceptable, necesitas Provisioned Concurrency en Lambda (que básicamente paga para mantener environments calientes todo el tiempo — a ese punto, pregúntate si no es más simple y más barato usar Fargate desde el inicio).

Conexiones a base de datos. Este es el error que más veo: cada execution environment de Lambda puede abrir su propia conexión a tu base de datos relacional. Con tráfico alto y concurrencia elevada, puedes agotar el pool de conexiones de tu RDS en minutos — algo que nunca pasaría con un puñado de contenedores de Fargate reutilizando conexiones persistentes. La solución (RDS Proxy, o un pooler externo) agrega complejidad que Fargate simplemente no necesita.

El patrón de tráfico. Lambda escala instantáneamente por diseño — cada invocación concurrente es, en esencia, un environment nuevo (hasta tu límite de concurrencia de cuenta). Fargate escala por políticas (target tracking sobre CPU/memoria, o ajustando el desired count manualmente) — reacciona en segundos a minutos, no instantáneamente. Para tráfico impredecible y en picos agudos, Lambda gana. Para carga sostenida y predecible, Fargate es más eficiente en costo.

Los casos de uso no son solo "corto vs largo"

Lambda gana cuando el trabajo es genuinamente basado en eventos: un webhook de Stripe, un objeto que se sube a S3 y dispara una función de procesamiento, un cron que corre cada noche, una API con tráfico esporádico donde pagar por request supera por mucho el costo de un servidor prendido 24/7 atendiendo casi nada. El common thread es: trabajo corto, disparado por un evento, sin estado que mantener entre invocaciones.

Fargate gana cuando el trabajo necesita mantener estado en memoria entre requests (un modelo de IA cargado, una conexión persistente a un socket), cuando el proceso individual puede exceder los 15 minutos (batch jobs, transcodificación de video, entrenar o correr inferencia sobre modelos grandes), o cuando necesitas control real sobre el entorno de ejecución (versiones específicas de librerías del sistema, GPUs, más de 10GB de memoria). Agentes de IA que mantienen contexto de conversación entre llamadas, o que orquestan múltiples pasos con estado, encajan naturalmente aquí — recrear ese estado desde cero en cada invocación de Lambda es exactamente el tipo de fricción que Fargate evita.

Buenas prácticas que separan un setup que funciona de uno que sangra dinero

No fuerces Lambda en tareas largas. Si tu proceso ocasionalmente se acerca a los 15 minutos, no es un caso límite — es una señal de que necesitas otra arquitectura (Step Functions para orquestar pasos más cortos, o simplemente mover ese trabajo a Fargate).

No uses Fargate para tareas triviales. Una task de Fargate mínima (0.25 vCPU, 0.5GB) cuesta centavos por hora — pero corriendo 24/7 para procesar cinco eventos al día, eso se acumula a más que cualquier factura de Lambda para la misma carga. El overhead de mantener un contenedor vivo no vale la pena si tu trabajo real ocupa segundos al día.

Combínalos. El patrón que más uso: Lambda como la capa de entrada (API Gateway, eventos, webhooks) que valida, autentica, y decide — y cuando el trabajo real es pesado, dispara una task de Fargate para hacerlo. Cada uno hace lo que hace mejor.

Mide el costo real, no el listado de precios. Lambda cobra por GB-segundo de ejecución; Fargate por vCPU-hora y GB-hora de memoria asignada mientras la task vive, sin importar si está procesando o esperando. El punto de equilibrio depende completamente de tu volumen y patrón de tráfico — sin datos reales de tu carga, cualquier comparación de precios en abstracto es solo una aproximación.

Cuándo NO usar cada uno

Lambda no, si: necesitas conexiones persistentes (WebSockets de larga duración, conexiones a bases de datos sin un pooler), tu trabajo regularmente se acerca o supera los 15 minutos, o la latencia del cold start es inaceptable y no quieres pagar por Provisioned Concurrency.

Fargate no, si: tu carga es genuinamente esporádica y de bajo volumen (vas a pagar por tiempo idle la mayor parte del día), necesitas escalar de cero a cientos de instancias en segundos ante picos impredecibles, o el trabajo es tan simple que la complejidad operativa de mantener una imagen de Docker no se justifica frente a subir una función.

Ejemplo práctico: cómo se ve la combinación en producción

En Fighter Foundry, cuando el sensor de impacto envía un golpe, eso dispara una Lambda que valida el payload, lo guarda, y actualiza el leaderboard — trabajo de milisegundos, tráfico impredecible según cuántos usuarios estén entrenando en ese momento. Facturar por invocación tiene sentido total ahí.

En StudioEngine.ai, el flujo es distinto: un usuario pide generar una imagen, esa request llega a la API (en EC2), y el trabajo pesado —la llamada a Replicate u OpenAI, que puede tardar decenas de segundos— se delega a un contenedor de Fargate que ya tiene las dependencias cargadas y no necesita reinicializarse en cada request. Si eso corriera en Lambda, cada generación de imagen sería, en el mejor caso, una función esperando cerca del límite de tiempo; en el peor, simplemente no cabría.

La diferencia no es el tamaño del proyecto — es la forma de la carga de trabajo.

Mi conclusión

Después de tener ambos en producción al mismo tiempo, la lección que más me ha servido no es técnica — es de diagnóstico. Antes de escribir una sola línea de infraestructura, me pregunto: ¿esto es un evento o un servicio? Un evento tiene principio y fin claros, no necesita recordar nada de la invocación anterior, y su costo debería ser proporcional a cuántas veces ocurre. Un servicio mantiene estado, tarda lo que tarda, y su costo es proporcional al tiempo que existe. Esa pregunta responde el 90% de la decisión antes de pensar en precios o límites técnicos — los detalles de Lambda vs Fargate son la implementación de esa respuesta, no la respuesta en sí.

---

Este artículo acompaña la infografía de Lambda vs Fargate — parte de la serie Tecnolog-IA con Inteligenc-IA.