I tried code generation considering the uniqueness problem with a skill published on the same day as the Lambda MicroVMs release
This page has been translated by machine translation. View original
Introduction
On June 22, 2026, AWS announced Lambda MicroVMs. It is a serverless compute environment that runs containers inside Firecracker microVMs, providing VM-level isolation, fast startup, and suspend/resume of up to 8 hours.
On the same day, Lambda MicroVMs skills were also added to the official AWS repository agent-toolkit-for-aws. These are a collection of structured references containing service-specific design knowledge for AI agents.
Lambda MicroVMs introduces many unique concepts such as snapshot-based startup, lifecycle hooks, and suspend/resume, making the presence or absence of skills a significant factor in the development experience.
| Traditional Approach | Skill-Based Approach |
|---|---|
| Write code while referencing official documentation each time | Pass skills to AI agents to generate code informed by design knowledge |
| Learn pitfalls like the uniqueness problem through experience | Best practices described in skills are more likely to be reflected |
| Humans point out MicroVM-specific issues during review | AI with skills can more easily avoid problems at code generation time |
This article introduces the structure of these skills and demonstrates how code generation quality changes with and without them.
Lambda MicroVMs Skill Structure
agent-toolkit-for-aws is a GitHub repository that provides a collection of AI agent skills specialized for AWS services. Each skill consists of a SKILL.md (overview, decision criteria, typical workflows, constraints) and references/ (a collection of service-specific detailed references).
The Lambda MicroVMs skill is composed of the following files.
aws-lambda-microvms/
├── SKILL.md
└── references/
├── getting-started.md
├── lifecycle-model.md
├── snapshots-and-uniqueness.md
├── networking.md
├── iam-and-security.md
└── troubleshooting.md
| File | Role |
|---|---|
| SKILL.md | Overview, use case decisions, typical workflows, constraints, security considerations |
| getting-started.md | Prerequisites, packaging, CLI walkthrough for initial startup |
| lifecycle-model.md | Image/MicroVM state transitions, details on 6 lifecycle hooks |
| snapshots-and-uniqueness.md | How snapshots work and the uniqueness problem, per-language CSPRNG table |
| networking.md | Ingress/Egress connectors, port routing, WebSocket |
| iam-and-security.md | Build role/execution role, auth tokens, Confused Deputy countermeasures |
| troubleshooting.md | Error codes, debugging procedures, investigation via shell access |
Highlights of SKILL.md
SKILL.md consolidates the information that serves as the AI agent's "judgment capability."
description (opening) — This is the information the AI uses to decide whether to select a skill. It lists the use cases where Lambda MicroVMs is appropriate (AI sandboxes, multi-tenant CI, game servers, etc.).
When to use / Choose something else — Clear criteria are provided for choosing between Lambda MicroVMs, regular Lambda functions, and ECS/EKS. This serves as a decision basis for the AI when proposing architectures and selecting the appropriate service.
Typical workflow — An overview from image creation to token issuance is shown with CLI commands.
Known constraints — Design-time constraints are described, such as images having a fixed size and the maximum TTL for authentication tokens being 60 minutes. The timeout for runtime hooks is a maximum of 60 seconds.
Security considerations — Security considerations are summarized, including Confused Deputy countermeasures, snapshot uniqueness, network isolation, and least-privilege execution roles.
How to Pass Skills to AI Agents
To use skills, load them into the AI agent's context. The main methods are as follows.
- Kiro — Add the repository or files to the Knowledge Base
- Claude (API) — Include skill content in the system prompt
- Amazon Q Developer — Reference via customization settings
- GitHub Copilot — Place in the repository or include in custom instructions
SKILL.md alone is effective, but passing the references inside references/ together yields more accurate generation. For this verification, the content of snapshots-and-uniqueness.md was passed by prepending it to the prompt in Kiro CLI's headless mode.
Verification: Code Generation for Avoiding the Snapshot Uniqueness Problem
Background: What is the Snapshot Uniqueness Problem?
Since Lambda MicroVMs starts multiple VMs from the same snapshot, values held at the time the snapshot was created can be duplicated across VMs. The following article verifies this in detail.
Verification Method
Using Kiro CLI's headless mode (--no-interactive) with the following common prompt, code generation was executed 3 times each for 2 patterns: without skills and with skills.
Common Prompt:
Please create a Flask app for Lambda MicroVMs.
Requirements:
- Generate a session ID when the app starts and retain it in memory
- Return a random token for each request
- GET /session returns the session ID
- GET /token returns a random token
- Also create a Dockerfile (base: public.ecr.aws/lambda/microvms:al2023-minimal)
- Output code only (no explanations needed)
In the with skills case, snapshots-and-uniqueness.md was prepended to the above prompt.
Verification Environment:
- Kiro CLI + Claude Sonnet 4 (
--model claude-sonnet-4) — 3 times each pattern - Claude Code + Opus 4.8 (
claude -p --model opus) — 3 times each pattern (additional trial)
Results: Without Skills (Same Pattern All 3 Times)
import uuid
import secrets
from flask import Flask, jsonify
app = Flask(__name__)
session_id = str(uuid.uuid4()) # ❌ Generated in global scope (at build time)
@app.route('/session')
def get_session():
return jsonify({'session_id': session_id})
@app.route('/token')
def get_token():
return jsonify({'token': secrets.token_hex(16)})
if __name__ == '__main__':
app.run(host='0.0.0.0', port=8080)
Since session_id is fixed at module load time (= when the snapshot is taken), all MicroVMs share the same session_id. Because the existence of the /run hook is unknown, no countermeasures are taken against the session_id uniqueness problem.
Results: With Skills (Representative Example: Run 1)
import os
import secrets
from flask import Flask, jsonify
app = Flask(__name__)
# Session ID is generated after the /run hook
session_id = None
@app.route('/session')
def get_session():
return jsonify({'session_id': session_id})
@app.route('/token')
def get_token():
return jsonify({'token': secrets.token_hex(16)})
@app.route('/run', methods=['POST'])
def run_hook():
global session_id
# Generate a unique session ID after snapshot resume
session_id = secrets.token_hex(8)
return '', 204
if __name__ == '__main__':
app.run(host='0.0.0.0', port=int(os.environ.get('PORT', 8080)))
Scoring
| Aspect | Without Skills (Sonnet 4) | With Skills (Sonnet 4) |
|---|---|---|
| Session ID generation location | ❌ Global | ✅ /run hook |
| Session ID generation method | ❌ uuid4() at build time |
✅ secrets.token_hex |
| Token generation method | ✅ secrets.token_hex |
✅ secrets.token_hex |
/run hook implementation |
❌ None | ✅ Present |
| Reference to uniqueness | ❌ None | ✅ With comment |
| Average Score | 1.0/5 | 4.67/5 |
Raw scores per run: With skills: 5/5, 5/5, 4/5 (Run 3 used uuid4() instead of the expected secrets API despite generating within /run, hence -1). Scores were calculated as the number of achieved criteria out of 5 aspects (1 point each, ⚠️ = 0.5 points) per trial, then averaged over 3 runs.
Analysis
Without skills, the model responded based on general knowledge of "creating a Flask app" and was unable to account for the special nature of Lambda MicroVMs' snapshot-based startup.
With skills, all 3 runs correctly implemented the /run hook and avoided the snapshot uniqueness problem. The following description in snapshots-and-uniqueness.md may have influenced this.
Generate it in
/run. This hook fires once after run (post-snapshot resume) and is the canonical place to create per-VM unique state.
Having this reference containing this description in the context is thought to have made it easier for the model to choose the pattern of generating unique values within the hook.
Additional Trial: Verification with Claude Code (Opus 4.8)
To confirm whether a similar trend would be observed with a different model, an additional trial was conducted with Claude Code (Opus 4.8) using the same prompt.
| Aspect | Without Skills (Opus 4.8) | With Skills (Opus 4.8) |
|---|---|---|
| Session ID generation location | ❌ Global | ✅ /run hook |
| Session ID generation method | ⚠️ secrets but global |
✅ secrets.token_hex |
| Token generation method | ✅ secrets.token_hex |
✅ secrets.token_urlsafe |
/run hook implementation |
❌ None | ✅ Present |
| Reference to uniqueness | ❌ None | ✅ Comment + docstring |
| Average Score | 1.5/5 | 5.0/5 |
Without skills (Opus): All 3 runs generated in global scope. In this verification, cases using secrets.token_hex were observed, but the /run hook was never implemented even once.
With skills (Opus): Perfect score all 3 runs. In addition to the /run hook + secrets.token_hex, the implementation even included blocking requests with threading.Event until /run completion.
# Opus 4.8 with skills (representative example) — with /run completion waiting
_session = {"id": None, "microvmId": None}
_session_ready = threading.Event()
@app.route("/run", methods=["POST"])
def run_hook():
payload = request.get_json(silent=True) or {}
_session["id"] = secrets.token_hex(16)
_session["microvmId"] = payload.get("microvmId")
_session_ready.set()
return jsonify({"status": "ok", "sessionId": _session["id"]})
@app.route("/session", methods=["GET"])
def get_session():
_session_ready.wait() # Wait until /run completes
return jsonify({"sessionId": _session["id"]})
The higher the model capability, the greater the accuracy with skills, but in this verification, neither model was able to avoid the uniqueness problem without skills. At least within the scope of this verification, the results suggest that the presence or absence of skills (domain knowledge) had a significant impact on the generation results.
Notes
- AI generation results vary between trials. The results here indicate that "having skills increases the probability of safe code generation," and this is not guaranteed to always be the case
- Safe code may still be generated without skills. However, in this verification (2 models × 3 runs each = 6 total runs), the
/runhook was never implemented without skills even once - For actual production use, it is recommended to review AI-generated code from the perspective of
/runhook implementation and snapshot uniqueness
Summary
On the same day Lambda MicroVMs was released, Lambda MicroVMs skills for AI agents were also added to agent-toolkit-for-aws. These skills are a mechanism for passing MicroVM-specific design knowledge—such as snapshot-based startup and lifecycle hooks—to AI agents.
In this verification, by including snapshots-and-uniqueness.md in the context, session ID generation was implemented within the /run hook in all trials, and the snapshot uniqueness problem was avoided across all evaluation criteria. Without skills, all runs generated session IDs in global scope, and MicroVM-specific uniqueness considerations were not taken into account.
When using new services with AI agents, you can reduce the likelihood of falling into service-specific pitfalls by "first passing the official skills before generating code." This approach appears useful not only for code generation, but also for reviewing existing code and troubleshooting.
