亚马逊云科技推出 Lambda MicroVM，提供隔离式智能体与用户代码运行环境

亚马逊云科技

Lambda MicroVM 与 Lambda Function 为相互独立的资源，拥有独立的 API 接口。它面向的是 Lambda Function 原生不支持的负载场景：长时间运行、有状态、多租户的应用程序，且执行的代码并非由开发者编写。

在过去几年中，一类新的多租户应用程序涌现出来，它们都有一个共同需求：为每个最终用户提供专用的执行环境，用于安全运行并非应用开发者编写的代码。

在此之前，构建这类应用的团队要面临一个三方权衡。虚拟机提供强大的隔离，但启动需要数分钟；容器启动速度快，但它们共享内核，需要对不受信任的代码进行大量定制化加固；函数则针对事件驱动的请求和响应模式进行优化，并不适合需要持久保存状态的长时交互会话。
Lambda MicroVM 打破了这种取舍困境，它将三者合而为一：虚拟机级隔离、近乎即时的启动速度以及有状态执行，全部集成在单一的托管基础组件中。

其执行模式与 Lambda Function 不同。首先需要创建 MicroVM 镜像：将 Dockerfile 和代码构件上传到 S3，Lambda 会运行 Dockerfile、初始化应用程序，并通过 Firecracker 对运行中的内存和磁盘状态生成快照。此后从该镜像启动的每个 MicroVM 都从预初始化的快照恢复，而非进行冷启动。调用 run-microvm，传入镜像 ARN 和闲置策略，服务就会返回一个专用 HTTPS 端点，此时应用程序已处于运行状态。无需负载均衡器，无需网络配置，无需管理任何基础设施。

这种挂起/恢复生命周期机制使其能够适配各类交互式业务场景。当用户离开编码会话时，MicroVM 在等待自定义的空闲窗口后挂起，同时对内存和磁盘生成快照。当流量返回时，它会完整恢复所有内容：已安装的软件包、已加载的模型、工作文件集。

隔离保证来自 Firecracker，这款轻量级 VMM 每月支撑超 15 万亿次 Lambda Function 调用。每个 MicroVM 在独立的专用虚拟机中运行，会话之间不共享内核、不共享资源。一个会话中的容器逃逸无法触及另一个会话或宿主机。对于大规模运行 AI 生成代码的团队而言，每天有数百万次执行来自无法审计的模型，这是一种比容器级隔离更强大的边界。

对于正在评估智能体生成代码运行平台的团队来说，主流超大规模云厂商产品的对比现已经比较完整了。

在

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 目前已在

最低配置 1 vCPU + 2 GB 内存，每天需要 3.03 美元。这是 Fargate Spot 价格的 9 倍以上。

这一溢价换取的是虚拟机级隔离和有状态挂起/恢复能力，但团队在正式采用前需要仔细测算闲置时段与运行时段的资源占比。

查看英文原文：