DEV Community: Ajit

Lambda MicroVM Architecture: A Deep Dive into Strengths, Limitations, and Real-World Patterns

Ajit — Mon, 07 Sep 2026 12:45:53 +0000

Introduction

When AWS Lambda processes your function invocation, something remarkable happens beneath the surface. Your code doesn't run on a bare metal server or inside a traditional virtual machine — it executes within a MicroVM, a purpose-built virtualization technology called Firecracker that AWS open-sourced in 2018. Understanding how Lambda's MicroVM architecture works isn't just an academic exercise. It directly influences how you design functions, manage cold starts, optimize performance, and make architectural trade-offs in serverless applications.

This post explores Lambda's MicroVM model through a practical lens: what makes it powerful, where it falls short, and how real-world projects on GitHub are working around its constraints. Whether you're building event-driven pipelines, containerized workloads, or latency-sensitive APIs, knowing what's happening at the virtualization layer helps you write better serverless code.

What Is a Lambda MicroVM, and Why Does It Exist?

Traditional hypervisors like KVM or Xen were designed for long-running, general-purpose workloads. They carry significant overhead — both in memory footprint and boot time — that makes them poorly suited for functions that may execute for milliseconds and then sit idle for hours.

Firecracker, the engine behind Lambda's MicroVM model, was engineered specifically to solve this problem. It's a Virtual Machine Monitor (VMM) written in Rust that uses Linux's KVM interface but strips away everything unnecessary: no BIOS emulation, no legacy device support, no GUI subsystems. The result is a hypervisor that can boot a minimal Linux kernel and launch a process in under 125 milliseconds, with a memory overhead as low as 5 MB per MicroVM.

Each Lambda execution environment runs inside its own dedicated MicroVM, providing:

Hardware-level isolation between tenants on the same physical host
A dedicated kernel per execution environment (not just a container namespace)
A minimal attack surface — Firecracker exposes fewer than 20 emulated devices

This architecture is what allows AWS to safely run millions of customer functions on shared infrastructure without compromising security boundaries.

Strengths: Where Lambda MicroVMs Excel

1. Security Isolation Without Compromise

The most significant advantage of the MicroVM model is the security boundary it creates. Unlike container-based isolation (which relies on Linux namespaces and cgroups), each Lambda execution environment has its own dedicated kernel. A kernel exploit in one tenant's environment cannot propagate to another because the attack surface is bounded by the virtualization layer.

This matters in multi-tenant environments where functions from different AWS accounts may coexist on the same physical hardware. The Firecracker threat model explicitly addresses this: even if an attacker achieves arbitrary code execution inside a MicroVM, they cannot escape to the host or to neighboring VMs.

For regulated workloads — financial services, healthcare, government — this isolation model provides a compliance-friendly foundation that pure container runtimes struggle to match.

2. Fast Boot Times Enable True Serverless Economics

Firecracker's sub-125ms boot time is what makes Lambda's pricing model viable. AWS can spin up a new execution environment on demand, route a single invocation through it, and reclaim those resources — all without the economics breaking down.

From a developer perspective, this translates to cold start times that, while noticeable, are measured in hundreds of milliseconds rather than seconds. A Python 3.12 Lambda function with no dependencies can cold-start in roughly 200–400ms end-to-end, with the MicroVM initialization representing only a fraction of that total.

3. Consistent, Predictable Resource Allocation

Each MicroVM receives a fixed allocation of vCPU and memory based on the Lambda configuration you specify. There's no noisy-neighbor CPU contention at the virtualization layer — Firecracker's jailer process enforces strict resource limits using cgroups before the MicroVM even starts.

This predictability is valuable when you're running CPU-intensive workloads like image processing, ML inference, or data transformation. The performance characteristics you observe in testing will closely match production behavior.

4. Snapshots and the SnapStart Optimization

AWS Lambda SnapStart (available for Java runtimes) leverages Firecracker's snapshot capability to dramatically reduce cold start latency. When you publish a SnapStart-enabled function version, Lambda initializes the execution environment, runs your initialization code, and then takes a snapshot of the MicroVM's memory state.

On subsequent cold starts, Lambda restores from this snapshot rather than booting a fresh MicroVM and re-running initialization. The result is cold start improvements of up to 90% for Java workloads that previously suffered 5–10 second initialization times.

// Lambda SnapStart - annotate your handler to signal initialization work
@Slf4j
public class OrderProcessor implements RequestHandler<APIGatewayProxyRequestEvent, APIGatewayProxyResponseEvent> {

    // This static initialization block runs ONCE during snapshot creation
    // not on every cold start when SnapStart is enabled
    private static final DynamoDbClient dynamoClient;
    private static final ObjectMapper mapper;

    static {
        log.info("Initializing heavyweight resources during snapshot phase");
        dynamoClient = DynamoDbClient.builder()
            .region(Region.US_EAST_1)
            .build();
        mapper = new ObjectMapper();
    }

    @Override
    public APIGatewayProxyResponseEvent handleRequest(
            APIGatewayProxyRequestEvent event, Context context) {
        // Handler logic benefits from pre-initialized resources
        return processOrder(event, dynamoClient, mapper);
    }
}

Limitations: The Real Constraints You Need to Plan Around

1. Cold Starts Remain a Structural Reality

