How to Generate Terraform from an Existing AWS Account

Almost every AWS account in the wild started the same way: someone opened the console, clicked through a wizard, and shipped. It worked — until the team grew, an audit landed, or a region needed rebuilding, and suddenly nobody could say exactly what was running or how to recreate it. Codifying that existing infrastructure into Terraform is the fix. The hard part is that Terraform was designed to create infrastructure from code, not to read infrastructure back into code. This guide covers the four approaches that actually work.

• Why codify at all?
• Method 1 — terraform import blocks
• Method 2 — Terraformer (open source)
• Method 3 — former2 (browser-based)
• Method 4 — automated scanners (InfraSync)
• Which should you use?
• A recommended workflow
• FAQ

Why codify at all?

Before the "how," a quick honest "why." Reverse-engineering a live account into Terraform buys you four things:

• A source of truth. The code becomes the canonical description of your infrastructure, reviewable in Git like any other code.
• Reproducibility. You can stand the same stack up in a new region or account for disaster recovery or a new environment.
• Change review. Every infrastructure change goes through a pull request, with a plan you can read before anything happens.
• Drift visibility. Once the real state is in code, you can detect when reality and code diverge. (More on that in our drift detection guide.)

The catch: none of the tooling makes this a one-click affair. Each method below trades effort for control differently.

Method 1 — terraform import blocks

Terraform has native import. Since Terraform 1.5, the modern form is the config-driven import block, which you write in HCL and which can even generate the starter resource configuration for you.

# imports.tf
import {
  to = aws_instance.web
  id = "i-0abc123def456"
}

Then you ask Terraform to generate the matching configuration:

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

Terraform reads the live resource, writes a best-effort aws_instance.web block into generated.tf, and binds it into state on the next apply. This is precise and uses no third-party tooling.

The fatal limitation: import does not discover anything. You must already know the type and ID of every resource you want to capture.

For a handful of resources, this is perfect. For an account with a few hundred resources across VPCs, security groups, IAM roles, S3 buckets, Lambda functions, and RDS instances, hand-writing an import block per resource is a multi-day slog — and you have to hunt down every ID first. The generated config also needs cleanup: it emits read-only and default attributes you'll want to prune.

Method 2 — Terraformer (open source)

Terraformer is a CLI by GoogleCloudPlatform that solves the discovery problem. Point it at a set of AWS resource types and it enumerates them, generating both the HCL and a matching terraform.tfstate.

terraformer import aws \
  --resources=vpc,subnet,sg,ec2_instance \
  --regions=ap-south-1

You get a directory of .tf files and state, organised by service. It's free, scriptable, and genuinely useful for a bulk first pass.

The trade-offs: Terraformer's provider coverage lags the real AWS API, so newer services or attributes may be missing or stale. The output is verbose and not idiomatic — you'll spend real time refactoring it into modules, wiring up references between resources (it often hard-codes IDs instead of using interpolation), and removing noise. And it's a one-time export: it has no concept of ongoing drift or scheduled re-scans. Run it again next month and you diff two messy snapshots by hand.

Method 3 — former2 (browser-based)

former2 takes a different tack: it runs in your browser, uses the AWS JavaScript SDK with credentials you supply, scans your account, and lets you pick resources from a visual list to export — as Terraform, CloudFormation, CDK, and more.

It's excellent for a guided, pick-and-choose export and for learning what's in an account. But the browser-based model means it's manual and interactive by nature — not something you wire into CI — and, like Terraformer, it produces a snapshot with no ongoing drift tracking. You're also running it with live credentials in a browser tab, which some security teams will want to scope very tightly.

Method 4 — automated scanners (InfraSync)

The newest category is hosted services that treat codification as an ongoing workflow rather than a one-off command. InfraSync is built for exactly this: you connect a read-only IAM role, it scans 87+ AWS services, generates clean Terraform (and OpenTofu-compatible) HCL, and opens a pull request against your GitHub repository.

# What InfraSync does, conceptually:
1. Assume a read-only role in your account
2. Enumerate selected services + regions
3. Generate idiomatic .tf with resolved references
4. Open a GitHub PR for review
5. Re-scan on a schedule → flag drift per resource

Two things distinguish this approach. First, it is read-only by design — it never holds credentials that can write to, apply to, or destroy your account, which removes an entire class of risk during audits. Second, it doesn't stop at the export: it re-scans on a schedule and shows you, resource by resource, where your code and your live account have diverged over time.

The trade-off is that it's a hosted product focused on AWS depth rather than a free local CLI spanning every cloud. If your priority is a no-cost, self-hosted, one-time dump, the open-source tools are the better fit. If you want a living, reviewable source of truth without standing up and maintaining tooling, this is the least-effort path.

Which should you use?

• A few known resources → terraform import blocks. Native, precise, no extra tools.
• A free, scriptable bulk dump → Terraformer. Expect cleanup and refactoring afterward.
• An interactive, pick-and-choose export → former2. Great for exploration and learning the account.
• An ongoing, reviewable, low-effort source of truth → a hosted scanner like InfraSync, especially if you're AWS-first and care about read-only safety and drift.

For a fuller side-by-side — including Firefly, ControlMonkey, Brainboard, and CloudGeni — see our comparison page.

A recommended workflow

Whichever tool you pick, the disciplined path looks the same:

1. Scan read-only first. Never give a codification tool write access. Generating code is a read operation; treat anything that wants more with suspicion.
2. Start with one service or VPC. Don't try to codify the whole account on day one. Capture the network layer, get it reviewed, merge it, then expand.
3. Review the HCL before it touches state. Read every generated block. Prune defaults, replace hard-coded IDs with references, and group resources into modules.
4. Reconcile state carefully. Whether you use generated state (Terraformer) or import (native), run a terraform plan and confirm it shows no changes before you trust it. A clean plan is proof your code matches reality.
5. Set up drift detection. Codification is not "done" the day you merge — it's done when you'd notice if someone clicked something in the console. Schedule re-scans.

FAQ

Can Terraform import existing AWS resources automatically?

Terraform can bind existing resources into its state with import blocks (Terraform 1.5+) and generate starter HCL using terraform plan -generate-config-out. It does not discover resources for you — you must know each resource's ID. For whole-account discovery you need Terraformer, former2, or a hosted scanner such as InfraSync.

What's the difference between terraform import and Terraformer?

terraform import is built in and binds one known resource at a time into state. Terraformer is a separate open-source tool that discovers many resources at once and generates both the HCL and the state file. Native import is precise but manual; Terraformer is bulk but needs cleanup.

Is it safe to generate Terraform from a production account?

Yes — if the tool only reads. Generating Terraform is a read operation. It becomes risky only when a tool also applies changes. Use read-only IAM credentials, and prefer tools that are read-only by design so nothing can write to your account during codification.