AWS 官方表示 CloudFront 最多需要 15 分钟来启用或禁用分配。尽管我们发现这通常是正确的，但我们遇到过禁用分发需要超过 15 分钟的情况，因此我建议任何解决方案都必须考虑到无论出于何种原因，它可能需要超过 15 分钟的可能性分钟来禁用分发。
虽然不是一个完美事件驱动的解决方案，但绝对有可能以大多数事件驱动的方式来做到这一点。我们的解决方案是使用 CloudWatch、Lambda、SQS 和 CloudTrail 完成的。很明显，您已经启用了 CloudTrail，但是对于可能面临类似挑战的未来读者，如果您还没有这样做，第一步是在您的帐户中启用 CloudTrail 登录（注意：使用 CloudTrail 会产生费用，详情@ 987654321@)。启用 CloudTrail 后，CloudWatch Events 将能够从 CloudTrail 获取 CloudFront 事件。
现在 CloudTrail 已启用，我们可以继续实际删除已禁用的发行版。在 CloudWatch 中，创建一个 CloudWatch 事件，该事件在来自 CloudFront 的 UpdateDistribution 事件上触发一个 Lambda 函数，该函数将包含分发 ID 的消息发布到最大延迟为 15 分钟 (console based setup instructions here) 的 SQS 延迟队列。
SQS 队列中消息的使用者是第二个 Lambda 函数。调用时，此 Lambda 函数应调用 CloudFront GetDistribution API 以获取所提供的分配 ID，并检查是否为 Distribution.DistributionConfig.Enabled === true，如果为假，则检查是否为 Distribution.Status === Deployed。
可以根据您的特定需求或用例调整逻辑，但从这里开始，一个潜在的工作流程将是简单地检查Distribution.DistributionConfig.Enabled === true。如果它是真的，那么就退出该功能，因为您希望它被禁用，但事实并非如此，所以有些事情是不对的；也许分发是手动重新启用的，或者在某处禁用它时出错，或者可能由于其他原因调用了UpdateDistribution API，无论是什么原因，分发不在我们预期的状态，我们不应该继续。在中断该功能之前，您应该/可以通过发送 SNS 消息通知管理员此错误发生来确保这不会静默失败。
继续，如果 Distribution.DistributionConfig.Enabled === true 返回 false，请检查以确保 Distribution.Status === Deployed。如果这返回 false 那么这意味着禁用仍然是 InProgress 并且您需要等待更长时间。要在不保持 Lambda 运行（并为此产生费用）的情况下处理此问题，只需将第二条消息发布到我的延迟队列，该消息再次包含分配 ID，然后函数结束。 Lambda 将在 15 分钟后再次触发，并在下次调用时重复上述过程。
如果对 Distribution.DistributionConfig.Enabled === true 的检查返回 false 并且 Distribution.Status === Deployed 返回 true，则分发被禁用并准备好被删除。从这里只需调用带有分发 ID 的 DeleteDistribution API 和您在开始时调用的 GetDistribution 中的 ETag。 API 操作类似于DeleteDistribution --id {distributionId} --if-match {ETag}。如果它被成功删除，你会得到一个 204，就是这样，一切都完成了。如果出现错误，您将获得需要处理的 4xx。