Despite Firecracker's fast boot times, cold starts are an inherent characteristic of the MicroVM model. Every time Lambda needs to create a new execution environment — whether due to scaling, a deployment, or a long idle period — a MicroVM must be initialized, the runtime must start, and your initialization code must run.

For latency-sensitive applications, this creates architectural pressure. Common mitigation strategies include:

Provisioned Concurrency: Pre-warms a specified number of execution environments, keeping MicroVMs initialized and ready to serve requests
Scheduled warming: Using EventBridge rules to invoke functions on a schedule, though this is less reliable than Provisioned Concurrency
Architecture redesign: Moving latency-sensitive paths to always-warm services like ECS or App Runner

# serverless.yml - Configure Provisioned Concurrency to eliminate cold starts
functions:
  orderApi:
    handler: src/handler.main
    memorySize: 1024
    timeout: 30
    provisionedConcurrency: 10  # Keep 10 MicroVMs pre-initialized
    events:
      - httpApi:
          path: /orders
          method: POST

2. Execution Duration and Stateless Constraints

Lambda functions have a hard maximum execution timeout of 15 minutes. This isn't a Firecracker limitation per se, but it reflects the design philosophy of the MicroVM model: short-lived, stateless compute. Any workload that requires persistent state, long-running processes, or execution beyond 15 minutes needs a different compute model.

Additionally, the MicroVM's filesystem is ephemeral. The /tmp directory provides up to 10 GB of ephemeral storage, but this disappears when the execution environment is recycled. Workloads that need durable local storage must externalize state to S3, EFS, or DynamoDB.

3. Limited System-Level Access

Because Lambda runs your code inside a locked-down MicroVM, you don't have access to many operating system primitives that you might take for granted on EC2:

No raw socket access (limits certain networking use cases)
No ability to load custom kernel modules
Restricted /proc and /sys filesystem access
No systemd or init system — your function is the only process (beyond the runtime)

This creates friction for workloads that depend on system-level tools, custom kernel features, or specific OS configurations. Container image deployments (up to 10 GB) provide more flexibility, but the fundamental MicroVM constraints still apply.

4. Networking Latency in VPC Configurations

When Lambda functions run inside a VPC, each execution environment requires an Elastic Network Interface (ENI). Historically, ENI attachment was a major source of cold start latency — adding 10+ seconds in some cases. AWS largely resolved this with Hyperplane ENIs (VPC-to-VPC NAT), which pre-allocate network interfaces and dramatically reduce VPC cold start overhead.

However, VPC-attached Lambda functions still experience higher cold starts than non-VPC functions, and the complexity of VPC configuration (subnets, security groups, NAT gateways) adds operational overhead that teams should factor into their architecture decisions.

5. Memory as the Single Scaling Dimension

Lambda allocates CPU proportionally to memory. You cannot independently configure vCPU allocation — if you need more CPU, you increase memory, which also increases cost. For CPU-bound workloads, this creates a cost inefficiency: you may need to allocate 3008 MB of memory not because your function needs that RAM, but because it needs the proportional CPU allocation.

The AWS Lambda Power Tuning tool (discussed below) helps navigate this trade-off empirically.

Notable GitHub Projects That Work With Lambda MicroVM Constraints

The open-source community has built a rich ecosystem of tools that either expose Firecracker's capabilities or help developers work around Lambda's MicroVM limitations. Here are four projects worth knowing:

1. Firecracker (aws/firecracker)

Repository: github.com/alexcasalboni/aws-lambda-power-tuning

The Firecracker VMM itself is open source and actively maintained. Beyond Lambda, it powers AWS Fargate and can be run independently for custom MicroVM workloads. If you're building a platform that needs Lambda-like isolation without Lambda's constraints, Firecracker is the foundation.

# Launch a Firecracker MicroVM directly (for platform engineering use cases)
# Download the Firecracker binary
curl -Lo firecracker https://github.com/firecracker-microvm/firecracker/releases/download/v1.6.0/firecracker-v1.6.0-x86_64

chmod +x firecracker

# Start Firecracker with an API socket
./firecracker --api-sock /tmp/firecracker.socket

2. AWS Lambda Power Tuning (alexcasalboni/aws-lambda-power-tuning)

Repository: github.com/alexcasalboni/aws-lambda-power-tuning

This Step Functions-based tool runs your Lambda function across multiple memory configurations and visualizes the cost/performance trade-off. Given that MicroVM resource allocation scales with memory, this tool is essential for finding the optimal configuration.

{
  "lambdaARN": "arn:aws:lambda:us-east-1:123456789:function:my-function",
  "powerValues": [128, 256, 512, 1024, 2048, 3008],
  "num": 50,
  "payload": {"test": "event"},
  "parallelInvocation": true,
  "strategy": "cost"
}

3. AWS Lambda Web Adapter (awslabs/aws-lambda-web-adapter)

Repository: github.com/awslabs/aws-lambda-web-adapter

This project lets you run conventional web frameworks (Express, FastAPI, Spring Boot) inside Lambda without modifying your application code. It works by running your HTTP server as a process inside the MicroVM and proxying Lambda invocations to it — effectively treating the MicroVM as a lightweight container runtime.

# Dockerfile - Run a FastAPI app inside Lambda MicroVM using Web Adapter
FROM public.ecr.aws/lambda/python:3.12

# Copy the Lambda Web Adapter binary
COPY --from=public.ecr.aws/awsguru/aws-lambda-adapter:0.8.1 \
    /lambda-adapter /opt/extensions/lambda-adapter

