Expected Terraform aws_instance root_block_device volume_type change will cause replace (destroy and create) of the instance because I believed the underlying SSD device type will cause replacement.

But it is actually in-place update. Please help understand why changing SSD device type does not cause destroy? Is it just changing the configuration change not changing the physical SSD device?

  # aws_instance.this["subnet-1111111111"] will be updated in-place
  ~ resource "aws_instance" "tokkio" {
        id                                   = "i-1111111111"
      ~ root_block_device {
            tags                  = {}
          ~ volume_type           = "gp2" -> "gp3"
            # (9 unchanged attributes hidden)
        }

        # (9 unchanged blocks hidden)
    }

Expected Terraform aws_instance root_block_device volume_type change will cause replace (destroy and create) of the instance because I believed the underlying SSD device type will cause replacement.

But it is actually in-place update. Please help understand why changing SSD device type does not cause destroy? Is it just changing the configuration change not changing the physical SSD device?

  # aws_instance.this["subnet-1111111111"] will be updated in-place
  ~ resource "aws_instance" "tokkio" {
        id                                   = "i-1111111111"
      ~ root_block_device {
            tags                  = {}
          ~ volume_type           = "gp2" -> "gp3"
            # (9 unchanged attributes hidden)
        }

        # (9 unchanged blocks hidden)
    }

• amazon-web-services
• amazon-ec2
• terraform
• terraform-provider-aws

2 Answers 2

This is because the root volume (root_block_device), the device from which the machine boots, is a special kind of EBS (Elastic Block Store) volume designed for flexibility. Since Terraform relies on the AWS API to modify EBS volumes attributes (size, type, IOPS) and the AWS API allows to change them "in place", so does Terraform.

From Quickly adopt new AWS features with the Terraform AWS Cloud Control provider :

"The Terraform AWS CC Provider leverages AWS Cloud Control API to automatically generate support for hundreds of AWS resource types, such as Amazon EC2 instances and Amazon S3 buckets. Since the AWS CC provider is automatically generated, new features and services on AWS can be supported as soon as they are available on AWS Cloud Control API, addressing any coverage gaps in the existing Terraform AWS standard provider.

Modifying elastic volumes can be done dynamically but it has some limits--for instance you can only increase but not reduce the volume size (see https://docs.aws.amazon/ebs/latest/userguide/requesting-ebs-volume-modifications.html). According to the article quote above, these features of the API are reflected on the Terraform provider.

Note: the only two attributes that cannot be changed without a destroy/recreate of the root_block_device are:

• encrypted
• kms_key_id (see: Terraform docs and source code)

A note on instance store-backed instances:

In the above, I assumed you are using EBS-backed instances. For instance store-backed instances the situation is different, as the root device is local and ephemeral, so it will get destroyed after each change. For such instances you can use a ephemeral_block_device to configure instance store volumes but a root_block_device wouldn't make sense since in this case the root device is determined by the AMI (and is not an EBS volume).

Hope this helps!

Because EC2 machine and block volume both are independent AWS resources. Hence it's not necessary to destroy EC2 instance when you are changing block volume storage.