CloudFormation Drift Detection and Remediation - Tutorial

Welcome to this tutorial on using AWS CloudFormation drift detection and remediation. AWS CloudFormation provides a powerful way to provision and manage your infrastructure as code. However, over time, manual changes made to resources outside of CloudFormation can cause drift, where the actual resource configuration diverges from the desired state defined in your CloudFormation templates. CloudFormation drift detection and remediation help you identify and rectify such drifts, ensuring that your infrastructure remains in sync with your templates.

Example of CloudFormation Drift Detection

Let's consider an example where you have a CloudFormation stack that provisions an Amazon EC2 instance. After the stack is created, someone manually modifies the instance's security group by adding an additional inbound rule. This change creates a drift between the desired state defined in the CloudFormation template and the actual state of the instance.

Command to Detect Drift:

You can use the AWS CLI to detect drift on your CloudFormation stack:

aws cloudformation detect-stack-drift --stack-name MyStack

This command initiates a drift detection operation on the specified stack and returns a drift detection ID.

Steps for Drift Detection and Remediation

  1. Initiate drift detection on your CloudFormation stack using the detect-stack-drift command.
  2. Monitor the status of the drift detection operation using the describe-stack-drift-detection-status command.
  3. Retrieve the drift detection results using the describe-stack-resource-drifts command.
  4. Analyze the drift detection results to identify the resources that have drifted.
  5. Decide on the appropriate remediation action for each drifted resource.
  6. Take remediation actions, such as updating the stack or replacing the drifted resources, using the appropriate CloudFormation commands.
  7. Monitor the status of the remediation actions and verify that the drifted resources are brought back into the desired state.

Common Mistakes with Drift Detection and Remediation

  • Not regularly performing drift detection and allowing drifts to accumulate over time.
  • Not monitoring the status of the drift detection and remediation operations, resulting in delays in identifying and resolving drifts.
  • Not understanding the impact of remediation actions and their potential consequences on the existing resources.
  • Ignoring drift detection results or not taking appropriate actions to rectify the drifts.

Frequently Asked Questions (FAQs)

1. Can I detect drift on CloudFormation stacks created with AWS CloudFormation Designer?

Yes, you can detect drift on CloudFormation stacks created with AWS CloudFormation Designer just like any other stack created with CloudFormation.

2. Can drift detection and remediation be automated?

Yes, you can automate drift detection and remediation using AWS CloudFormation StackSets and AWS Config rules. This allows you to perform drift detection across multiple accounts and regions.

3. Does drift detection work for all resource types?

Drift detection is supported for most resource types managed by CloudFormation, including EC2 instances, RDS databases, S3 buckets, and more. However, there are some resource types for which drift detection is not available.

4. Can I exclude specific resources from drift detection?

Yes, you can specify resource exclusion filters to exclude specific resources from drift detection. This can be useful for resources that are intentionally managed outside of CloudFormation.

5. How can I be notified when drift is detected on a CloudFormation stack?

You can configure AWS Config rules to send notifications when drift is detected on a CloudFormation stack. Notifications can be sent via Amazon SNS, AWS Lambda, or other AWS services.


CloudFormation drift detection and remediation provide essential tools for keeping your infrastructure in sync with your CloudFormation templates. By regularly detecting and resolving drifts, you can ensure that your infrastructure remains consistent with the desired state and maintain the benefits of infrastructure-as-code deployments.