WORKDIR /app
COPY requirements.txt .
RUN pip install -r requirements.txt

COPY app.py .

# Web Adapter will start this process and proxy requests to port 8000
CMD ["uvicorn", "app:app", "--host", "0.0.0.0", "--port", "8000"]

4. Serverless Spy (ServerlessLife/serverless-spy)

Repository: github.com/ServerlessLife/serverless-spy

Testing event-driven Lambda architectures is notoriously difficult because the MicroVM execution model makes traditional debugging approaches (attaching a debugger, inspecting process state) impractical. Serverless Spy intercepts Lambda invocations and publishes execution data to WebSockets, enabling real-time test assertions against live Lambda functions.

Architectural Best Practices for MicroVM-Aware Lambda Design

Understanding the MicroVM model should directly inform how you structure Lambda functions:

Initialize outside the handler: Code in the global scope runs during MicroVM initialization and is reused across warm invocations. Database connections, SDK clients, and configuration loading belong here.

import boto3
import json

# Initialized ONCE during MicroVM setup — reused across warm invocations
dynamodb = boto3.resource('dynamodb')
table = dynamodb.Table('Orders')

def handler(event, context):
    # This code runs on every invocation
    # but benefits from the pre-initialized `table` client
    order_id = event['pathParameters']['orderId']

    response = table.get_item(Key={'orderId': order_id})

    return {
        'statusCode': 200,
        'body': json.dumps(response.get('Item', {}))
    }

Right-size memory for your workload type: Use Lambda Power Tuning to find the memory configuration where cost and performance intersect optimally. CPU-bound functions often benefit from higher memory; I/O-bound functions often don't.

Externalize all state: Design functions assuming the MicroVM will be recycled after every invocation. Use S3 for files, DynamoDB or ElastiCache for application state, and SQS/EventBridge for inter-function communication.

Use container images for complex dependencies: If your function requires system libraries, custom binaries, or a large dependency tree, package it as a container image (up to 10 GB). The MicroVM still provides the same isolation guarantees, but you gain full control over the filesystem layout.

Conclusion

Lambda's MicroVM architecture represents a genuine engineering achievement: hardware-level tenant isolation with boot times measured in milliseconds. Firecracker makes the economics of serverless compute work, and understanding its design helps you make better decisions about when Lambda is the right tool and how to use it effectively.

The strengths — fast initialization, strong isolation, predictable resource allocation, and SnapStart optimization — make Lambda MicroVMs compelling for event-driven workloads, API backends, and data processing pipelines. The limitations — cold starts, 15-minute execution caps, restricted system access, and the memory-CPU coupling — define the boundaries where you should consider ECS, Fargate, or EC2 instead.

The open-source ecosystem around Firecracker and Lambda tooling continues to mature rapidly. Projects like Lambda Web Adapter are blurring the line between "serverless functions" and "containerized services," while Power Tuning gives teams empirical data for cost optimization decisions.

The most effective serverless architects aren't the ones who avoid Lambda's constraints — they're the ones who understand them deeply enough to design around them.

For further reading, explore the Firecracker design documentation and the AWS Lambda operator guide for production best practices.

How I Used Kiro Web + Graviton Migration Power to Audit My Production SaaS in 21 Seconds

Ajit — Tue, 12 May 2026 06:06:58 +0000

The Problem

I run a production SaaS on AWS Lambda (Python 3.12, 7 source files, boto3 + MCP dependencies). All functions on x86_64. AWS Graviton2 offers 20% cheaper duration charges — but switching without
verifying ARM64 compatibility is risky.

The manual audit process:

Check every pip dependency for native C extensions
Verify no inline assembly or architecture-specific intrinsics
Confirm container base images support linux/arm64
Cross-reference AWS docs for runtime support

For a small codebase, this takes a few hours. For larger projects with numpy, pandas, or compiled extensions — days.

The Setup: Kiro Web + Graviton Migration Power

Kiro Web is AWS's agentic IDE in public preview. It runs an autonomous agent in a remote sandbox with Docker support, MCP servers, and installable "Powers" (domain-
specific tool packages).

Step 1: Install the Graviton Migration Power

From the AWS Agent Toolkit, I installed:

Graviton Migration Power (includes arm-mcp Docker container)
AWS MCP server (for account access)

The Power adds these tools to the agent:

migrate_ease_scan — scans code for ARM64 compatibility issues
check_image (skopeo) — verifies container images support linux/arm64
knowledge_base_search — queries Arm documentation

Step 2: Connect your repo

Fork/connect your GitHub repo to Kiro Web. The agent checks out your code in the sandbox.

Step 3: Run the analysis

Prompt:
Run the full Graviton Migration Power analysis on this codebase.
If required, install Docker in the sandbox.

What the Agent Did (Autonomously)

Verified Docker was running in the sandbox
Found the arm-mcp container active
Sent JSON-RPC requests to the MCP server:

json
{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"capabilities":{}}}
{"jsonrpc":"2.0","id":2,"method":"tools/call","params":{"name":"migrate_ease_scan","arguments":{"path":"/workspace","language":"python","target":"armv8-a"}}}

