AWS Lambda MicroVMs: A Deep Dive into the Compute Primitive That Changes Multi-Tenant Architecture

Why I stopped and read the docs twice

I've been in platform engineering long enough to know that most AWS announcements are incremental. A new instance type. A higher concurrency limit. A new region. Useful, but not architecture-changing.

Lambda MicroVMs is different.

When I read the launch post on June 22, 2026, I immediately went to the docs, then re-read the architecture section, then pulled up the pricing page, then opened a terminal to try it. That doesn't happen often. This post is the result of working through everything — the concepts, the internals, the lifecycle, the networking model, and what it actually changes for platform engineers and SREs building multi-tenant systems today.

This isn't a re-hash of the AWS announcement. It's everything I wish I'd had as a single document when I started reading.

The problem that made this necessary

To understand why Lambda MicroVMs matters, you need to understand the specific class of problem it's solving — because it's not a general-purpose compute improvement. It's targeted at a very specific architectural pain.

Over the last few years, a new class of applications has emerged. They all share one defining characteristic: they need to hand each user, agent, or job its own dedicated execution environment in which to safely run code the application developer did not write.

Think about that for a second. This isn't your standard API server serving your own code. This is:

• A CI/CD platform where every pull request triggers a pipeline that executes code from contributors you don't control

• An AI coding assistant that generates and then executes code on behalf of a user

• A Jupyter-style analytics platform where each data scientist runs arbitrary Python scripts

• A vulnerability scanner that detonates potentially malicious packages in a controlled environment

• A game server platform where players upload scripts that run server-side

In every case, the threat model is the same: you are running code you didn't write, on behalf of someone you may not fully trust, and you cannot afford for that code to affect other tenants, access your infrastructure credentials, or persist state it shouldn't have.

Why existing compute doesn't fit

Virtual Machines give you real isolation. Each VM has its own kernel, its own memory, its own disk. A compromised VM cannot reach the host or another tenant through kernel exploits. But provisioning a VM takes minutes. If you're building an interactive environment where a user hits a button and expects their sandbox to appear in under a second, VMs don't work. And idle VMs cost money — you either pay for always-on capacity or you accept the cold start.

Containers are fast and cheap but they share the host kernel. The Linux kernel namespaces and cgroups that container runtimes use for isolation were designed for process separation, not for safely containing genuinely adversarial code. Every year, new kernel exploits demonstrate container escapes. Running truly untrusted code in containers requires significant custom hardening — seccomp profiles, AppArmor policies, stripped capabilities, user namespace remapping — and even then, you're defending against a constantly evolving attack surface. That's a full-time security engineering job, not something you bolt on.

