AWS 推出 Lambda MicroVMs：为多租户应用提供全生命周期控制的隔离沙箱

背景

近年来，一种新型的多租户应用程序类别正在兴起。这类应用的核心需求是为每个最终用户提供独立的执行环境，以便安全地运行由用户或 AI 生成的代码，而非应用开发者编写的代码。典型的场景包括 AI 编程助手、交互式代码环境、数据分析平台、漏洞扫描器以及运行用户脚本的游戏服务器。

然而，在 AWS Lambda MicroVMs 推出之前，开发者在构建此类功能时面临艰难的权衡：

1. 虚拟机 (VM)：提供强大的隔离性，但启动时间长达数分钟，无法满足低延迟需求。
2. 容器 (Containers)：启动速度快（秒级），但由于共享内核架构，需要大量的自定义加固措施才能安全地容纳不受信任的代码。
3. 函数即服务 (FaaS/Lambda Functions)：针对事件驱动和请求-响应型工作负载进行了优化，但并非为需要跨用户交互保留环境状态的长时间运行交互式会话而设计。

这导致开发者要么在性能和隔离性之间妥协，要么投入大量工程资源去构建和运营自定义的虚拟化基础设施，这不仅需要深厚的专业知识，还分散了开发核心产品的精力。AWS 推出 Lambda MicroVMs 正是为了填补这一空白。

核心内容

AWS 正式宣布推出 AWS Lambda MicroVMs，这是 AWS Lambda 中一种全新的无服务器计算原语。它允许用户在隔离的、有状态（stateful）的执行环境中运行由用户或 AI 生成的代码。

技术基石：Firecracker

Lambda MicroVMs 由 Firecracker 技术支持。Firecracker 是一种轻量级的虚拟化技术，目前已在 AWS Lambda 中运行超过 15 万亿次月度函数调用。这意味着开发者无需管理基础设施或掌握复杂的虚拟化技术，即可享受虚拟机级别的隔离、近乎瞬时的启动与恢复，以及对环境生命周期和状态的直接控制。

核心能力

Lambda MicroVMs 提供了三种以前没有任何单一 AWS 计算服务同时具备的能力：

1. 虚拟机级别的隔离： 每个会话都在其专用的 MicroVM 中运行，拥有独立的内核和资源。用户 A 提供的不可信代码被严格限制在其执行环境中，无法访问其他环境或底层系统。

2. 快速启动与恢复： 采用“镜像后启动”（image-then-launch）模式。开发者提供 Dockerfile 和打包在 Amazon S3 中的代码，Lambda 会运行 Dockerfile 初始化应用，并捕获运行环境的内存和磁盘状态快照。后续启动时，MicroVM 从预初始化的快照恢复，而非冷启动，从而实现近乎瞬时的启动延迟。

3. 有状态执行： 运行的 MicroVM 会在用户会话期间保留内存、磁盘和正在运行的进程。在空闲期间，MicroVM 可以暂停（suspend），其内存和磁盘状态会被快照并存储。当流量再次到达时，MicroVM 会恢复，已安装的包、加载的模型和工作文件集均可立即使用。

   • 运行时限制：MicroVM 支持最长 8 小时的总运行时间。
   • 空闲策略：可配置空闲窗口，超时后自动暂停以降低成本。

操作演示与工作流程

AWS 在官方博客中展示了如何通过 CLI 和控制台使用 Lambda MicroVMs：

1. 创建 MicroVM 镜像：

   • 将 Flask Web 应用及其 Dockerfile 打包为 zip 文件并上传至 Amazon S3。
   • 使用 aws lambda-microvms create-microvm-image 命令，指定代码制品 URI、镜像名称、基础镜像 ARN（如 al2023-1）和 IAM 角色 ARN。
   • Lambda 会检索 zip 文件，运行 Dockerfile，初始化应用，并生成 Firecracker 快照。构建日志实时流式传输至 Amazon CloudWatch。

2. 运行 MicroVM：

   • 使用 aws lambda-microvms run-microvm 命令，传入镜像 ARN、执行角色 ARN 以及空闲策略（例如：15 分钟无活动后自动暂停，300 秒后自动恢复）。
   • Lambda 分配唯一的 MicroVM ID 和专用的端点 URL。
   • 由于是从快照恢复，Flask 应用在启动完成时已经处于运行状态。

3. 流量处理与状态保持：

   • 客户端通过 CLI 生成短期身份验证令牌，并通过 X-aws-proxy-auth 头附加到 HTTPS 请求中。
   • 请求到达后，应用立即响应。
   • 当 MicroVM 超过空闲阈值时，它会被暂停，内存和磁盘状态被快照存储。
   • 再次发送请求时，MicroVM 恢复，应用状态完整保留。对客户端而言，暂停过程是透明的。

适用场景与限制

• 适用场景：软件漏洞扫描（几分钟完成）、长时间运行的数据分析应用、具有长时间空闲期的交互式编码会话。
• 注意事项：由于应用是从预初始化快照启动的，如果在初始化过程中生成唯一内容、建立网络连接或加载临时数据，可能需要集成服务提供的钩子（hooks）以确保兼容性。

关键要点

• 全新计算原语：Lambda MicroVMs 是 AWS Lambda 中的新资源，拥有独立的 API 表面，与现有的 Lambda Functions 互补而非替代。
• 隔离与性能的平衡：解决了多租户应用中“强隔离”与“低延迟”难以兼得的问题，提供了虚拟机级的安全性和容器级的启动速度。
• 有状态支持：支持内存和磁盘状态的持久化，允许交互式会话在暂停后无缝恢复，适合需要保留上下文的应用。
• 自动化生命周期管理：内置空闲暂停和自动恢复机制，有效降低闲置成本，同时保持用户体验的连续性。
• 基于 Firecracker：继承了 AWS Lambda 大规模运行的成熟运维经验和技术栈。
• 运行时长限制：单个 MicroVM 会话最长支持 8 小时，适合中等时长的任务，而非无限期运行的服务。

意义与影响

Lambda MicroVMs 的推出标志着 AWS 在无服务器计算领域的进一步细化。它精准地切入了 AI 时代下多租户应用的痛点，特别是对于需要运行不可信代码（如 AI 生成的代码片段、用户提交的脚本）的场景，提供了既安全又高效的基础设施支持。

对于开发者而言，这意味着无需再自行构建复杂的虚拟化层或忍受传统 VM 的启动延迟，即可构建出类似 Replit、GitHub Codespaces 或在线 IDE 这样的交互式产品。对于 AWS 而言，这不仅丰富了 Lambda 的服务矩阵，使其从单纯的事件驱动函数扩展到支持有状态、长运行的微虚拟机，也进一步巩固了其在全栈无服务器计算领域的领先地位。Lambda Functions 将继续主导事件驱动工作负载，而 Lambda MicroVMs 则填补了交互式、多租户隔离环境的空白，两者共同构成了更完整的 AWS 计算解决方案。