It offers a unique combination of properties amongst AWS’s compute services:

• Strong isolation guarantees.
• Fast boot time.
• Stateful executions.

and is suitable for multi-tenant applications that require per-user or per-session execution environments without a shared kernel.

The Problem

Imagine you’re building a product where users or AI agents need to execute arbitrary code. A coding assistant, an AI notebook, or perhaps a platform where users can run custom scripts.

The requirements are simple enough, but none of the existing compute services is an exact fit:

• VMs provide strong isolation, but take minutes to boot.
• Containers have a fast boot time, but the shared kernel makes it difficult to create truly sandboxed environments.
• Lambda functions have great isolation (thanks to Firecracker MicroVMs), but their 15-minute max timeout is not suited for long-running environments.

So teams end up duct-taping solutions together. EC2 with a custom lifecycle manager, ECS with heavy isolation config, or running Firecracker directly on bare metal.

Meanwhile, Lambda already has the right isolation guarantee, but its invocation-based model is a showstopper.

What Lambda MicroVMs changes

Lambda MicroVMs combines important properties from each of the options above:

• VM-level isolation via Firecracker: no shared kernel between execution environments, same as Lambda functions.
• Fast startup (in seconds) from pre-initialized snapshots. The same technology behind Lambda SnapStart is used here.
• Stateful sessions: memory and disk persist for up to 8 hours, with automatic suspend/resume when idle.

The use cases are pretty clear – coding assistants that need to run AI-generated code safely, interactive AI notebooks, agent sandboxes, vulnerability scanners, etc.

A completely different mental model

Lambda MicroVMs isn’t request/response at all.

Instead, you spin up a persistent VM per user or session, and it gets a dedicated HTTPS endpoint.

Clients connect over HTTP/2, gRPC or WebSockets. Every inbound connection is authenticated using bearer tokens (which you can generate using the CreateMicrovmAuthToken API).

The VM automatically suspends when idle (no compute charges) and resumes when traffic arrives. The practical unit is a session, not an invocation.

Scaling is different too.

Vertical scaling within a MicroVM is automated. It can burst to 4× its configured baseline CPU and memory.

But there’s no automatic horizontal scaling. You call “run-microvm” to create new environments as needed. Your application manages the fleet – which VM belongs to which tenant, when to spin up, when to clean up, etc. That’s the real engineering work you don’t have with Lambda functions.

Things to know

Aidan Steele did some hands-on exploration on launch day and gave us some useful details not in the launch posts (source):

Shell access is first-class. “/dev/ptmx” (pseudo-terminal) is supported, and there’s a CreateMicrovmShellAuthToken API to connect directly to a shell inside the VM. No reverse-shell workarounds needed. This is what tools like Claude Code and OpenCode use to give you a real terminal experience. And it means you can build the same thing for your users.

Docker works inside MicroVMs. Full OS capabilities are available, including running containers inside your MicroVM. One gotcha: all outbound UDP is blocked by default, which breaks DNS inside containers. See Aidan’s post for the fix.

Caveats

• ARM64 only at launch.
• Only five regions: N. Virginia, Ohio, Oregon, Ireland and Tokyo.
• Pricing is per vCPU-second + per Memory GB-second + snapshot read/write charges. This is closer to Fargate than Lambda.
• You’re billed per second, not per millisecond (as with Lambda functions). Again, this is closer to Fargate than Lambda.

Compared with AgentCore Runtime

If you’re building AI agents, you might have also looked at AgentCore Runtime, a managed platform for running agent workloads.

Both run on Firecracker MicroVMs and support up to 8 hours of total runtime. Both now have PTY/shell access (AgentCore added the InvokeAgentRuntimeCommandShell API in early June).

They look similar on paper, but I think the difference lies in the level of abstraction and who’s running the code.

AgentCore is a managed agent platform. You deploy your agent code (LangGraph, CrewAI, Strands, whatever), and AWS manages the fleet. This includes routing sessions to VMs, scaling and tearing down idle sessions. It has built-in inbound/outbound auth, MCP and A2A protocol support, versioning, and endpoints. Your users talk to your agent, and you don’t even think about VMs.

Lambda MicroVMs, on the other hand, is a low-level compute primitive. You call “run-microvm” to create environments, track which VM belongs to which tenant, and decide when to clean up, etc. There is no fleet management, no built-in auth, no protocol support.

There are overlaps in capabilities. For example, AgentCore Runtime also recently added support for interactive shells. But ultimately, I think they’re designed for different use cases:

