Infrastructure Import into Terraform: No Downtime, Guaranteed

An EKS cluster was created via the AWS console a while ago. RDS, VPC, security groups—all done manually. Terraform has just appeared in your company, and the task is to bring everything under management without downtime and recreating resources. This is where terraform import becomes the key tool.

Inventory often uncovers dozens of unaccounted resources: forgotten NAT gateways, unused EBS volumes, outdated security groups. Manual import of each resource requires precise configuration and verification. Our engineers have performed over 500 successful imports, saving clients an average of 40% on infrastructure management costs, with typical project costs starting at $1,500 for small infrastructures. We'll help you carry out this process turnkey: from inventory to full transition to IaC, with a guarantee of zero drifts in terraform plan. Our one-time audit fee is $500, deductible from the project cost if you proceed. We specialize in migration to terraform, import infrastructure terraform, and comprehensive terraform state management. Contact us for an assessment.

How Terraform Import Works

terraform import takes an existing cloud resource and records it into the state under the specified resource address. The config must be written manually in advance.

Step-by-Step Classic Approach (Terraform < 1.5)

1. Write the resource configuration block in .tf files (e.g., aws_vpc.main).
2. Run terraform init to initialize the working directory.
3. Execute terraform import aws_vpc.main vpc-0abc1234 to import the resource.
4. Run terraform plan to verify no changes are detected.
5. If changes appear, adjust the config until plan shows No changes.

example: terraform import aws_security_group.main sg-0abc1234def567890 

After import, terraform plan should show No changes—this means the config accurately describes the real resource. If plan shows changes, the config drifts from reality, and you must either fix the config or accept the changes.

Import blocks in Terraform 1.5+

Starting from version 1.5, import can be described directly in the config:

import {
  to = aws_vpc.main
  id = "vpc-0abc1234"
}

resource "aws_vpc" "main" {
  cidr_block = "10.0.0.0/16"
  enable_dns_hostnames = true
  tags = {
    Name = "main-vpc"
  }
}

terraform plan shows what will be imported, terraform apply performs the import. After a successful import, the import block can be removed from the config.

Terraform 1.5 also added terraform plan -generate-config-out=generated.tf—generation of a config for imported resources. This is a draft that must be reviewed and structured, but it saves time compared to writing from scratch.

Ensuring a Successful Import

Import is only successful when terraform plan shows no changes. This confirms that your config fully matches the real resource. If the plan shows changes (e.g., extra tags or wrong CIDR), the config does not perfectly describe the resource. Fix the config, do not accept the changes—otherwise you risk making unexpected modifications to production.

Typical import mistakes

• Resource ID mismatch: when importing, you must specify the exact ID from the cloud API. An error in ID leads to failure.
• Missing optional attributes: if the config does not specify attributes that exist in the real resource, plan will show changes.
• Importing resources with dependencies: order matters—import foundational resources (VPC, networks) first, then dependent ones.
• Ignoring implicit dependencies: some resources (e.g., aws_instance with subnet_id) implicitly depend on others. Ensure parent resources are already in the state.

Resources that cannot be imported

Some resources do not support import at all—for example, resources with one-time secret output (keys, passwords) that AWS returns only at creation. aws_iam_access_key—the secret_key is not available after creation, so the state will be empty and Terraform will always show it in plan as a change.

For such resources, the only path is to recreate them with Terraform and update dependent services.

When to recreate a resource instead of importing?

If a resource has secret output data or its configuration greatly differs from what you want, it's easier to recreate it with Terraform. This is faster than dealing with import and subsequent corrections.

Process and Timelines

Automating Import for Hundreds of Resources

When importing 200+ resources, systematization is needed. Our process includes full resource import automation. Compare approaches:

Our experience shows: the best result comes from combining terraformer for initial generation and manual verification of configs with import via import blocks. This reduces MTTR by 2-3 times compared to a pure manual approach. We provide comprehensive devops infrastructure management.

Additionally, you can use terraform refresh to sync state, but it does not generate config—only updates attributes. Therefore, for full migration to terraform, it's better to combine tools.

Timeline estimates

What's included in the work

• Inventory of all resources via cloud API or Terraform Cloud
• Writing configs and importing by layers (network, compute, databases)
• Verification of each resource via terraform plan
• Documentation of state files and the process
• Knowledge transfer to your team

Timelines

Depend on the number of resources and their complexity. A small project (50-100 resources of one cloud provider) — 1-2 weeks. A large heterogeneous infrastructure with multiple clouds, legacy resources, and non-standard configurations — 1-2 months. Cost is calculated after inventory. Get a consultation—we'll assess your project within 1 day. Order an infrastructure audit—we'll propose the optimal import strategy.

For more details, refer to the Terraform import documentation. Terraform import — official documentation.