本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。
了解 RFC 更新 CTs 和 CloudFormation 模板偏差检测
在 AMS 中配置的资源使用修改后的 AWS CloudFormation 模板。如果资源的参数通过服务的 AWS 管理控制台直接更改，则该资源的 CloudFormation 创建记录将不同步。如果发生这种情况，并且您尝试使用 AMS 更新更改类型来更新 AMS 中的资源，则 AMS 将引用原始资源配置并可能重置更改的参数。此重置可能会造成损害，因此，如果检测到任何额外的 AMS 配置更改，AMS 将不允许 RFCs 更新更改类型。
要查看更新更改类型的列表，请使用控制台筛选器。
漂移补救 FAQs
有关 AMS 漂移补救的问题和答案。您可以使用两种更改类型来启动偏差补救，一种是执行模式=手动或 “需要审查”，另一种是执行模式=自动。
支持漂移修复的资源 (ct-3kinq0u4l33zf)
这些是漂移修复更改类型 (ct-3kinq0u4l33zf) 支持的资源。 要修复任何资源，请改用 “需要审查” (ct-34sxfo53yuzah) 更改类型。
AWS::EC2::Instance
AWS::EC2::SecurityGroup
AWS::EC2::VPC
AWS::EC2::Subnet
AWS::EC2::NetworkInterface
AWS::EC2::EIP
AWS::EC2::InternetGateway
AWS::EC2::NatGateway
AWS::EC2::NetworkAcl
AWS::EC2::RouteTable
AWS::EC2::Volume
AWS::AutoScaling::AutoScalingGroup
AWS::AutoScaling::LaunchConfiguration
AWS::AutoScaling::LifecycleHook
AWS::AutoScaling::ScalingPolicy
AWS::AutoScaling::ScheduledAction
AWS::ElasticLoadBalancing::LoadBalancer
AWS::ElasticLoadBalancingV2::Listener
AWS::ElasticLoadBalancingV2::ListenerRule
AWS::ElasticLoadBalancingV2::LoadBalancer
AWS::CloudWatch::Alarm漂移补救更改类型
有关使用 AMS 漂移补救变更类型的问题与解答。
有关漂移修复功能支持的资源列表，请参阅支持漂移修复的资源 (ct-3kinq0u4l33zf)。
重要
漂移修复会修改堆栈模板 and/or 参数，并且必须更新您的本地模板存储库或任何正在更新这些堆栈的自动化以使用最新的堆栈模板和参数。在不进行同步的情况下使用旧的模板 and/or 参数可能会对底层资源造成破坏性更改。
无需审查、自动化 CT（ct-3kinq0u4l33zf）仅支持每个 RFC 修复 10 个资源。要在 10 个批次中修复剩余的资源，请创建新的资源， RFCs 直到所有资源都已修复。
- 我应该使用哪种漂移补救更改类型？
我们建议在以下情况下使用无需复查的自动 CT（ct-3kinq0u4l33zf）：
您尝试使用自动 CT 对现有堆栈资源执行更新，但 RFC 按堆栈原样被拒绝。
DRIFTED你过去使用过 Update CT，但由于堆栈已漂移，它失败了。您无需再次尝试更新，可以改用所需的审核、手动、CT。
我们建议仅在漂移补救不支持漂移资源类型（无需审查）、自动、CT（ct-3kinq0u4l33zf）或漂移补救无需审查、自动化、CT（ct-3kinq0u4l33zf）或漂移补救无需审查、自动化、CT 失败时才使用所需的审查（ct-34sxfo53yuzah）。
- 修复期间对堆栈进行了哪些更改？
修复需要更新堆栈模板 and/or 参数，具体取决于偏移的属性。修复还会在修复期间更新堆栈的堆栈策略，并在修复完成后将堆栈策略恢复到之前的值。
- 我们怎样才能看到对堆栈模板 and/or 参数所做的更改？
在对 RFC 的回复中，提供了包含以下信息的变更摘要：
ChangeSummaryJson：包含作为偏差补救一部分的堆栈模板 and/or 参数的更改摘要。补救分多个阶段执行。此变更摘要包含各个阶段的更改。如果修复成功，请检查最后一个阶段的更改。有关按顺序执行的阶段，请参阅 ExecutionPlan JSON 中的。例如，存在时 RestoreReferences 段总是在最后执行，并且包含用于修复后更改的 JSON。如果在 DryRun 模式下运行修复，则这些更改都不会应用于堆栈。PreRemediationStackTemplateAndConfigurationJson：包含在 CloudFormation 堆栈上触发修复 StackPolicyBody 之前的堆栈配置快照，包括模板、参数、输出。
- 执行修复后我需要做什么？
重要
您需要使用 RFC 摘要中提供的最新模板和参数来更新本地模板存储库或任何将更新已修复堆栈的自动化。这样做非常重要，因为使用旧的模板 and/or 参数可能会对堆栈资源造成进一步的破坏性更改。
- 在此补救期间，我的应用程序会受到影响吗？
补救是一个离线过程，只能在 CloudFormation 堆栈配置上执行。不对底层资源执行任何更新。
- 修复后，我能否继续使用管理 | 其他 | 其他 RFCs 来更新资源？
我们建议您始终使用可用的自动更新来更新堆栈资源 CTs。如果可用的更新 CTs 不支持您的用例，请使用管理 | 其他 | 其他请求。
- 修复是否会在堆栈中创建任何新资源？
修复不会在堆栈中创建任何新资源。但是，修复会创建新的输出并更新堆栈模板元数据部分以存储修复摘要供您参考。
- 补救总是成功吗？
修复需要仔细分析和验证模板配置，以确定是否可以执行。在这些验证失败的情况下，修复过程将停止，并且不会对堆栈模板或参数进行任何更改。此外，只能对支持的资源类型执行修复。
- 如果修复不成功，如何更新堆栈资源？
你可以使用 “管理 | 其他 | 其他 | 更新 CT” (ct-0xdawir96cy7k) 来请求更改。AMS 对此类情况进行监控，并努力改进补救解决方案。
- 我能否修复同时具有受支持和不支持的资源类型的堆栈？
是。但是，只有在堆栈中发现支持的资源类型存在漂移时，才会执行修复。如果有任何不受支持的资源类型为 DRIFTED，则修复不会继续。
- 我能否请求对通过非 CFN Ingest 创建的堆栈进行补救？ CTs
是。无论用于创建堆栈的更改类型如何，都可以对堆栈执行修复。
- 我能否知道在补救之前会对堆栈执行哪些更改？
是。两种更改类型都提供了一个DryRun选项，您可以使用该选项来请求在堆栈修复后将要执行的更改。但是，最终的补救更改可能会有所不同，具体取决于补救时堆栈上存在的偏差。
