A new AMI may be available without it being a good time to replace a running instance. In a Terraform resource’s lifecycle block, ignore_changes lists attributes whose later changes should not, by themselves, cause an update. Terraform still uses their configured values when creating the resource. section 2.7.2
Listing 2.29 Ignoring changes for a specific attribute
resource "aws_instance" "hello_world" {
ami = data.aws_ami.ubuntu.id
subnet_id = data.aws_subnets.default.ids[0]
instance_type = var.instance_type
lifecycle {
ignore_changes = [ami] #1
}
}
The instance configuration uses ignore_changes = [ami] to keep a later AMI change from triggering replacement of that instance. section 2.7.2
The setting is also useful when another system adds or removes tags. For broader suppression, ignore_changes = all tells Terraform to create the resource but not update it afterward; Terraform still reads its values to produce resource attributes. section 2.7.2
Listing 2.30 Ignoring all changes example
resource "aws_instance" "hello_world" {
ami = data.aws_ami.ubuntu.id
subnet_id = data.aws_subnets.default.ids[0]
instance_type = var.instance_type
lifecycle {
ignore_changes = all #1
}
}
Compare the all-value configuration with the targeted AMI list: it ignores every later change, not just one attribute. section 2.7.2
Use the rule deliberately when reviewing a plan:
- Look for a resource marked for replacement and identify the attribute that forces it. section 5.7.2
- Decide whether the existing resource should remain. If so, add that attribute to ignore_changes rather than ignoring more changes than necessary. section 5.7.2
- Check downstream effects: one changed input can cause replacements throughout a dependency chain. section 5.7.2
A small change with a large plan
Changing a TLS private key algorithm from ECDSA to ED25519 causes the dependent certificates to be re-created. A plan’s “forces replacement” warning helps reveal that scope before applying the change. section 5.7.2
