Skip to content

Why did CloudFormation delete resources after I tagged them using the root account via Tag Editor?

0

I recently used AWS Tag Editor to apply tags across multiple resources using the root account. Some of these resources were created and managed by **CloudFormation stacks, including EC2 instances and S3 buckets.

Shortly after tagging the resources, I noticed that one of the CloudFormation stacks entered an abnormal state, showing the following messages:

  • "No updates are to be performed"
  • "UPDATE_ROLLBACK_IN_PROGRESS"

I did not perform any manual updates, deletions, or changes through CloudFormation.

However, two days later, several resources that were originally part of the stack were automatically deleted.

According to a report provided by AWS Support, the delete actions were logged as being performed by the root user, but I never issued any delete commands myself.

My Questions:

  1. Does using Tag Editor to tag resources that are managed by CloudFormation trigger drift detection or rollback behavior?

  2. Can CloudFormation automatically delete resources during a rollback even if no manual update or delete was triggered?

  3. Why would AWS CloudTrail show that the root user performed delete operations when no such action was taken manually?

Any clarification, documentation references, or best practice suggestions would be greatly appreciated.

Thank you.

asked 9 months ago114 views
1 Answer
1
Accepted Answer

If you modifying CloudFormation-managed resources outside of the stack for example using Tag Editor can cause drift, which may lead to unexpected behavior like rollbacks or resource deletions. CloudFormation uses the credentials of the initiating user (e.g., root) for such actions, which is why CloudTrail logs show the root user performing deletions.

To avoid such issues:

  1. Avoid using the root account for routine tasks.
  2. Manage all stack resources exclusively through CloudFormation.
  3. Use drift detection to identify changes.
  4. Apply stack policies to protect critical resources.
  5. Regularly monitor CloudTrail logs.
  6. Test changes in non-prod environments.

You can read more here

  1. AWS CloudFormation Drift Detection
    AWS CloudFormation Drift Detection Documentation

  2. AWS CloudFormation Best Practices
    AWS CloudFormation Best Practices

  3. AWS Tagging Best Practices
    AWS Tagging Best Practices

  4. AWS CloudTrail Documentation
    AWS CloudTrail Documentation

  5. AWS Root User Best Practices
    AWS Root User Best Practices

EXPERT
answered 9 months ago
EXPERT
reviewed 9 months ago

You are not logged in. Log in to post an answer.

A good answer clearly answers the question and provides constructive feedback and encourages professional growth in the question asker.