Terraform removed Block Deep Dive: Declaratively Unmanage Resources

In Terraform, removing a resource definition from code normally schedules a destroy. That is a problem in operations when you want to keep the actual resource you created but stop managing it with Terraform.

The removed block is a declarative state operation that fills this gap. It replaces one-off CLI operations such as terraform state rm with code, letting you “forget” a resource in a reviewable and reproducible way.

Purpose and Use Cases of the removed Block

The removed block is a declaration that drops an existing managed resource from Terraform state management without destroying it. At apply time, no destroy is requested from the provider; only the corresponding state entry is removed. The real infrastructure resource stays in place.

Expected use cases include handing off log-storage buckets to another tool or manual operations, putting back into unmanaged state any temporary resources that were Terraform-managed only during validation, and removing entries from state in a team-reviewable fashion.

• Expresses “forget” declaratively so it can be reviewed and tracked via diffs
• Does not trigger destroy, so critical resources can be safely unmanaged
• Re-running has no side effects (idempotent)

Syntax and Evaluation Timing

removed is a top-level block. In from, you specify “the address of the object that was previously managed.” count/for_each instances are supported via index/key specifications. At plan time, Terraform interprets the relevant state entry as a “state removal” rather than a destroy.

In terms of apply ordering, removed is processed as part of the normal diff resolution. If the target does not exist in state, nothing happens. After apply, you may delete the removed block itself from your code (it is a temporary declaration meant for migration).

• Syntax: removed { from = "<address>" }
• Target: instances of managed resources (e.g., aws_s3_bucket.logs or aws_instance.web[0])
• Effect: deletes only the state entry without performing destroy

Plan and apply flow with removed

Choosing Between removed and Other Approaches

removed is the tool for “taking a resource out of management.” Use moved for rename and address changes, terraform state rm for an immediate local-only state edit, and destroy when you actually want to delete the real infrastructure. This distinction is also a frequent exam topic.

In particular, note that merely deleting a resource definition from code schedules a destroy. Use removed in combination when you want to suppress destroy and forget the resource from state.

• moved: declares an address change (from → to). The real resource is preserved; only the association in state is updated
• removed: declares removal from management. The real resource is preserved; it is removed from state
• terraform state rm: a one-off CLI state operation (not declarative, hard to put through review)
• terraform destroy / -target: deletes the real resource. Does not turn it into an unmanaged resource

Real-world Scenario: Unmanage an S3 Log Bucket from Terraform

As an example, suppose aws_s3_bucket.logs (an audit log bucket) will from now on be managed directly by the security team. You want to remove it from Terraform’s scope but keep the actual bucket. Simply deleting it from code schedules a destroy, so you use removed.

After apply, the bucket disappears from state and subsequent plans no longer reference it from Terraform. If other resources reference it, first switch those references (to data sources, external inputs, variables, etc.) before applying.

• When using count/for_each, you can pinpoint a specific instance to exclude (e.g., aws_iam_user.legacy["temp"])
• Once apply completes and a no-op is confirmed, the removed block itself can be deleted (it is a temporary declaration)
• Assumes Terraform 1.6 or later (in real projects, check the docs for the version you use)

HCL example: take an S3 bucket out of management

# Assumes Terraform >= 1.6
# Existing: aws_s3_bucket.logs is present in state

terraform {
  required_version = ">= 1.6.0"
}

# Previously this file defined aws_s3_bucket.logs but it has been removed

# We want to drop it from state without destroying it
removed {
  from = "aws_s3_bucket.logs"
}

# Example of removing a specific count/for_each instance
# removed {
#   from = "aws_iam_user.legacy[\"temp\"]"
# }

Design and Operational Considerations

Watch the order in which dependencies are resolved. If other resources reference the target of removed, plan fails due to a broken reference. Replace the references first (switch to data sources, external inputs, or avoid hardcoding) or split the apply into phases.

To preserve state consistency, the safe practice is to include removed in a PR, get it reviewed, confirm a no-op after apply, and then delete the removed block. If you also use CLI state rm, retain an audit log and runbook of who did what and when.

• removed does not call the provider API (no destroy)
• If the target is not in state, it is a no-op (safe to re-apply)
• Works the same way in Terraform Cloud/Enterprise remote runs (evaluated per workspace)

Certification Exam Prep (Pro-level)

You are expected to clearly articulate the difference between removed and moved, and how they differ from destroy. In scenario questions, read “keep the real resource,” “take it out of management,” and “change the address” as cues, then pick the right block or command.

Other common topics include specifying individual count/for_each instances, the fact that removed is a temporary declaration that can be deleted from code after apply, and that team operations should prefer declarative approaches (removed/moved).

• Keep the real resource + unmanage it → removed
• Keep the real resource + change its address → moved
• Delete the real resource → destroy
• One-off state operation → terraform state rm (not declarative)

Check Your Understanding

Frequently Asked Questions