How to Find Resources Not Managed by Terraform or OpenTofu

This post is part of a series on Terraform Drift Detection and Management: A Comprehensive Guide.

An engineer spins up an RDS instance from the console to unblock an incident. A script provisions a load balancer during a migration and nobody wires it into Terraform afterward. A teammate on a different team stands up an S3 bucket for a one-off export and forgets about it. None of these show up in terraform plan, because plan only compares your configuration against resources already in state. A resource nobody ever imported isn't drift; it's invisible.

This is a different problem from the drift this guide otherwise covers, and it needs a different fix. Drift detection tells you when a known resource changed underneath you. Finding unmanaged resources means going the other direction: starting from what actually exists in your cloud account and working out what Terraform or OpenTofu never touched. There are three native ways to do that without adopting a third-party scanning tool, and a tagging discipline that keeps the list from growing back.

How do you use tags to find unmanaged resources?

Tag every resource your configuration creates with a ManagedBy key, then ask the cloud which resources lack it. In AWS, the Resource Groups Tagging API's GetResources action lists resources with their tags but never returns one that has never been tagged, so pair it with an AWS Resource Explorer tag:none search to catch those. In Azure, a policy assignment requiring the tag flags every resource missing it, untagged ones included, and Resource Graph lists them by ID.

No IDs get compared here, which keeps the method cheap. It's only as good as the tagging convention behind it, though, so start there.

Set the convention

Add a ManagedBy = "terraform" (or "opentofu") tag to every resource your configuration creates. In the AWS provider, the default_tags block on the provider configuration applies it automatically without touching every resource block:

provider "aws" {
  region = "us-east-2"
  default_tags {
    tags = {
      ManagedBy = "terraform"
    }
  }
}

The azurerm provider has the same mechanism.

Query for what's missing it

With AWS, the Resource Groups Tagging API's GetResources action returns every resource matching a filter, along with its tags, so you can flag anything missing ManagedBy:

aws resourcegroupstaggingapi get-resources \
  --resource-type-filters ec2:instance rds:db s3 \
  --query "ResourceTagMappingList[?!contains(Tags[].Key, 'ManagedBy')].ResourceARN"

