AWS with Terraform (Day 25)

Terraform Import in AWS: Bringing Existing Resources Under Terraform Control

In an ideal world, every AWS resource would be created by Terraform from day one. In reality, most environments contain legacy resources—VPCs, EC2 instances, security groups, IAM roles—created manually, by the console, or by older automation.

On Day 25 of my DevOps journey, I focused on a critical real-world skill:
bringing existing AWS resources under Terraform management using Terraform import.

This is an essential capability for DevOps engineers working on migrations, brownfield environments, or recovering from lost Terraform state.

---

Why Terraform Import Matters

Terraform works best when it owns the full lifecycle of the infrastructure it manages. Import allows you to:

• Migrate manually created or legacy resources into Infrastructure as Code

• Recover when terraform.tfstate is lost or corrupted

• Onboard existing infrastructure into a new Terraform repository

• Standardize environments without downtime or recreation

In production, this is not optional knowledge—it’s expected.

---

Three Ways to Bring Existing AWS Resources Under Terraform

1. terraform import (Recommended & Production-Safe)

This is the native and supported approach.

• You write the Terraform resource block yourself

• Terraform maps the real AWS resource into state

• No resource recreation

Pros

• Predictable

• Fully supported

• Fine-grained control

Cons

• Manual effort required

• Requires reconciling HCL with imported state

This is the preferred approach for production systems and interviews.

---

2. aws2tf

An open-source AWS-backed script that:

• Scans AWS resources

• Generates Terraform HCL automatically

Useful for quick scaffolding, but the generated code must be reviewed and cleaned up before use.

---

3. Terraformer

A multi-cloud export tool that:

• Generates Terraform files and state

• Supports many AWS resources

Great for large environments, but not all edge cases are covered. Generated code often needs manual correction.

---

Practical Import Workflow (Security Group & EC2)

Below is a safe, repeatable approach I followed.

---

Step 1: Identify Existing Resources

From the AWS Console, note:

• Security Group ID: sg-0123456789abcdef0

• EC2 Instance ID: i-0abc123def456

---

Step 2: Write Minimal Terraform HCL

Terraform does not generate code during import, so the resource block must already exist.

data "aws_vpc" "default" {
  default = true
}

resource "aws_security_group" "app_sg" {
  name        = "test-tf-sg"
  description = "managed-by-terraform"
  vpc_id      = data.aws_vpc.default.id

  ingress {
    from_port   = 80
    to_port     = 80
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }

  ingress {
    from_port   = 443
    to_port     = 443
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }

  ingress {
    from_port   = 22
    to_port     = 22
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }

  egress {
    from_port   = 0
    to_port     = 0
    protocol    = "-1"
    cidr_blocks = ["0.0.0.0/0"]
  }
}

Keep the configuration minimal and intentional.

---

Step 3: Initialize and Plan

terraform init
terraform plan

Terraform will show it intends to create the resource—this is expected because it’s not in state yet.

---

Step 4: Import the Resource

terraform import aws_security_group.app_sg sg-0123456789abcdef0
terraform import aws_instance.example i-0abc123def456

Syntax:

terraform import <resource_address> <resource_id>

This updates state only, not configuration.

---

Step 5: Inspect Imported State

terraform state list
terraform state show aws_security_group.app_sg

Now Terraform knows the resource exists.

---

Step 6: Reconcile Configuration

Run:

terraform plan

If Terraform shows changes:

• Update your HCL to match the real resource

• Aim for zero-drift plans before applying

---

Common Pitfalls (Real-World Lessons)

• Import does not generate HCL
  Import updates state only. You must write the resource block yourself.

• Attribute mismatches can force replacement
  Fields like vpc_id, name, or description can trigger recreation if mismatched.

• Composite IDs
  Some resources require composite import IDs—always check provider docs.

• Helper tools aren’t perfect
  aws2tf and Terraformer accelerate work but are not production-ready out of the box.

• Always back up state
  Before large imports, protect yourself from irreversible mistakes.

---

Terraform Import Cheat Sheet

terraform init
terraform plan
terraform import <address> <id>
terraform state list
terraform state show <address>
terraform apply
terraform destroy

---

When to Use Manual Import vs Helper Tools

Use terraform import when:

• Working in production

• You need precision and predictability

• Preparing for interviews or certifications

Use aws2tf / Terraformer when:

• Migrating large environments

• You need fast scaffolding

• You’re prepared to review and refactor generated code

---

Diagram

Final Thoughts

Terraform import is not just a command—it’s a migration discipline.

The core pattern is simple:

1. Write minimal HCL

2. Import the existing resource

3. Reconcile configuration and state

4. Achieve zero-drift plans

Once mastered, importing becomes a routine and safe operation, enabling teams to bring legacy infrastructure under consistent, auditable Terraform control.

Onward to deeper infrastructure mastery 

Here is the session link: