aws_instance detecting changes even though no changes done to the terraform file

[ghost]

This issue was originally opened by @jsanant as hashicorp/terraform#19434. It was migrated here as a result of the provider split. The original body of the issue is below.

---

Terraform Version

Terraform v0.11.10
+ provider.aws v1.46.0
+ provider.template v1.0.0

Terraform Configuration Files

provider "aws" {
  region     = "us-east-1"
}

resource "aws_instance" "example" {

  ami           = "ami-2757f631"
  instance_type = "t2.micro"
  security_groups = ["sg-xxxxx"]
  associate_public_ip_address = false

  ebs_block_device       = [{ device_name = "/dev/sda1", volume_size = "8", volume_type = "gp2"}]

  key_name = "xxxx"
  subnet_id = "subnet-XXXXX"

  tags = { "Name" = "terraform-test" "owner" = "anant"}

}

Expected Behavior

When I do a terraform plan this is what it should show:

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

Actual Behavior

After I run terraform plan I get this output, even though I haven't done any changes to the terraform file:

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

Steps to Reproduce

1. `terraform init`
2. `terraform apply`
3. `terraform plan` --> To see if it's actually detecting no changes. 

[YakDriver]

I believe this was related to the volume_tags. However, the Op did not provide enough information to determine conclusively.

We have merged a fix to the volume_tags issue in #15474. We have added tests to cover the issues observed. Please note that using volume_tags in aws_instance is not compatible with using tags in aws_ebs_volume. You need to use one or the other. Prior to this fix, even following this rule, you would encounter errors. Along with the fix, we've added tags to the root_block_device and ebs_block_device configuration blocks in aws_instance.

Now that the fix is in place, if you find any problems with volume_tags, let us know by opening a new issue.

[ghost]

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.

If you feel this issue should be reopened, we encourage creating a new issue linking back to this one for added context. Thanks!