Surprising diff on aws_s3_bucket_logging with expected_bucket_owner

I’m upgrading from AWS provider 3 to 4.14, and so I am adding a new aws_s3_bucket_logging resource, specifying that the account that owns it is different from the one in the TF provider:

resource "aws_s3_bucket_logging" "my_logging" {
  bucket                = "my-bucket"
  expected_bucket_owner = "1234567"
  target_bucket         = "my-logging-bucket"
  target_prefix         = "AWSLogs/my-bucket/"

So then I import it:

terraform import -var-file=./
vars aws_s3_bucket_logging.my_logging my-bucket,1234567

**aws_s3_bucket_logging.my_logging: Importing from ID "my-bucket,1234567"...**

**aws_s3_bucket_logging.my_logging: Import prepared!**

Prepared aws_s3_bucket_logging for import

**aws_s3_bucket_logging.my_logging: Refreshing state... [id=my-bucket,1234567]**

Import successful!

And then I run Terraform plan:

Terraform will perform the following actions:

  # aws_s3_bucket_logging.my_logging must be replaced
-/+ resource "aws_s3_bucket_logging" "my_logging" {
      ~ bucket                = "my-bucket,1234567" -> "my-bucket" # forces replacement
      ~ id                    = "my-bucket,1234567" -> (known after apply)
        # (3 unchanged attributes hidden)

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

I am surprised that the account ID is in the bucket name in the existing state. Did the terraform import put the whole ID in the bucket name by mistake? Was there another way I should have done the import?


I should have noted I have Terraform AWS provider hashicorp/aws v4.14.0 and Terraform 1.1.6.

Please note that I have no experience with AWS, but based on general Terraform concepts, this looks like a bug in the provider’s import implementation. Therefore I would suggest raising it in the provider’s issue tracker.

1 Like

Thanks, I opened an issue here.