Lambda Functions are isolated per invocation (they've actually used Firecracker internally since 2018), fast, and cheap. But they were designed for event-driven, short-lived, stateless workloads. A function has a maximum execution time. It doesn't hold state between invocations the way an interactive session needs. You can't SSH into it or install packages at runtime. It's not built for a user sitting in a browser-based IDE for two hours.

The gap has always been: what if you need VM-level isolation, with container-level startup speed, priced like serverless? Until now, the honest answer was "you build it yourself, at great expense." Lambda MicroVMs is AWS's answer to that gap.

What Firecracker actually is — and why it matters here

You cannot understand Lambda MicroVMs without understanding Firecracker, because the entire capability rests on it.

Firecracker is a Virtual Machine Monitor (VMM) written in Rust that AWS open-sourced in 2018. The design philosophy is radical minimalism. A traditional VMM like QEMU emulates an enormous amount of hardware: BIOS, ACPI, PCI buses, USB controllers, floppy drive controllers — decades of legacy device emulation in 1.7 million lines of C. Most of it exists for compatibility reasons, not because anyone actually needs a floppy drive in a cloud VM.

Firecracker strips all of that away. It emulates exactly five devices. It has no BIOS, no ACPI negotiation, no PCI bus. The guest boots directly from a Linux kernel image into a completely minimal hardware environment. The result is a VMM that can boot a minimal Linux guest in under 125 milliseconds and uses roughly 5MB of memory overhead per VM.

Because it's written in Rust, entire categories of memory safety vulnerabilities that plague C codebases — buffer overflows, use-after-free, double-free — are eliminated at compile time. The attack surface is radically smaller than any conventional VMM.

AWS has been running Firecracker in production since 2018, first for Lambda Functions and then for AWS Fargate. By the time Lambda MicroVMs launched, Firecracker had processed over 15 trillion Lambda invocations per month. The reliability and security track record isn't theoretical — it's proven at the largest scale in the industry.

Lambda MicroVMs exposes the Firecracker-based isolation that was previously only available internally as a first-class, configurable compute primitive you can use directly.

Core concepts before we go deeper

Before getting into the mechanics, it helps to understand the three resource types you work with.

MicroVM Image

A MicroVM Image is not a Docker image. It's closer to a VM snapshot or an AMI, but created through a Docker-based build process. When you create a MicroVM Image, Lambda executes your Dockerfile, starts your application, waits for it to signal readiness, and then takes a Firecracker snapshot of the fully initialized running state — disk and memory both.

This snapshot is the key innovation. When you later launch a MicroVM from this image, Lambda doesn't boot an OS, doesn't start a container runtime, doesn't execute your init process. It restores directly from the snapshot. Your application is already running at the moment the MicroVM reaches RUNNING state. The startup time is essentially the time to restore memory pages from the snapshot, not the time to boot a machine.

MicroVM Images are versioned. Each time you update the image (new code, new base image, new config), a new version is created. You can have multiple active versions and control which version new MicroVMs launch from.

MicroVM

A MicroVM is a running instance of a MicroVM Image. Each MicroVM represents a single tenant, user session, or job — one execution environment with complete isolation from all other MicroVMs. Each MicroVM gets its own kernel, its own memory address space, its own disk state, and its own dedicated HTTPS endpoint URL.

MicroVMs are not replicas of a service. They are not behind a load balancer sharing traffic. Each MicroVM endpoint routes to exactly one MicroVM. This is architecturally significant — it means your application in the MicroVM can maintain stateful connections, user-specific in-memory data, and session context without any coordination layer.

Network Connectors

Network Connectors are resources that control how traffic flows to and from a MicroVM. You associate them at launch time. Ingress connectors control how clients reach your MicroVM endpoint. Egress connectors control what your MicroVM can reach outbound — public internet, your VPC, or nothing.

This is a clean separation. You can configure a MicroVM to accept inbound traffic but have no outbound internet access (useful for vulnerability scanning, where you want to analyze code but not allow the code to beacon out). Or you can allow full internet egress for a dev environment where the user needs to install packages.

How the image build process works

This is worth understanding in detail because it determines startup behavior and has implications for how you write your application.

When you call create-microvm-image, Lambda does the following:

First, it retrieves your zip archive from S3. This archive contains your Dockerfile and any application artifacts you've bundled in. Lambda then provisions a fresh MicroVM from the Lambda-managed base image — an Amazon Linux 2023 environment that provides the OS and service components — and executes your Dockerfile instructions within that environment. This is where your dnf install commands run, where your pip install -r requirements.txt runs, where your application binaries land on the filesystem.

Once your Dockerfile has finished executing, Lambda runs your application using the CMD or ENTRYPOINT instruction. At this point, your application is live inside the build VM, listening on its configured port.

If you've configured a /ready hook, Lambda now calls GET /aws/lambda-microvms/runtime/v1/ready on your application. Your app should respond HTTP 503 while it's still initializing (warming caches, loading models, precomputing data) and HTTP 200 when it's genuinely ready. Lambda keeps polling until it receives 200 or the configured timeout elapses (between 1 and 3600 seconds). This is where you do expensive pre-computation — anything that would otherwise delay the first request from a real user.

Once your app signals ready, Lambda takes the snapshot. Everything in memory and on disk at that moment — loaded libraries, initialized connections, precomputed data, open file handles — is preserved in the snapshot. This is the image.

Optionally, Lambda then runs a /validate hook on a fresh MicroVM restored from the just-created snapshot. This confirms the image works correctly when resumed. The validate hook is also where you can run mock payloads to warm Lambda's snapshot access optimizer — Lambda tracks which memory pages you access during validation and pre-fetches those pages on future restores, making startup even faster.

The build process is captured in CloudWatch logs under /aws/lambda/microvms/<image-name>, so you can diagnose build failures without guessing.

An important implication of this architecture: anything that generates unique content during the build (random UUIDs, cryptographic secrets, unique connection IDs) will be shared identically across all MicroVMs launched from that image. If MicroVM A and MicroVM B are both restored from the same snapshot, they have the same UUID in memory if that UUID was generated during build. Generate unique content in the /run lifecycle hook instead, which runs after each individual MicroVM starts, not during the build.

Sizing: the baseline-peak model

Lambda MicroVMs uses what AWS calls a baseline-peak model, and it's worth understanding because it affects both architecture and cost.

When you create a MicroVM Image, you configure a baseline memory allocation. This baseline determines the vCPU allocation proportionally — 2 GB of memory = 1 vCPU is the ratio. The available baseline sizes are:

0.5 GB / 0.25 vCPU with a peak of 2 GB / 1 vCPU 1 GB / 0.5 vCPU with a peak of 4 GB / 2 vCPU 2 GB / 1 vCPU with a peak of 8 GB / 4 vCPU (this is the default) 4 GB / 2 vCPU with a peak of 16 GB / 8 vCPU 8 GB / 4 vCPU with a peak of 32 GB / 16 vCPU

At any time, a MicroVM can burst to up to 4× its configured baseline resources. You pay the baseline rate continuously while the MicroVM is running. You pay for burst usage above baseline per second, only during periods of elevated activity. This means you provision for average load, not peak load, and pay only for the peak usage when it actually occurs.

When the MicroVM is suspended, you pay zero compute. Only snapshot storage and any pending data transfer costs apply.

The practical implication: right-sizing is less critical than with traditional VMs. If your CI runner or dev environment occasionally spikes to 8 vCPU for a heavy compile job, configure 2 GB / 1 vCPU baseline and let it burst to 8 GB / 4 vCPU when needed. Pay baseline the rest of the time.

The lifecycle in detail

A MicroVM transitions through well-defined states. Understanding these states is essential for building reliable applications on top of MicroVMs.

PENDING is where every MicroVM starts after you call run-microvm. Lambda is allocating resources, loading the snapshot, and preparing the networking. You cannot send traffic yet.

RUNNING means the MicroVM is fully active. The /run lifecycle hook has completed (if configured), and the MicroVM is accepting traffic through its endpoint. This is the normal operating state. Note that if your /run hook fails or times out, the MicroVM transitions directly to TERMINATING without ever reaching RUNNING — implement proper error handling in your run hook.

SUSPENDING is a transient state entered when either the idle policy threshold is hit or you explicitly call suspend-microvm. While in SUSPENDING, the /suspend lifecycle hook runs (if configured), giving your application a chance to flush state, close connections gracefully, or log the suspension event. Lambda then checkpoints memory and disk state. This is not a crash or a shutdown — it's a controlled pause.

SUSPENDED means the MicroVM is fully paused. Memory and disk state are preserved exactly as they were at the moment of suspension. No compute charges accrue. The MicroVM is stored as a snapshot and can remain suspended for up to the suspendedDurationSeconds you configured. When the configured duration is exceeded, Lambda terminates the MicroVM automatically — so if you need a session to persist across a weekend, configure your suspended duration accordingly (up to 8 hours total maximum duration).

RUNNING again — when traffic arrives at the suspended MicroVM's endpoint and autoResumeEnabled is true, Lambda restores from the checkpoint and brings the MicroVM back to RUNNING. From the user's perspective, their request lands, there's a brief resume latency (milliseconds to low seconds depending on how much memory was in use), and the response comes back. The application in the MicroVM never knows it was suspended.

TERMINATING is the cleanup phase, entered when you call terminate-microvm, when the maximumDurationInSeconds limit is reached, or when the MicroVM has been suspended longer than suspendedDurationSeconds. The /terminate lifecycle hook runs here. After it completes, all resources are released.

TERMINATED is final. A terminated MicroVM cannot be restarted.

This lifecycle model is purpose-built for interactive, long-running sessions. You launch one MicroVM per user session or job. The MicroVM stays alive for the duration of the session, suspending during idle periods to avoid billing, resuming transparently when the user returns.

Networking: the details that matter

The networking model in Lambda MicroVMs is worth understanding carefully because it's different from what you'd expect if you're coming from EC2 or ECS.

Every MicroVM gets a unique public HTTPS endpoint assigned at launch: <microvm-id>.lambda-microvm.<region>.on.aws. This endpoint is not a load balancer. It routes to exactly one MicroVM. There is no concept of scaling replicas behind a single endpoint — each MicroVM has its own endpoint, and your application layer is responsible for routing users to the right endpoint.

The protocols supported on the inbound endpoint are HTTP/1.1, HTTP/2, WebSockets, gRPC, and Server-Sent Events. All traffic between client and the endpoint is TLS-encrypted by Lambda — your application can serve HTTP internally. This is important: you don't need to configure TLS in your application, manage certificates, or set up any ingress controller. Lambda terminates TLS at the endpoint.

By default, traffic arriving at the endpoint is forwarded to port 8080 inside the MicroVM. You can override this per-request using the X-aws-proxy-port header, or via WebSocket subprotocol negotiation if headers aren't available.

Authentication

Every request must include a JWE (JSON Web Encryption) token in the X-aws-proxy-auth header. There is no unauthenticated access option — this is by design. You generate tokens programmatically using create-microvm-auth-token, scoping each token to a specific MicroVM ID, a set of allowed ports, and an expiration time.

In practice, your orchestration layer (the application that assigns users to MicroVMs) generates a short-lived token when a user establishes a session and passes it to the frontend. The frontend includes this token in all requests. Tokens can expire in as little as one minute, enabling you to rotate access frequently.

This model means Lambda handles authentication at the proxy layer before your application even sees the request. Your app doesn't need to implement its own auth for the MicroVM endpoint — only for the orchestration layer that hands out tokens.

Egress: internet vs VPC

By default, MicroVMs can reach the public internet. This is the INTERNET_EGRESS connector. If your MicroVM needs to call AWS services (S3, Secrets Manager, DynamoDB), install packages from package managers, or call external APIs, this works out of the box.

If you need your MicroVM to reach resources inside your VPC — a private RDS database, an internal API, an ElastiCache cluster — you create a customer-managed VPC egress connector. This routes outbound traffic from your MicroVM through your VPC networking, where your security groups and route tables apply.

You can also use NO_INGRESS to disable inbound traffic entirely, or configure egress to be completely blocked. This is useful for security scanning workloads where the analyzed code should be fully airgapped from the network.

The CI/CD architecture change

This is the part of Lambda MicroVMs I find most architecturally interesting, so I want to go deep on it.

What multi-tenant CI looks like today

Most CI platforms — self-hosted GitHub Actions runners, GitLab Runner, Buildkite agents, Jenkins — run jobs on shared compute. "Ephemeral" container runners spin up a container, run the job, destroy the container. Sounds clean. The problem is that all those containers share the host kernel.

In a world where CI pipelines run arbitrary code from pull requests (including PRs from external contributors on open-source projects, or PRs that install npm packages from the public registry), shared kernel = shared risk. A malicious package in a PR could theoretically escape the container namespace through a kernel exploit. Shared /tmp on the host might leak data between jobs if cleanup is imperfect. Environment variables can persist across container restarts in subtle ways.

The "safe" alternative — one VM per job — solves the isolation problem but creates a fleet management problem. You need an autoscaling group of VM instances, each capable of running a job. Cold starts for EC2 instances are measured in minutes. You're paying for instances that sit idle between jobs unless you maintain a warm pool, which you're also paying for constantly. You need AMI pipelines to keep your runner images current. You need to handle spot instance interruptions. You need to manage the lifecycle of thousands of VMs across concurrent pipelines.

This is not a small engineering investment. It's a platform team's entire year.

What the Lambda MicroVMs model enables

With Lambda MicroVMs, you pre-bake your CI runner environment as a MicroVM Image. Install your build tools, language runtimes, test frameworks, and any other dependencies in the Dockerfile. Use the /ready hook to signal when the environment is fully initialized. Lambda takes the snapshot.

When a pipeline job needs to run, your orchestration layer calls run-microvm. Lambda restores the runner from the snapshot — build tools already installed, environment already initialized — and returns a RUNNING MicroVM with a dedicated endpoint in seconds, not minutes. You pass job-specific context (repo URL, branch, commit SHA, secrets paths) via --run-hook-payload, which your runner application receives and uses to configure the specific job.

The job runs in complete isolation. Its own kernel. Its own memory. Its own disk. A compromised dependency in this job cannot affect any other job, cannot read the host kernel's memory, cannot persist state to the next job's environment. When the job completes, terminate-microvm. All resources are released. No cleanup scripts to hope work correctly. The VM is gone.

For jobs that have natural idle periods — waiting for a human review, waiting for a slow test suite to produce output — the MicroVM can suspend. Memory and disk are preserved. Compute billing stops. When the next stage of the pipeline needs the environment, resume and continue from exactly where it left off.

The cost model aligns directly with usage. You pay for the seconds each job runs. No idle runner fleet. No warm pool capacity math. No autoscaling group over-provisioning for peak pipeline load.

For teams building internal developer platforms, this removes an entire layer of infrastructure ownership. The runner fleet is gone. In its place: one MicroVM Image (or a few, for different language environments), managed through a simple API, scaled automatically by Lambda to whatever concurrency your pipelines demand.

Lifecycle hooks: the integration surface

Lambda MicroVMs exposes four lifecycle hooks — HTTP endpoints your application implements — that give you control at key moments in the MicroVM lifecycle. These are how you integrate your application with the platform.

The /ready hook (GET /aws/lambda-microvms/runtime/v1/ready) runs during image build, after your CMD/ENTRYPOINT starts. Return HTTP 503 while initializing, HTTP 200 when ready to snapshot. This is where you preload models, warm caches, establish database connections that should be included in the snapshot.

The /validate hook (GET /aws/lambda-microvms/runtime/v1/validate) runs after image build, on a fresh MicroVM restored from the just-created snapshot. Return HTTP 503 while validating, HTTP 200 when done. Use this to confirm the image resumes correctly and optionally to run mock workloads that optimize snapshot page access patterns for future startups.

The /run hook runs when each individual MicroVM starts from a snapshot. This is where you handle per-MicroVM uniqueness — generate unique IDs, connect to tenant-specific resources, parse the runHookPayload you passed at launch time. When your /run hook returns HTTP 200, the MicroVM transitions to RUNNING and begins accepting traffic.

The /suspend hook runs when a MicroVM is about to be suspended. Use this to flush in-memory state to durable storage (a database, S3), close connections that won't survive suspension gracefully, or emit telemetry about the session. When the hook completes, Lambda takes the checkpoint.

The /terminate hook runs before a MicroVM is terminated. Final cleanup — close connections, write final state, emit completion events.

These hooks are the boundary between Lambda's lifecycle management and your application logic. You don't need to implement all of them, but the /ready hook in particular is critical for maximizing the value of snapshot-based startup — it's where you move expensive initialization out of the per-user startup path.

Image versioning and update strategy

MicroVM Images are versioned, and understanding the versioning model is important for operating MicroVMs in production.

Each time you call create-microvm-image or update-microvm-image, a new image version is created. Versions progress through build states: PENDING → IN_PROGRESS → SUCCESSFUL or FAILED. Successful versions can be set to ACTIVE (available to launch MicroVMs from) or INACTIVE (retained for history but not launchable).

When you call run-microvm without specifying --image-version, Lambda uses the latest active version. This means you can roll out a new application version by updating the image and activating the new version — subsequent MicroVM launches automatically use the new code. Existing running MicroVMs continue to run their current version until terminated.

To roll back, deactivate the new version and reactivate the previous one. New launches revert to the old version immediately.

The base image (the Lambda-managed Amazon Linux 2023 environment) follows its own versioning and deprecation lifecycle:

AVAILABLE means it's current and recommended. DEPRECATED (lasts 60 days) means a newer version exists but the old one still builds and runs. EXPIRING (lasts 30 days) means you can still run existing MicroVMs but cannot create new images from it. EXPIRED means neither build nor run is possible. RECALLED means it's immediately unavailable due to a critical security issue.

In practice, you want to rebuild your MicroVM Image whenever a new base image version is released — this is how you get OS security patches and service component updates. Set up a CI pipeline that triggers update-microvm-image when AWS publishes new base image versions, validate the result with your /validate hook, and activate the new version automatically. This is the Lambda MicroVMs equivalent of keeping your EC2 AMIs or container base images patched.

Where Lambda MicroVMs sits vs Lambda Functions

This is a question worth addressing directly because it comes up naturally.

Lambda MicroVMs is not a replacement for Lambda Functions. AWS is explicit about this, and it's architecturally correct.

Lambda Functions are optimized for event-driven, request-response workloads. A function runs for the duration of a single invocation, scales by creating new concurrent execution environments, and is stateless between invocations by design. If you have an API that handles 10,000 requests per second, each taking 200ms, Lambda Functions are exactly the right tool. The concurrency model is perfect, the cold start story has improved dramatically with SnapStart, and the operational overhead is minimal.

Lambda MicroVMs are optimized for persistent, stateful, interactive sessions. A MicroVM runs for the duration of a user session or a job — potentially hours. It's intentionally stateful. It has one endpoint, one tenant. If you have 1,000 concurrent users each needing their own isolated environment, you launch 1,000 MicroVMs, each with its own endpoint, each with its own persistent state.

The two can compose. Your Lambda Function-based event-driven backbone can call out to Lambda MicroVMs when it needs to hand a user a persistent sandbox. The orchestration layer between a user's browser and their assigned MicroVM is a great fit for Lambda Functions. They're complementary, not competitive.

What this signals about where compute is going

Standing back from the specifics, Lambda MicroVMs is part of a broader architectural shift that's been underway since Firecracker shipped in 2018.

The traditional boundaries between VMs, containers, and functions are dissolving. Firecracker proved that VM-level isolation doesn't require VM-level overhead. Docker Sandboxes, Kata Containers, AWS Fargate, and now Lambda MicroVMs all use the same insight: you can give users the ergonomics of containers or functions while giving the isolation guarantees of hardware virtualization.

The driver is AI. As AI coding assistants, AI agents, and AI-driven automation become standard parts of software infrastructure, the ability to safely execute AI-generated code becomes a critical platform capability. That code is, by definition, code you didn't write and can't fully audit. The only defensible isolation model is hardware virtualization. Shared-kernel containers are not sufficient for this threat model.

Lambda MicroVMs is AWS's bet on what the execution environment for the agentic era looks like: isolated, stateful, near-instant, serverless. The same infrastructure that runs the world's largest serverless compute platform now powers per-tenant, per-session, per-agent execution environments, accessible with a single API call, billed by the second.

For platform engineers, this is one of those moments where a difficult, expensive infrastructure problem becomes a managed service. Building the equivalent of Lambda MicroVMs in-house — a Firecracker-based, snapshot-driven, serverless isolation layer with per-VM networking, lifecycle management, and automated billing — would take a team months and produce something much less reliable than a service that has run 15 trillion invocations per month for years.

The smart move is to prototype this week.

Getting started

AWS has published a thorough getting-started guide that takes you from nothing to a running MicroVM with a live HTTPS endpoint in about ten minutes. The core steps are:

Create an S3 bucket to store your application artifact. Create an IAM build role that Lambda assumes during image creation — it needs s3:GetObject on your bucket and CloudWatch Logs write permissions. Write your application and a Dockerfile, zip them, and upload to S3. Call create-microvm-image to bake the snapshot. Wait for CREATED state. Call run-microvm to launch a MicroVM. Wait for RUNNING state. Call create-microvm-auth-token to generate an access token. curl your endpoint with the token in the X-aws-proxy-auth header. You're in.

The service is available today in us-east-1, us-west-2, eu-west-1 (Ireland), and ap-northeast-1 (Tokyo).

References and further reading

All of the technical details in this post come directly from the AWS documentation. If something I've described has changed or you need the authoritative source, these are the pages to read:

Lambda MicroVMs overview: https://aws.amazon.com/lambda/lambda-microvms/

Official launch blog post: https://aws.amazon.com/blogs/aws/run-isolated-sandboxes-with-full-lifecycle-control-aws-lambda-introduces-microvms/

Developer guide (top level): https://docs.aws.amazon.com/lambda/latest/dg/lambda-microvms-guide.html

Core concepts and lifecycle: https://docs.aws.amazon.com/lambda/latest/dg/microvms-how-it-works.html

Getting started tutorial: https://docs.aws.amazon.com/lambda/latest/dg/microvms-getting-started.html

MicroVM Images (build process, sizing, hooks, versioning): https://docs.aws.amazon.com/lambda/latest/dg/microvms-images.html

Running and lifecycle management: https://docs.aws.amazon.com/lambda/latest/dg/microvms-launching.html

Networking (ingress, egress, auth, protocols): https://docs.aws.amazon.com/lambda/latest/dg/microvms-networking.html

Pricing: https://aws.amazon.com/lambda/pricing/

Firecracker open source project: https://firecracker-microvm.github.io/

Anurag Bhatt is a Platform Engineer based in Bengaluru, currently working on cloud infrastructure and IoT platforms. He writes about platform engineering, AWS, Kubernetes, and the infrastructure decisions that matter at scale at bhattdev.in.