We manage nine AWS accounts across production and non-production. We adopted Terraform about two years ago, but only used it for new work—we never imported the existing resources into state. As a result, perhaps 50–60% of our infrastructure is represented in Terraform, while the rest exists only in the cloud accounts with little ownership information or documentation.
This has made troubleshooting increasingly difficult. Recently, we found an OpenSearch instance in a rarely used VPC that was supporting an integration nobody remembered creating. We also discovered an S3 bucket whose lifecycle policy had been failing silently for about a year. If we lost an account today, we could rebuild only the Terraform-managed portion; the remaining dependencies would emerge gradually as applications stopped working.
We need a practical plan, and possibly a reasonably priced tool, for discovering resources across AWS accounts, identifying ownership and relationships, generating Terraform configuration for existing infrastructure, and tracking IaC coverage over time. We are a small team, so enterprise-priced platforms are not realistic. Multi-cloud support would be useful if we eventually add GCP, but AWS coverage is the immediate priority. What approach or tools have worked for teams in this situation?
5 Answers
Treat this as a staged migration rather than trying to generate perfect Terraform for everything at once. Resource Explorer and service-specific inventory tools can help you build an account-by-account list, then manually verify what each resource does before importing it. Generators such as Former2 and Terraformer can produce a useful starting point, but neither supports every AWS resource type, so expect cleanup and manual configuration. For unsupported resources, Terraform's import blocks and plan-based configuration generation can help.
The long-term fix is preventing the unmanaged side from growing again. In production, restrict create and modify permissions so normal deployments go through a Terraform pipeline using tightly scoped roles and short-lived credentials. Keep a controlled break-glass path for emergencies. Development accounts can allow more experimentation, but still enforce tagging and periodically remove or review untagged resources. Read-only access should be the default for people and automation that do not need to provision anything.
Be especially careful with coding agents. If they have write access to AWS, they can create temporary resources that never make it into Terraform. Give them read-only access or require all provisioning to pass through the same Terraform approval process.
For recovery planning, rank resources by blast radius and test rebuilding the most important services in a separate account or environment. A clean-room reconstruction often reveals hidden dependencies faster than simply exporting the current account. Have application teams validate the rebuilt systems, document the results, and use incident reviews to capture anything discovered during outages. Once the critical path is covered, continue importing lower-risk resources as time allows.
Terraform will tell you how resources are configured, but it will not explain why they exist or who depends on them. Build a searchable, lightweight documentation trail alongside the migration. Record the owner, repository, purpose, dependencies, recovery requirements, and any unknowns for each important resource. Even a note saying “purpose unknown; accumulating files; investigate with the finance team” is valuable because the next person has somewhere to add findings.
Start with ownership and coverage tags on everything Terraform creates—for example, repository, environment, team, and owner. After deploying those tags, inventory untagged resources service by service. That gives you a manageable list of candidates to investigate, delete, document, or import. Work through one account or service at a time and prioritize production resources with the highest recovery impact instead of chasing 100% coverage immediately.
This also exposes old one-off deployments that should be consolidated into reusable modules or repositories. The migration is a lot of import work, but it usually improves the deployment model along the way.
The difficult part is usually understanding the purpose and dependencies of a resource before changing it. Automating the inventory is fine, but review each item before importing or replacing it.