In Terraform, an autoscaler keeps changing an attribute that your configuration also sets, so every plan shows a diff. How does the lifecycle block's `ignore_changes` fix that, and what does it cost you?

## The problem it solves Some attributes have two owners. You declare a desired count, a capacity, a tag set or a deployed artefact version in Terraform; then an autoscaler, a deployment pipeline, or an organisation-wide tagging policy changes it in the real world. On the next run Terraform refreshes, sees the difference between the real value and your configuration, and plans to put it back. If you apply, you fight the other system; if you do not, every plan is noisy and reviewers stop reading plans carefully — which is the more expensive failure. `ignore_changes` is the declared answer to "something else mutates this attribute". ## Syntax and semantics ```hcl lifecycle { ignore_changes = [ desired_count, tags["LastDeployed"], ] } ``` The entries are references to attributes of this resource's own configuration, written bare rather than as strings, and you can address a single map element such as `tags["LastDeployed"]` instead of the whole map. The special keyword `all` — `ignore_changes = all` — suppresses every attribute at once. Two details candidates routinely get wrong: - **It only affects updates to an existing object.** When the resource is first created, the configured value is used normally. So a service created with `desired_count = 2` and `ignore_changes = [desired_count]` starts at 2 and then never hears from Terraform about that attribute again. - **It does not stop the refresh.** Terraform still reads the object and stores the current real value in state. What it changes is the diff step: for the ignored attributes Terraform compares against the prior state value rather than your configuration, so there is nothing to propose. ## What it does to drift detection This is the sentence to say out loud: for the listed attributes, drift stops being reported at all. Not "reported and skipped" — simply absent from the plan. That is exactly what you want for an attribute another controller legitimately owns, and exactly what you do not want for an attribute a human changed at 3am in the console. Since the two look identical from inside Terraform, the size of the list is the size of your blind spot. That makes `ignore_changes = all` a heavy instrument. It is defensible for a resource Terraform should create and then never manage — an imported legacy object you are keeping in state for reference, or a resource whose whole configuration is owned elsewhere — but as a way of quietening a noisy plan it hides real regressions along with the noise. ## Common, legitimate uses - `desired_count` on `aws_ecs_service` or `desired_capacity` on `aws_autoscaling_group`, where an autoscaling policy is the real owner. - Tags injected by an external governance tool, ignored individually so the tags you do manage still get enforced. - An artefact reference — an image tag or a Lambda source hash — that a deployment pipeline updates between Terraform runs, so infrastructure changes do not roll the application back to whatever the last committed version was. - An attribute the provider itself normalises or populates in a way that produces a permanent phantom diff. ## Getting back in control Because the configured value is only applied at create time, changing your configuration for an ignored attribute has no effect. To reassert Terraform's value you remove the entry from `ignore_changes` and run a plan, which will then show the difference and let you apply it. Some teams keep the ignore permanent but move the value out of the resource and into a comment or variable documenting who the real owner is — the point is that an `ignore_changes` entry is a statement about ownership, and it belongs in review with a reason attached. ## Interaction with the rest of the lifecycle block If the attribute being ignored is one that forces replacement, ignoring it also stops the replacement being planned — that is often the actual reason for adding it, for example ignoring an `ami` change so instances are not rolled by an AMI lookup returning something new. `prevent_destroy` and `create_before_destroy` are unaffected: they act on destroys and their ordering, not on which attributes are compared.