AWS Lambda MicroVMs: il serverless ottiene una sandbox isolata e stateful

Le AWS Lambda MicroVMs sono una nuova primitiva di calcolo serverless che ti offre isolamento a livello di macchina virtuale, avvio quasi istantaneo da uno snapshot ed esecuzione stateful che puoi sospendere e riprendere. Girano su Firecracker, la stessa virtualizzazione leggera che gia oggi sostiene piu di 15 trilioni di invocazioni Lambda al mese. In breve: Lambda ha appena acquisito la capacita di assegnare a ogni sessione la propria sandbox dedicata, isolata e a lunga durata, e di farlo senza che tu debba gestire alcuna virtualizzazione.

Se hai mai provato a eseguire in modo sicuro codice che la tua applicazione non ha scritto, esecuzione di codice multi-tenant, notebook interattivi, scanner di vulnerabilita, sai gia perche questo conta. La risposta onesta fino ad oggi era "avvia container o VM e costruisci tu stesso l'orchestrazione, l'isolamento e il plumbing del ciclo di vita". Le MicroVMs riducono tutto questo a una chiamata API.

Cosa c'e davvero di nuovo

Le normali funzioni Lambda sono stateless, di breve durata ed event-driven. Per questo sono eccellenti. Sono pero lo strumento sbagliato quando ti serve una sessione che vive per minuti o ore, mantiene lo stato in memoria e isola codice non affidabile a livello di kernel. Le MicroVMs sono una primitiva diversa all'interno dello stesso servizio, pensata esattamente per colmare quel divario. AWS la descrive come tre capacita che nessun singolo servizio di calcolo AWS offriva insieme prima di oggi.

1. Isolamento a livello di VM

Ogni sessione gira nella propria MicroVM dedicata, senza kernel condiviso e senza risorse condivise tra gli utenti. Questa e la garanzia di Firecracker: il codice non affidabile di un tenant resta confinato nel suo ambiente, senza alcun percorso verso altri ambienti o verso l'host. I container condividono un kernel; una MicroVM no. Per eseguire codice che non hai scritto, quel confine e tutto cio che conta.

2. Avvio e ripresa rapidi da snapshot

Il modello e build-then-launch. Costruisci una MicroVM Image a partire da un Dockerfile piu un artefatto di codice in Amazon S3. Lambda esegue il Dockerfile, inizializza la tua applicazione e cattura uno snapshot Firecracker della memoria e dello stato del disco in esecuzione. Ogni MicroVM avviata da quell'immagine riprende dallo snapshot pre-inizializzato invece di fare un cold boot. Anche una sessione interattiva da diversi gigabyte torna disponibile abbastanza in fretta da sembrare attiva in tempo reale. E l'idea di SnapStart portata alla sua conclusione logica: non stai avviando un processo, ne stai ripristinando uno gia in esecuzione.

3. Esecuzione stateful e sospendibile

Una MicroVM in esecuzione mantiene memoria, disco e processi per tutta la sessione. Quando rimane inattiva puo essere sospesa con lo stato intatto, per poi riprendere quando il traffico ritorna. I pacchetti installati, i dati caricati e i file di lavoro sono tutti ancora li. Le MicroVMs supportano fino a 8 ore di runtime totale e si auto-sospendono dopo una finestra di inattivita configurabile. Questa e la parte che rompe la vecchia assunzione del serverless stateless, e lo fa in senso buono.

Come si presenta operativamente

Due chiamate CLI gestiscono la maggior parte del flusso. Prima, costruisci l'immagine:

aws lambda-microvms create-microvm-image \
  --code-artifact uri=<path/to/s3/artifact.zip> \
  --name my-sandbox \
  --base-image-arn arn:aws:lambda:us-east-1:aws:microvm-image:al2023-1 \
  --build-role-arn <build role ARN>

I log di build vengono inviati a CloudWatch sotto /aws/lambda/microvms/<image-name>, e l'immagine finita compare con il proprio ARN e la propria versione. Poi avvia una MicroVM da essa:

aws lambda-microvms run-microvm \
  --image-identifier arn:aws:lambda:<region>:<acct>:microvm-image:my-sandbox \
  --execution-role-arn arn:aws:iam::<acct>:role/MicroVMExecutionRole \
  --idle-policy '{"maxIdleDurationSeconds":900,"suspendedDurationSeconds":300,"autoResumeEnabled":true}'

Lambda restituisce un ID univoco della MicroVM e un endpoint URL dedicato, con l'applicazione gia in esecuzione perche ha ripreso dallo snapshot. Nessuna rete da configurare. La idle-policy e il punto in cui risiede il controllo del ciclo di vita: per quanto tempo restare inattiva prima di sospendere, per quanto tempo restare sospesa prima di terminare e se riprendere automaticamente alla richiesta successiva.

Dove si inserisce, e dove no

Le MicroVMs non sono un sostituto delle funzioni, e non sono un modo economico per far girare un server 24/7. Il limite di 8 ore e il modello suspend-resume sono pensati per le sessioni: una sandbox di coding che un utente apre e abbandona, una scansione che gira per dieci minuti, un job di analytics che lavora per due ore e poi si zittisce. Se il tuo carico e un servizio long-running costantemente occupato, quello resta territorio di ECS o EC2.

L'avvertenza sullo snapshot da conoscere

Poiche ogni MicroVM riprende da uno snapshot pre-inizializzato, qualunque cosa la tua app faccia durante l'inizializzazione che presuppone la freschezza puo sorprenderti. ID univoci generati all'avvio, connessioni di rete aperte al boot, seed casuali o dati effimeri caricati una sola volta possono tutti restare congelati nello snapshot e riutilizzati tra un avvio e l'altro. E la stessa classe di insidie che gli utenti di SnapStart conoscono gia: se qualcosa deve essere univoco o fresco per sessione, generalo dopo la ripresa, non durante l'init. AWS espone hook a questo scopo, e ti serviranno per qualsiasi cosa orientata alle connessioni o sensibile dal punto di vista della sicurezza.

La conclusione

Le Lambda MicroVMs sono il segnale piu chiaro finora che il serverless ha smesso di essere soltanto stateless e di breve durata. Ora ottieni una sandbox Firecracker gestita con isolamento reale, avvii alla velocita dello snapshot e stato suspend-resume, esposti come due chiamate API e una idle policy. Per chiunque costruisca esecuzione di codice multi-tenant, questo elimina la parte piu difficile e meno differenziante del lavoro: l'isolamento e il plumbing del ciclo di vita. Costruisci il prodotto, lascia che Lambda gestisca il fleet di MicroVM.

Leggi anche questo

• AWS Monthly (Nov '25): The Stateful Serverless Revolution, per la linea di tendenza su cui si collocano le MicroVMs.
• Securing Docker Containers, sul perche un kernel condiviso e il confine che le MicroVMs sono nate per rimuovere.

Per l'angolo AI e agentico sullo stesso lancio, perche le MicroVMs sono pensate per eseguire codice generato dall'AI, leggi le field notes su ercan.ai. Per consulenza su AWS, serverless e lavoro di piattaforma, o anche solo per salutare, parti da ercanermis.com.