使用 AWS CloudFormation 实现 AWS Lambda 支持的自定义资源的最佳实践有哪些?

上次更新时间:2019 年 6 月 28 日

使用 AWS CloudFormation 实现 AWS Lambda 支持的自定义资源的最佳实践有哪些?

解决方法

考虑采用以下最佳实践:

构建您的自定义资源,以顺利报告、记录和处理故障

异常可能导致您的函数代码退出而不发送响应。AWS CloudFormation 需要 HTTPS 响应来确认操作是成功还是失败。未报告的异常将导致 AWS CloudFormation 等到操作超时后再开始堆栈回滚。如果回滚时再次发生异常,则 AWS CloudFormation 将再次等待超时,最终以回滚失败结束。在此期间,您的堆栈不可用。

为避免出现需要耗时进行故障排除的超时问题,请在您为 Lambda 函数创建的代码中包含以下内容:

  • 用于处理异常的逻辑
  • 记录故障排除场景失败情况的能力
  • 通过确认操作失败的 HTTPS 响应对 AWS CloudFormation 作出响应的能力
  • 可使您捕获和处理未完成执行的死信队列

设置合理的超时时间段,并在临近超时期限时进行报告

如果一个操作没有在既定的超时时间段内执行,则函数会引发异常,并且不会向 AWS CloudFormation 发送响应。

为避免此问题,请考虑以下事项:

  • 将 Lambda 函数的超时值设置得足够高,从而应对各种情况下的处理时间和网络状况。
  • 在函数中设置一个计时器,以便在函数即将超时时对 AWS CloudFormation 错误作出响应。计时器可以帮助防止自定义资源延迟。

了解和处理 Create、Update 和 Delete 事件

根据堆栈操作,AWS CloudFormation 向您的函数发送 CreateUpdateDelete 事件。每种事件的处理方式不同,因此请确保在收到其中任何一种事件时都不会发生意外的行为。

有关更多信息,请参阅自定义资源请求类型

了解 AWS CloudFormation 识别和替换资源的方式

当更新操作触发对物理资源的替换时,AWS CloudFormation 会将您的 Lambda 函数返回的 PhysicalResourceId 与之前的 PhysicalResourceId 进行比较。如果 ID 不同,AWS CloudFormation 会假定资源已被新的物理资源替换。

但是,不会隐式移除旧资源,以备需要时回滚。堆栈更新成功完成后,将用旧物理 ID 作为标识符发送 Delete 事件请求。如果堆栈更新失败并发生回滚,则将在 Delete 事件中发送新的物理 ID。

仔细考虑何时返回新的 PhysicalResourceId。使用 PhysicalResourceId 唯一标识资源,以便在接收到 Delete 事件时,在替换更新期间仅删除正确的资源。

设计函数时要考虑幂等性

幂等函数可以用相同输入重复任意次数,结果与其仅执行一次时相同。幂等性非常有价值,它与 AWS CloudFormation 结合使用时,可确保重试、更新和回滚不会产生重复的资源或造成错误。

例如,如果 AWS CloudFormation 调用您的函数来创建资源,但是未接收到已成功创建资源的响应,则 AWS CloudFormation 可能会再次调用该函数,从而第二次创建资源。第一个资源可能因此变成孤立资源。

实施您的处理程序,以正确处理回滚

如果堆栈操作失败,AWS CloudFormation 会尝试回滚,将所有资源还原到其之前的状态。根据更新是否造成了资源替换,此回滚操作可能会导致不同行为。

为了帮助确保顺利执行回滚,请考虑以下事项:

  • 在接收到 Delete 事件之前,避免隐式删除旧资源。
  • 使用 Accustom自定义资源帮助程序帮助您遵照最佳实践在 AWS CloudFormation 中使用自定义资源。

这篇文章对您有帮助吗?

我们可以改进什么?


需要更多帮助?