我知道 AWS Lambda 中的冷启动和热启动。
但是,我不确定在热启动期间 Lambda 架构是否在后端重用了 Firecracker 虚拟机?还是它在一个全新的虚拟机中进行调用?
有没有办法通过其他 AWS 解决方案对每次调用强制执行 VM 级别隔离?
我知道 AWS Lambda 中的冷启动和热启动。
但是,我不确定在热启动期间 Lambda 架构是否在后端重用了 Firecracker 虚拟机?还是它在一个全新的虚拟机中进行调用?
有没有办法通过其他 AWS 解决方案对每次调用强制执行 VM 级别隔离?
根据Lambda 执行上下文文档中的说明,Lambda 尝试在后续执行之间重用执行上下文,这就是导致冷启动(当上下文启动时)和热启动(当重用现有上下文时)的原因)。
您通常会在首次调用 Lambda 函数时或在其更新后看到此延迟,因为 AWS Lambda 尝试将执行上下文重用于 Lambda 函数的后续调用。
Lambda 运行时环境文档中的另一条语句证实了这一点,其中指出:
调用 Lambda 函数时,数据平面会为该函数分配一个执行环境,或选择已为该函数设置的现有执行环境,然后在该环境中运行函数代码。
同一页面的稍后段落提供了有关如何在同一 AWS 账户中的功能和执行之间共享环境/资源的更多信息:
执行环境在硬件虚拟化虚拟机 (microVM) 上运行。microVM 专用于 AWS 账户,但可以由账户内跨功能的执行环境重复使用。[...] 执行环境永远不会跨函数共享,microVM 永远不会跨 AWS 账户共享。
此外,还有另一个文档页面提供了有关环境之间隔离的更多详细信息,但同样没有提及每个环境强制执行 1 次的能力。
据我所知,没有办法让新的执行将使用新的环境而不是现有的环境。AWS 在这方面没有提供太多见解,但围绕该主题的措辞似乎表明大多数人实际上试图做与您正在寻找的相反的事情:
当您编写 Lambda 函数代码时,不要假设 AWS Lambda 会自动将执行上下文重用于后续函数调用。其他因素可能要求 AWS Lambda 创建新的执行上下文,这可能导致意外结果,例如数据库连接失败。
我想说的是,如果您担心与其他客户/账户的隔离,AWS 通过虚拟化保证隔离,虽然不在物理级别,但取决于他们的 SLA 和您的 SLA/要求可能就足够了。相反,如果您正在考虑做某种需要 Lambda 执行相互隔离的多租户基础设施,那么这个组件可能不是您想要的。