• AgentCore Runtime – run my agent so users can talk to it.
• Lambda MicroVMs – give each user their own isolated VM so they can run arbitrary code in it.

As such, AgentCore Runtime’s execution environment is more locked down, whereas Lambda MicroVMs gives you full rein of the VM.

A good analogy is that AgentCore Runtime is to Lambda MicroVMs what Fargate is to EC2. Fargate runs your container in a microVM but constrains what you can do within it. EC2 gives you the full machine.

AgentCore gives you managed container hosting in a microVM. Lambda MicroVMs gives you the VM itself. The isolation boundary is the same (Firecracker), but what you can do inside it is not.

Links

• Announcement
• Launch blog post
• Developer guide
• API reference
• Pricing
• Aidan Steele’s hands-on notes
• Bedrock AgentCore Runtime

Related Posts

What you need to know about Lambda Managed Instances

The post What you need to know about Lambda MicroVMs appeared first on theburningmonk.com.

An API request creates an order, and then another service needs to reserve stock, another to charge the customer, another to send an email, and so on. In a serverless or event-driven architecture, follow-up actions are usually triggered by messages (either events or commands).

That gives us loose coupling, better scalability, and independent services. But it also introduces a reliability problem.

“What happens when the database update succeeds, but publishing the event fails?”

Or the opposite:

“What happens when a consumer processes an event successfully, but crashes before acknowledging it?”

This is where the Outbox Pattern and Inbox Pattern come in.

The TL;DR is:

• Outbox Pattern: ensure state changes reliably produce events.
• Inbox Pattern: ensure incoming events are processed safely, even when they are delivered multiple times.

They are often used together to build reliable event processing flows.

The problem with naive event publishing

Imagine an Orders service that stores orders in DynamoDB and publishes an OrderCreated event to EventBridge.

The simplest implementation might look like this:

await dynamodb.putItem({
  TableName: 'Orders',
  Item: order
});

await eventbridge.putEvents({
  Entries: [{
    Source: 'myapp.orders',
    DetailType: 'OrderCreated',
    Detail: JSON.stringify({ orderId: order.id })
  }]
});

This looks fine, but it has a failure case.

Now, the order exists, but the event was never published.

Downstream services do not know the order exists. Inventory is not reserved. Payment is not started. The customer does not receive a confirmation email.

The mistake here is treating the database write and the event publish as if they are one atomic operation. They are not.

This is a distributed transaction problem.

The Outbox Pattern

The Outbox pattern solves the “database updated but event not published” problem.

Instead of writing to the database and then immediately publishing to EventBridge, the service writes both the order and the outgoing event (the outbox item) in a single database transaction.

Later on, another process will pick up the outbox item and publish it to EventBridge asynchronously.

The idea is simple: first persist the intent to publish, then publish later.

You can easily implement the Outbox pattern with DynamoDB and EventBridge Pipes.

For example, you’d have an Orders table and an Outbox table and use TransactWriteItems to write both records atomically.

From here, DynamoDB Streams captures the INSERT events from the Outbox table. EventBridge Pipes reads from the stream, optionally filters and enriches the records, then sends matching records to an EventBridge event bus. All without writing any custom glue code.

A raw DynamoDB stream record is a database change notification. It contains DynamoDB-specific structure, such as NewImage, OldImage, keys, and attribute types.

That is not what you want downstream services to consume.

Instead, the pipe should transform the DynamoDB INSERT event into a clean domain event before sending it to EventBridge. Also, don’t forget to wrap the event in an envelope so you can capture important metadata with the event payload.

{
  "version": "1.0",
  "id": "01J...",
  "source": "order-service",
  "detail-type": "OrderCreated",
  "time": "2026-05-04T10:15:00Z",
  "detail": {
    "metadata": {
      "id": "01HXHMF28A94NS7NSHC5GM80F4",
      "version": "1",
      "timestamp": "2020-04-28T07:20:20Z",
      "domain": "orders",
      "service": "order-service",
      "type": "order-placed"
    },
    "data": {
      "user_id": "123456",
      "order_id": "1234567890123",
      "restaurant_id": "123456789",
      "currency": "USD",
      "total": "42.42"
    }
  }
}

There are many variations to this basic pattern.

For example, you may replace EventBridge Pipes with a Lambda function if the publishing step has real business logic.

Or you may forego the Outbox table altogether and derive the outgoing event from the inserted Order item. However, if you wish to track the status of the outbox item (e.g. from PENDING to PUBLISHED), then this is not a viable option.

