更新自定义资源会导致它们被删除？

Question

在使用 CloudFormation 模板时，我发现“自定义资源”功能及其 Lambda 支持函数实现对于处理 CloudFormation 无法提供良好支持的各种任务非常有用。

通常，我使用自定义资源在堆栈创建过程中进行设置（例如查找 AMI 名称）或在删除过程中清理内容（例如从 S3 或 Route53 中删除会阻止删除的对象） - 这很有效。

但是，当我尝试实际使用“自定义资源”来管理实际自定义资源时，必须在堆栈创建期间创建该资源，在堆栈删除期间删除该资源，并且 - 这就是问题所在 - 有时会使用新值进行更新在堆栈更新期间，CloudFormation 集成出现意外行为并导致自定义资源失败。

问题似乎在于，在自定义资源属性之一已更改的堆栈更新期间，在堆栈的 UPDATE_IN_PROGRESS 阶段，CloudFormation 将更新事件发送到支持 Lambda 函数，所有值设置正确并复制发送的旧值。但更新完成后，CloudFormation 会启动 UPDATE_COMPLETE_CLEANUP_IN_PROGRESS 阶段并向支持的 Lambda 函数发送删除事件（RequestType 设置为 Delete）。

发生这种情况时，后备 lambda 函数会假定堆栈正在被删除并移除自定义资源。结果是更新后自定义资源消失了。

我查看了日志中的请求数据，“清理删除”看起来与真正的“删除”事件相同：

清理删除：

{
RequestType: 'Delete',
ServiceToken: 'arn:aws:lambda:us-east-2:1234567890:function:stackname-resname-J0LWT56QSPIA',
ResponseURL: 'https://cloudformation-custom-resource-response-useast2.s3.us-east-2.amazonaws.com/arn%3Aaws%3Acloudformation%3Aus-east-2%3A1234567890%3Astack/stackname/3cc80cf0-5415-11e8-b6dc-503f3157b0d1%7Cresnmae%7C15521ba8-1a3c-4594-9ea9-18513efb6e8d?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Date=20180511T140259Z&X-Amz-SignedHeaders=host&X-Amz-Expires=7199&X-Amz-Credential=AKISOMEAWSKEYID%2Fus-east-2%2Fs3%2Faws4_request&X-Amz-Signature=3abc68e1f8df46a711a2f6084debaf2a16bd0acf7f58837b9d02c805975df91b',
StackId: 'arn:aws:cloudformation:us-east-2:1234567890:stack/stackname/3cc80cf0-5415-11e8-b6dc-503f3157b0d1',
RequestId: '15521ba8-1a3c-4594-9ea9-18513efb6e8d',
LogicalResourceId: 'resname',
PhysicalResourceId: '2018/05/11/[$LATEST]28bad2681fb84c0bbf80990e1decbd97',
ResourceType: 'Custom::Resource',
ResourceProperties: {
    ServiceToken: 'arn:aws:lambda:us-east-2:1234567890:function:stackname-resname-J0LWT56QSPIA',
    VpcId: 'vpc-35512e5d',
    SomeValue: '4'
} 
}

真正的删除：

{
RequestType: 'Delete',
ServiceToken: 'arn:aws:lambda:us-east-2:1234567890:function:stackname-resname-J0LWT56QSPIA',
ResponseURL: 'https://cloudformation-custom-resource-response-useast2.s3.us-east-2.amazonaws.com/arn%3Aaws%3Acloudformation%3Aus-east-2%3A1234567890%3Astack/stackname/3cc80cf0-5415-11e8-b6dc-503f3157b0d1%7Cresname%7C6166ff92-009d-47ac-ac2f-c5be2c1a7ab2?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Date=20180524T154453Z&X-Amz-SignedHeaders=host&X-Amz-Expires=7200&X-Amz-Credential=AKISOMEAWSKEYID%2F20180524%2Fus-east-2%2Fs3%2Faws4_request&X-Amz-Signature=29ca1d0dbdbe9246f7f82c1782726653b2aac8cd997714479ab5a080bab03cac',
StackId: 'arn:aws:cloudformation:us-east-2:123456780:stack/stackname/3cc80cf0-5415-11e8-b6dc-503f3157b0d1',
RequestId: '6166ff92-009d-47ac-ac2f-c5be2c1a7ab2',
LogicalResourceId: 'resname',
PhysicalResourceId: '2018/05/11/[$LATEST]c9494122976b4ef3a4102628fafbd1ec',
ResourceType: 'Custom::Resource',
ResourceProperties: {
    ServiceToken: 'arn:aws:lambda:us-east-2:1234567890:function:stackname-resname-J0LWT56QSPIA',
    VpcId: 'vpc-35512e5d',
    SomeValue: '0'
}
}

