Removing Resources with the removed Block

In this lesson we explain how to use Terraform’s removed block to stop Terraform from tracking resources in state without destroying the actual infrastructure. This pattern is useful when you need Terraform to “forget” a resource (for example, handing it off to another team or switching to manual management) but you must not delete the underlying resource. Example scenario You manage two Cloud SQL instances with Terraform in production. Here are the original resource blocks:

resource "google_sql_database_instance" "prd_db_1" {
  name             = "production-db-01"
  database_version = "POSTGRES_15"
  region           = "us-central1"

  settings {
    tier = "db-f1-micro"
  }
}

resource "google_sql_database_instance" "prd_db_2" {
  name             = "production-db-02"
  database_version = "POSTGRES_15"
  region           = "us-central1"

  settings {
    tier = "db-f1-micro"
  }
}

If the database team asks that schema changes be done manually, you may need Terraform to stop managing one or both instances. Deleting the resource blocks from your configuration without updating state causes terraform plan to show a destroy for the now-absent resources — which would delete months of production data. The removed block prevents that by updating state while leaving the real infrastructure intact. What the removed block does

Removes the resource from the Terraform state so Terraform no longer tracks or manages it.
Does not destroy the actual infrastructure when used correctly.
Acts as temporary scaffolding to update state safely; after the state change, you can delete the removed block from your configuration.

Important: when mentioning lifecycle settings inline in text, wrap them in backticks to avoid MDX parsing issues, for example use lifecycle { prevent_destroy = true }. Example removed block Below is an example removed block for each database we want Terraform to forget. The lifecycle setting prevents Terraform from destroying the resource during the state update, ensuring the database remains intact while Terraform stops tracking it:

removed {
  from = google_sql_database_instance.prd_db_1
  lifecycle {
    prevent_destroy = true
  }
}

removed {
  from = google_sql_database_instance.prd_db_2
  lifecycle {
    prevent_destroy = true
  }
}

Warning: remove or comment out the resource blocks You must remove (or comment out) the corresponding resource blocks from your Terraform configuration before running terraform plan / terraform apply with removed blocks present. If a removed block and its corresponding resource definition both exist in your configuration, Terraform will detect the conflict and refuse the state update.

Always back up your state file (for example, export a copy of your Terraform Cloud workspace state or copy your local state file) before manipulating state with removed blocks.

Step-by-step workflow for using removed

Add a removed block for every resource you want Terraform to stop managing. Include lifecycle { prevent_destroy = true } if you want to explicitly prevent accidental destroys while you update state.
Delete or comment out the corresponding resource blocks from your Terraform configuration.
Run terraform plan to validate the plan and ensure Terraform will perform a state-only update (no destroy).
Run terraform apply to update the state. Terraform will remove those resources from state and will not destroy the underlying infrastructure.
After confirming the state is updated and you no longer need Terraform to reference the resource, remove the removed blocks from your configuration (they are temporary scaffolding).

Comparing moved vs removed

Situation	Desired outcome	Recommended Terraform feature
You are renaming or reorganizing a resource within Terraform and want to preserve management	Update state to a new address so Terraform continues to manage the resource	`moved`
You want Terraform to stop managing a resource entirely (hand off to another team, manual management, or import into a different state)	Remove the resource from Terraform state but keep the actual resource	`removed`

Real-world use cases for removed

Handing off a shared networking resource to another team: remove it from your state and let the other team import it into theirs.
Breaking a monolithic Terraform project into smaller projects: remove resources from one state and import them into another workspace.
Migrating away from another IaC tool (for example, AWS CloudFormation → Terraform): you may choose to stop management in the source tool, import into Terraform, and then remove the old tool’s management.

Best practices and tips

Always back up state before performing state manipulation.
Test the process in a non-production workspace or with a copy of your state file first.
Use lifecycle { prevent_destroy = true } in the removed block (as shown) to avoid accidental destruction while applying state changes.
Confirm team ownership and import requirements before removing resources from state to prevent orphaned infrastructure that no one manages.

Links and references

A purple "Decision Tree" infographic that helps choose Terraform blocks, mapping common tasks to outcomes. It shows actions like renaming resources or reorganizing into modules → "moved block," and stopping management, handing off, or splitting configurations → "removed block."

Course Introduction

Preparing Your Environment

Terraform Foundations

The Core Terraform Workflow

Terraform CLI

Terraform File Structure and Organization

Terraform Configuration - Fundamentals

Understading and Managing Terraform State

Marking Code Reusable

Refactoring Terraform State

Terraform Modules

Managing Resource Behavior and Dependencies

Securing Terraform Configurations

Terraform Troubleshooting

HCP Terraform

Removing Resources with the removed Block

Watch Video