The Inbox Pattern

The Inbox pattern solves the duplicate delivery problem on the consumer side.

Most event and messaging systems should be treated as at least once delivery systems from the application’s point of view. Even if the infrastructure reduces duplicates, your business logic should still assume duplicates are possible.

This is especially true for Lambda, because all async invocations (e.g. via EventBridge or SNS) have at least-once delivery.

Without protection, the payment service might charge the customer twice!

The Inbox Pattern prevents that by recording which messages have already been processed.

The consumer stores the incoming event ID in an Inbox table, and the inbox item then acts as a deduplication key.

The key to implementing this pattern with DynamoDB is to use conditional writes to ensure the event ID does not exist in the Inbox table already.

Inbox vs. Idempotency

You might be wondering,

“How is this different from using simple idempotency keys?”

These are related ideas that mainly differ in scope.

An idempotency key protects one business operation. Whereas the Inbox pattern protects message processing.

Within one message processing, there might be several business operations, each with its own idempotency key.

The Inbox pattern is idempotency applied at the message processing boundary, using the message/event ID as the deduplication key.

Inbox item first, or business update first?

Avoid this flow:

1. Write inbox item.
2. Commit.
3. Perform business update.

If step 1 succeeds and step 3 fails, future retries will see the inbox item and skip processing, even though the business action never happened.

Also, avoid this flow:

1. Perform business update.
2. Commit.
3. Write inbox item.

If step 1 succeeds and step 3 fails, future retries may repeat the business action.

The safest solution is to write the inbox item and business change in the same transaction.

But what if that’s not possible? For example, what if there are intermediate side-effecting actions, such as calling a third-party API?

In that case, this is a safer flow:

1. Try to write the inbox item with status = PROCESSING and a lock expiration.
2. If the insert succeeds, this worker owns the event.
3. If the insert fails, another worker has already claimed or processed it.
4. Only the owner performs side effects.
5. Mark the inbox item as PROCESSED.

If the first worker fails or times out, a subsequent retry can resume processing after the lock has expired.

But what about the side effects that the first worker has already performed?

That’s where we also need idempotency keys to protect the individual side-effecting actions!

Final thoughts

Most real-world event-driven systems have both consumers and producers.

For example, the payment service consumes OrderCreated and publishes PaymentSucceeded or PaymentFailed events.

That means it needs both patterns:

• Producers use the Outbox pattern to ensure events are reliably published.
• Consumers use the Inbox pattern to ensure exactly-once message processing.

These patterns are not about making failures impossible. They are about making failures safe.

The Outbox pattern accepts that publishing can fail, so it first stores the intent to publish.

The Inbox pattern accepts that duplicate deliveries can happen, so it makes message handling idempotent.

Together, they give you a strong foundation for reliable event processing.

Related Posts

Event versioning strategies for event-driven architectures

Event-Driven Architectures: How to limit the scope of end-to-end tests

EventBridge best practice: why you should wrap events in event envelopes

How to implement Durable Execution for Lambda (without frameworks)

How to reprocess Lambda dead-letter queue messages on-demand

Understanding push vs poll in event-driven architectures

When to use Light Events vs. Rich Events in Event-Driven Architectures

The post Inbox & Outbox patterns for reliable event processing appeared first on theburningmonk.com.

There’s usually a Wait -> Poll -> Choice loop that runs until the task is complete (or failed), like the one below.

Polling is inefficient and can add unnecessary cost as standard workflows are charged based on the number of state transitions.

There is an event-driven alternative to this approach.

Here’s the high level approach:

1. To start the data migration, the state machine calls a Lambda function with a task token (required for callback). This pauses the state machine execution.
2. The Lambda function calls the Database Migration service to start the data migration.
3. The function saves the data migration ARN (hash key) and the callback token in DynamoDB, along with other relevant information (created date, etc.)
4. The Database Migration service publishes “StateChange” events to the default EventBridge event bus (see docs here). A Lambda function subscribes to this event and waits for a replication task to finish or fail.
5. When triggered, the function extracts the data migration ARN from the event payload and retrieves the Step Functions task token from DynamoDB.
6. It can use the task token to send a success or failure signal back to the state machine execution. From here, the state machine can proceed with the rest of its steps.

This is a more efficient but also more complex approach. There are more moving parts involved, but it’s simple to implement.

But what if you’re calling a 3rd party API that do not support events?

