Terraform ignore_changes: Stop Plans Fighting Over What You Don't Own
By Vladimir Mikhalev · Docker Captain · CNCF Ambassador · IBM Champion
Here’s a classic Terraform moment:
You tweak a single variable, hit terraform plan, and suddenly Terraform wants to rebuild half your infrastructure because it noticed a change in something it shouldn’t even care about.
Yeah. That.
When you don’t want Terraform getting twitchy over metadata, external changes, or stuff it didn’t create in the first place, you need ignore_changes. No magic. No hacks. You’re just telling Terraform to back off where that makes sense.
Here’s how to use it properly, so your deployments stop acting like an overprotective robot.
What the Hell Is ignore_changes?
It’s a Terraform lifecycle argument that tells the engine:
“Even if this attribute has changed, don’t touch it.”
When used right, it stops Terraform from updating or replacing a resource just because some value drifted from your original config. Especially when that drift was intentional, came from outside, or just doesn’t matter.
The syntax lives inside the lifecycle block of a resource, like so:
lifecycle { ignore_changes = [some_attribute]}No, it doesn’t ignore all changes. And no, it’s not a get-out-of-IaC-responsibility-free card. Used carelessly, it’ll bite you. Used wisely, it’ll save your uptime and your sanity.
When Should You Use ignore_changes?
Here are the real reasons you’d reach for it. Not made-up edge cases.
1. External Systems Are Messing With Your Resources
Example: a team updates tags in the cloud console, outside Terraform. Now every plan shows a diff.
Fix? Ignore the tags.
lifecycle { ignore_changes = [tags]}2. Terraform Keeps Picking Fights with Random Metadata
Timestamps, version IDs, generated names. Terraform can’t help itself. You don’t want it to re-provision a resource because some backend system touched a metadata field.
Ignore those noisy attributes.
3. You’re Managing Part of the Resource Elsewhere
Say your networking is owned by a platform team running a different tool.
You just need to reference the network_interface_ids, not own them.
Fine. Ignore the changes:
lifecycle { ignore_changes = [network_interface_ids]}4. Secrets Drift, and That’s Okay
Passwords and keys get rotated externally all the time. Vault, AWS Secrets Manager, whatever. Terraform sees the change and freaks out.
Unless you tell it to chill:
lifecycle { ignore_changes = [admin_password]}(But for the love of ops, don’t hardcode passwords in plain HCL. Ever.)
5. You Want to Lock a Resource in Place
Sometimes you just want Terraform to stop touching a resource altogether. During a migration, say, or disaster recovery, or while someone’s elbow-deep in it by hand.
Yes, this is a band-aid. But it’s better than destroying production during a Friday deploy.
Things to Know Before You Use It
Don’t just copy-paste this like a Stack Overflow spell. Know what you’re doing:
ignore_changesis resource-specific. You define it inside the resource, nowhere else.- You must name each attribute exactly as Terraform sees it.
- It won’t ignore everything unless you explicitly tell it to.
- It doesn’t stop Terraform from tracking changes. It only stops it from acting on them.
Real-World Examples
Azure VM: Ignore Volatile Attributes
resource "azurerm_virtual_machine" "example" { name = "example-vm" location = "UK South" resource_group_name = azurerm_resource_group.example.name network_interface_ids = [azurerm_network_interface.example.id] vm_size = "Standard_DS1_v2"
storage_os_disk { name = "example-os-disk" caching = "ReadWrite" create_option = "FromImage" managed_disk_type = "Premium_LRS" }
os_profile { computer_name = "examplevm" admin_username = "adminuser" admin_password = var.admin_password # declare it with sensitive = true, never a literal }
lifecycle { ignore_changes = [ network_interface_ids, storage_os_disk, os_profile[0].computer_name, ] }}This stops Terraform from rewriting your VM every time the disk or network interface shifts. Azure loves to tweak those behind your back.
Ignore All Changes (Yes, Really)
resource "azurerm_storage_account" "example" { name = "examplestorageaccount" resource_group_name = azurerm_resource_group.example.name location = "East US" account_tier = "Standard" account_replication_type = "LRS"
lifecycle { ignore_changes = all }}Terraform will still track the resource, but it won’t try to update it. Useful when you need Terraform to “know” something exists without touching it.
Final Thoughts: Use It Like a Scalpel, Not a Sledgehammer
ignore_changes is powerful. Too powerful, if you’re not careful.
Use it when:
- You have external systems or human changes that you don’t want Terraform to reverse
- You’re stuck with flaky, drift-prone metadata
- You need Terraform to respect reality instead of overwriting it with an idealized config
But always document why you reached for it. And review those ignores in every PR. What makes sense today can cause a surprise outage next month.