How to Safely Change an AWS EC2 Instance Type with Terraform Without Losing Root Volume Data

When you modify the instance_type attribute of an aws_instance resource in Terraform, modern Terraform versions can perform an in‑place update (marked with ~ in the plan) instead of destroying and recreating the instance. The plan will show a line such as ~ instance_type: "t2.micro" => "t3.small", indicating the change will be applied without replacement.

Impact Analysis

Terraform will stop the instance, change its type via the AWS API, and start it again. This mimics the manual console workflow “stop → change type → start” and introduces a brief downtime window that must be evaluated for business impact.

Root Volume Safety

Because the update is in‑place, the instance ID stays the same and the attached EBS root volume is neither recreated nor detached. As long as the instance uses an EBS root device (the default for modern instance types), data on the root volume is preserved. Changing instance_type alone does not affect root_block_device or delete_on_termination settings, which remain at their defaults (typically true for termination deletion, but irrelevant when no destroy occurs).

Instance Stop and Change Strategy

AWS requires the instance to be stopped before its type can be altered. Whether you use the console or the CLI (

aws ec2 modify-instance-attribute --instance-id <ID> --instance-type <newType>

), the instance must be in a stopped state. Terraform’s AWS provider automatically performs this stop‑modify‑start sequence when it detects a change to instance_type.

Side Effects of Stopping

Stopping may cause the instance to move to different underlying hardware. After restart, the Elastic IP (if attached) and private IP remain, but a non‑elastic public IP can change. In Auto Scaling groups, a prolonged stop may trigger health‑check failures, so pause scaling activities if needed.

Ephemeral Storage Warning

If the instance uses instance‑store (ephemeral) disks, those disks are lost on stop. Ensure no critical data resides on them; the EBS root remains safe.

Inspecting the Terraform Plan

Run terraform plan -out=ftplan and verify that the only change shown is the ~ update to instance_type. Look for symbols: ~ – in‑place update -/+ – replace (should not appear) - – destroy (should not appear)

Confirm that root_block_device, volume_id, and delete_on_termination are unchanged. The summary line should read

Plan: 0 to add, 1 to change, 0 to destroy.

Applying the Change

After confirming the plan, execute terraform apply "ftplan". Terraform will display progress such as: aws_instance.my_instance: Modifying... [id=i-xxxx] Instance transitions through stopping , stopped , pending , and finally running .

Final output: Apply complete! Resources: 0 added, 1 changed, 0 destroyed. Handle possible errors: incompatible instance types, quota limits, or interrupted Terraform runs. Use terraform refresh or re‑run terraform plan to recover state.

Verification After Apply

Check the instance in the AWS console or via CLI to ensure:

State is running and the instance type matches the desired value.

Instance ID is unchanged (indicating an in‑place update).

The root volume ID is identical to the pre‑change volume (verify with terraform state show or console volume details).

Data on the root volume is intact – log into the instance and confirm key files/services.

If a non‑elastic public IP was used, verify any IP changes and update DNS if necessary.

Fallback and Data Protection

For extra safety, you can temporarily set delete_on_termination = false on the root block device or create an EBS snapshot before applying the change. In the unlikely event of a replacement, the snapshot or retained volume prevents data loss.

Cleanup and Documentation

Re‑apply any temporary configuration changes (e.g., restore delete_on_termination to its original value).

Record the change details – old and new instance types, volume IDs, downtime window, and any IP adjustments.

Future type changes can follow the same workflow.

Key Takeaways

Terraform’s in‑place update capability allows safe instance‑type modifications without destroying the instance.

Stopping the instance is mandatory; Terraform automates stop‑modify‑start while preserving the instance ID and root EBS volume.

Always verify the plan shows only ~ changes to instance_type and that root‑volume attributes remain unchanged.

Post‑apply verification of instance state, volume ID, and application data ensures the change succeeded without data loss.