You can adapt this approach to work with any service that accept a callback URL. When the 3rd party service makes the callback, your API handler will look up the task token and make the callback to Step Functions. Everything else stays the same as before.

What’s more, both the polling and event-driven approach can be implemented with the new Lambda Durable Functions too!

The waitForCondition operation is perfect for implementing the polling loop in just a few lines, like this:

const job = await startDataMigrationJob();

const result = await context.waitForCondition(
  async (job, ctx) => {
    const status = await checkJobStatus(job.arn);
    return { ...job, status };
  },
  {
    initialState: { job, status: null },
    waitStrategy: (state) => 
      state.status === 'Stopped' || state.status === 'Failed' 
        ? { shouldContinue: false }
        : { shouldContinue: true, delay: { seconds: 30 } }
  }
);

Similarly, the waitForCallback operation makes implementing the event-driven approach trivial. Instead of a task token, we have to store a callback ID. As before, the callback can be triggered by an event or by a 3rd party service via a callback URL.

const job = await startDataMigrationJob();

const result = await context.waitForCallback(
  "wait for data migration to finish",
  async (callbackId, ctx) => {
    // save the callback ID against job ARN
    await saveJobDetails(job.arn, callbackId)

    // when the StateChange event is fired
    // another function will fetch the callback ID
    // and send a success/failure signal to the
    // durable execution
  }
);

Polling is the default because it’s easy, not because it’s good.

If you can get an event (or a callback), you can stop spinning your state machine and start treating “waiting” as a first-class step. Less noise, fewer transitions, lower cost.

Thank you to Patrick for bringing this up in our last Q&A session. If you want to level up your AWS game, check out my Production-Ready Serverless workshop. The next cohort starts on April 13th, and the early bird tickets (30% off) is available until March 16th.

Related Posts

The biggest re:Invent 2025 serverless announcements

What's the best way to do fan-out/fan-in serverlessly in 2024?

The post The anti-polling pattern for Step Functions appeared first on theburningmonk.com.

Lambda Managed Instances

Here’s the official announcement.

A common pushback against Lambda is that “it’s expensive at scale” because:

1) Each execution environment can only process one request at a time, wasting available CPU cycles while you wait for IO response.

2) Paying for execution time is less efficient when handling thousands of requests per second, especially given the above.

Lambda Managed Instances address these concerns.

You keep the same programming model with Lambda and the same event triggers.

But instead of your function running in a shared pool of bare metal EC2 instances, you can now instruct AWS to use EC2 instances from your account instead. Importantly, AWS still manages these EC2 instances for you, including OS patching, load balancing and auto-scaling.

It gives you more control and flexibility, e.g. what instance types to use (but no GPU instances) and the memory-to-CPU ratio.

See this post for my more in-depth coverage of this new feature.

Lambda Durable Functions

Here’s the official announcement.

This is my favourite announce from re:Invent 2025 :-)

Lambda Durable Functions use a replay mechanism similar to how reState works and how I implemented durable execution on Lambda for a client project.

The basic idea is simple – you can add checkpoints along the execution and the Lambda service will re-invoke your function from the start and skip over previously executed checkpoints when:

• The initial invocation timed out.
• You called context.wait to pause the current invocation.
• You used context.invoke to invoke another function and wait for its response (which suspends the current invocation).
• You created a callback and awaiting its response.

Here’s a handy visualization from the official documentation.

(source: https://docs.aws.amazon.com/lambda/latest/dg/durable-functions.html)

In addition to the usual Lambda function timeout (max 15 mins), Durable Functions also have a “execution timeout” for the total duration of a durable execution which can span over multiple invocations. The max execution timeout is 1 year.

Durable functions can be invoked both synchronously and asynchronously.

However, for synchronous invocations, the max execution timeout is limited to 15 mins. Whereas asynchronous invocations can have execution timeout of up to 1 year.

Durable functions also work with all event source mappings. But ESM-triggered invocations are also limited to a max execution duration of 15 mins.

Additionally, Durable Functions support DLQs, but they DO NOT support Lambda destinations.

Similar to Step Functions, Durable Functions also supports exactly-once processing, if you provide an “DurableExecutionName” when invoking a durable function.

Durable Functions blur the line between Lambda and Step Functions. I’m still organizing my thoughts on how to choose between them, but off the top of my head, these are areas where I think Step Functions wins over Lambda Durable Functions:

• Visualization: being able to design and visualize the workflow as well as its executions. This is especially useful when working with non-technical stakeholders.
• Parallel processing: the context.parallel function of the Durable execution SDK does not actually guarantee parallel processing. In Node.js, it’s essentially a wrapper around promise.all, which gives you concurrency, not parallelism. So if you need to process large amounts of data in parallel, e.g. as part of a map-reduce task, then you want Step Function’s Parallel state.

The replay mechanic also has some interesting failure modes and gotchas. More on that in another post! Or, you can learn all about them in my next Production-Ready Serverless workshop ;-)

