aws-lambda-microvms

Builds, runs, and operates Firecracker-isolated MicroVMs on AWS Lambda with snapshot resume.

Updated Jul 21, 2026
One-click install
npx skills add https://github.com/richardnroman/Synthetic-Data-Exchange-Licensing-Platform --skill aws-lambda-microvms-richardnroman
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: aws-lambda-microvms
Source: https://github.com/richardnroman/Synthetic-Data-Exchange-Licensing-Platform/tree/main/.agents/skills/aws-lambda-microvms
Command: npx skills add https://github.com/richardnroman/Synthetic-Data-Exchange-Licensing-Platform --skill aws-lambda-microvms-richardnroman

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve? Running untrusted code, long-lived sessions, or multi-tenant workloads on standard serverless functions is limited by 15-minute timeouts, per-invocation isolation, and no persistent in-memory state. This Skill guides you through packaging, deploying, and operating AWS Lambda MicroVMs — Firecracker-isolated compute environments that boot from snapshots, suspend and resume with state preserved, and live up to 8 hours. ## Core Features & Use Cases - Image Build & Snapshot Workflow: Package an app as a zip with a Dockerfile, create a MicrovmImage from a managed base image, and let Lambda capture a memory + disk snapshot for fast cold starts. - Lifecycle Hook Implementation: Implement /ready, /validate, /run, /resume, /suspend, and /terminate hooks to control snapshot timing, per-VM initialization, and graceful shutdown. - Networking, Auth & Shell Access: Configure auth tokens with per-port scoping, WebSocket subprotocols, VPC egress connectors, and SHELL_INGRESS for interactive debugging. - Use Case: An AI agent platform needs an isolated sandbox per user session to execute untrusted code. Use this Skill to build a MicroVM image, run one MicroVM per session, mint scoped auth tokens, and auto-suspend idle sessions to control cost. ## Quick Start Ask the assistant to walk you through creating a Lambda MicroVM image from a Dockerfile zip in S3 and running your first MicroVM with an auth token.

Frequently Asked Questions about aws-lambda-microvms

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I create and run an AWS Lambda MicroVM?▼

Zip your app with a Dockerfile at the root, upload to S3 in the same region, then call create-microvm-image with a managed base image and build role. Once the build succeeds, call run-microvm with the image ARN, version, and execution role to get an endpoint.

When should I use Lambda MicroVMs instead of Lambda functions?▼

Use MicroVMs when you need sessions longer than 15 minutes, a real port-listening server like gRPC or WebSocket, state preserved across suspend and resume, or container-level access such as FUSE and eBPF. Use standard Lambda functions for short event-driven workloads under 15 minutes.

Why do all my MicroVMs share the same UUIDs or random values?▼

Every MicroVM boots from the same memory and disk snapshot, so anything generated at image build time is replicated across instances. Generate unique state in the /run hook or at first use, and use CSPRNGs like Python's secrets module that reseed on snapshot resume.

How do I authenticate requests to a MicroVM endpoint?▼

Call create-microvm-auth-token with an expiration up to 60 minutes and an allowedPorts list, then send the token in the X-aws-proxy-auth header. For browsers and WebSockets, pass the token via the lambda-microvms.authentication subprotocol instead.

Why does my MicroVM return 502 errors after starting?▼

A 502 usually means the app is not listening on the routed port (default 8080), there is a TLS mismatch with the proxy, or the app crashed after run. Check CloudWatch logs and verify the port with the X-aws-proxy-port header.

What are the limitations of AWS Lambda MicroVMs?▼

MicroVMs live at most 8 hours, auth tokens expire after 60 minutes, images are single-size, and network connectors cannot be swapped after suspend. Workloads needing continuous compute beyond 8 hours should use ECS, EKS, or EC2 instead.