Scanned all Python files for:
- PythonPackageIssue (native extensions)
- PythonLinkLibraryIssue (linked libraries)
- PythonInlineAsmIssue (inline assembly)
- PythonIntrinsicIssue (architecture intrinsics)
Checked python:3.12-slim base image:
Architectures: amd64, arm64, arm, 386, ppc64le, riscv64, s390x
Queried knowledge base for Lambda Graviton pricing data

The Results

Scanner: Python (armv8-a target)
Files scanned: 7
Total issues found: 0
PythonPackageIssue: 0
PythonLinkLibraryIssue: 0
PythonInlineAsmIssue: 0
PythonIntrinsicIssue: 0

All dependencies verified:

Dependency	ARM64 Compatible	Reason
boto3	✅	Pure Python
mcp >= 1.19.0	✅	Pure Python
python:3.12-slim	✅	Multi-arch image

The Migration: 1 Line

yaml

CloudFormation

ApiFunction:
Type: AWS::Lambda::Function
Properties:
Architectures:
- arm64 # This is the entire migration
Runtime: python3.12
Handler: handler.handler

Or in CDK:
typescript
new lambda.Function(this, 'Api', {
architecture: lambda.Architecture.ARM_64, // Add this
runtime: lambda.Runtime.PYTHON_3_12,
handler: 'handler.handler',
});

Cost Impact

From AWS documentation:
│ Duration charges are 20% lower than x86 pricing with millisecond granularity. Up to 34% better price-performance.

For functions with 900-second timeouts running complex reviews, this is meaningful savings with zero code changes.

When This Gets Interesting

My codebase was pure Python — easy case. The Graviton Power becomes truly valuable when you have:

numpy/pandas — need to verify wheels exist for linux_aarch64
Compiled extensions (cryptography, lxml) — may need different build
Custom Docker images — need multi-arch builds
Inline assembly — rare in Python, common in C extensions

The scanner catches all of these. That's the point — you don't need to know what to look for.

TL;DR

Step	Time
Install Graviton Power	2 min (one-time)
Run analysis	21 seconds
Apply migration	1 line change
Cost savings	20% on Lambda duration

References:

I Used an AI "Skill" to Audit My CloudFormation Stack — Found a Broken Alarm Running for 3 Months

Ajit — Wed, 06 May 2026 05:30:43 +0000

TL;DR

Kiro CLI has a feature called "skills" — domain-specific expertise packages you can load on demand. I loaded the aws-cloudformation skill to validate my production Spot Fleet template. It found 4 critical issues including a CloudWatch alarm that literally never worked.

Situation

I run a development environment on AWS Spot instances — Kiro CLI, VS Code Server, persistent EBS, the works. The CloudFormation stack has been deployed since February 2026. It's been updated once, runs daily, and I considered it production-ready.

I was about to upgrade stack and wanted to validate my base template first.

Task

Verify whether my "security-hardened" template actually follows CloudFormation best practices before using it as the foundation for upgrade.

Action

Step 1 — Discover the skill:
search_documentation("CloudFormation deployment", topics=["agent_skills"])

This returned 5 relevant skills. I picked aws-cloudformation.

Step 2 — Load the skill:
retrieve_skill("aws-cloudformation")

What I got back wasn't generic advice. It was:

A structured 10-step authoring checklist
3-layer validation pipeline (syntax → security → pre-deploy)
Troubleshooting SOPs for failed stacks
Decision frameworks for template vs environment fixes

Step 3 — Load the reference SOP:
retrieve_skill("aws-cloudformation", file="references/author-cloudformation-best-practices.script.md")

This gave me the detailed checklist: resource naming, parameter design, security defaults, deletion policies, cross-stack references, conditions, outputs.

Step 4 — Apply it to my template:

I asked Kiro CLI to review CFN yaml against the skill's checklist.

Result

4 critical, 5 recommended, 1 strict finding.

Here's what hit hardest:

🔴 Critical #1: Broken CloudWatch Alarm (3 months undetected)

yaml
HighCPUAlarm:
Dimensions:
- Name: InstanceId
Value: !Ref SpotFleetRequest # ← This is a Fleet ID, not an Instance ID

My "cryptomining detection" alarm was monitoring a dimension that doesn't exist. It never evaluated. Never fired. I had zero protection for 3 months while thinking I was
covered.

Fix: Reference the actual instance ID (requires a Lambda or instance self-registration pattern since Spot Fleet instances are dynamic).

What Are "Skills" Exactly?

They're not prompts. They're not RAG documents. They're structured domain expertise packages containing:

Component	What it does
Workflows	Step-by-step procedures with decision points
Checklists	Deterministic validation (like the 10-step authoring review)
SOPs	Standard operating procedures for troubleshooting
Decision trees	"If X, do Y; if Z, do W" frameworks
Reference files	Architecture docs, schemas, examples

The CloudFormation skill has SOPs for:

Authoring with secure defaults
3-layer pre-deployment validation (cfn-lint → cfn-guard → change set)
Troubleshooting failed stacks (using describe-events --filters FailedEvents=true)
Resource property lookup

Key insight: The skill told me to use describe-events (newer API with filter support) instead of describe-stack-events (legacy, no filters). I didn't know this API existed.

How to Use Skills in Kiro CLI

bash

1. Search for relevant skills