S3 Vectors goes GA with better scale and performance

Here’s the official announcement.

S3 Tables support intelligent-tiering and replication

Here’s the official announcement.

CloudFront supports mutual TLS authentication

Here’s the official announcement.

And a lot of AI-related announcements, such as Nova 2 models.

Related Posts

The biggest pre:invent serverless announcements you may have missed

What you need to know about Lambda Managed Instances

The post The biggest re:Invent 2025 serverless announcements appeared first on theburningmonk.com.

• Lambda Managed Instances
• Lambda Durable Functions

I will be updating the Production-Ready Serverless workshop to cover these new features in the January cohort.

In this post, let’s take a closer look at Lambda Managed Instances, why you should care and when to use it.

Introducing Lambda Managed Instances

A common pushback against Lambda is that “it’s expensive at scale” because:

1) Each execution environment can only process one request at a time, wasting available CPU cycles while you wait for IO response.

2) Paying for execution time is less efficient when handling thousands of requests per second, especially given the above.

Lambda Managed Instances address these concerns.

You keep the same programming model with Lambda and the same event triggers.

But instead of your function running in a shared pool of bare metal EC2 instances, you can now instruct AWS to use EC2 instances from your account instead.

Importantly, AWS still manages these EC2 instances for you, including OS patching, load balancing and auto-scaling.

With managed instances, you have more control over HOW the Lambda service should manage these EC2 instances.

For example, what CPU architecture and instance types to use.

You can choose specific instance types that works best for your workload, and use EC2 saving plans on these instances.

Note: GPU instances are NOT supported.

Similarly, you can let Lambda choose the scaling threshold or provide a target CPU utilization level you wish to maintain.

When creating a function using managed instances, you can also set the memory size and the memory-to-CPU ratio.

This lets you tailor the execution environment based on your workload. For example, for basic CRUD APIs, a 2-to-1 ratio is fine. But for memory intensive workloads you might choose a higher memory-to-cpu ratio.

Important considerations

Execution environments can handle multiple concurrent requests

This allows better utilization of the available CPU cycles. This is important for keeping cost in check when running at scale.

But it also means your code need to be thread-safe. For example, you need to be more careful when using and modifying global variables, because another concurrent request might have also modified them.

Paying for uptime instead of execution time

You no longer pay for execution time, but instead, you pay for a combination of:

• No. of Lambda requests – $0.20 per million.
• The EC2 cost.
• 15% premium on the EC2 cost.

As mentioned before, you can use existing EC2 saving plans on the managed EC2 instances.

No cold starts but slower scaling

Because execution environments are reused and can handle multiple concurrent requests, there are no more cold starts.

However, when exceeding the capacity of the EC2 fleet, requests are throttled until the system is able to scale up the fleet.

Regular Lambda functions can scale rapidly by tapping into a large, shared pool of EC2 instances. With managed instances, it takes tens of seconds to launch new EC2 instances. As such, it’s not a good fit when you have large, unpredictable spikes in traffic.

When to use it

Considering the above, here are the reasons I’d consider using managed instances:

• Cost-efficiency at scale, when you have a consistent high throughput.
• Predictable performance. Managed instances is more effective at eliminating cold starts than Provisioned Concurrency.
• More control over execution environment. More choices of instance types, memory-to-CPU ratio, etc.

However, for most of us, who aren’t handling thousands, or even hundreds of requests per second consistently, it’s better to stay with the default compute mode for Lambda.

Also, if you have a very bursty traffic and you can deal with a bit of cold starts, then you’re also better off staying with regular functions.

Regardless, I’m glad that there’s another option we can upgrade to, should the needs arise. And after all the relentless focus on AI, it’s good to see AWS going back to and innovating on its core services.

Related Posts

The biggest pre:invent serverless announcements you may have missed

The biggest re:Invent 2025 serverless announcements

What you need to know about Lambda MicroVMs

The post What you need to know about Lambda Managed Instances appeared first on theburningmonk.com.