Actualización de la facturación INIT de AWS Lambda: qué cambia y por qué es importante para sus costos en la nube

¿Prefieres un resumen de este blog? ¡Da click en el botón de abajo y deja que ChatGPT te lo cuente! (también puedes probar con Perplexity)
A partir del 1 de agosto de 2025, AWS facturará la fase de inicialización (INIT) de las funciones Lambda. Esto supone un cambio clave en la forma de cobrar las cargas de trabajo sin servidor. Dicha actualización de la facturación afectará a las funciones que utilicen tiempos de ejecución gestionados con empaquetado de archivos ZIP. Anteriormente, excluían la fase INIT de la duración facturada.
La fase INIT, aunque corta, podría introducir costos que antes eran invisibles. Si no está monitoreando activamente sus arranques en frío de Lambda o controlando las tendencias de costo por función, esta actualización podría tomarlo desprevenido.
Este blog le ayudará a entender qué está cambiando exactamente, cómo podría afectar a su factura de la nube y por qué ahora es el momento adecuado para empezar a utilizar una herramienta dedicada a la gestión de los costos de la nube.
Comprender la fase INIT
La ejecución de una función Lambda tiene tres fases: INIT, INVOKE y SHUTDOWN. INIT se activa cuando la función se ejecuta en un entorno nuevo, una situación conocida comúnmente como arranque en frío. Durante esta fase, AWS:
∙ Descarga el código de su función de un bucket interno de Simple Storage Service (S3) o de un registro de contenedores.
∙ Configura el entorno de tiempo de ejecución (la memoria, las variables y las dependencias).
∙ Ejecuta el código estático INIT.
∙ Establece las extensiones necesarias.
Esta fase puede durar desde unos pocos milisegundos hasta varios segundos, en función del tamaño del paquete, el idioma y la lógica incluida. Ocurre con menos frecuencia que la fase de INVOKE, pero su duración es notable.
Previamente, el tiempo INIT no se facturaba para las funciones empaquetadas con ZIP que utilizaban tiempos de ejecución gestionados. A partir de agosto, esto cambiará. La duración facturada incluirá el tiempo de INIT de todas las funciones. No importará el método de empaquetado o del tiempo de ejecución.
¿Cómo repercutirá esto en sus costos de Lambda?
Para muchos usuarios, este cambio tendrá un efecto muy pequeño. Los arranques en frío suelen producirse en menos del 1% de las invocaciones totales. Lo mismo no puede decirse de los sistemas de alta velocidad de transferencia, los entornos grandes o las funciones mal optimizadas. En estos casos, los raros arranques en frío podrían acumular costos significativos.
Suponga que está ejecutando una función que trabaja con 1 GB de memoria y tarda 300 ms en ejecutarse. Si la fase INIT añade otros 100 ms durante un arranque en frío, este tiempo pronto será facturable. Multiplique eso por miles de invocaciones en un día y su factura subirá, especialmente en las regiones con precios Lambda más elevados.
La actualización también afectará a la forma en que se registra la duración. A partir del 1 de agosto, los logs de CloudWatch mostrarán un valor incrementado de Duración facturada. Esto incluirá el tiempo de INIT. Es una señal crucial para que los equipos monitoreen y analicen el comportamiento de las funciones.
Por qué la visibilidad es clave y dónde encaja CloudSpend
No puede gestionar lo que no puede ver. A medida que AWS se vuelve más detallado con la facturación, las organizaciones necesitan un control más detallado de los costos.
ManageEngine CloudSpend puede ayudarle a:
∙ Desglosar los costos de Lambda por región, cuenta o función.
∙ Aislar las funciones con arranques en frío frecuentes o costosos.
∙ Identificar duraciones INIT inusualmente altas en los distintos entornos.
∙ Proyectar los aumentos de costos debidos a los cambios en los modelos de facturación de AWS.
∙ Establecer presupuestos y alertas antes de que los costos se le vayan de las manos.
Esta visibilidad le permite planificar, optimizar el diseño de las funciones y evitar sobrecostos presupuestarios inesperados.
Qué debe hacer para reducir los costos de INIT
AWS ofrece varias formas de reducir los tiempos de arranque en frío y, por extensión, la facturación INIT:
∙ Reduce el tamaño del paquete de funciones. Elimine las dependencias innecesarias, minimice el código y utilice herramientas como esbuild para empaquetar de forma eficiente. Los paquetes más pequeños se cargan más rápido y reducen la duración del INIT.
∙ Desplace la lógica fuera de INIT. Mantenga solo el código de configuración esencial en la fase INIT. Mueva la lógica de negocio o las inicializaciones no críticas al manejador para limitar la duración del arranque en frío.
∙ Habilite Lambda SnapStart. Disponible para los tiempos de ejecución de Java, .NET y Python, SnapStart toma una instantánea de su función después de la fase INIT y la reutiliza para los arranques en frío. Esto elimina la necesidad de repetir el proceso INIT.
∙ Utilice la concurrencia aprovisionada. Para las funciones con un tráfico constante, la concurrencia aprovisionada mantiene calientes los entornos de ejecución. Lo anterior elimina de forma efectiva los arranques en frío. Esto conlleva costos adicionales, pero garantiza un rendimiento estable y evitará los picos de facturación de INIT.
∙ Monitoree e itere. Utilice métricas de CloudWatch como initDuration y herramientas como CloudSpend para realizar un control continuo de las funciones que necesitan ajuste. La optimización es un proceso continuo, especialmente a medida que AWS actualiza sus precios y su comportamiento.
Reflexiones finales
La decisión de AWS de facturar la fase INIT en todas las configuraciones de Lambda es una evolución natural del modelo de facturación sin servidor. Si bien el impacto pueda ser pequeño a primera vista, abre la puerta a un aumento de los costos si no se gestionan los arranques en frío.
Esta actualización destaca la creciente necesidad de una visibilidad de costos precisa y en tiempo real. Con CloudSpend, los equipos pueden detectar las tendencias a tiempo, hacer mejores proyecciones y optimizar el uso de la nube antes de que las facturas se inflen. Si sus cargas de trabajo dependen de Lambda, ahora es el momento de revisar sus funciones, ajustar el rendimiento y establecer controles de costos más inteligentes.