The API reference says plainly that GetResources does not return untagged resources, whatever filter you pass, and sends you to AWS Resource Explorer with a tag:none query for those. Every Resource Explorer search runs against a view (the Region's default view unless you name one), so set that up first, and one search returns at most 1,000 results, so in a large account narrow the tag:none query by resource type.

If your account uses AWS Organizations Tag Policies, GetResources also accepts IncludeComplianceDetails and ExcludeCompliantResources, which returns a MissingTagKeys list per resource, a useful shortcut if you've already codified your tagging requirement as an org-wide policy.

Azure's equivalent is Azure Policy's built-in "Require a tag and its value on resources" definition. Its effect is hard-coded to deny, so assign it with enforcement mode set to Disabled (DoNotEnforce): Azure then evaluates existing resources for compliance without blocking anyone's deploys. The definition skips resource groups themselves, so scope it to the subscriptions or resource groups Terraform manages and query the compliance results with Azure Resource Graph to get the noncompliant resource IDs.

How do you diff Terraform state against live cloud inventory?

Export the resource IDs Terraform manages with terraform show -json, export a live inventory from the cloud provider, and diff the two: anything in the cloud but missing from state is unmanaged. Because this method exists to catch what tagging misses, build the inventory from a source that sees untagged resources, such as AWS Config or az resource list, rather than the tagging API.

On AWS, list-discovered-resources returns every resource AWS Config has discovered for a given type, tagged or not. It takes one resource type per call and only returns what Config has discovered, so Config has to be set up in every Region you want covered.

# Export every resource ID Terraform currently manages
terraform show -json | jq -r '.values.root_module.resources[].values.id' | sort -u > managed_ids.txt
 
# Export every live resource ID AWS Config has discovered, tagged or not
for type in AWS::EC2::Instance AWS::S3::Bucket; do
  aws configservice list-discovered-resources --resource-type "$type" \
    --query "resourceIdentifiers[].resourceId" --output text
done | tr '\t' '\n' | sort -u > live_ids.txt
 
# Whatever's in live_ids.txt but not managed_ids.txt is unmanaged
comm -23 live_ids.txt managed_ids.txt > unmanaged_ids.txt

Run terraform show -json per workspace (state only covers what that workspace manages), and swap in az resource list --query "[].id" for Azure. Config returns each resource's native ID rather than an ARN, which lines up with what Terraform stores as id for many resource types but not all of them, so spot-check each type before trusting an exact match. Resource Explorer (aws resource-explorer-2 search) also sees untagged resources, but it returns ARNs and stops at 1,000 results per search, which makes it the better fit for the tag method above than for a full diff.

This method scales about as well as any hand-rolled script: fine for a handful of workspaces, tedious once you're running it across dozens.

Can Terraform find and import unmanaged resources natively?

Yes. Since Terraform 1.14 (November 2025), you can describe what to look for in a list block inside a .tfquery.hcl file, run terraform query, and have Terraform write the matching import and resource blocks for you. The query goes from the plain Terraform CLI straight to your cloud provider's API, so it works the same way whichever backend holds your state.

Terraform search is HashiCorp's first-party answer to this problem, and the difference from the two methods above is that the query itself is HCL, with no tagging convention or diff script to maintain.

Create a .tfquery.hcl file with a list block describing what to search for. A resource nobody tagged won't match a tag filter, so this one asks for every running EC2 instance in the Region:

# search.tfquery.hcl
list "aws_instance" "all_running" {
  provider = aws
  limit    = 500 # the default is 100 results per list block
 
  config {
    region = "us-east-2"
    filter {
      name   = "instance-state-name"
      values = ["running"]
    }
  }
}

Run terraform query to print the matches. The results include every instance the filter catches, managed or not, and the CLI doesn't mark which ones already sit in a state file (HashiCorp only offers that comparison in the HCP Terraform UI). Treat the output as a live inventory: run terraform query -json and check the returned IDs against the managed_ids.txt you built from terraform show -json in the diff above, across every workspace. Then add -generate-config-out=generated.tf to have Terraform write the import and resource blocks for every result:

terraform query -generate-config-out=generated.tf

Delete the generated blocks for anything the diff showed is already managed, since applying them would pull the same resource into a second state file. Copy what's left into your configuration, review it (generated config often needs edits for conflicting or computed arguments), and run terraform apply to bring those resources into state in one pass.

Two things worth knowing before you reach for it. First, searching by resource identity requires Terraform v1.12 or newer, and provider support for the resources you want to query varies, so check your provider's documentation. Second, HCP Terraform isn't required. Connecting through a cloud block adds an optional comparison against resources other workspaces already manage, but nothing about the search depends on it, which is why a Scalr-run workspace gets the same results as any other.

As of this writing, the OpenTofu community is investigating the equivalent of this feature.

How do you stop unmanaged resources from reappearing?

Apply the ManagedBy tag through the provider's default_tags block instead of trusting each resource block to carry it, and re-run the tag query on a schedule so anything created outside Terraform surfaces within a cycle rather than at the next audit.

Finding unmanaged resources once is a cleanup project. Keeping the list empty is a policy, and a policy that relies on engineers remembering it won't hold for long.

Scalr's AWS provider configuration supports the same default-tags mechanism directly: set a ManagedBy tag (and a merge strategy for handling conflicts with resource-level tags) once on the provider configuration, and every workspace that uses it inherits the tag automatically going forward. It's scoped to the AWS provider today and needs agent version 0.50.0 or higher for agent-based runs; check the Scalr AWS provider docs for current provider coverage.

One practical note on the cleanup itself. Importing a backlog of newly discovered resources grows the number of resources a platform manages, which matters on a platform that charges for them. As of September 2026, Scalr's pricing is per run, with no charge for users, workspaces, resources under management, private agents, or SAML. Scalr doesn't meter the imported resources, but the runs that perform the imports count as billable runs: each apply that brings a batch into state is one, and so is each dry run (a plan-only run) you use to review it, so importing in a few large batches uses fewer runs than importing one resource per run. Runs that fail during terraform init aren't billed, which covers one of the more common failures while you're still iterating on import blocks: a broken provider configuration.

Further Reading

• Terraform Drift Detection and Management: A Comprehensive Guide: the pillar guide this post belongs to.
• Terraform Import: How to Import Existing Resources Into Terraform: once you've found an unmanaged resource, this is how you bring a single one in by hand.
• How to Set Up Scheduled Drift Detection for Terraform and OpenTofu: once resources are under management, this is how you keep them that way.
• Enforcing Policy as Code in Terraform: A Comprehensive Guide: use OPA to require the ManagedBy tag on every apply, not just report on its absence after the fact.
• What is OpenTofu?: every method above applies the same way whether you're running Terraform or OpenTofu.