AWS Lambda MicroVMs: lo que promete un blog y AWS no confirma
Un post asegura que Lambda ya ejecuta microVMs con estado persistente hasta ocho horas y sin arranques en frío. No hay documentación, precios ni regiones publicados por AWS.
Una entrada de blog defiende que AWS ya tiene operativas las Lambda MicroVMs: máquinas virtuales muy ligeras que arrancan en milisegundos, aíslan cada sesión a nivel de hardware y conservan su memoria y sus ficheros temporales hasta ocho horas. El texto las vende como el remedio al sobrediseño que domina la nube, como el final de los arranques en frío y como una forma de no montar una base de datos solo para guardar el testigo de una sesión. La compañía no ha publicado nota de prensa, documentación, precios ni regiones.
Conviene separar lo que el artículo afirma de lo que un lector puede comprobar. No hay identificadores de API, ni nombre de runtime, ni ejemplo de despliegue, ni enlace a la consola. Tampoco hay cifras: ni tiempo de arranque medido, ni límite de memoria, ni coste por GB-segundo.
Qué cambiaría si fuera cierto
Para quien despliega cosas pequeñas, el atractivo está en dos puntos concretos. El primero es el estado: si la sesión vive ocho horas, un trabajo en segundo plano que sondea una cola o una API externa deja de necesitar una instancia de Redis o de DynamoDB solo para recordar por dónde iba. El segundo es el aislamiento: sin kernel ni memoria compartidos entre sesiones, desaparece buena parte de la superficie que hoy se tapa con grupos de seguridad y reglas de IAM.
El aislamiento por microVM, además, no es una idea nueva dentro de Lambda. Firecracker lleva años siendo la pieza que separa unas ejecuciones de otras. Lo que este texto presenta como novedad es el otro extremo: mantener una sesión viva durante horas en un servicio gestionado, algo que el modelo de función no ofrece hoy y que obliga a tirar de contenedores o de máquinas siempre encendidas.
Lo que falta por responder
Si el producto existe, quedan las preguntas de siempre. Cuánto cuesta el rato en que la MicroVM está viva pero no hace nada, porque ahí se decide si sustituye a un servicio pequeño o sale más caro. Qué runtimes soporta y si el SDK cambia. Si entra en una VPC y con qué latencia. Y si convive con lo que ya hay —Function URLs, colas, capas— o si obliga a montar un flujo aparte.
Mientras no haya documentación que leer, no hay decisión de arquitectura que tomar. El interés de la pieza es el de un aviso: si AWS mueve ficha en esa dirección, los trabajos de larga duración y las sesiones con estado dejan de necesitar infraestructura propia. Hasta entonces, es una promesa sin precio.
