Ignore AMI Changes

Adds ignore_changes = [ami, image_id] to EC2 instances, preventing Terraform from replacing instances when a newer AMI is published.

When to use this rule

Use this when: Your EC2 instances use data.aws_ami lookups that resolve to new AMI IDs when AWS publishes updates, and you manage AMI updates separately (Systems Manager, AMI pipelines, or blue-green deployments).

Do not use this when: You want Terraform to replace instances when a new AMI is available. Or you use a fixed AMI ID rather than a data source lookup.

Why this rule exists

Many Terraform configurations use data.aws_ami lookups to find the latest AMI matching a set of filters. When AWS publishes a new AMI, the data source resolves to a different ID on the next plan. Because ami is a ForceNew attribute on aws_instance, Terraform plans to destroy and recreate the instance.

In production, unexpected instance replacement causes downtime. Teams that manage AMI updates through patching pipelines or blue-green deployments need Terraform to leave the ami attribute alone after creation.

Repository	Issue	Title
hashicorp/terraform	#27360	A method to override configuration and meta arguments within a module
hashicorp/terraform	#21546	Passing ignore_changes into a module

Affected resources

Resource	Service	Why
`aws_instance`	Amazon EC2	ami is a ForceNew attribute; changes trigger instance replacement
`aws_launch_template`	EC2 Launch Templates	image_id changes trigger new template versions

Known limits

Only ignores ami on aws_instance and image_id on aws_launch_template. Does not cover aws_launch_configuration (deprecated) or ECS task image references.
Does not prevent AMI-related changes on Auto Scaling Groups or Spot Fleet requests.

What this rule does

Adds a lifecycle { ignore_changes = [...] } block to each matching resource. Terraform and OpenTofu will ignore external changes to the listed attributes on subsequent plans.

Ignored attributes: ami, image_id

Before and after

Before (upstream module)After (with Ignore AMI Changes applied)

resource "aws_instance" "this" {
  # ... resource configuration ...

  tags = var.tags
}

resource "aws_instance" "this" {
  # ... resource configuration ...

  tags = var.tags

  lifecycle {
    ignore_changes = [
      ami,
      image_id,
    ]
  }
}

The only change is the rule transformation. All existing arguments, outputs, and module behavior remain identical.

Real-world scenario

AWS published a new Amazon Linux 2 AMI on a Tuesday. Wednesday morning, terraform plan proposed replacing 12 production EC2 instances, which would have caused 15 minutes of downtime per instance during business hours.

Compliance framework support

This rule is not a compliance control. It supports these framework objectives as an operational safeguard:

Framework	Controls	Role
SOC 2	CC7.1	Supports change management by preventing unplanned instance replacements

Default configuration

This rule ships with the following defaults. Custom parameterization via the registry is planned for a future release.

Parameter	Type	Default	Description
`ignore_changes`	`list(string)`	`["ami", "image_id"]`	Lifecycle attributes to ignore
`resource_types`	`list(string)`	`["aws_instance", "aws_launch_template"]`	Target resource type patterns

How to enable

URL query parameterOrganization defaults

Add ?rules=pofix/ignore_ami_changes to your HTTPS module source:

module "example" {
  source = "https://soc2.compliance.tf/terraform-aws-modules/s3-bucket/aws?version=5.0.0&rules=pofix/ignore_ami_changes"
}

Configure via the compliance.tf API. See Getting Started with Operational Rules.

Failure modes

Scenario	Result
Instance needs a critical AMI security patch	You are responsible for updating the AMI through your patching pipeline. Terraform will not trigger a replacement automatically.
AMI data source is removed from config	The ignore_changes block remains but has no practical effect if the ami attribute is now a static value.

Terraform and OpenTofu compatible

This rule works with both Terraform (1.x+) and OpenTofu (1.6+). The generated HCL uses standard lifecycle meta-arguments supported by all versions.

Help us improve this page

Operational Rules are a new feature. We'd love your feedback on this rule page — what's useful, what's missing, what's confusing. Share feedback.