Fundamentos de AWS Lambda: cómo se ejecuta tu código sin servidores
Qué pasa por dentro cuando algo activa tu función, cómo se crea el entorno y por qué la primera vez tarda más
Series: Serverless Fundamentos (5 articles)
- 2Fundamentos de AWS Lambda: cómo se ejecuta tu código sin servidores This article
A mí siempre me ha incomodado que me digan "solo usa esto" sin explicarme cómo funciona. Y con Lambda fue justo lo que me pasó: todos me decían "sube tu código y ya, Lambda se encarga". Pero yo necesitaba entender qué pasa entre que algo activa mi función y me llega la respuesta.
📺 Y si prefieres el formato en video, puedes verlo acá:
Normalmente, para ejecutar código necesitas un servidor, un programa que está corriendo todo el tiempo esperando peticiones. Tú lo configuras, lo actualizas y lo mantienes vivo (si quieres entender esto a fondo, lo expliqué en el primer artículo de esta serie . AWS Lambda abstrae todo ese trabajo por ti. Veamos cómo Lambda funciona por dentro.
El cambio mental
Con un servidor tradicional, tu aplicación está corriendo todo el tiempo esperando peticiones. Con Lambda es diferente: tú escribes una función, defines qué la activa, y AWS la ejecuta solo cuando ocurre ese evento. Cuando termina, se apaga. No tienes que configurar una máquina, ni mantenerla corriendo, ni preocuparte por actualizaciones. Solo escribes la lógica de lo que quieres que pase.
¿Qué activa una función Lambda?
Lambda no corre sola, necesita que algo la active. A eso le llamamos un trigger.
Algunos ejemplos:
| Lo que pasa | Qué activa tu función |
|---|---|
| Un usuario hace clic en "comprar" | Un request HTTP |
| Alguien sube una foto de perfil | Un archivo nuevo en almacenamiento |
| Se confirma un pago | Un mensaje en una cola |
| Son las 2am | Un timer programado |
| Un usuario actualiza su dirección | Un cambio en la base de datos |
Cualquier cosa que pasa en tu sistema puede ser un evento, y cualquier evento puede activar una función. Tú defines cuál evento conecta con cuál función, y Lambda se encarga del resto.
El handler: lo que tú escribes
Ya sabes qué activa una función. Ahora, ¿qué pasa después de que llega el evento? Ahí es donde entra tu código.
Lo que escribes se llama handler. Es una función que recibe dos cosas: el evento (la información que viene del trigger, qué pasó, quién lo disparó, con qué datos) y el contexto (información sobre la ejecución misma, como cuánto tiempo tiene tu función antes de que Lambda la detenga por timeout, o el nombre de la función).
1
2
3
4
5
6
def handler(event, context):
name = event.get("name", "mundo")
return {
"statusCode": 200,
"body": f"Hola, {name}!"
}El handler recibe el evento, lo procesa, y devuelve una respuesta. Eso es todo.
Qué pasa por dentro cuando Lambda ejecuta tu código
Ahora que ya sabes qué activa una función y qué escribes, veamos qué pasa por debajo.
Lambda necesita un lugar donde correr tu función. Piensa en ese lugar como un entorno de ejecución temporal: un servidor pequeño y aislado que contiene tu código, las bibliotecas que usas y el runtime de tu lenguaje (Python, Node.js, Java, etc.). Este entorno pasa por tres fases:
INIT: preparar el entorno
Cada vez que Lambda necesita un entorno nuevo, lo prepara desde cero. Crea un servidor temporal, descarga tu código junto con sus dependencias, inicializa el runtime del lenguaje que elegiste y ejecuta cualquier código que tengas fuera del handler (conexiones a bases de datos, configuraciones, imports). Al final de esta fase, tu handler está listo para recibir eventos.
INVOKE: ejecutar tu código
Aquí es donde Lambda llama a tu handler con el evento, tu código hace lo suyo y devuelve una respuesta.
Pero lo interesante viene después: si llega otra llamada poco después, Lambda no vuelve a crear el entorno desde cero. Reutiliza el que ya tiene listo. A eso le llamamos una ejecución warm, y es mucho más rápida porque se salta todo el proceso de INIT.
SHUTDOWN: liberar recursos
Si pasa un rato sin que lleguen eventos, Lambda destruye el entorno y libera los recursos. La próxima vez que llegue algo, el ciclo empieza desde INIT.
El patrón es: INIT cuando se necesita un entorno nuevo, INVOKE que se repite mientras sigan llegando eventos, y SHUTDOWN cuando ya no hay actividad.
Cold starts: la primera vez tarda más
¿Recuerdas la fase INIT? Esa fase extra que ocurre la primera vez tiene un nombre: cold start.
Piensa en un restaurante. Si llegas y ya está abierto, con la cocina caliente y los meseros listos, te atienden rápido. Eso es una ejecución warm. Pero si el restaurante tiene que abrir solo para ti (encender luces, calentar la cocina, llamar al chef) vas a esperar un poco más. Eso es un cold start: la fase INIT que tarda un poco más porque Lambda tiene que crear un entorno nuevo desde cero.
Un cold start pasa cuando:
- Es la primera ejecución después de subir tu código
- Llegan muchos usuarios de golpe y Lambda necesita más entornos de ejecución
- Tu función llevaba mucho tiempo sin usarse y el entorno se destruyó
¿Cuánto tarda? Entre 100 milisegundos y un segundo, dependiendo del lenguaje que uses y el tamaño de tu código.
Para la gran mayoría de los casos no es un problema real. Si tu función procesa mensajes, genera reportes, o trabaja con archivos, 200 milisegundos extra no hacen diferencia.
Donde sí importa es cuando tu aplicación necesita responder en menos de 100 milisegundos siempre. Ahí se vuelve algo a considerar.
Nota: Si quieres entender cold starts a fondo, tengo un artículo dedicado al tema .
Pricing: ¿cuánto cuesta?
Lambda cobra por dos cosas: cuántas veces se ejecuta tu función y cuánto tiempo de cómputo consume cada ejecución. El tiempo de cómputo se mide en GB-segundos, que es la combinación de la duración y la memoria asignada a tu función.
Un ejemplo concreto:
Una función que procesa órdenes de una tienda online:
- 1 millón de ejecuciones al mes
- 200ms de duración promedio
- 512MB de memoria asignada
Costo: ~$1.87/mes
Un servidor corriendo 24/7 para hacer lo mismo: $15-30/mes mínimo. Y ese servidor está corriendo todo el tiempo, aunque a las 3am no tenga ni un solo usuario.
Lambda tiene una capa gratuita generosa que se compone de dos partes:
- 1 millón de requests gratis al mes (cada vez que tu función se ejecuta cuenta como un request)
- 400,000 GB-segundos de cómputo gratis al mes (equivale a ~3.2 millones de segundos si tu función usa 128MB de memoria)
Para muchos proyectos personales o startups en etapa temprana, tu aplicación puede correr sin que pagues nada.
Ojo: esto no significa que Lambda siempre sea más barato. Si tu aplicación tiene tráfico constante las 24 horas, un servidor puede salirte mejor. Pero para tráfico que sube y baja, pagar solo por lo que usas tiene mucho sentido.
Lo que quiero que te lleves
- Con Lambda escribes una función, defines qué la activa, y pagas solo cuando se ejecuta.
- Los triggers conectan eventos del mundo real con tu código. Lo configuras una vez y listo.
- Tu handler recibe el evento, lo procesa, y devuelve una respuesta. Eso es todo lo que escribes.
- La primera ejecución tarda un poco más (cold start), pero después responde rápido.
- Para la mayoría de proyectos, cuesta centavos.
Qué sigue
Ya entiendes cómo corre una función Lambda. Pero Lambda rara vez trabaja sola. En el mundo real, tu función necesita comunicarse con otros servicios: recibir mensajes, guardar datos, notificar a otro sistema.
Eso nos lleva a un patrón clave en serverless: Event-Driven Architecture. En el próximo artículo vamos a ver cómo los servicios se hablan entre sí a través de eventos y por qué eso cambia la forma en que diseñas aplicaciones.
¿Te resultó útil este artículo? Si conoces a alguien que está empezando con Lambda y le vendría bien esta explicación, compártelo. Y si ya usas Lambda, cuéntame en los comentarios qué fue lo primero que construiste con el servicio.
Si quieres seguir aprendiendo sobre serverless y desarrollo en AWS en español, suscríbete al canal de AWS Developers en Español .
Series: Serverless Fundamentos (5 articles)
- 2Fundamentos de AWS Lambda: cómo se ejecuta tu código sin servidores This article
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article