Surprising diff on imported aws_s3_bucket_logging with expected_bucket_owner

[mark-at-nuna]

Terraform CLI and Terraform AWS Provider Version
Terraform v1.2.8 on linux_amd64
Provider hashicorp/aws v4.29.0

Affected Resource(s)
aws_s3_bucket_logging

I’m upgrading from AWS provider 3.6 to 4.29, 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=./myvars.tfvars 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!

So far so good! 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.

Expected behavior: I expected no diffs between the configuration and the state.

Actual behavior: I am surprised that the account ID appears in the bucket field. 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 confirmed that the bucket looks like this in the statefile:

        "attributes": {
          "bucket": "my-bucket,1234567",

To reproduce this, you might need two AWS accounts, one to be expected_bucket_owner and one to run Terraform.

Thanks!

[gabegorelick]

I think this issue affects more than just imported resources. I see the same thing on all freshly created aws_s3_bucket_logging resources that specify expected_bucket_owner.

To reproduce this, you might need two AWS accounts, one to be expected_bucket_owner and one to run Terraform.

I'm able to reproduce using a single AWS account.

To reproduce:

1. Create an aws_s3_bucket_logging resource with expected_owner equal to the account ID of the target bucket.
2. Run a new plan without making any changes.
3. Notice diff on bucket.

Unfortunately, the diff on bucket forces replacement of the aws_s3_bucket_logging resource. Since this can be prohibitively disruptive, the only solution seems to be to remove expected_owner. I can confirm that removing it fixes the issue.

[github-actions]

This functionality has been released in v5.13.0 of the Terraform AWS Provider. Please see the Terraform documentation on provider versioning or reach out if you need any assistance upgrading.

For further feature requests or bug reports with this functionality, please create a new GitHub issue following the template. Thank you!

[github-actions]

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 have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.