(you can't guess skill names — they must be discovered)

search_documentation("your task description", topics=["agent_skills"])

2. Load the skill

retrieve_skill("exact-skill-name-from-search")

3. Load reference files if the skill links to them

retrieve_skill("skill-name", file="references/some-sop.md")

4. Apply — ask the AI to use the loaded expertise

"Review my template against the authoring checklist"
"Troubleshoot my failed stack using the SOP"
"Validate before I deploy"

Available skills I found:

aws-cloudformation — authoring, validation, troubleshooting
launching-ec2-instance-with-best-practices — secure EC2 launches
creating-production-vpc-multi-az — VPC design
creating-ec2-image-builder-pipeline — AMI automation
aws-cdk — CDK patterns and deployment

Lessons Learned

"It works" ≠ "It's correct." My stack ran fine for 3 months with a broken alarm. Functional doesn't mean secure.
Validate infrastructure like you lint code. We wouldn't ship code without tests. Why do we ship CloudFormation without a structured review?
AI skills > AI chat. A general "review my template" prompt gives generic advice. A loaded skill applies a deterministic, comprehensive checklist. The difference is like
asking a random person vs. asking a CloudFormation specialist with a clipboard.
The scariest bugs are silent ones. A broken alarm doesn't throw errors. It just... doesn't protect you.

The skill doesn't just find problems — it prevents them in new templates.

The Model Is the Brain. The Harness Is the Body. Here's Why That Matters

Ajit — Mon, 04 May 2026 05:18:31 +0000

TL;DR: I built the same browser agent twice — once with 500 lines of Python, once with 7 lines of JSON. The second one took 5 minutes. The agent harness layer is becoming the real competitive advantage, not the model.

Last month, I built a browser automation agent. Playwright. Custom orchestration. Login handlers. Error retries. Session management. React-aware form filling. Anti-detection scripts. 500+ lines of Python.

This week, I built the same thing:

{
  "model": { "provider": "bedrock", "modelId": "us.anthropic.claude-sonnet-4-6" },
  "tools": [{ "type": "agentcore_browser", "name": "browser" }],
  "systemPrompt": "You are a web browsing assistant."
}

Deploy. Invoke. It browses websites, extracts data, fills forms. Seven lines. Zero orchestration code.

But here's the thing most people miss: I kept both versions. And that's the real insight.

What Changed (and What Didn't)

	500-Line Script	7-Line Harness
What it does	Automates a specific multi-site workflow	Browses any website, extracts info
How it decides	I wrote every step	AI decides the steps
Cost per run	$0 (Playwright, local)	~$0.10-0.50 (Bedrock tokens)
Reliability	95%+ (deterministic)	~80% (AI reasoning varies)
Flexibility	Only does what I coded	Handles any browsing task
Time to build	3 days of debugging	5 minutes

The 500-line script is better for its specific job. It runs faster, cheaper, and more reliably. Because it doesn't need AI — the steps are known.

The 7-line harness is better for everything else. Research tasks. Data extraction from unfamiliar sites. Competitive analysis. Anything where the steps aren't known in advance.

This is my POV: deterministic + AI is the right architecture. Don't use a $0.03/call model to click a button you can click with Playwright for free. But don't write 500 lines of Playwright when 7 lines of config can handle it.

The Harness Is the New Battleground

Everyone's talking about which model is best. Claude vs GPT vs Gemini. Benchmarks. Context windows. Reasoning scores.

That conversation is becoming irrelevant.

Models are commoditizing. Claude Sonnet 4.6 and GPT-5.5 are both "good enough" for most agent tasks. The real question is: what wraps around the model to make it actually work in production?

That's the harness — the orchestration loop, tool execution, memory, security, compute isolation. And every cloud provider is racing to own it:

Provider	Harness Product	Status
AWS	AgentCore Harness	Preview (Apr 2026)
AWS	Bedrock Managed Agents (OpenAI-specific)	Limited Preview
Google	Gemini Enterprise Agent Platform	GA (Apr 2026)
Microsoft	Azure AI Agent Service	GA
Salesforce	Agentforce	GA

This is the container orchestration war all over again. In 2015, everyone had containers. The question was who manages running them. Kubernetes won, and whoever controlled K8s controlled where workloads ran.

In 2026, everyone has models. The question is who manages running agents. Whoever controls the harness controls the next decade of cloud spend.

How AgentCore Harness Works

You (prompt) → AgentCore Harness → Bedrock Model (reasoning)
                    ↓                      ↓
              Firecracker microVM    Tool selection
              (isolated per session)       ↓
                    ↓              AgentCore Browser / Shell / Code
              Persistent memory    
              (across sessions)    
                    ↓
              Streamed response → You

What AWS handles: compute, orchestration loop, tool invocation, memory, auth, observability.
What you handle: a JSON config and a prompt.

Each session runs in its own Firecracker microVM — the same isolation technology behind Lambda. Not a container. A VM. One session can't see another's data, cookies, or credentials.

Getting Started (I Actually Ran This)

# Install CLI
sudo npm install -g @aws/agentcore@preview

# Create project
agentcore create --name browseragent --model-provider bedrock
cd browseragent

# Add browser tool
agentcore add tool --harness browseragent --type agentcore_browser --name browser

# Set target account + region
# Edit agentcore/aws-targets.json: [{"name":"default","region":"us-west-2","account":"YOUR_ACCOUNT"}]

# Deploy (~3 min)
agentcore deploy --yes

# Use it
agentcore invoke --harness browseragent --stream \
  --prompt "Go to example.com and describe what you see"

Output from my actual run:

🔧 Tool: browser
⚡ 6005 in · 110 out · 2.2s
Here's what's on the page at example.com:
### Example Domain
The page contains: "Example Domain" heading, body text about documentation use,
and a "Learn more" link to IANA documentation.

Real. Not a demo. Not a screenshot from someone else's blog.

Production Considerations

Area	What I Found
Cost	No harness charge. You pay for Bedrock tokens + Browser session time
Regions	us-west-2, us-east-1, eu-central-1, ap-southeast-2 (preview)
Models	Any Bedrock model, plus OpenAI and Gemini. Switch mid-session
Security	Firecracker microVM isolation, IAM execution role, Cedar policies
Limitation	Preview — not for production workloads yet

⚠️ Gotcha I hit: The harness execution role needs bedrock:Converse and bedrock:ConverseStream permissions, plus aws-marketplace:ViewSubscriptions for 3P models. The default CDK policy only includes bedrock:InvokeModel. I had to add permissions manually.

When NOT to Use Harness

Deterministic automation (same steps every time) → Playwright. Cheaper, faster, more reliable.
Complex multi-agent workflows → Strands Agents SDK with AgentCore Runtime. More control.
Existing framework investment (LangChain/CrewAI) → Use AgentCore tools standalone.
Production workloads → Wait for GA. It's preview.

Bottom Line

The model is the brain. The harness is the body. Most teams are spending all their time picking the brain and hand-building the body from scratch every time.

AgentCore Harness lets you stop building bodies and start building solutions. For 80% of agent use cases, config beats code. For the other 20%, write code — but use the harness infrastructure underneath.

The teams still hand-coding agent orchestration loops are building technical debt. The same way teams hand-coding REST APIs built technical debt before API Gateway existed.

The question isn't whether to adopt managed agent infrastructure. It's whether you'll be building on it — or competing against someone who already is.

Ajit NK — AWS Community Builder, APN FasTrack Partner. Building AI agent solutions at CloudNestle.
"The model is the brain. The harness is the body. I build the body."

📚 Sources:

How I Track 44 New AWS Repos Per Week Automatically with EventBridge, Bedrock, and FAISS

Ajit — Wed, 01 Apr 2026 09:38:28 +0000

AWS publishes new sample repos almost daily — reference architectures, agent patterns, CDK constructs, security blueprints — spread across 5 different GitHub organizations.

Most developers never see them until weeks later.

I built a system that catches them the same day. Here's how.

The Problem

AWS maintains 9,657+ repos across these orgs:

aws-samples (8,044 repos)
awslabs (992 repos)
aws-ia (234 repos)
aws-solutions (153 repos)
aws-solutions-library-samples (234 repos)

When AWS publishes a new repo — say, a production-ready Bedrock AgentCore sample or a CDK construct for EKS — it's buried. GitHub search doesn't surface it. Google takes days to index it. By the time you find it, someone else already built on it.

The Solution: Auto-Indexing Pipeline

I built AWS Solution Finder with a twice-daily auto-indexing pipeline that detects and classifies new repos automatically.

Architecture

EventBridge (cron: 2 AM + 2 PM UTC daily)
↓
5 separate rules (one per org)
↓
Indexer Lambda (Docker, Python 3.12, 3GB, 15-min timeout)
↓
For each org:

Fetch ALL repos from GitHub API (paginated)
Compare with master index in S3 → find NEW + REMOVED repos
Classify new repos with Bedrock Nova Pro (22 metadata fields)
Generate Titan Embed v2 embeddings (1024-dim)
Incrementally update FAISS index
Save to S3 + publish new Lambda version
Write run record to DynamoDB

The 22 Metadata Fields

Every repo gets classified by Bedrock Nova Pro:

Solution type, competency area, AWS services used
Primary/secondary language, deployment tools
Cost range, setup time, complexity
Business value, target audience, freshness status
Agentic capabilities (yes/no/partial)
And more

This is what makes search actually useful — you're not just matching keywords, you're matching intent against structured metadata.

Safety Guards

If >50% of repos would be removed in a single run → blocked (likely GitHub API error)
If GitHub returns 0 repos → master index NOT updated
Ghost repo detection: repos in FAISS but not on GitHub get cleaned up
Rate limiting on GitHub API calls (1 sec between classifications)

The New Feature: "New Repos This Week"

Today I shipped a badge on the search page showing repos added in the last 7 days:

🆕 44 new repos this week
Grouped by org (aws-samples, awslabs, etc.)
Direct GitHub links for each
Rolling 7-day window, updated twice daily

This gives users a reason to come back daily — not just when they need to search.

Tech Stack

Layer	Technology
Scheduling	Amazon EventBridge (5 rules, twice daily)
Compute	AWS Lambda (Docker, Python 3.12, 3GB)
AI Classification	Amazon Bedrock Nova Pro
Embeddings	Amazon Bedrock Titan Embed v2 (1024-dim)
Vector Search	FAISS (IndexFlatL2, in-memory)
Storage	Amazon S3
Audit Trail	Amazon DynamoDB
IaC	AWS CDK (TypeScript)

Total cost for the indexing pipeline: almost nothing. The Lambda runs for ~5 minutes twice a day. Bedrock calls are only for NEW repos (not re-classifying existing ones).

Try It

The 🆕 badge is live now. Free to try — 3 searches without registration.

→ awssolutionfinder.solutions.cloudnestle.com/search

What AWS repos have you discovered recently that more people should know about?

Built by Ajit NK — AWS Community Builder (Dev Tools). Building AI-powered developer tools at CloudNestle.

How I Search 10,000+ AWS GitHub Repos in 10 Seconds

Ajit — Tue, 31 Mar 2026 12:51:14 +0000

The Problem

Every AWS developer knows this pain: you need a reference architecture or sample code, and you end up with 47 browser tabs open across GitHub, AWS docs, Stack Overflow, and random blog posts from 2019.

GitHub search gives you 2,000 results with zero context. ChatGPT confidently hallucinates repos that don't exist. Stack Overflow answers are outdated.

What I Built

I built an AI-powered search engine that indexes 10,000+ repos from AWS's official GitHub organizations:

aws-samples: 8,031 repos
awslabs: 993 repos
aws-solutions-library-samples: 315 repos
aws-ia: 234 repos
aws-solutions: 72 repos

How It Works

The search uses a hybrid approach:

70% BM25 (keyword matching) — catches exact AWS service names
30% FAISS (semantic vector search) — understands what you mean, not just what you type

Each repo is classified by Amazon Bedrock (Nova Pro) across 22 metadata fields: solution type, AWS services used, complexity, freshness, setup time estimate, and more.

Auto-indexed twice daily via EventBridge — new AWS repos are searchable within 12 hours.

Tech Stack

Amazon Bedrock (Nova Pro) for AI classification
FAISS with Titan Embed v2 (1024-dim) for vector search
AWS Lambda (Docker, Python 3.12)
API Gateway
DynamoDB for usage tracking
CloudFront + S3 for frontend
EventBridge for scheduled indexing
AWS CDK (TypeScript) for infrastructure

Key Architecture Decisions

Why hybrid search over pure vector?
AWS service names are precise — "Lambda" means something specific. Pure semantic search sometimes returns "serverless compute" results when you specifically want Lambda. BM25 catches exact matches, FAISS catches intent. The 70/30 split was tuned through testing.

Why FAISS over OpenSearch?
Cost. OpenSearch Serverless has a minimum cost that runs 24/7. FAISS on Lambda + S3 costs under $6/month for the search component. For a bootstrapped product, that matters.

Why 22 metadata fields?
Developers don't just want to find a repo — they want to know: Is it maintained? How complex is it? What AWS services does it use? How long will setup take? Nova Pro classifies each repo across all 22 fields automatically.

What I Learned

Hybrid search beats pure vector for domain-specific queries
FAISS on Lambda is surprisingly cost-effective
The 22-field classification is what makes results actually useful — not just the search itself
Auto-indexing twice daily keeps results fresh without manual work

Try It

Free to use — 3 searches without registration, 10 per day with a free account.

AWS Solution Finder

What's Next

Exploring ways to improve relevance scoring and add more metadata fields. If you've worked with FAISS or hybrid search, I'd love to hear your approach.

Built solo by an AWS Community Builder. Questions? Drop a comment.

# Building a Mobile AI Assistant with Kiro CLI and the Agent Client Protocol

Ajit — Tue, 24 Mar 2026 11:14:41 +0000

Situation

AI coding assistants are powerful — but they're trapped. Locked inside your terminal or IDE. Step away from your desk and you lose access to your AI agent, your workspace context, your tools.

I work across multiple environments — laptop, phone, sometimes just a quick check between meetings. My AI assistant (Kiro CLI) knows my codebase, has access to MCP tools (web search, AWS docs), and can read/write files. But only when I'm sitting at my terminal.

The question: Can I take my AI agent mobile without rebuilding it from scratch?

Task

Build a bridge that connects Kiro CLI to Telegram — so I can message my AI assistant from my phone and get the same capabilities as the terminal: file access, tool execution, MCP servers, streamed responses.

Constraints:

No modifications to Kiro CLI itself — use its public protocol
Channel-agnostic architecture — Telegram today, Slack/Discord tomorrow
Real tool access — not just a chatbot wrapper, but actual file reads, terminal commands, web search
Production-ready — auth, error handling, message splitting, typing indicators

Action

Discovering ACP

Kiro CLI implements the Agent Client Protocol (ACP) — an open standard for AI agent communication, similar to how LSP standardized language servers. It uses JSON-RPC 2.0 over stdio.

This means any process that can spawn kiro-cli acp and pipe JSON through stdin/stdout becomes an ACP client. Not just IDEs — anything.

Architecture

Three layers, cleanly separated using the Adapter Pattern:

Telegram Adapter — Auth, typing indicators, message splitting. Knows nothing about ACP.
ACP Client — JSON-RPC transport. Manages protocol lifecycle. Knows nothing about Telegram.
Kiro CLI — AI agent runtime. Model inference, tool execution, MCP servers.

Swap Telegram for Slack by writing a new adapter. The ACP client stays identical.

Implementing the ACP Handshake

ACP has a clear lifecycle — initialize, create session, prompt, stream:

// Step 1: Spawn Kiro CLI as ACP agent
const proc = spawn("kiro-cli", ["acp", "--trust-all-tools"], {
  stdio: ["pipe", "pipe", "pipe"],
  cwd: "/path/to/workspace",
});

// Step 2: Initialize — exchange capabilities
const init = await request("initialize", {
  protocolVersion: 1,
  clientCapabilities: {
    fs: { readTextFile: true, writeTextFile: true },
    terminal: true,
  },
  clientInfo: { name: "my-bot", version: "1.0.0" },
});

// Step 3: Create session
const session = await request("session/new", {
  cwd: "/path/to/workspace",
  mcpServers: [],
});

The clientCapabilities declaration is the key insight — it tells Kiro what your client can handle. Declare fs.readTextFile: true and Kiro will send file read requests to your client:

// Kiro sends requests TO us when it needs tools
async function handleServerRequest(msg) {
  switch (msg.method) {
    case "fs/readTextFile":
      return { content: fs.readFileSync(msg.params.path, "utf-8") };
    case "terminal/execute":
      return { output: execSync(msg.params.command, { encoding: "utf-8" }) };
  }
}

Streaming Responses

ACP streams responses via session/update notifications — each containing a text chunk:

function prompt(text) {
  return new Promise((resolve) => {
    const chunks = [];
    acp.on("notification", (method, params) => {
      if (params.update?.sessionUpdate === "agent_message_chunk") {
        chunks.push(params.update.content.text);
      }
    });
    request("session/prompt", {
      sessionId,
      prompt: [{ type: "text", text }],
    }).then(() => resolve(chunks.join("")));
  });
}

Adding MCP Tools

MCP servers extend the agent with external capabilities. One JSON config gives the bot web search:

{
  "name": "my-agent",
  "tools": ["*"],
  "mcpServers": {
    "web-search": {
      "command": "npx",
      "args": ["-y", "duckduckgo-mcp-server"]
    }
  }
}

Ask the bot "What's the weather in Tokyo?" — Kiro automatically invokes the search tool, processes results, and responds. All within a single session/prompt call.

Wiring Telegram

The adapter is the simplest layer — receive, forward, respond:

bot.on("message", async (msg) => {
  if (!allowedUsers.has(String(msg.from.id))) return;
  await bot.sendChatAction(msg.chat.id, "typing");
  const response = await acp.prompt(msg.text);
  for (const part of splitMessage(response, 4096)) {
    await bot.sendMessage(msg.chat.id, part);
  }
});

Result

~200 lines of code. A fully functional mobile AI assistant that:

✅ Connects to Kiro CLI via ACP (JSON-RPC 2.0 over stdio)
✅ Full workspace access — reads files, writes files, runs terminal commands
✅ MCP tool integration — web search, AWS docs, custom tools
✅ Streamed responses — no waiting for the full response to generate
✅ Auth, typing indicators, automatic message splitting for Telegram's 4096 char limit
✅ Channel-agnostic — adding Slack or Discord means writing one new adapter file

Patterns That Made It Work

Pattern	Why It Matters
Adapter Pattern	Telegram adapter is decoupled from ACP. New channels = new adapter, same core.
JSON-RPC 2.0 / stdio	Same transport as LSP. Battle-tested, no HTTP overhead, works with any language.
Capability Negotiation	Client declares what it supports during `initialize`. Forward-compatible.
Bidirectional Requests	Client sends prompts, agent sends tool requests back. Both sides are client and server.
Streaming via Notifications	Agent streams chunks as generated. No polling, no buffering.

Key Learnings

ACP is underutilized. Most people use Kiro in the terminal or IDE. But ACP is a general-purpose protocol — any client that speaks JSON-RPC can connect.
MCP servers are the real power. The bot isn't just a chatbot — it's an agent with tools. Web search, AWS docs, file operations. MCP turns text generation into action.
stdio is elegant. No HTTP servers, no WebSocket complexity, no ports. Spawn a process, pipe JSON, done.
The Adapter Pattern pays off immediately. Started with Telegram. Slack would take an afternoon because the ACP client is completely separate.

What's Next

[ ] Multi-channel — Slack and WhatsApp adapters using the same ACP client
[ ] Voice messages — Speech-to-text → prompt → response → voice note
[ ] Serverless — Lambda + API Gateway with Telegram webhooks
[ ] Session persistence — Resume conversations across restarts

Try It

The full source is open: kiro-acp-telegram-bot

MIT-0 licensed. Fork it, extend it, build your own channels.

git clone https://github.com/ajitnk-lab/kiro-acp-telegram-bot.git
cd kiro-acp-telegram-bot
npm install
cp .env.example .env  # add your Telegram token
npm start

I'd love your feedback:

What channels would you connect next?
Would a serverless (Lambda) deployment be useful?
What MCP servers would you want on your phone?

Drop a comment or open an issue on the repo. If you build something with this — a Slack bot, a Discord integration, a voice assistant — let me know. 🚀

Built with Kiro CLI · Agent Client Protocol · MCP

References

Kiro CLI Documentation — Installation, authentication, usage
Kiro ACP Integration Guide — Supported methods, session updates, Kiro extensions
Agent Client Protocol Specification — The open standard for AI agent-editor communication
Kiro MCP Configuration — Setting up MCP servers (stdio + HTTP)
Kiro Custom Agents — Agent JSON config, hooks, MCP server selection
Model Context Protocol — Anthropic's open standard for AI tool integration
JSON-RPC 2.0 Specification — The transport protocol ACP is built on
Telegram Bot API — Bot creation, message handling, polling vs webhooks
ACP Changelog — Kiro 1.25 — ACP launch, MCP tools, session management
Exploring the latest features of Amazon Q Developer CLI — Background on CLI + MCP architecture