AWS Lambda MicroVMs for Secure AI Code Sandboxes

DEV Community

Lambda MicroVMs: run AI code safely in a sandbox

Lambda MicroVMs are the building block I had been waiting for to solve one very specific problem: running code that I did not write myself. An AI assistant suggests a solution, an agent wants to test it, a learning platform lets beginners write their first loops. Simply running that code inside your own Lambda function would be reckless. Operating a container cluster just for sandboxes, on the other hand, feels a lot like “servers are back”. On November 11, 2026, AWS added x86 support to MicroVMs, and that was my reason to take a thorough look. In this article we build a small code sandbox together: one MicroVM per learning session, controlled by a Lambda function that you deploy with the Serverless Framework. On top of that you get my honest take on where the model shines and where you are better off sticking with regular functions. In short Lambda MicroVMs start an isolated VM with its own HTTPS endpoint from a snapshot. It lives for up to eight hours and is put to sleep when idle. This lets you build sandboxes for AI-generated or third-party code without running servers. The biggest pitfall: outbound internet access is open by default, and for untrusted code you have to close it deliberately. What you will learn in this article What Lambda MicroVMs are and how they differ from Lambda functions How the snapshot, the /ready hook and the /run hook work together How to build a code sandbox step by step with TypeScript and the Serverless Framework Which security settings are mandatory for untrusted code What a session costs What are Lambda MicroVMs? A MicroVM is a very lightweight virtual machine. AWS builds it on Firecracker, the same virtualization technology that regular Lambda functions run on. What is new is that you now control the VM yourself: you start it, it gets its own HTTPS endpoint, it keeps its memory and disk state, and when it is idle it is put to sleep instead of being thrown away. The trick behind this is the snapshot. When you create a MicroVM image, Lambda runs your Dockerfile, starts your application and waits until it reports that it is ready. Then Lambda freezes the complete state of memory and disk. Every new MicroVM starts from this frozen state, so your application does not have to boot again. If you know SnapStart, you will recognize the principle. Two more terms come up all the time. Suspend means the VM is paused, memory and disk are kept, and you only pay for storing the state. Resume wakes it up again, automatically on the next request if you want. In addition, there are hooks: HTTP endpoints in your application that Lambda calls at fixed points in the lifecycle, for example /ready during the build or /run when a new VM starts. Lambda function or MicroVM: the difference Lambda function Lambda MicroVM Invocation event or invoke, Lambda distributes the load own HTTPS endpoint per VM, no load balancer Duration at most 15 minutes per invocation up to 8 hours including suspend State ephemeral, no guarantee between invocations memory and disk survive a suspend Isolation execution environment is reused for invocations of the same function one VM per session, job or tenant, full operating system Billing per request and duration baseline size per second while RUNNING, storage cost while suspended Bottom line: functions are built for many short, similar invocations. MicroVMs are meant for longer, stateful sessions in which someone (or something) brings code you do not trust. When are Lambda MicroVMs worth it? Among other use cases, AWS lists sandboxes for AI code, interactive development environments, notebooks, security scans and multi-tenant CI/CD runners. I would make the decision with three questions. First: are you running code you do not control? If yes, a dedicated VM per session is the cleanest boundary you can get with serverless. Second: does the session need state for minutes or hours, for example installed packages, an open database connection or a conversation with an agent? That is where su...

Powered by Readybot.io