Terraform workflow: remove resources without destroying with removed blocks
Deleting a config block destroys the object by default. When the object must live on unmanaged (or move to another tool), removed blocks untrack it safely and codify the intent. Not the full reference manual.
TL;DR: Deleting a config block destroys the object by default. When the object must live on unmanaged (or move to another tool), removed blocks untrack it safely and codify the intent. Replace the resource block with a removed block: destroy = false is the load-bearing line: without it, Terraform destroys the object. The plan must show the resource being forgotten, with NO destroy.
When
A resource leaves Terraform management but must keep existing: handoff to another team, migration to another IaC tool, or decomposing a monolith config.
Steps
Replace the resource block with a removed block:
removed { from = aws_instance.legacy lifecycle { destroy = false } }destroy = falseis the load-bearing line: without it, Terraform destroys the object.terraform plan. The plan must show the resource being forgotten, with NO destroy. If it shows a destroy, stop: the lifecycle setting is wrong or in the wrong place.terraform apply. Verify the object still exists in the console and no longer appears interraform state list.- Keep the removed block as documentation, or delete it once the handoff is complete and everyone has applied past it.
Rules for agents
- Default
removedwithout the lifecycle block destroys. This is the single most dangerous default in the removal workflow; double-check the block every time. - For resources with dependencies: removing a resource others reference breaks their config. Update or remove the references in the same change.
- Data loss check: if the object holds state (database, bucket with data), confirm the new owner/management before untracking. Untracked and unowned is how data gets deleted by the next person who finds it.
- Prefer removed blocks over
terraform state rm: the block is in version control, reviewed, and replayable. state rm is invisible to the next reader.
When to use this
- This covers exactly what the title says: Terraform workflow.
- You are setting this up for the first time, or auditing an existing setup.
- You want the key gotchas in one place before you start.
When not to use this
- You are doing a different workflow with Terraform; these steps are specific to the title above.
- You need the full reference docs; this is the short path, not the manual.