CODEWITHSUNDEEP
amazon-web-servicesaws-cloudformation
blahblah
blahblah

Reputation: 1251

AWS CloudFormation - ignore changes in property - `ignore_changes` from Terraform equivalent?

Suppose I created

    CognitoUserPoolIdentityProviderGoogle:
      Type: AWS::Cognito::UserPoolIdentityProvider
      Properties:
        ProviderName: Google
        AttributeMapping:
          email: emailAddress
        ProviderDetails:
          client_id: xxxx
          client_secret: yyyy
          authorize_scopes: profile email openid phone
        ProviderType: Google
        UserPoolId:
          Ref: CognitoUserPoolUserPool

and later somebody updated client_id and client_secret manually to 1111 and 2222. Rerunning CloudFormation would result in overwriting the manual change and reverting the values to xxxx and yyyy.

How do I avoid that? AWS::Cognito::UserPoolIdentityProvider is just an example - this could be any resource.

What I am looking for is basically a functionality of ignore_changes in Terraform

Upvotes: 2

Views: 2958

Answers (2)

FTPROJ
FTPROJ

Reputation: 27

Actually, this is a very frequent issue, here is another example and the way we solved it:

Having a CloudFront Distribution declared in CloudFormation, and the attached CNAMES/Cert are managed by the app ( attached on the fly ).

So the better and automatic way we implemented to solve this 'engineering' problem is :

  1. Declare all the values that are changed outside as Parameters of the template ( the list of CNAMES in the case described above )
  2. Whenever a change is required => that will trigger an auto deploy pipeline
  3. The pipeline would go first to retrieve the values from the currently deployed instance ( list of the CNAMES values attached by the app )
  4. Then, updating the Cloudformation Template passing this list as param

Upvotes: 1

Marcin
Marcin

Reputation: 238169

In CFN there is no "ignore changes". It is a bad practice to modify any resources managed by CFN, manually outside of its control. Manual changes can result in a lot of issues, one of which you are describing.

The technical term for what you are observing is a stack drift. There are few ways of managing it. But the first thing you do when you suspect it is to run drift detection on your stack before any updates.

Since in your case the drift is not that bad, you have two choices:

  • update CFN template manually to match the manual changes, and the update the stack
  • manually modify the resources back to their original state and then apply all updates through CFN.

Upvotes: 3

Related Questions