Serverless en AWS: cuándo conviene Lambda o Fargate y cómo no dispararte los costos

Qué significa serverless de verdad

Hay un malentendido que cuesta dinero y que escucho seguido en reuniones con equipos de tecnología en Panamá: creer que "serverless" quiere decir que no hay servidores. Los hay, claro que los hay. Lo que cambia es quién los administra. En un modelo serverless tú no aprovisionas máquinas, no parchas sistemas operativos, no calculas cuántas instancias encender un lunes a las nueve de la mañana. AWS hace todo eso por debajo y a ti solo te cobra por lo que tu código realmente consume. La promesa real no es "sin servidores", es "sin gestión de servidores y pagando por uso".

Esa distinción importa porque define cómo gastas. En un servidor tradicional, encendido las veinticuatro horas, pagas por tenerlo disponible aunque nadie lo use a las tres de la madrugada. En serverless, idealmente, pagas cuando algo sucede. Y ahí está tanto la magia como la trampa: cuando el modelo de cobro está atado al uso, un error de diseño no te cuesta una instancia ociosa, te cuesta millones de ejecuciones que no esperabas. Antes de elegir herramienta conviene entender que el verdadero cambio es de "pago por capacidad reservada" a "pago por consumo medido", y que controlar el consumo pasa a ser una disciplina de arquitectura, no de operaciones.

Dentro del ecosistema de AWS, las dos piezas que casi siempre entran a la conversación son Lambda y Fargate. Ambas son serverless en el sentido estricto, ninguna te obliga a administrar máquinas, pero resuelven problemas distintos y se cobran de forma distinta. Confundirlas es la primera fuente de sustos en la factura.

Lambda: funciones que despiertan por un evento

AWS Lambda es computación dirigida por eventos. Escribes una función, la subes, y esa función duerme hasta que algo la despierta: una petición HTTP que llega por API Gateway, un archivo que aterriza en un bucket de S3, un mensaje que entra a una cola, una regla de tiempo en EventBridge. Cuando el evento ocurre, Lambda levanta tu código, lo ejecuta y lo apaga. Si llegan mil eventos a la vez, levanta mil ejecuciones en paralelo sin que tú toques nada. Si no llega ninguno, no corre nada y no pagas nada de cómputo.

El modelo de cobro refleja esa naturaleza. Según la página oficial de precios de Lambda, pagas por dos cosas: la cantidad de solicitudes, a razón de veinte centavos de dólar por cada millón de invocaciones, y la duración medida en GB-segundos, es decir la memoria que asignaste multiplicada por el tiempo que tu código estuvo ejecutándose, redondeado al milisegundo más cercano. No hay piso por minuto ni instancia mínima: si tu función corre cuarenta milisegundos, pagas cuarenta milisegundos. Para cargas que aparecen a ráfagas y luego desaparecen, ese cobro al milisegundo es lo más cercano a no pagar por nada ocioso.

Lambda brilla justamente en esas cargas intermitentes y de vida corta: procesar una imagen recién subida, transformar un registro, atender el backend de una aplicación web o móvil, reaccionar a un webhook, ejecutar una tarea programada. Tiene un límite que conviene tener presente desde el primer día, una función no puede correr más de quince minutos por invocación. Si tu proceso necesita más que eso, Lambda no es la herramienta y forzarla termina en parches feos.

Hay un detalle que en sof-IA cuidamos mucho y que mucha gente descubre tarde: el llamado "cold start". Cuando una función lleva rato sin usarse, la primera invocación tiene que inicializar el entorno antes de ejecutar tu lógica, y eso añade latencia. Ese tiempo de arranque, incluido el código que escribes fuera del handler para inicializar conexiones o cargar dependencias, cuenta como duración facturable. Es decir, una inicialización pesada no solo hace lento el primer request, también te lo cobran. La lección de diseño es directa, inicializa lo mínimo indispensable y reutiliza conexiones entre invocaciones.

Fargate: contenedores que viven mientras los necesitas

AWS Fargate juega en otra cancha. Aquí no subes una función, empaquetas tu aplicación en un contenedor y Fargate lo corre sobre ECS sin que tú administres las máquinas que lo sostienen. La diferencia conceptual es que un contenedor en Fargate está vivo de forma continua mientras tú quieras: mantiene estado en memoria, atiende conexiones persistentes, corre procesos en segundo plano, sirve una API que recibe tráfico todo el día. No depende de un evento que lo despierte, simplemente está corriendo.

El cobro acompaña esa realidad. La página oficial de precios de Fargate explica que pagas por los vCPU y la memoria que asignas a cada tarea, medidos por segundo desde que se descarga la imagen del contenedor hasta que la tarea termina, con un mínimo de un minuto por tarea. Cada tarea trae veinte gigabytes de almacenamiento efímero sin costo adicional y solo pagas almacenamiento si configuras más. La diferencia práctica con Lambda es que en Fargate pagas por la capacidad que reservaste mientras el contenedor está encendido, lo use o no a plena carga en ese instante.

