DEV Community

Cover image for Firecracker – The Virtualization Technology Behind AWS Lambda and Bedrock AgentCore Runtime
Nghi Danh
Nghi Danh

Posted on

Firecracker – The Virtualization Technology Behind AWS Lambda and Bedrock AgentCore Runtime

Many of you may already be familiar with AWS Lambda — a key name whenever we talk about serverless architecture. Behind this powerful service lies a virtualization technology called Firecracker.

What is Firecracker?
In November 2018, Amazon Web Services (AWS) introduced Firecracker AWS Firecracker 2018 , an open-source virtualization technology that enables service owners to operate multi-tenant, container-based services by combining the speed and resource efficiency of containers with the security and isolation of virtual machines. The result is Micro-Virtual Machines (MVMs) based on Linux’s Kernel-based Virtual Machine (KVM) technology.

Which Service Using Firecracker?
AWS Fargate tasks are also executed using Firecracker microVMs.

AWS Lambda uses Firecracker-provisioned sandboxes to run customer functions.

Bedrock AgentCore Runtime
AgentCore Runtime is the execution environment for agents within the Bedrock AgentCore ecosystem, where developers can deploy agent code, LLMs, etc., without having to worry about infrastructure management or scaling.

A fully isolated execution environment: Each user session (8 hours) in AgentCore Runtime has its own dedicated microVM with isolated compute resources, memory, and its own filesystem, preventing any agent from accessing another user’s data.

AgentCore Runtime Firecracker
After a session ends, the entire microVM is destroyed and all session data is deleted. During the session, a user may have multiple interactions — multiple tool calls, multiple LLM invocations. (If persistent memory is needed, one can use a related ecosystem service: Bedrock AgentCore Memory Add memory to your Amazon Bedrock AgentCore agent - Amazon Bedrock AgentCore

AgentCore Runtime Session Lifecycle

AgentCore Runtime Session

  • Active: The runtime is either processing a synchronous invocation or performing background tasks (tracked automatically).
  • Idle: The runtime is not handling requests or background tasks, but remains available for future invocations.
  • Terminated: The execution environment provisioned for the session is destroyed — which may occur due to inactivity (15 minutes), reaching max session duration (8 hours), or failing health checks. Subsequent invocations to a terminated runtimeSessionId will result in provisioning of a new execution environment.

CPU charges: Only when actively consumed in ACTIVE or IDLE states - True idle: No CPU consumption (I/O wait, genuinely idle) = No CPU charges - Memory charges: Based on peak memory allocated

References:

Top comments (0)