Skip to content
Ask AI about this
Help improve this page

CloudFormation stacks should have rollback enabled

A failed CloudFormation stack operation without rollback leaves resources in an inconsistent state. You end up with half-created infrastructure that still costs money, breaks dependent services, and requires manual cleanup. Disabling rollback is sometimes used during debugging, but it should never reach production.

Automatic rollback is your safety net during deployments. When a resource fails to provision or a CloudWatch alarm fires during a monitored update, rollback reverts the entire stack to its previous state atomically. Without it, you accept the risk of partial deployments that are harder to reason about and recover from than a clean failure.

Retrofit consideration

Stacks currently running with disable_rollback = true may be in that state intentionally for debugging. Verify each stack before flipping the setting, as enabling rollback on a stack already in a failed state could trigger an immediate rollback on the next update.

Implementation

Choose the approach that matches how you manage Terraform.

Use AWS provider resources directly. See docs for the resources involved: aws_cloudformation_stack.

resource "aws_cloudformation_stack" "this" {
  name              = "pofix-abc123"
  notification_arns = ["arn:aws:sns:us-east-1:123456789012:example-topic"]
  template_body     = jsonencode({ AWSTemplateFormatVersion = "2010-09-09", Description = "Empty stack", Resources = { NullResource = { Type = "AWS::CloudFormation::WaitConditionHandle" } } })

  disable_rollback = false
}

What this control checks

For aws_cloudformation_stack, disable_rollback must be false or omitted entirely (it defaults to false). Setting disable_rollback = true causes a failure.

The on_failure argument applies only to stack creation behavior. on_failure = "DO_NOTHING" is non-compliant because it preserves partial resources on create failure. on_failure = "DELETE" is not a rollback-disable flag, but it uses delete-on-failure semantics rather than rollback.

A rollback_configuration block with CloudWatch alarm ARNs in rollback_triggers and a monitoring_time_in_minutes value adds alarm-based rollback monitoring. The primary check is simply that rollback isn't disabled.

Common pitfalls

  • on_failure overrides disable_rollback

    Terraform's aws_cloudformation_stack treats on_failure and disable_rollback as mutually exclusive. If you set on_failure = "DO_NOTHING", rollback is effectively disabled even though disable_rollback remains at its default false. Scanners that only check disable_rollback will miss this.

  • Nested stack failures can be misinterpreted as inherited rollback settings

    In nested stack deployments, parent stack failure handling cascades to child resources, but child stacks don't automatically inherit the parent's rollback configuration. Assuming they do is a common gap. Audit both root and nested stack configurations and review actual failure events to understand the effective behavior.

  • Debugging workflows leave rollback disabled

    Developers often set disable_rollback = true during development to inspect failed resources. If that change gets committed and promoted through CI/CD, production stacks lose their rollback protection without anyone noticing. Use environment-specific variable files or policy-as-code checks in the pipeline to catch this before it ships.

  • Terraform-managed infrastructure may not use CloudFormation

    If your organization uses Terraform's AWS provider directly rather than aws_cloudformation_stack, this control has no resources to evaluate. It applies only when Terraform is used to manage CloudFormation stacks, or when stacks are created outside Terraform entirely.

Audit evidence

An auditor expects AWS Config rule evaluation results showing all CloudFormation stacks pass the rollback check, or equivalent output from a cloud security posture management tool. Console screenshots of each in-scope stack with "Rollback on failure" set to "Enabled" work as supporting evidence.

CloudTrail logs for CreateStack and UpdateStack should show DisableRollback absent or false and OnFailure as ROLLBACK or absent. CloudFormation event history showing successful automatic rollbacks confirms the control has actually operated, not just been configured.

Tool mappings

Use these identifiers to cross-reference this control across tools, reports, and evidence.

  • Compliance.tf Control: cloudformation_stack_rollback_enabled

  • Powerpipe Control: aws_compliance.control.cloudformation_stack_rollback_enabled

Last reviewed: 2026-03-08