Ec2 userdate change update in-place instead of replace error

Terraform Providers AWS
1

Terraform and aws provider versions

❯ terraform version
Terraform v1.3.6
on linux_amd64
+ provider registry.terraform.io/hashicorp/aws v4.45.0

The problem.

I recently upgraded from terraform v1.3.0 to v1.3.6 and to hashicorp/aws v4.45.0, unfortunately I cannot remember the hashicorp/aws version prior.

Before I upgraded changing the ec2 user data would trigger a replacement of an ec2 instance, but now it just causes an in-place update and reboot the instance. When I then connect to the instance I can see /var/lib/cloud/instance/part-001 has my user data updated in it, but the script has not run because the instance was rebooted, not rebuilt.

Example terraform plan showing the user data change -

Terraform used the selected providers to generate the following execution plan. Resource actions are indicated with the following symbols:
  ~ update in-place

Terraform will perform the following actions:

  # module.ec2.aws_instance.this[0] will be updated in-place
  ~ resource "aws_instance" "this" {
        id           = "i-007jbond"
      ~ user_data    = "958121fa728742c324520c03b9471543740e2da0" -> "508a96608ae504b20fc497a96ac4586d64215aac"
        # (32 unchanged attributes hidden)

        # (7 unchanged blocks hidden)
    }

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

And this is the bit of terraform setting up the ec2 user data

  user_data = base64encode(templatefile("${path.module}/template/userdata.tftpl", {
    account       = var.account
    environment   = var.environment
  }))

I did try the plan/apply with terraform v1.3.0 again but still get the same issue, so it seems to be the aws provider v4.45.0 causing this.

Before the terraform and aws provider updates, changes to the userdata.tftpl file would always cause an instance rebuild.

Why is it now saying in-place update instead?

2

If you open up the provider’s changelog: terraform-provider-aws/CHANGELOG.md at main · hashicorp/terraform-provider-aws · GitHub and search for user_data you’ll find several entries which record this change in behaviour.

1 Like
3

Thanks for that @maxb. I can see where that would be a useful feature.
All sorted now by adding user_data_replace_on_change = true

Thanks again.