Le AWS Lambda MicroVMs sono una nuova primitiva serverless costruita, secondo la formulazione di AWS stessa, per eseguire codice generato da utenti o dall'AI in ambienti isolati e stateful. È quella seconda parola quella da notare. Il lancio non riguarda davvero le funzioni. Riguarda il dare a un agent AI un luogo sicuro dove eseguire il codice che ha appena scritto, e il fatto che AWS abbia aperto con "utenti o AI" ti dice a chi è rivolto.

Se costruisci agent, hai già sbattuto contro questo muro. Il modello scrive codice, e poi devi eseguirlo da qualche parte. Eseguire codice non attendibile, generato dal modello, sulla tua infrastruttura è la parte che tutti sottovalutano, ed è esattamente la parte che le MicroVMs sono progettate per togliere dal tuo piatto.

Il problema del sandbox che gli agent hanno davvero

Un agent capace non si limita a rispondere. Scrive uno script, lo esegue, legge il risultato e itera. I code interpreter, gli agent di analisi dati e gli strumenti di coding autonomo vivono o muoiono su un'unica domanda: dove viene eseguito quel codice?

Le risposte ingenue sono tutte cattive. Eseguilo nel processo della tua applicazione e una singola generazione ostile o difettosa può mandare giù l'host o leggere i dati di un altro utente. Eseguilo in un container condiviso e sei a un kernel exploit di distanza da una violazione cross-tenant, perché i container condividono un kernel. Costruisci la tua flotta di VM e ti sei appena impegnato a gestire l'infrastruttura più difficile e meno differenziante del tuo stack. Il codice generato dal modello è codice non attendibile per definizione. Ha bisogno di un vero confine di isolamento, non di uno gentile.

Perché le MicroVMs si adattano alla forma agentic

Le Lambda MicroVMs si allineano con il modo in cui gli agent si comportano davvero, su tre assi.

Isolamento che regge contro l'output ostile

Ogni sessione viene eseguita nella propria Firecracker MicroVM: nessun kernel condiviso, nessuna risorsa condivisa, nessun percorso da un ambiente all'altro o verso l'host. Quando il tuo agent esegue codice prodotto da un modello linguistico a partire dal prompt di un utente, quello è il confine che vuoi tra "l'agent ha fatto qualcosa di strano" e "l'agent ha compromesso la piattaforma." Un agent vittima di prompt injection che decide di esfiltrare o distruggere resta contenuto in una VM usa e getta.

Stato che corrisponde a un task multi-step

Il lavoro di un agent è raramente uno solo. Installa un pacchetto, carica un dataset, scrive file intermedi e ci ritorna tre passi più tardi. Una MicroVM mantiene memoria, disco e processi in esecuzione attraverso la sessione, e può sospendere con quello stato intatto durante le lunghe pause mentre il modello pensa o l'utente si allontana, per poi riprendere quasi istantaneamente. I modelli caricati e i set di file su cui si sta lavorando sono semplicemente ancora lì. È un adattamento molto migliore rispetto a ri-effettuare il bootstrap di un container nuovo a ogni chiamata di tool.

Avvio abbastanza rapido da sembrare interattivo

Poiché ogni MicroVM riprende da uno snapshot Firecracker pre-inizializzato invece di fare un cold boot, anche una sessione da diversi gigabyte torna su rapidamente. Per un agent interattivo dove un essere umano sta osservando il cursore lampeggiare, la differenza tra una ripresa da snapshot e l'avvio a freddo di un container è la differenza tra usabile e abbandonato. Le sessioni possono durare fino a 8 ore, il che copre comodamente una lunga analisi o una sessione di coding prolungata.

AWS sta costruendo l'intero loop dell'agent, non solo il runtime

Il lancio delle MicroVM non è arrivato da solo. AWS ha anche rilasciato una agent setup guide che collega gli agent di coding, Claude Code, Codex, Cursor, Kiro, Copilot, Windsurf, OpenCode, allo sviluppo serverless tramite plugin, agent skill e un MCP Server. Leggi i due insieme e la strategia è chiara: gli agent ti aiutano a costruire l'applicazione serverless, e le MicroVMs sono il luogo dove il codice che quegli agent generano può essere eseguito in sicurezza. AWS sta cercando di possedere entrambi i lati del loop, l'agent che scrive e il sandbox che esegue.

Cosa non risolve

L'isolamento è un confine, non un cervello. Una MicroVM impedisce al codice generato dal modello di evadere dal suo sandbox. Non fa nulla per impedire all'agent di fare qualcosa di stupido ma permesso dentro la scatola, o di ricevere credenziali che permettono al raggio d'impatto di estendersi oltre. Se monti segreti reali o assegni al sandbox un ruolo IAM ampio, il confine della VM è irrilevante rispetto al danno che un prompt iniettato può fare attraverso chiamate API legittime. Limita ciò che il sandbox può raggiungere con la stessa rigidità con cui lo isoli. Il runtime è la metà facile; il least-privilege per l'agent resta a carico tuo.

La conclusione

Per gran parte del boom agentic, la domanda sul runtime, dove viene davvero eseguito il codice generato, è stata risolta con il nastro adesivo: un container qui, un processo blindato là, un pool di VM fatto in casa per i team che potevano permetterselo. Le Lambda MicroVMs trasformano tutto questo in una primitiva gestita con isolamento a livello di VM, sessioni stateful e ripresa alla velocità di uno snapshot, esposta come una chiamata API. Non rende il tuo agent più intelligente o più sicuro in ciò che decide di fare. Dà al codice che scrive un luogo dove essere eseguito che non può mandare giù tutto ciò che lo circonda, e per gli agent in produzione, quello era il pezzo mancante.

Leggi questo dopo

Per l'analisi serverless e infrastrutturale dello stesso lancio, il ciclo di vita, la CLI e dove si colloca rispetto al normale Lambda, vedi le field notes su ercan.cloud. Per consulenza su AI, AWS e lavoro di piattaforma, o anche solo per salutare, parti da ercanermis.com.

Riferimenti