Lambda tiene una característica muy comentada: los cold starts (arranques en frío). Es el «precio» que a veces se paga por el modelo bajo demanda del subcapítulo 14.1. En este subcapítulo entenderás qué son, por qué ocurren y qué puedes hacer para reducir su impacto.

Recuerda cómo funciona Lambda: tu código no está siempre encendido, sino que AWS lo arranca cuando llega un evento. Pues bien, ese arranque tiene dos escenarios:

• Cold start (arranque en frío): es la primera vez que se invoca la función (o tras un rato sin usarse). AWS tiene que preparar el entorno desde cero: reservar recursos, cargar tu código, inicializar el runtime (Python, Java...), cargar las librerías. Esto añade un retraso extra, normalmente de unos cientos de milisegundos a un par de segundos.

• Warm start (arranque en caliente): si la función se ha usado hace poco, AWS reutiliza el entorno que ya estaba preparado. Aquí no hay retraso de preparación: la función responde al instante.

Analogía: un cold start es como arrancar un coche en una mañana de invierno: el motor frío tarda un poco en ponerse a punto. Una vez en marcha (caliente), arrancas y aceleras al instante. Si lo dejas aparcado un buen rato, vuelve a enfriarse.

El impacto del cold start depende del tipo de aplicación:

• Importa en aplicaciones interactivas donde el usuario espera una respuesta rápida (una API que responde a una app móvil). Un retraso de 1-2 segundos en la primera petición puede notarse.
• No importa en tareas de fondo o asíncronas (procesar un archivo subido, vaciar una cola). Si la tarea tarda unos segundos más en empezar, a nadie le afecta.

También depende del lenguaje: runtimes ligeros como Python o Node.js tienen cold starts cortos; runtimes más pesados como Java o .NET arrancan más despacio (aunque hay técnicas para mejorarlo).

Es la solución más directa: le dices a AWS que mantenga un número de entornos siempre calientes y listos, esperando peticiones. Así, esas invocaciones nunca sufren cold start.

Es como tener varios coches con el motor ya encendido en el aparcamiento, listos para salir. El compromiso: pagas por mantenerlos calientes (incluso sin uso), así que se usa cuando la latencia de la primera petición es crítica.

Una técnica sencilla: programar una invocación cada pocos minutos (con CloudWatch, recuerda el subcapítulo 14.2) para que el entorno no se enfríe. Es un truco económico, aunque menos fiable que la provisioned concurrency, sobre todo si hay muchas peticiones simultáneas.

Cuanto menos código y librerías tenga que cargar AWS, más rápido es el arranque. Por eso conviene:

• Incluir solo las librerías que realmente usas (recuerda el subcapítulo 14.3).
• Usar capas para no inflar el paquete.
• Evitar dependencias pesadas innecesarias.

Si el cold start es crítico y puedes elegir lenguaje, Python o Node.js suelen arrancar más rápido que Java o .NET. (Para Java existen optimizaciones específicas, pero de partida es más pesado.)

Lo que pones fuera del handler (conexiones, configuración) se ejecuta una sola vez por entorno y se reutiliza en los warm starts. Aprovecharlo bien evita repetir trabajo costoso en cada invocación:

No al principio. Para la mayoría de aplicaciones, los cold starts ocasionales son perfectamente asumibles, y runtimes como Python o Node los hacen muy llevaderos. Preocúpate de ellos solo si tienes una aplicación interactiva sensible a la latencia y mides que los cold starts molestan a los usuarios. Entonces aplica la provisioned concurrency y las demás estrategias. Recuerda: optimizar antes de tener un problema medido suele ser tiempo perdido.

• Un cold start (arranque en frío) es el retraso extra la primera vez que se invoca una Lambda (o tras un rato sin uso), porque AWS prepara el entorno desde cero. En warm starts ese entorno se reutiliza y no hay retraso.
• Importa en aplicaciones interactivas sensibles a la latencia; no importa en tareas de fondo. Runtimes ligeros (Python, Node) arrancan más rápido.
• Estrategias: Provisioned Concurrency (entornos siempre calientes), invocaciones periódicas, reducir el tamaño del paquete, runtime ligero e inicializar conexiones fuera del handler para reutilizarlas.
• No te obsesiones de entrada: optimiza los cold starts solo si mides que afectan de verdad a tus usuarios.

En el último subcapítulo del capítulo veremos los límites de Lambda y los antipatrones: cuándo Lambda no es la herramienta adecuada.