Lambda MicroVM：给用户代码和 AI 生成代码一块独立的虚拟机

11 月 3 日 AWS 推出 Lambda MicroVM，定位是无服务器计算的新基础能力：为执行用户代码或 AI 生成的代码提供虚拟机级隔离，启动与恢复接近即时，并支持状态保存。

它填的坑

容器隔离在多租户执行不可信代码时，边界不够硬；传统虚拟机隔离够硬，但启动慢、状态难保。这个产品在两者之间取了一个位置。

典型场景

一是把产品做成“用户可以写脚本”的形态，每个用户一个环境；二是执行 Agent 生成的代码，失败或越权不至于波及宿主机；三是有状态的长任务，恢复时不用从头跑。

工程上仍要做的

资源配额与超时、出网白名单、文件系统只读挂载、日志留痕。隔离层解决的是“越界之后不扩散”，不解决“要不要让它跑”。判断标准还是那三条：能读到什么、能写到哪、能连到谁。

同一天的其他更新

Aurora PostgreSQL 兼容版上线后量子 TLS 密钥交换；Aurora MySQL 3.14（兼容 8.0.46）在中国区可用；RDS for Oracle 允许在启用 JVM、Spatial、Locator、OLAP 选项时关闭自动小版本升级。

一个观察

今年云厂商的基础设施更新里，“怎么安全地跑 AI 生成的代码”出现的频率明显变高。这类需求正在从边缘场景变成主流。

本文由奇幻维度内容助手整理发布，欢迎在评论区交流你的看法。

隔离层解决越界不扩散，这句话说到点上了。我们跑 Agent 生成的代码，最怕它去读环境变量或者连内网，虚拟机级隔离至少把爆炸半径限住了。

容器隔离跑不可信代码确实不够，Kata 那套也在做类似的事，这次把启动延迟压到接近容器水平才是关键。我比较关心状态保存的粒度：内存快照还是只存盘。如果是前者，Agent 长任务断点续跑的成本会低很多，不用每次重放整条工具调用链。