选择您的 Cookie 首选项

我们使用必要 Cookie 和类似工具提供我们的网站和服务。我们使用性能 Cookie 收集匿名统计数据,以便我们可以了解客户如何使用我们的网站并进行改进。必要 Cookie 无法停用,但您可以单击“自定义”或“拒绝”来拒绝性能 Cookie。

如果您同意,AWS 和经批准的第三方还将使用 Cookie 提供有用的网站功能、记住您的首选项并显示相关内容,包括相关广告。要接受或拒绝所有非必要 Cookie,请单击“接受”或“拒绝”。要做出更详细的选择,请单击“自定义”。

使用 Lambda SnapStart 提高启动性能

聚焦模式
使用 Lambda SnapStart 提高启动性能 - AWS Lambda

Lambda SnapStart 可以提供低至次秒级的启动性能,通常无需更改函数代码。SnapStart 可以更轻松地构建响应速度快且可扩展的应用程序,而无需预调配资源或实施复杂的性能优化。

导致启动延迟的最大因素(通常称为冷启动时间)是指 Lambda 在初始化函数上花费的时间,其中包括加载函数代码、启动运行时以及初始化函数代码。通过 SnapStart,Lambda 可以在您发布函数版本时初始化您的函数。Lambda 会对已初始化的执行环境的内存和磁盘状态创建 Firecracker microVM 快照、加密该快照,并智能地对其进行缓存以优化检索延迟。

为了确保弹性,Lambda 会保留每个快照的多个副本。Lambda 使用最新的运行时和安全更新自动修补快照及其副本。当您首次调用某个函数版本时,以及随着调用的纵向扩展,Lambda 会从缓存的快照恢复新的执行环境,而不是从头开始初始化,从而减少了启动延迟。

重要

如果您的应用程序要求状态唯一,则必须评估您的函数代码并验证其能否在快照操作后快速恢复。有关更多信息,请参阅 使用 Lambda SnapStart 处理唯一性

何时使用 SnapStart

Lambda SnapStart 旨在解决由一次性初始化代码引入的延迟变化,例如加载模块依赖项或框架。在初始调用期间,这些操作有时候可能需要几秒钟才能完成。在最佳情况下,使用 SnapStart 将此延迟从几秒钟缩短至次秒级。SnapStart 在与大规模函数调用搭配使用时效果最佳。不经常调用的函数可能无法获得相同的性能改进。

SnapStart 对两种主要类型的应用程序尤为有益:

  • 延迟敏感型 API 和用户流:作为关键 API 端点或面向用户的流的一部分,函数可以受益于 SnapStart 的延迟减少和响应时间的缩短。

  • 延迟敏感型数据处理工作流:使用 Lambda 函数的限时数据处理工作流可以通过减少异常函数初始化延迟来实现更好的吞吐量。

预置并发可使函数保持初始化状态,并做好准备在几十毫秒内做出响应。如果您的应用程序具有严格的冷启动延迟要求,而 SnapStart 无法充分满足该要求,则请使用预调配并发。

支持的功能和限制

SnapStart 适用于以下 Lambda 托管式运行时

不支持其他托管运行时系统(例如 nodejs22.xruby3.3)、仅限操作系统的运行时系统容器映像

SnapStart 不支持预置并发Amazon Elastic File System(Amazon EFS)或大于 512MB 的短暂存储。

注意

您只能对已发布的函数版本以及与版本关联的别名使用 SnapStart。不能对函数的未发布版本($LATEST)使用 SnapStart。

支持的区域

对于 Java 运行时,Lambda SnapStart 可在除亚太地区(马来西亚)以外的所有商业区域使用。

对于 Java 运行时,Lambda SnapStart 可在除亚太地区(马来西亚)以外的所有商业区域使用。

对于 Python 和 .NET 运行时,Lambda SnapStart 可在以下 AWS 区域使用:

  • 美国东部(弗吉尼亚州北部)

  • 美国东部(俄亥俄州)

  • 美国西部(俄勒冈州)

  • 亚太地区(新加坡)

  • 亚太地区(悉尼)

  • 亚太地区(东京)

  • 欧洲地区(法兰克福)

  • 欧洲(爱尔兰)

  • 欧洲地区(斯德哥尔摩)

对于 Python 和 .NET 运行时,Lambda SnapStart 可在以下 AWS 区域使用:

  • 美国东部(弗吉尼亚州北部)

  • 美国东部(俄亥俄州)

  • 美国西部(俄勒冈州)

  • 亚太地区(新加坡)

  • 亚太地区(悉尼)

  • 亚太地区(东京)

  • 欧洲地区(法兰克福)

  • 欧洲(爱尔兰)

  • 欧洲地区(斯德哥尔摩)

兼容性注意事项

通过 SnapStart,Lambda 可以使用单个快照作为多个执行环境的初始状态。如果您的函数在初始化阶段使用以下任何内容,则可能需要在使用 SnapStart 之前进行一些更改:

独特性

如果您的初始化代码生成了唯一内容,而此内容包含在快照中,则跨执行环境重复使用该内容时,该内容可能不唯一。若要在使用 SnapStart 时保持唯一性,则必须在初始化后生成唯一的内容。其中包括唯一 ID、唯一密钥以及用于生成伪随机性的熵。要了解如何还原唯一性,请参阅 使用 Lambda SnapStart 处理唯一性

网络连接

当 Lambda 从快照恢复您的函数后,无法保证您的函数在初始化阶段所建立连接的状态不变。验证您的网络连接状态,并在必要时重新建立连接。在大多数情况下,AWS 开发工具包建立的网络连接会自动恢复。关于其他连接,请查看最佳实践

临时数据

有些函数会在初始化阶段下载或初始化暂存数据,例如临时凭证或缓存的时间戳。使用暂存数据之前,请在函数处理程序中刷新此数据,即使不使用 SnapStart 也是如此。

SnapStart 定价

注意

对于 Java 托管式运行时,SnapStart 不会产生额外成本。您需要根据对您的函数发出的请求数量、您的代码运行所用时间以及为您的函数配置的内存来支付相关费用。

使用 SnapStart 的成本包括以下内容:

  • 缓存:对于在启用 SnapStart 的情况下发布的每个函数版本,您需要支付缓存和维护快照的成本。此价格取决于您为函数分配的内存量。您至少要支付 3 小时的费用。只要您的函数保持活动状态,就会继续向您收费。使用 ListVersionsByFunction API 操作识别函数版本,然后使用 DeleteFunction 删除未使用的版本。要自动删除未使用函数版本,请参阅 Serverless Land 上的 Lambda 版本清理模式。

  • 还原:每次从快照还原函数实例时,您都要支付还原费用。价格取决于您为函数分配的内存量。

与所有 Lambda 函数一样,持续时间收费适用于在函数处理程序中运行的代码。对于 SnapStart 函数,持续时间费用也适用于在处理程序之外声明的初始化代码、运行时加载所需的时间,以及在运行时钩子中运行的任何代码。持续时间从代码开始运行开始计算,直到代码返回或以其他方式结束为止,并向上取整为最接近的 1 毫秒。Lambda 会维护快照的缓存副本以实现弹性,并自动应用软件更新,例如运行时升级和安全补丁。每次 Lambda 重新运行初始化代码以应用软件更新时,都会收取费用。

有关 SnapStart 的使用成本的更多信息,请参阅 AWS Lambda 定价

隐私网站条款Cookie 首选项
© 2025, Amazon Web Services, Inc. 或其附属公司。保留所有权利。