Fix CloudFormation drift outside of the context of templates

1
votes

I have done drift detection before and have had to changes CloudFormation templates to fix the drift. However what if I can't find the template and suspect the change was made manually such as through AWS console? Specifically the resources are

  • Pipeline Roles
  • DeploymentId
  • CODETEST_CodeTestHistoryViewLambda_DO-NOT-DELETE

I saw on other questions that I may have to modify IAM policies to fix these. Others have said I have to manually delete the stack and recreate it which I do not want to do. Wondering what next best steps are. Thanks.

1
amazon-web-servicesamazon-cloudformation

1 Answers

1
votes

what if I can't find the template

CloudFormation automatically tags almost all resources that it creates:

AWS CloudFormation automatically creates the following stack-level tags with the prefix aws:

  • aws:cloudformation:logical-id

  • aws:cloudformation:stack-id

  • aws:cloudformation:stack-name

Thus this is the first place to check if you have a resource and you are not sure which template created it.

Not all resources support drift detection, only some. Thus you can only inspect for the drift for these resources. From what you listed IAM role for pipeline could be used in drift detection. Its unclear what do you mean by the other two resources.

And how to deal with the drift is a case-specific task. You can manually modify the resources back to be in line with its CFN template, modify template to match the resources, recreate the resources.

General recommendations about how to deal with the drift with focus on resource imports are provided in the following AWS blog post:

Once drift is detected, you have a few options. The simplest option tends to be updating the template itself to match the current live state. However, this may require potentially undesirable changes to your resource. Another option is to update the resource itself to match the template, but sometimes the live resource state is the desired state. Resource import affords us a third option. By decoupling the resource from the template, with a deletion policy of retain and importing the same resource back, we can adopt the updated property changes without having to execute a resource update that requires replacement.