aws-lambda-microvms

Builds, runs, and operates Firecracker-isolated MicroVMs on AWS Lambda via CLI workflows.

2.5k|282|Updated Apr 23, 2026
One-click install
npx skills add https://github.com/aws/agent-toolkit-for-aws --skill aws-lambda-microvms
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: aws-lambda-microvms
Source: https://github.com/aws/agent-toolkit-for-aws/tree/main/skills/specialized-skills/serverless-skills/aws-lambda-microvms
Command: npx skills add https://github.com/aws/agent-toolkit-for-aws --skill aws-lambda-microvms

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve?

Running untrusted code, multi-tenant workloads, or long-lived sessionful servers requires strong isolation that standard Lambda functions (15-minute limit, per-invocation model) cannot provide. This Skill guides AI agents through packaging, building, running, and operating AWS Lambda MicroVMs — Firecracker-isolated, snapshot-resumable compute environments with up to 8-hour lifetimes.

Core Features & Use Cases

  • Image build and run workflow: Package a Dockerfile-based zip to S3, create a MicrovmImage with lifecycle hooks, run MicroVMs with idle policies, and authenticate traffic with scoped auth tokens.
  • Lifecycle and snapshot guidance: Implement /ready, /validate, /run, /resume, /suspend, and /terminate hooks correctly, and avoid the snapshot-uniqueness pitfall (shared PRNG seeds, UUIDs, secrets across instances).
  • Networking, IAM, and troubleshooting: Configure ingress/egress network connectors, WebSocket shell access for agents, build vs. execution IAM roles, and diagnose build failures, 502s, and hook timeouts.
  • Use Case: An AI coding agent needs a sandbox to execute user-supplied code. Use this Skill to build a MicroVM image, run an isolated environment per session, attach SHELL_INGRESS for command execution, and suspend/resume between turns.

Quick Start

Ask the agent to package a Flask app with a Dockerfile, create a Lambda MicroVM image from an S3 artifact, run a MicroVM, and call its endpoint 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 run 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?▼

Choose MicroVMs for long-lived sessions up to 8 hours, port-listening servers like gRPC or WebSocket, state preserved across suspend/resume, or strong multi-tenant isolation. Choose standard Lambda functions for event-driven workloads under 15 minutes.

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

State generated during image build is captured in the snapshot and replicated across every MicroVM. Generate unique values in the /run hook or at first use, and use CSPRNGs like Python's secrets module or Node's crypto.randomBytes that reseed on 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 WebSockets, pass the token via the lambda-microvms.authentication subprotocol.

Why does my MicroVM return 502 errors after starting?▼

A 502 usually means the app is not listening on the routed port (default 8080), 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 have a maximum 8-hour lifetime, 16 vCPUs and 32 GB memory per instance, 60-minute auth token TTL, and no self-suspend from inside the VM. Network connectors are bound at run time and cannot be swapped on resume.