使用完全生命周期控制运行隔离沙箱：AWS Lambda 推出 MicroVMs
今天，我们宣布推出 AWS Lambda MicroVMs，这是 AWS Lambda 内部的一个全新无服务器计算原语，让你能够在隔离的、有状态的执行环境中运行用户或 AI 生成的代码。你获得虚拟机级别的隔离、近乎瞬时的启动和恢复、以及对环境生命周期和状态的直接控制——全部无需管理基础设施或掌握复杂的虚拟化技术。Lambda MicroVMs 由 Firecracker 驱动，这是与支撑每月超过 15 万亿次 Lambda 函数调用相同的轻量级虚拟化技术。
客户为什么需要这个
过去几年中，出现了一类新的多租户应用，它们都有一个共同需求：为每个最终用户提供他们专属的执行环境，以安全运行应用开发者未编写的代码。AI 编程助手、交互式代码环境、数据分析平台、漏洞扫描器、以及运行用户提供脚本的游戏服务器都属于这一类。构建这个能力需要做出艰难选择。虚拟机提供强隔离但需要数分钟启动。容器秒级启动，但其共享内核架构需要大量的定制加固才能安全容纳不可信代码。函数即服务（FaaS）针对事件驱动、请求-响应工作负载进行了优化，不适合需要跨用户交互保持状态的长时间运行交互式会话。这迫使开发者要么在性能和隔离之间做出取舍，要么投入巨大的工程资源来构建和运维自定义虚拟化基础设施。
Lambda MicroVMs 正是为此而生。每个 MicroVM 为单个最终用户或会话提供其专属的隔离环境，快速启动，在会话期间保留内存和磁盘状态，并在用户离开时暂停以降低空闲成本。由于相同的 Firecracker 技术已经在支撑 AWS Lambda Functions，你继承了一个在大规模运行此技术栈的服务的运维成熟度。
图 1：Lambda MicroVMs 在 AWS 控制台中的展示
动手实践
首先，我导航到 AWS Lambda 控制台，Lambda MicroVMs 现在出现在左侧导航菜单中。首先需要创建一个 MicroVM Image（镜像）。
我将一个 Flask Web 应用及其 Dockerfile 打包为 zip 文件，上传到 Amazon S3 存储桶。
我的 Flask API – app.py
import logging
from flask import Flask, jsonify
app = Flask(__name__)
logging.basicConfig(level=logging.INFO)
@app.route("/")
def hello():
app.logger.info("Received request to hello world endpoint")
return jsonify(message="Hello, World!")
if __name__ == "__main__":
app.run(host="0.0.0.0", port=5000)我的 Dockerfile
FROM public.ecr.aws/lambda/microvms:al2023-minimal
RUN dnf install -y python3 python3-pip && dnf clean all
WORKDIR /app
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt
COPY app.py .
EXPOSE 5000
CMD ["gunicorn", "--bind", "0.0.0.0:5000", "app:app"]我使用以下命令创建我的 MicroVM Image：
aws lambda-microvms create-microvm-image \
--code-artifact uri=<path/to/s3/artifact.zip> --name <VM_image_name> \
--base-image-arn arn:aws:lambda:us-east-1:aws:microvm-image:al2023-1 \
--build-role-arn <IAM role ARN>你也可以在 AWS 控制台中创建 MicroVM Image。命令运行后，Lambda 会拉取 zip，运行 Dockerfile，初始化应用，并对运行中的磁盘和内存状态拍摄 Firecracker 快照。构建日志会实时流式传输到 Amazon CloudWatch（位于 /aws/lambda/microvms/<image-name>），镜像就绪后会显示在控制台中，包含其 ARN 和版本号。
图 2：创建 MicroVM Image 的完整流程
aws lambda-microvms run-microvm \
--image-identifier arn:aws:lambda:<region>:<acct>:microvm-image:my-image \
--execution-role-arn arn:aws:iam::<acct>:role/MicroVMExecutionRole \
--idle-policy '{"maxIdleDurationSeconds":900,"suspendedDurationSeconds":300,"autoResumeEnabled":true}'启动也可以通过 AWS 控制台或 CLI 完成。我传入镜像 ARN 和一个配置为闲置 15 分钟后自动暂停、下一个请求到达时自动恢复的空闲策略。无需任何网络配置。Lambda 分配了唯一的 MicroVM ID，返回一个专属端点 URL，并启动一个新的 MicroVM——由于是从快照恢复，我的 Flask 应用已经处于运行状态。一次 API 调用获取一个完全初始化、已启动的计算环境。
为了发送流量，我使用 CLI 生成一个短期有效认证令牌，通过 X-aws-proxy-auth 头附加到普通 HTTPS 请求中。请求立即到达我的 Flask 应用。然后我让 MicroVM 空闲超过暂停阈值，此时 MicroVM 被挂起，其内存和磁盘状态被快照并存储。然后我发送另一个请求，MicroVM 恢复运行，应用状态完全完好。从客户端来看，暂停从未发生过。
工作原理
在底层，Lambda MicroVMs 提供了三项此前没有任何 AWS 计算服务能同时提供的能力。
第一是虚拟机级别的隔离，来自 Firecracker。每个会话运行在自己的专属 MicroVM 中，没有共享内核，没有跨用户共享资源，因此一个用户提供的不可信代码被限制在其执行环境中，无法访问其他环境或底层系统。
第二是快速启动和恢复。模型是"镜像→启动"：你提供一个 Dockerfile 和打包为 zip 的代码（存放在 Amazon S3），Lambda 运行你的 Dockerfile，初始化你的应用，并对运行环境的磁盘和内存状态拍摄 Firecracker 快照。此后从该镜像启动的每个 MicroVM 都从预初始化的快照恢复，而非冷启动——这意味着启动和闲置恢复都能实现近乎瞬时的启动延迟。即使是数 GB 的交互式会话也能快速恢复，给最终用户以响应迅速的体验。
第三是有状态执行。运行中的 MicroVM 在用户会话期间保留内存、磁盘和运行中进程。在空闲期间，MicroVM 可以被挂起——内存和磁盘状态保持完整——并在流量到达时恢复。已安装的包、已加载的模型和工作文件集在用户恢复会话时立即可用。MicroVM 支持最多 8 小时的运行时间，可以在可配置的空闲窗口后自动挂起，这使得构建从数分钟完成的软件漏洞扫描、到运行数小时的数据分析应用、再到包含长时间空闲的交互式编程会话等各种产品变得简单直接。
图 3：MicroVM 架构概览
Lambda MicroVMs 是 AWS Lambda 中的一个新资源，拥有独立的 API 接口。Lambda Functions 仍然是事件驱动、请求-响应工作负载的正确选择，而 Lambda MicroVMs 专为需要为每个最终用户或会话提供隔离环境来执行用户或 AI 生成代码的多租户应用而设计。两者相辅相成。使用 Lambda Functions 作为事件驱动骨干的应用，可以在需要隔离运行不可信代码的步骤调用 Lambda MicroVMs。你带来应用，服务提供执行环境。
现已可用
AWS Lambda MicroVMs 今天在美国东部（弗吉尼亚北部、俄亥俄）、美国西部（俄勒冈）、欧洲（爱尔兰）和亚太地区（东京）区域上线，基于 ARM64 架构，每个 MicroVM 最多支持 16 个 vCPU、32 GB 内存和 32 GB 磁盘。空闲 MicroVM 可以通过 API 调用显式挂起，或通过生命周期策略自动挂起，在保留完整状态以快速恢复的同时降低运行成本。定价详情请参阅 AWS Lambda 定价页面。
图 4：区域可用性与配置选项
要开始使用，请访问 AWS Lambda 控制台，或在 Lambda MicroVMs 产品页面了解更多信息。文档请参阅 Lambda MicroVMs 开发者指南。
原文链接：Run isolated sandboxes with full lifecycle control: AWS Lambda introduces MicroVMs — AWS News Blog