我能看到的唯一有趣的请求字段是物理资源 ID 不同，但我不知道将其与什么相关联，以检测它是否是真正的删除。

Answer 1

问题似乎是用于将自定义资源完成事件发送回 CloudFormation 的 sendResponse() 函数的示例实现。此方法负责设置自定义资源的物理资源 ID。据我了解，此值表示由支持 CloudFormation 自定义资源的 Lambda 函数管理的“外部资源”的全局唯一标识符。

从CloudFormation's "Lambda-backed Custom Resource" sample code 以及cfn-response NPM module 的send() 和CloudFormation's built-in cfn-response module 中可以看出，如果没有作为第 5 个参数，它使用 CloudWatch Logs 的日志流来处理正在处理的请求的日志记录：

var responseBody = JSON.stringify({
    ...
    PhysicalResourceId: context.logStreamName,
    ...
})

由于 CloudFormation（或 AWS Lambda 运行时？）偶尔会更改日志流到新的日志流，sendResponse() 生成的物理资源 ID 会不时发生意外变化，从而使 CloudFormation 感到困惑。

据我了解，CloudFormation 托管实体有时需要在更新期间更换（一个很好的例子是 RDS::DBInstance，几乎所有更改都需要更换）。 CloudFormation 的策略是，如果某个资源需要替换，则在“更新阶段”创建新资源，在“清理阶段”删除旧资源。

所以使用默认的sendResponse()物理资源ID计算，流程如下：

1. 创建了一个堆栈。
2. 会创建一个新的日志流来处理自定义资源日志记录。
3. 调用后备 Lambda 函数来创建资源，默认行为将其资源 ID 设置为日志流 ID。
4. 一段时间过去了
5. 使用自定义资源的新参数更新堆栈。
6. 会创建一个新的日志流来处理自定义资源日志记录，并使用新 ID。
7. 调用后备 Lambda 函数来更新资源，默认行为将新资源 ID 设置为新的日志流 ID。
8. CloudFormation 了解创建了一个新资源来替换旧资源，根据策略，它应该在“清理阶段”删除旧资源。
9. CloudFormation 到达“清理阶段”并使用旧物理资源 ID 发送删除请求。

至少在我从不“替换外部资源”的情况下，解决方案是为托管资源制造一个唯一标识符，将其作为第 5 个参数提供给发送响应例程，然后坚持使用它 - 保持在更新响应中发送在更新请求中收到的相同物理资源 ID。然后，CloudFormation 将永远不会在“清理阶段”发送删除请求。

我的实现（在 JavaScript 中）看起来像这样：

    var resID = event.PhysicalResourceId || uuid();
    ...
    sendResponse(event, context, status, resData, resID);

另一种选择 - 只有在您确实需要替换外部资源并希望遵守 CloudFormation 在清理期间删除旧资源的模型时才有意义 - 是使用实际的外部资源 ID 作为物理资源 ID ，并在收到删除请求时 - 使用提供的物理资源 ID 删除旧的外部资源。这可能是 CloudFormation 设计人员首先想到的，但他们的默认示例实现引起了很多混乱——可能是因为示例实现不管理真实资源并且没有更新功能。 CloudFormation 中也有零文档来解释设计和推理。

Answer 2

了解自定义资源生命周期很重要，以防止您的数据被删除。

要知道的一件非常有趣且重要的事情是 CloudFormation 比较您的 Lambda 函数返回的物理资源 ID 到您之前返回的那个。如果ID不同， CloudFormation 假定资源已被替换为新的 资源。然后有趣的事情发生了。

当资源更新逻辑成功完成时，一个 Delete 使用旧的物理资源 ID 发送请求。如果堆栈更新 失败并发生回滚，新的物理资源id被发送进来 删除事件。

您可以阅读更多关于自定义资源生命周期和其他最佳实践的here