相关疑难解决方法(0)

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

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

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

问题似乎是，在其中一个自定义资源属性已更改的堆栈更新过程中，在堆栈UPDATE_IN_PROGRESS阶段，CloudFormation将更新事件发送到支持Lambda函数，所有值均已正确设置，而旧值的副本发送为好。但是更新完成后，CloudFormation将开始该UPDATE_COMPLETE_CLEANUP_IN_PROGRESS阶段并向后备Lambda函数发送一个delete事件（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不同，但是我不知道将其关联到什么，以检测它是否是真正的删除。