亚马逊云科技推出 Lambda MicroVM，一种全新的无服务器计算基础组件，每个用户会话或 AI 智能体都在自己的 Firecracker 虚拟机中运行，具备硬件级隔离能力、基于快照的快速启动能力，以及最长可达八小时的状态保留。MicroVM 目前已上线五个区域，采用 ARM64 架构，单实例最高支持 16 个 vCPU、32 GB 内存和 32 GB 磁盘。
Lambda MicroVM 与 Lambda Function 为相互独立的资源，拥有独立的 API 接口。它面向的是 Lambda Function 原生不支持的负载场景：长时间运行、有状态、多租户的应用程序，且执行的代码并非由开发者编写。
AWS 新闻博客直白点出了这一痛点：
在过去几年中，一类新的多租户应用程序涌现出来，它们都有一个共同需求：为每个最终用户提供专用的执行环境，用于安全运行并非应用开发者编写的代码。
在此之前，构建这类应用的团队要面临一个三方权衡。虚拟机提供强大的隔离，但启动需要数分钟；容器启动速度快，但它们共享内核，需要对不受信任的代码进行大量定制化加固；函数则针对事件驱动的请求和响应模式进行优化，并不适合需要持久保存状态的长时交互会话。
Lambda MicroVM 打破了这种取舍困境，它将三者合而为一：虚拟机级隔离、近乎即时的启动速度以及有状态执行，全部集成在单一的托管基础组件中。
其执行模式与 Lambda Function 不同。首先需要创建 MicroVM 镜像：将 Dockerfile 和代码构件上传到 S3，Lambda 会运行 Dockerfile、初始化应用程序，并通过 Firecracker 对运行中的内存和磁盘状态生成快照。此后从该镜像启动的每个 MicroVM 都从预初始化的快照恢复，而非进行冷启动。调用 run-microvm，传入镜像 ARN 和闲置策略，服务就会返回一个专用 HTTPS 端点，此时应用程序已处于运行状态。无需负载均衡器，无需网络配置，无需管理任何基础设施。
这种挂起/恢复生命周期机制使其能够适配各类交互式业务场景。当用户离开编码会话时，MicroVM 在等待自定义的空闲窗口后挂起，同时对内存和磁盘生成快照。当流量返回时，它会完整恢复所有内容：已安装的软件包、已加载的模型、工作文件集。DevelopersIO 在东京区域使用 Flask 应用测试了完整生命周期，确认挂起和恢复能够无缝保留应用状态。从客户端视角完全感知不到中间存在暂停过程。
隔离保证来自 Firecracker，这款轻量级 VMM 每月支撑超 15 万亿次 Lambda Function 调用。每个 MicroVM 在独立的专用虚拟机中运行，会话之间不共享内核、不共享资源。一个会话中的容器逃逸无法触及另一个会话或宿主机。对于大规模运行 AI 生成代码的团队而言，每天有数百万次执行来自无法审计的模型，这是一种比容器级隔离更强大的边界。
对于正在评估智能体生成代码运行平台的团队来说，主流超大规模云厂商产品的对比现已经比较完整了。Cloudflare Sandboxes 使用基于容器的隔离，分布在边缘网络中，并为更轻量的工作负载提供 V8 隔离。谷歌的 GKE Agent Sandbox 使用 gVisor 内核拦截作为 Kubernetes 原生底层组件。Azure Container Apps 动态会话 使用 Hyper-V microVM 实现硬件级隔离。AWS Lambda MicroVM 使用 Firecracker，并采用基于快照的启动机制。每种方案做出了不同的权衡：Cloudflare 优化边缘延迟和全球分布，谷歌优化 Kubernetes 原生可移植性，Azure 优化与其 Logic Apps 和 Foundry 智能体平台的集成，AWS 则优化有状态隔离与挂起/恢复生命周期控制。
在 Reddit 上，业务从业者一边为本次新品发布感到振奋，一边也保持着务实理性的态度。一位评论者对官方将 MicroVM 定义为颠覆性全新技术的说法，提出了质疑：
Lambda MicroVM 并没有真正实现以前完全不可能实现的新工作负载。它们改变的是成本、性能与安全性之间的权衡。核心适用场景包括不可信代码执行、多租户 SaaS 服务、AI 智能体，以及对隔离等级要求极高的无服务器业务：这类场景下容器的安全强度不足，而完整虚拟机资源开销又过大。它真正的突破在于在近乎无服务器的规模下实现虚拟机级隔离。
网络层面支持可自定义端口的入站 HTTPS 访问，兼容 HTTP/2、gRPC 与 WebSocket 协议。出站访问可按需配置，支持访问公网或接入私有网络（VPC）。身份认证采用云服务提供的 JWE 令牌，通过 X-aws-proxy-auth 请求头附加。
Lambda MicroVM 是对 Lambda Function 的补充而非替代。以 Function 作为事件驱动的应用程序可以在需要隔离运行不受信任代码的步骤中调用 MicroVM。两者共享 Lambda 控制台，并继承相同的运维模型（CloudWatch 日志、IAM 角色、VPC 集成），但面向的业务负载模式有着本质区别。
Lambda MicroVM 目前已在以下区域可用：美国东部（弗吉尼亚北部、俄亥俄）、美国西部（俄勒冈）、欧洲（爱尔兰）和亚太地区（东京）。定价采用基准加突发模式：MicroVM 运行时按基准计算付费，仅在工作负载超出基准时按额外资源消耗计费。挂起的 MicroVM 降至空闲成本，同时保留运行状态。Reddit 的一位网友测算过成本，并指出该服务存在额外溢价：
最低配置 1 vCPU + 2 GB 内存，每天需要 3.03 美元。这是 Fargate Spot 价格的 9 倍以上。
这一溢价换取的是虚拟机级隔离和有状态挂起/恢复能力，但团队在正式采用前需要仔细测算闲置时段与运行时段的资源占比。
查看英文原文：https://www.infoq.com/news/2026/06/aws-lambda-microvms/
