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.