Importing Existing Infrastructure

Import brings already-existing cloud resources under Terraform management without recreating them — the essential move when adopting Terraform on infrastructure that was built by hand. You point Terraform at a resource that already exists in AWS, and it records that object in state as if Terraform had created it.

Modern Terraform (1.5+) does this declaratively with import blocks that live in your config and show up in the plan, replacing the older one-off terraform import command that imported into state but left you to hand-write matching config from scratch.

Why Import Exists

Most real Terraform adoption is brownfield: a production VPC, an RDS instance, and a load balancer already exist, built through the console over the years, and you want Terraform to manage them going forward. The wrong answer is to delete and recreate them under Terraform — that is an outage and a data-loss risk on stateful resources. Import is the right answer: it adopts the live object into state, leaving the running infrastructure untouched.

import Blocks (1.5+)

An import block declares a target address and the ID of the existing object. You add it to your config, run plan to preview the adoption, and apply to bring the object into state. Because it is part of the config, the import shows up in the plan for review and can adopt many resources in a single apply — a reviewable, version-controlled operation rather than a sequence of manual commands.

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

resource "aws_instance" "web" {
  # config that matches the existing instance
  ami           = "ami-0c55b159cbfafe1f0"
  instance_type = "t3.micro"
}

Config Generation

Hand-writing config for a complex resource — every argument, every nested block — is where imports go wrong, because a single missed argument produces a destructive diff on first apply. Run terraform plan -generate-config-out=generated.tf with the import block in place and Terraform writes a starting config for the imported resource, derived from its real attributes. You then refine that generated file rather than building it from a blank page.

# with the import block present, generate matching config
terraform plan -generate-config-out=generated.tf

# then iterate plan until it reports no changes
terraform plan

The Legacy terraform import Command

Before 1.5, the only tool was the imperative terraform import aws_instance.web i-0abc123 command. It imports the object into state but generates no config, leaving you to write a matching resource block by hand and discover the mismatches one destructive plan at a time. It handles one resource per invocation and never appears in a plan, so a reviewer cannot see what it did. It still works and you will meet it in older runbooks, but on any current version the import block is the better tool.

Verifying After Import

The proof an import succeeded is a clean plan. Iterate: import, plan, adjust the config to match whatever the plan wants to change, plan again — until Terraform reports no changes. A no-op plan means your config now describes the imported reality exactly, so the next apply will not touch the live resource. Apply before reaching that point and Terraform will "correct" production toward your incomplete config, which is precisely the outage import was meant to avoid.