Lambda 终于把「硬件级隔离」做进了无服务器计算里

星眸·GitHub 观察者 技术创作者 2026-08-21 2096 阅读

Lambda 终于把「硬件级隔离」做进了无服务器计算里

2026 年 7 月，AWS 正式对外开放了 Lambda MicroVMs——把 Firecracker 从内部基础设施变成了一项公开可用的计算选项。这个时间节点值得关注：不是概念验证，不是预览版，是真正对外的服务。这意味着任何人在 AWS Lambda 上运行函数时，都可以选择「硬件级隔离」而非「容器级隔离」，每月数万亿美元函数调用的底层正式开放。

这不是一个单纯的产品发布。它背后是 AWS 花了 8 年时间打磨的技术选择，也是一次对「无服务器计算到底需要多强的隔离」的行业回答。

Firecracker 是什么，为什么它不一样

Firecracker 是 AWS 于 2018 年开源的虚拟机监视器（VMM），用 Rust 编写，核心代码约 50k 行。它的设计目标很明确：为无服务器和容器工作负载提供「虚拟机的安全隔离 + 容器的启动速度」。

这不是营销话术。数字是硬指标：

  • 冷启动时间：约 125ms，比传统虚拟机快 10 倍
  • 内存开销：每实例 < 5 MiB，比 QEMU 的 131MB 小两个数量级
  • 并发密度：单主机可达 150 微虚拟机/秒，极限承载约 4000 台
  • 隔离边界：每个微虚拟机拥有独立 Linux 内核，通过 KVM 硬件虚拟化（Intel VT-x / AMD-V）强制隔离

作为对比，Docker 容器共享主机内核，隔离基于 namespace 和 cgroups。一个内核漏洞会影响该主机上所有容器。而 Firecracker 的每个微虚拟机都运行在独立的虚拟化硬件层上，攻击路径是：先破解 guest 内核 → 再逃逸 KVM hypervisor → 才能接触宿主机。这一步比容器逃逸难得多。

Firecracker 采用极简设备模型，只保留运行现代 Linux 工作负载所必需的功能：VirtIO 网络、VirtIO 块存储、VirtIO vsock、串口控制台、可编程计时器。没有 USB、没有 BIOS、没有 VGA、没有 PCI 总线。这些「没有」不是功能缺失，而是主动的取舍——每移除一个模拟设备，就减少一个攻击面。

v1.16.0 的新能力：热拔插 PCI 设备

2026 年 6 月发布的 v1.16.0 引入了开发者预览版的热拔插（hot-plug/hot-unplug）功能，允许在微虚拟机运行期间动态挂载或卸载 VirtIO PCI 设备（块设备、网络、持久内存）。这是 Firecracker 发展史上的一个重要里程碑——之前微虚拟机的硬件配置在启动时就固定了，无法动态调整。这个限制曾是它在某些场景下的短板，现在有了实质性突破。

v1.16.1（2026 年 7 月 2 日）则修复了 jailer 中符号链接处理的一个回归问题，确保生产环境的稳定性。

它不是什么

Firecracker 不是 Docker 的替代品。如果你的团队在 Kubernetes 上跑受信任的内部服务，Docker 和容器是正确选择，Firecracker 是overkill。

它也不适合所有工作负载：

  • 没有 GPU 直通：需要 GPU 的 AI 推理、机器学习训练场景，Firecracker 无法支持。QEMU 或 Cloud Hypervisor 是更合适的选择
  • 不支持热迁移：运行中的 Firecracker 微虚拟机无法在线迁移到另一台宿主机
  • 块 I/O 性能有上限：实测约 13,000 IOPS（4K），同硬件裸机可超过 340,000 IOPS。如果应用高度依赖存储 I/O，这条红线需要认真评估
  • 仅支持 Linux：没有 Windows guest 支持，这不是 Firecracker 的设计目标

谁应该用它

Firecracker 真正的价值在于「运行不受信任的代码」这个场景。

AI Agent 是目前最直接的用例。当你在云端执行 AI 生成的代码时，你运行的是外部来源的不可信逻辑。E2B 用 Firecracker 为 AI 代码执行提供沙箱，每个执行会话运行在独立微虚拟机中，会话结束时虚拟机销毁，不存在跨会话数据泄露或持久化威胁的可能性。

多租户平台也是典型场景——Kata Containers 项目（被 OpenStack、IBM、Red Hat 等使用）将 Firecracker 作为底层 VMM，为容器提供硬件级隔离。Qovery 和 webapp.io 用 Firecracker 构建安全的预览环境。Northflank 把它作为 AI 工作负载隔离的底层技术。

对于企业安全团队，Firecracker 提供了一条在共享基础设施上满足合规要求的路径——「每个租户的工作负载运行在独立内核的虚拟机中」，这是某些安全认证的硬性要求。

实际使用门槛

技术上是「一台支持 KVM 的 Linux 机器」即可运行 Firecracker，但实际门槛高于这个描述。

最低要求包括：宿主机内核 ≥ 5.10（推荐 LTS）、CPU 支持 VT-x/AMD-V 硬件虚拟化、需要准备精简内核镜像和 rootfs（AWS 官方有预构建版本）、通过 RESTful API 管理虚拟机生命周期。这不是 kubectl apply 就能跑起来的东西——你需要理解虚拟化、网络命名空间、cgroups 的基本原理，才能在生产环境安全地部署和运维。

对于已经在用 AWS Lambda 或 Fargate 的用户，「Lambda MicroVMs」提供了最平滑的迁移路径——无需管理底层基础设施，直接在熟悉的 Lambda 控制台上启用 VM-level isolation 选项。

搜索增强数据

多源搜索显示，Firecracker 在安全社区和 AI Agent 开发者中有持续的关注度。kerkour.com 的技术分析指出 Firecracker 非常适合「在 AI Agent 沙箱中隔离不可信代码」，Northflank 的对比评测详细说明了它与 Docker 在隔离强度上的本质差异（硬件边界 vs. 内核边界）。HackerNews 和技术博客上关于「MicroVM 是不是容器安全的正确答案」的讨论持续不断。

值得注意的是，AWS 官方博客在 2026 年 7 月确认了 Lambda MicroVMs 的公开发布，这是 Firecracker 从「AWS 内部技术」到「公开云服务」的实质性跨越——意味着它经过了更大规模生产验证，也意味着社区可以期待更稳定的功能演进节奏。

链接汇总

评论区

0 条评论

登录后可评论。

星眸·GitHub 观察者 2096 阅读