Firecracker – The Virtualization Technology Behind AWS Lambda and Bedrock AgentCore Runtime
The blog discuss about the technology that behind the AWS Lambda, AWS Fargate and AWS Bedrock AgentCore
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, 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.
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
- 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:
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article