Modern Terraform Practices: Removing Resources Safely from State

Introduction and Usecase

There are times when we want Terraform to stop managing a resource, but don’t want to delete it from the infrastructure.

In this brief blog, I’m going to discuss removing resources from Terraform configuration files while keeping them in real infrastructure. But why would you want to do this in the first place? Let’s see some possible reasons:

1. One possible reason is that you are handing over the resource to another team that prefers to manage it differently.
2. There could be a maintenance window planned, and you want to remove certain resources from being managed by Terraform during that time frame.
3. Or maybe you’re splitting Terraform modules and want to restructure your configuration files.
   In this blog, I’ll show different ways to remove a resource from Terraform without deleting it from your AWS cloud environment, using a simple EC2 instance as an example.

Removing Resources from Terraform Management

There are two ways to go about it. The first is the quick way, and the second is to leave a trace in your configuration file so that other people know you removed the resource. Let’s explore both ways and see how they work.

Setup

Let’s say you already have a configuration like this:

resource "aws_instance" "web" {
  ami           = "ami-04999cd8f2624f834"
  instance_type = "t2.micro"
  tags = {
    Name = "my-ec2-instance"
  }
}

You can check what Terraform is managing with:

terraform state list

terraform state list

Possible Solutions

Solution 1: Using terraform rm (Traditional Way)

So with our first approach, what I will do is run terraform state rm and specify the resource that I want to remove. Once I click Enter, my EC2 instance has now been removed from the state.

terraform state rm

So if I do terraform state list now, Terraform is no longer managing my resource, and it has been removed from the state file.

terraform state list

If I do a terraform plan now, Terraform does not have it in the state file anymore, so it would try to recreate the resource.

Terraform Plan

Terraform Plan

Since we are trying to remove it, we have removed it from the state file. The next step would be to remove it from the configuration file. I’m going to comment this out so that Terraform doesn’t read it anymore and create the resource again.

Comment Code

Okay, so now if I do terraform plan, it’s been removed from my configuration. If I do a terraform plan now, we should not see any changes, and the resource has been removed.

Terraform Plan

This is an acceptable way of removing resources from the state file, but still keeping them in a real cloud environment — you removed it from the state and then removed it from the configuration. But, you know, nobody knows that you’ve done it, and that’s when the second way of doing this kind of stuff comes in. Let’s explore how.

Solution 2: Terraform Removed Block

Note: Terraform v1.7 or later is required to use the `removed` block.

Let’s now look into the second approach — using the removed block, which is a more advanced and trackable way to remove resources from the Terraform state without destroying them in the real infrastructure.

Before we do that, I want to have the resource created in my infrastructure. So what I will do is bring the config back and do a terraform apply, which will create my EC2 instance again.

In the previous setup, I had removed it from the state file, but it was still sitting in my AWS console. So just make sure, if you’re following along and destroying resources using Terraform, that you also remove them from the console if needed.

For this one, I’m just going to say “yes” here. This will create my EC2 instance.

Terraform Plan

Okay, so my EC2 instance has been created again, and it is part of the state now. If I just do terraform state list, this instance is now part of the state and part of the Terraform configuration.

terraform state list

But just keep in mind one thing: we created a new EC2 instance. The one that we removed from the configuration file — that’s the one you would have to remove from the console. Now we’re going to look into the second way of removing it, which is using the terraform removed block, which was released in terraform v1.7. Read here: https://github.com/hashicorp/terraform/blob/v1.7/CHANGELOG.md

Remove or comment out the existing aws_instance resource and add this new removed block, where you specify the from and the resource that you are going to remove, and then you use the lifecycle block, which is required so that Terraform does not destroy your resource.

Terraform Removed Block

This tells Terraform:

from = aws_instance.web: This is the resource being removed from the state.

lifecycle { destroy = false }: Ensures Terraform doesn’t attempt to destroy the actual resource in AWS, just forgets about it in state.

Once you have commented  the resource and specified this new removed block, you can save your configuration, come back here, and just do terraform plan. This would tell you that some of the objects will no longer be managed by Terraform.

Terraform Removed Block

For that to take effect, we have to do a terraform apply. So my state file knows about this. As soon as I do terraform apply, I just have to confirm it, and once the apply is completed, my EC2 instance is no longer being managed by Terraform.

Terraform Apply

If I go to my state list with terraform state list, that EC2 instance is no longer being managed by Terraform.

terraform state list

And with that, we’ve safely removed a Terraform-managed resource from state without destroying it, using the proper, trackable removed block approach.

Comparison

Conclusion

With the introduction of the removed block in Terraform v1.7, the process of safely removing terraform managed resources without impacting live infrastructure has  become more transparent, auditable,versioned and collaboration-friendly. This can be really helpful during code refactoring, team transitions or complex migrations.

At TO THE NEW, we specialize in solving real-world DevOps challenges, from state management to large-scale infrastructure transformations on AWS, Azure, GCP, and other cloud providers. Whether you’re modernizing Terraform practices or planning a zero-downtime migration, our certified AWS architects and DevOps engineers are here to ensure your cloud journey is efficient, reliable, and future-proof.

To The New Devops Solutions

Stay connected for more practical insights as we continue to simplify cloud operations and enable smarter infrastructure decisions.