Chapter 37: Terraform Import Moved and Removed Blocks

37.3 removed block — stop managing without deleting

By Ravindra Bagale · Last updated: 25 October 2026

Story. An Instagram-style team handed a CloudWatch log group to another team's Terraform. Simply deleting the block would make the next apply delete the log group and its history. A removed block with destroy = false tells Terraform to forget the resource but leave it running in AWS. It replaces risky manual terraform state rm in reviewed code.

removed {
  from = aws_cloudwatch_log_group.app

  lifecycle {
    destroy = false
  }
}

What each line does

• removed { — Declares that this address should no longer be managed here.
• from = aws_cloudwatch_log_group.app — The address to forget; the resource block itself is deleted from code.
• lifecycle { destroy = false } — Keep the real log group in AWS; only remove it from state.

When it is green.

  # aws_cloudwatch_log_group.app will no longer be managed by Terraform
Plan: 0 to add, 0 to change, 0 to destroy.

When it is red.

  # aws_cloudwatch_log_group.app will be destroyed
  # (because aws_cloudwatch_log_group.app is not in configuration)
Plan: 0 to add, 0 to change, 1 to destroy.

Fix. You deleted the resource block but forgot the removed block. Do not apply. Add the removed block with destroy = false and plan again.

What: every term in plain English

• removed block — Tells Terraform to stop managing an address.
• destroy = false — Keep the real object in AWS. Only forget it in state.
• destroy = true — Delete the real object too. Same as deleting the block, but clearer.
• hand-off — Giving a resource to another team or another state file.
• state rm — The old CLI way to forget a resource. No review.
• not in configuration — Plan text that means: the block is gone, so Terraform will destroy it.
• prevent_destroy — A lifecycle setting that blocks any plan that would delete the resource.

Example 1: Hand a log group to another team

An Instagram-style platform team gave the app log group to the app team. The logs must stay.

1. Delete the aws_cloudwatch_log_group.app block from main.tf.
2. Add the removed block.
3. Plan and apply.
4. Check the log group still exists.

removed {
  from = aws_cloudwatch_log_group.app

  lifecycle {
    destroy = false
  }
}

terraform plan
terraform apply
terraform state list
aws logs describe-log-groups --log-group-name-prefix /app/web --query "logGroups[].logGroupName"

Output

  # aws_cloudwatch_log_group.app will no longer be managed by Terraform, but will not be destroyed

Plan: 0 to add, 0 to change, 0 to destroy.
Apply complete! Resources: 0 added, 0 changed, 0 destroyed.
[
    "/app/web"
]

What it shows: state list no longer shows the log group, but AWS still has it.

Example 2: Move a bucket between two state files

The bucket must leave the platform state and join the data team state. removed in one, import in the other.

1. In platform repo: delete the block, add removed with destroy = false, apply.
2. In data repo: add an import block and the resource, apply.

# platform repo
removed {
  from = aws_s3_bucket.events
  lifecycle {
    destroy = false
  }
}

# data repo
import {
  to = aws_s3_bucket.events
  id = "demo-events-1234"
}

resource "aws_s3_bucket" "events" {
  bucket = "demo-events-1234"
}

cd platform && terraform apply
cd ../data && terraform apply

Output

platform: Apply complete! Resources: 0 added, 0 changed, 0 destroyed.
data:     Apply complete! Resources: 1 imported, 0 added, 0 changed, 0 destroyed.

What it shows: Order matters: forget first, then import. Never let two states manage the same bucket.

Example 3: Forget a whole module

A legacy module created a VPC that the network team now owns.

1. Delete the module call.
2. Add removed for the module address.
3. Plan.

removed {
  from = module.legacy_vpc
  lifecycle {
    destroy = false
  }
}

terraform plan

Output

  # module.legacy_vpc.aws_vpc.this will no longer be managed by Terraform, but will not be destroyed
  # module.legacy_vpc.aws_subnet.a will no longer be managed by Terraform, but will not be destroyed

Plan: 0 to add, 0 to change, 0 to destroy.

What it shows: All resources inside the module are forgotten together.

Example 4: Guard with prevent_destroy

A Paytm-style team wanted a hard stop so nobody deletes the payments bucket by mistake.

1. Add prevent_destroy to the bucket.
2. Delete the block by mistake and plan.
3. See the error.

resource "aws_s3_bucket" "payments" {
  bucket = "demo-payments-1234"
  lifecycle {
    prevent_destroy = true
  }
}

terraform plan -destroy

Output

Error: Instance cannot be destroyed
  on main.tf line 1:
Resource aws_s3_bucket.payments has lifecycle.prevent_destroy set, but the plan calls for this resource to be destroyed.

What it shows: prevent_destroy stops deletion. To hand it off, use removed with destroy = false instead.

Command cheat sheet

Verify: did it work?

1. Gone from state

   terraform state list
   

   Output

   (address not listed)
   

2. Still in AWS

   aws s3api head-bucket --bucket demo-events-1234; echo $?
   

   Output

   0
   

When it is red 1

  # aws_cloudwatch_log_group.app will be destroyed
  # (because aws_cloudwatch_log_group.app is not in configuration)
Plan: 0 to add, 0 to change, 1 to destroy.

Cause. You deleted the block without a removed block.

Fix, step by step

1. Stop. Do not apply.
2. Add removed with destroy = false.
3. Plan again.

When it is red 2

Error: Removed resource block still exists
This statement declares that aws_s3_bucket.events was removed, but it is still declared in a resource block.

Cause. The resource block is still in code.

Fix, step by step

1. Delete the resource block.
2. Keep only the removed block.

When it is red 3

Error: creating S3 Bucket (demo-events-1234): BucketAlreadyOwnedByYou

Cause. The new state tried to create instead of import.

Fix, step by step

1. Add an import block for the bucket.
2. Plan again and expect 1 to import.

Cleanup

aws logs delete-log-group --log-group-name /app/web
aws s3 rb s3://demo-events-1234 --force

Practice tasks

Homework: try at home

Recap

• Deleting a block means destroy.
• removed with destroy = false forgets but keeps.
• For hand-offs: removed first, then import in the new state.
• removed replaces state rm in reviewed code.
• prevent_destroy blocks deletes of key data.

FAQ

Which version do I need?

Terraform 1.7 or later for removed blocks.

Can I delete the removed block later?

Yes, after it has been applied in every environment.

Is state rm still useful?

Only in emergencies. Take terraform state pull first.

Does removed work on modules?

Yes, use the module address.

What if both states manage one bucket?

They will fight. Each apply may undo the other. Always remove first, then import.

Interview questions

1. How do you stop managing a resource without deleting it?

   A removed block with lifecycle destroy = false, then apply.

2. How do you move a resource between two state files?

   removed with destroy = false in the old state, then an import block in the new one.

3. removed vs state rm?

   removed is code, reviewed and repeatable. state rm is a one-off command on one machine.

4. What does not in configuration mean in a plan?

   The block was deleted, so Terraform will destroy the object.

5. How do you protect a critical bucket?

   lifecycle prevent_destroy = true, plus versioning and backups.

Samajla ka?

Ravi Sir's Cards for this lesson

Revision cardInterview card

मराठी cards