AWS 在 2026 年 6 月 22 日推出 Lambda MicroVMs，这是一种位于传统云服务器、容器和 Lambda 函数之间的新型计算资源。它面向的核心场景，是在多租户应用中为每个用户或任务提供独立环境，用来运行用户提交或 AI 生成的代码。
这项服务基于 Firecracker，提供虚拟机级隔离、接近即时的启动与恢复能力，并能在会话期间保留内存、磁盘和运行进程。它并不是把普通 Lambda 函数换个名字，而是为交互式开发、AI 编程助手和在线代码环境补上更适合的执行层。
MicroVMs 填补三类计算模式之间的空档
传统云服务器隔离性强、控制权高，但创建系统、安装依赖和启动服务需要时间，团队还要自己处理镜像、调度、休眠和回收。容器启动更快，却共享宿主机内核，运行不可信代码时需要更复杂的安全加固。
Lambda 函数适合事件触发和短请求处理，但不擅长持续数小时的交互式会话，也不适合在多次用户操作之间一直保留完整环境状态。
AI 编程助手、在线 IDE、数据分析平台、安全扫描器和允许用户脚本的游戏服务，恰好同时需要隔离、快速启动与状态保留。Lambda MicroVMs 就是针对这三个需求的交集设计。
预初始化快照缩短启动时间
开发者先提供 Dockerfile 和存放在 Amazon S3 中的代码压缩包。Lambda 会构建环境、启动应用，并对已经初始化的内存与磁盘状态创建 Firecracker 快照。
之后创建的新 MicroVM 不必从头启动操作系统和应用，而是从预初始化快照恢复。AWS 表示，这种方式可以让启动和空闲恢复都达到接近即时的延迟，即使会话环境包含数 GB 数据，也能较快回到可交互状态。
运行中的 MicroVM 会保留内存、磁盘、已安装软件包、加载的模型、工作文件和进程。进入空闲状态后，它可以按照生命周期策略自动挂起；新的请求到来时再恢复，并继续使用原有状态。
Firecracker 提供虚拟机级隔离
每个会话使用独立的 MicroVM，不与其他用户共享内核或运行资源。不可信代码被限制在自己的执行环境中，无法直接访问其他会话或底层系统。
底层使用的 Firecracker 并不是全新实验项目。AWS 已经用它支撑 Lambda 和 Fargate 等服务。AWS 公布的数据称，Firecracker 每月承载超过 15 万亿次 Lambda 函数调用。
不过，虚拟机级隔离不等于应用可以忽略权限设计。IAM 执行角色、网络访问、临时凭证、输入校验和数据边界仍然需要按照最小权限原则配置。特别是运行 AI 生成代码时，隔离环境只是安全体系的一层。
与传统云服务器定位不同
普通云服务器更适合长期运行的固定业务，用户拥有完整系统管理权，可以自由配置网络、磁盘、系统服务和监控。代价是需要自行维护操作系统、补丁、容量和资源回收。
Lambda MicroVMs 更接近按会话创建的托管执行环境。开发者使用镜像和 API 管理生命周期，不需要维护底层虚拟化平台。空闲时可以挂起并保留状态，适合大量用户间歇使用的场景。
它并不会取代普通 VPS。网站、数据库、长期守护进程和需要完整网络拓扑的服务，仍然更适合云服务器。MicroVMs 的优势主要出现在 每个用户都需要独立代码沙箱 的多租户产品中。
MicroVMs 并非替代 Lambda 函数
如果任务是短时间、无状态、由事件触发的处理，例如图片转换、消息消费和 API 请求，Lambda 函数仍然更直接。
如果团队控制全部代码，工作负载可以安全共享宿主机内核，并且需要成熟的 Kubernetes 生态，容器通常更灵活。
如果应用必须执行用户或 AI 提供的代码，同时需要保留数小时会话状态，MicroVMs 的定位更合适。实际架构中也可以组合使用：Lambda 函数处理事件与业务流程，把需要隔离执行的部分交给 MicroVMs。
首批支持 ARM64 和五个区域
Lambda MicroVMs 首批支持美国东部弗吉尼亚北部、美国东部俄亥俄、美国西部俄勒冈、欧洲爱尔兰和亚太东京地区。
目前使用 ARM64 架构，单个 MicroVM 最高提供 16 vCPU、32GB 内存和 32GB 磁盘。单次总运行时间最长为 8 小时，并支持通过 API 或生命周期策略挂起空闲环境。
这意味着迁移现有 x86 镜像时，需要检查依赖是否支持 ARM64。32GB 本地磁盘和 8 小时运行上限，也决定了它不适合长期保存大量本地数据或持续运行的后台服务。
恢复兼容性和成本仍待验证
MicroVM 从预初始化快照恢复，应用如果在初始化阶段生成唯一内容、建立长期网络连接或加载一次性数据，需要使用服务提供的钩子处理恢复兼容性。
成本也不能只看挂起机制。应把运行时长、vCPU、内存、镜像构建、S3、CloudWatch 日志和外部流量一起计算，再与常驻云服务器或容器集群比较。
此外，首批区域和 ARM64 限制会影响部署选择。面向中国用户的应用还要单独测试跨区域访问延迟，不能因为东京地区可用就直接判断最终体验。
