r/aws_instance: fix perpetual source_dest_check diff with primary_network_interface

[zoispag]

Description

When an ENI with source_dest_check = false is attached to an instance through a primary_network_interface block, consecutive applies toggle the value forever:

• aws_instance plans source_dest_check false -> true
• applying that issues ModifyInstanceAttribute, which writes straight through to the primary ENI
• aws_network_interface then plans source_dest_check true -> false
• applying that returns to the first step

source_dest_check has Default: true, Read populates it from the primary ENI, and both its DiffSuppressFunc and the ModifyInstanceAttribute guard in Update only accounted for the deprecated network_interface block. Practitioners can't sidestep it by setting the correct value on the instance either — source_dest_check is in ConflictsWith for primary_network_interface.

This extends both checks to primary_network_interface, so the attribute is owned solely by the aws_network_interface resource, exactly as it already is for network_interface.

One wrinkle worth calling out for review: primary_network_interface is Optional+Computed and Read always populates it, so d.GetOk cannot distinguish a configured block from a computed one. Using GetOk here would suppress the diff for every instance and silently break source_dest_check on instances that don't manage their own ENI. The new hasConfiguredPrimaryNetworkInterface helper consults the raw configuration instead. (network_interface avoids this because Read only writes back the device indexes present in configuration, leaving it empty when unconfigured.)

Docs for source_dest_check are updated to state the ConflictsWith behavior and point at aws_network_interface.

Relations

Fixes #44768

References

• The instance-level SourceDestCheck attribute is the primary ENI's attribute, which is why the Update write is observable as drift on the aws_network_interface resource.

Output from Acceptance Testing

Run in eu-central-1.

% make testacc TESTS=TestAccEC2Instance_PrimaryNetworkInterface_sourceDestCheck PKG=ec2
--- PASS: TestAccEC2Instance_PrimaryNetworkInterface_sourceDestCheck (118.82s)
PASS
ok      github.com/hashicorp/terraform-provider-aws/internal/service/ec2 124.541s

To confirm the new test is genuine regression coverage rather than something that would pass either way, I also ran it against unmodified main with only the test cherry-picked (i.e. the ec2_instance.go change reverted). It fails with exactly the behaviour reported in #44768:

--- FAIL: TestAccEC2Instance_PrimaryNetworkInterface_sourceDestCheck (103.77s)
    ec2_instance_test.go:3421: Step 1/2 error: After applying this test step, the non-refresh plan was not empty.

        Terraform will perform the following actions:

          # aws_instance.test will be updated in-place
          ~ resource "aws_instance" "test" {
                id                                   = "i-0cd7b24c91111dc42"
              ~ source_dest_check                    = false -> true
                tags                                 = {
                    "Name" = "tf-acc-test-992075738155928027"
                }
                # (39 unchanged attributes hidden)

                # (9 unchanged blocks hidden)
            }

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

I have not run the full TestAccEC2Instance_ suite, so a maintainer run of the neighbouring TestAccEC2Instance_PrimaryNetworkInterface_*, TestAccEC2Instance_NetworkInterface_* and TestAccEC2Instance_sourceDestCheck tests would still be worthwhile to confirm nothing regressed on the paths this touches.

[github-actions]

✅ Thank you for correcting the previously detected issues! The maintainers appreciate your efforts to make the review process as smooth as possible.

[github-actions]

Community Guidelines

This comment is added to every new Pull Request to provide quick reference to how the Terraform AWS Provider is maintained. Please review the information below, and thank you for contributing to the community that keeps the provider thriving! 🚀

Voting for Prioritization

• Please vote on this Pull Request by adding a 👍 reaction to the original post to help the community and maintainers prioritize it.
• Please see our prioritization guide for additional information on how the maintainers handle prioritization.
• Please do not leave +1 or other comments that do not add relevant new information or questions; they generate extra noise for others following the Pull Request and do not help prioritize the request.

Pull Request Authors

• Review the contribution guide relating to the type of change you are making to ensure all of the necessary steps have been taken.
• Whether or not the branch has been rebased will not impact prioritization, but doing so is always a welcome surprise.