Por eso Fargate es el lugar natural para cargas sostenidas y de larga vida: un servicio que recibe tráfico constante, microservicios con conexiones abiertas, procesos por lotes que tardan horas, trabajos de cómputo que no caben en quince minutos. También escala muy bien hacia arriba cuando necesitas lanzar muchas tareas a la vez, pero su economía premia la continuidad, no la intermitencia extrema.

El patrón que decide: intermitente contra sostenido

Si tuviera que reducir la elección a una sola pregunta, sería esta: ¿tu carga aparece a ráfagas y luego desaparece, o vive corriendo de forma sostenida? Esa es la línea divisoria que más veces acierta.

Una carga intermitente, picos impredecibles, eventos esporádicos, trabajo que llega y se va, encaja con Lambda, porque pagar al milisegundo y no pagar nada cuando no pasa nada es imbatible para ese perfil. Una carga sostenida, un servicio con tráfico continuo, un proceso que corre horas, algo que mantiene estado, encaja con Fargate, porque ahí el cobro por segundo de un contenedor encendido sale más barato y más predecible que millones de invocaciones cortas que además pagan su arranque una y otra vez.

El error que vemos a diario es usar la herramienta a contracorriente de su modelo de cobro. Meter un servicio de alto tráfico continuo en Lambda multiplica las invocaciones y los arranques hasta convertir una factura razonable en una sorpresa. Y al revés, dejar un contenedor de Fargate encendido para atender un evento que ocurre tres veces al día es pagar veinticuatro horas por tres minutos de trabajo real.

Los errores que disparan la factura

La mayoría de los sustos no vienen del precio de AWS, vienen del diseño. El primero y más común es el sobredimensionamiento: asignar a una Lambda mucha más memoria de la que necesita o a una tarea de Fargate más vCPU del que usa. Como ambos cobran por recurso asignado y por tiempo, cada gigabyte de más se paga en cada ejecución y en cada segundo. Ajustar ese tamaño al consumo real es de los cambios que más bajan la factura sin tocar una línea de lógica.

El segundo es dejar cosas encendidas. En Fargate, tareas que quedaron corriendo sin tráfico, entornos de prueba que nadie apagó, réplicas dimensionadas para un pico que ya pasó. En Lambda, la concurrencia aprovisionada es un caso a vigilar: sirve para eliminar el cold start manteniendo entornos calientes, pero se cobra aunque estén ociosos, así que activarla "por si acaso" en funciones que no la necesitan es gasto puro.

El tercero son las llamadas excesivas. En modelos por invocación, cada solicitud cuesta. Un cliente mal diseñado que reintenta sin control, un bucle que invoca la función más de lo necesario, o procesar mensajes de uno en uno cuando podrías agruparlos en lotes, todo eso se traduce en millones de invocaciones evitables. Procesar en lotes y poner límites de reintento no es una optimización menor, es la diferencia entre una factura sana y una desbocada.

Cómo mantener la elasticidad sin sustos

La buena noticia es que controlar el gasto en serverless es metódico, no mágico. La práctica de mayor impacto es el right-sizing: dimensionar memoria y CPU contra el consumo medido real, observando métricas en CloudWatch, en lugar de aprovisionar "por si acaso". Va de la mano con preferir arquitecturas dirigidas por eventos donde el cómputo solo corre cuando hay trabajo, agrupando mensajes en lotes para reducir invocaciones.

Sobre esa base limpia entran los descuentos por compromiso. Para cargas estables, los Compute Savings Plans dan ahorros de hasta diecisiete por ciento en Lambda y de hasta cincuenta por ciento en Fargate a cambio de comprometer un consumo por una duración determinada. Para trabajo tolerante a interrupciones, Fargate Spot ofrece hasta setenta por ciento de descuento. Y elegir la arquitectura de procesador correcta importa: Lambda sobre Graviton, el chip Arm de AWS, ofrece hasta treinta y cuatro por ciento mejor relación precio-rendimiento que x86 según AWS, así que migrar funciones compatibles suele pagar solo. La regla de oro es ordenar primero el consumo y después comprometerlo, nunca al revés: comprometer un gasto inflado solo congela el error.

Aterrizando en tu empresa

La elasticidad sin sustos no sale de elegir Lambda o Fargate como si una fuera mejor que la otra. Sale de mapear cada carga a su naturaleza, intermitente o sostenida, dimensionar al consumo real, evitar lo encendido sin propósito y las llamadas de más, y solo entonces aplicar los descuentos que correspondan. Hecho así, pagas por lo que usas de verdad y la factura sube y baja con tu negocio, no con tus descuidos.

En sof-IA arquitectamos exactamente esto a la medida sobre AWS: decidimos contigo qué carga vive en Lambda, cuál en Fargate y cómo se conectan con colas y eventos para que escale solo cuando hay trabajo, con el dimensionamiento y los planes de ahorro ajustados a tu patrón de uso. Si quieres elasticidad real sin sorpresas en la factura, hablemos.