How to Import Existing AWS Resources into Terraform Without Disruption

In many DevOps workflows, teams create or modify AWS resources manually, which leads to resources that are not tracked by Terraform. This article provides a step‑by‑step method to import those “orphaned” resources into Terraform, handle manual changes, and keep the infrastructure as code (IaC) state consistent.

Scenario 1: Managing Manually Created AWS Resources

Assume a team member created an Amazon S3 bucket manually and you now want Terraform to manage it.

1. Write a minimal Terraform configuration

resource "aws_s3_bucket" "example_bucket" {
  bucket = "your-existing-bucket-name" # replace with the actual bucket name
}

2. Import the resource with terraform import

terraform import aws_s3_bucket.example_bucket your-existing-bucket-name

aws_s3_bucket.example_bucket

: the resource address defined in

main.tf

your-existing-bucket-name

: the actual name of the existing S3 bucket

3. Complete the Terraform configuration

Run terraform show to display all attributes imported into the state.

Copy the full output and paste it into main.tf, replacing the minimal stub.

Remove automatically generated attributes such as arn and id that AWS manages; Terraform will suggest their removal during terraform plan.

4. Verify the configuration

Execute terraform plan. If everything matches, the output should be:

No changes. Your infrastructure matches the configuration.

Terraform has compared your real infrastructure against your configuration and found
no differences, so no changes are needed.

Example workflow:

Initial main.tf:

resource "aws_s3_bucket" "my_bucket" {
  bucket = "my-existing-bucket"
}

Import the bucket:

terraform import aws_s3_bucket.my_bucket my-existing-bucket

Run terraform show, copy the output, and update main.tf with additional attributes (e.g., acl = "private").

Run terraform plan to confirm no changes are pending.

Scenario 2: Handling Manually Modified AWS Resources

Suppose an EC2 instance managed by Terraform was manually changed from t2.micro to t2.small via the AWS console.

1. Refresh the state terraform refresh 2. Check configuration drift terraform plan The plan will show the difference between the state file and main.tf, indicating that the instance type will be changed back to the value defined in the configuration.

3. Synchronize configuration

If you want to keep the manual change, edit main.tf to match the current instance type ( t2.small).

If you want to revert, run terraform apply to enforce the configuration ( t2.micro).

Example:

Refresh state: terraform refresh Plan: terraform plan The plan will propose changing the instance type back to t2.micro .

Synchronize configuration:

Keep manual change: modify instance_type in main.tf to t2.small.

Rollback change: run terraform apply to apply the original t2.micro configuration.

Best Practices and Caveats

Run terraform refresh regularly to keep the state file in sync with actual AWS resources.

Use state locking (e.g., S3 with DynamoDB) in collaborative environments to prevent concurrent state modifications.

Use terraform import cautiously : it only imports resources, not their dependencies; complex resources may require manual configuration of relationships.

Review terraform plan output before applying changes to ensure the actions match expectations.

Version control all Terraform files (e.g., Git) to track changes and enable collaboration.

Modularize configurations into reusable modules for better maintainability.

Apply the principle of least privilege to the IAM role or user that Terraform uses.

Following these practices allows teams to effectively manage existing AWS resources with Terraform, handle manual modifications safely, and achieve automated, consistent, and auditable infrastructure.