{"id":72032,"date":"2025-05-29T15:04:47","date_gmt":"2025-05-29T09:34:47","guid":{"rendered":"https:\/\/www.tothenew.com\/blog\/?p=72032"},"modified":"2025-05-29T22:38:47","modified_gmt":"2025-05-29T17:08:47","slug":"modern-terraform-practices-removing-resources-safely-from-state","status":"publish","type":"post","link":"https:\/\/www.tothenew.com\/blog\/modern-terraform-practices-removing-resources-safely-from-state\/","title":{"rendered":"Modern Terraform Practices: Removing Resources Safely from State"},"content":{"rendered":"

Introduction and Usecase<\/strong><\/span><\/h2>\n

There are times when we want Terraform to stop managing a resource, but don\u2019t want to delete it from the infrastructure.<\/p>\n

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\u2019s see some possible reasons:<\/p>\n

    \n
  1. One possible reason is that you are handing over the resource to another team that prefers to manage it differently.<\/li>\n
  2. There could be a maintenance window planned, and you want to remove certain resources from being managed by Terraform during that time frame.<\/li>\n
  3. Or maybe you’re splitting Terraform modules and want to restructure your configuration files.
    \nIn this blog, I\u2019ll 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.<\/li>\n<\/ol>\n
    \"Removing

    Removing Resources from Terraform Management<\/p><\/div>\n

    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\u2019s explore both ways and see how they work.<\/p>\n

    Setup<\/strong><\/span><\/h2>\n

    Let\u2019s say you already have a configuration like this:<\/p>\n

    resource \"aws_instance\" \"web\" {\r\n\u00a0 ami \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 = \"ami-04999cd8f2624f834\"\r\n\u00a0 instance_type = \"t2.micro\"\r\n\u00a0 tags = {\r\n\u00a0 \u00a0 Name = \"my-ec2-instance\"\r\n\u00a0 }\r\n}<\/pre>\n
    You can check what Terraform is managing with:<\/p>\n
    terraform state list<\/pre>\n
    \"terraform
    terraform state list<\/p><\/div>\n
    Possible Solutions<\/strong><\/span><\/h2>\n
    Solution 1: Using terraform rm (Traditional Way)<\/strong><\/span><\/h3>\n
    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.<\/p>\n
    \"terraform
    terraform state rm<\/p><\/div>\n
    So if I do terraform state list now, Terraform is no longer managing my resource, and it has been removed from the state file.<\/p>\n
    \"terraform
    terraform state list<\/p><\/div>\n
    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.<\/p>\n
    \"Terraform
    Terraform Plan<\/p><\/div>\n
    \"Terraform
    Terraform Plan<\/p><\/div>\n
    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\u2019m going to comment this out so that Terraform doesn\u2019t read it anymore and create the resource again.<\/p>\n
    \"Comment
    Comment Code<\/p><\/div>\n
    Okay, so now if I do terraform plan, it\u2019s been removed from my configuration. If I do a terraform plan now, we should not see any changes, and the resource has been removed.<\/p>\n
    \"Terraform
    Terraform Plan<\/p><\/div>\n
    This is an acceptable way of removing resources from the state file, but still keeping them in a real cloud environment \u2014 you removed it from the state and then removed it from the configuration. But, you know, nobody knows that you\u2019ve done it, and that\u2019s when the second way of doing this kind of stuff comes in. Let\u2019s explore how.<\/p>\n
    Solution 2: Terraform Removed Block<\/strong><\/span><\/h3>\n
    Note: Terraform v1.7 or later is required to use the `removed` block.<\/strong><\/span><\/em><\/p>\n
    Let\u2019s now look into the second approach \u2014 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.<\/p>\n
    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.<\/p>\n
    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\u2019re following along and destroying resources using Terraform, that you also remove them from the console if needed.<\/p>\n
    For this one, I\u2019m just going to say \u201cyes\u201d here. This will create my EC2 instance.<\/p>\n
    \"Terraform
    Terraform Plan<\/p><\/div>\n
    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.<\/p>\n
    \"terraform
    terraform state list<\/p><\/div>\n
    But just keep in mind one thing: we created a new EC2 instance. The one that we removed from the configuration file \u2014 that\u2019s the one you would have to remove from the console. Now we\u2019re 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<\/a><\/p>\n
    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.<\/p>\n
    \"Terraform
    Terraform Removed Block<\/p><\/div>\n
    This tells Terraform:<\/p>\n
    from = aws_instance.web: This is the resource being removed from the state.<\/pre>\n
    lifecycle { destroy = false }: Ensures Terraform doesn\u2019t attempt to destroy the actual resource in AWS, just forgets about it in state.<\/pre>\n
    Once you have commented\u00a0 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.<\/p>\n
    \"Terraform
    Terraform Removed Block<\/p><\/div>\n
    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.<\/p>\n
    \"Terraform
    Terraform Apply<\/p><\/div>\n
    If I go to my state list with terraform state list, that EC2 instance is no longer being managed by Terraform.<\/p>\n
    \"terraform
    terraform state list<\/p><\/div>\n
    And with that, we\u2019ve safely removed a Terraform-managed resource from state without destroying it, using the proper, trackable removed block approach.<\/p>\n
    Comparison<\/strong><\/span><\/h2>\n\n\n\n\n\n\n\n\n\n\n\n
    Feature<\/strong><\/span><\/td>\nterraform state rm<\/strong><\/span><\/td>\nTerraform removed Block (Terraform v1.7+)<\/strong><\/span><\/td>\n<\/tr>\n
    Purpose<\/td>\nRemoves a resource from the state file using the imperative command.<\/td>\nDeclaratively removes a resource from the state via code<\/td>\n<\/tr>\n
    Configuration Visibility<\/td>\nHidden \u2013 nothing in the code shows the resource was removed<\/td>\nVisible in the Terraform configuration \u2013 leaves a trace<\/td>\n<\/tr>\n
    Version Control Friendly<\/td>\nNot trackable in version control<\/td>\nYes, as part of .tf files<\/td>\n<\/tr>\n
    Auditable \/ Collaborative<\/td>\nNo<\/td>\nYes – visible and trackable by teams<\/td>\n<\/tr>\n
    Required Terraform Version<\/td>\nWorks with all versions of Terraform<\/td>\nRequires Terraform v1.7 or newer<\/td>\n<\/tr>\n
    Safety of Execution<\/td>\nManual \u2013 error-prone if misused<\/td>\nSafer \u2013 explicit and intentional with lifecycle block<\/td>\n<\/tr>\n
    Automation Friendly<\/td>\nLess automation-friendly (CLI-only)<\/td>\nEasily works in CI\/CD pipelines<\/td>\n<\/tr>\n
    Ideal for<\/td>\nQuick, ad-hoc resource removal<\/td>\nStructured, team-based workflows<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
    Conclusion<\/strong><\/span><\/h2>\n
    With the introduction of the removed block in Terraform v1.7, the process of safely removing terraform managed resources without impacting live infrastructure has\u00a0 become more transparent, auditable,versioned and collaboration-friendly. This can be really helpful during code refactoring, team transitions or complex migrations.<\/p>\n
    At TO THE NEW<\/a>, 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.<\/p>\n
    \"To
    To The New Devops Solutions<\/p><\/div>\n
    Stay connected for more practical insights as we continue to simplify cloud operations and enable smarter infrastructure decisions.<\/p>\n
     <\/p>\n","protected":false},"excerpt":{"rendered":"
    Introduction and Usecase There are times when we want Terraform to stop managing a resource, but don\u2019t 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 […]<\/p>\n","protected":false},"author":1601,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"iawp_total_views":203},"categories":[2348],"tags":[248,7324,7325,6276,7322,1892,6961,7321,6544,6835,7323,6053,1585,7320,2987],"aioseo_notices":[],"_links":{"self":[{"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/posts\/72032"}],"collection":[{"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/users\/1601"}],"replies":[{"embeddable":true,"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/comments?post=72032"}],"version-history":[{"count":5,"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/posts\/72032\/revisions"}],"predecessor-version":[{"id":72410,"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/posts\/72032\/revisions\/72410"}],"wp:attachment":[{"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/media?parent=72032"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/categories?post=72032"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/tags?post=72032"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}