Rework of aws_lambda_layer_version_permission resource.

[Lerdson]

Rollback Plan

If a change needs to be reverted, we will publish an updated version of the library.

Changes to Security Controls

Are there any changes to security controls (access controls, encryption, logging) in this pull request? If so, explain.

No Changes

Description

Support for multiple aws_lambda_layer_version_permission resources attached to the same lambda layer version is currently non functional. Each aws_lambda_layer_version_permission currently assumes it is the only such resource and reads the first statement within the policy. This creates some very strange issues where you can create multiple permissions, but on the next state refresh each one will assume the attributes of the first statement created.

I believe this is partly due to the very unique nature of the lambda layer permission endpoints. They are asymmetrical in their CRUD structure. This can be represented as follows:

• The reading endpoint fetches the entire policy JSON, with every permission attached within.
• The creation/update/deletion endpoints target singular permissions/statements within the full policy list.
  

In this PR, each permission resource still has its own state tracking of the overall policy and revision ID. This means these attributes can fall out of sync as sequential permissions are created until the next state refresh. This is not a new problem and was already present. I predict 4 options that I would like to put forward to reviewers:

• Move forward with these downsides, being that there is measurable improvement elsewhere and they already existed. Looking at the docs for the policy attribute, the full policy looks to have always been intended to be present in the state of each individual permission.
• Remove the overall policy and revision ID from the resource schema and thus the state file. These attributes were likely of very limited use.
• Use a separate data source to represent the overall policy information such as the policy and revision ID, as this information is essentially computed and not directly controllable. The permission resource can then be reserved for representing individual permissions within the overall computed policy.
• A method of ensuring policy and revision ID are always 100% up to date on access. This is my first time working with the SDK with anger and I haven't spotted anything yet, so I'd love to hear from people with experience.

My initial inclination would be the first option, which this PR represents. I believe this provides the best balance of improved function, work overhead and breaking changes. I believe the only breaking change in this PR is the import identification for the permission resource.

Relations

Closes most of the issues hinted upon within #21917

References

Documented ideal capabilities with support of multiple permission resources: https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/lambda_layer_version_permission

Output from Acceptance Testing

% make testacc TESTS='TestAccLambdaLayerVersionPermission_*' PKG=lambda
2025/10/15 15:30:33 Initializing Terraform AWS Provider...
=== RUN   TestAccLambdaLayerVersionPermission_basic_byARN
=== PAUSE TestAccLambdaLayerVersionPermission_basic_byARN
=== RUN   TestAccLambdaLayerVersionPermission_basic_byName
=== PAUSE TestAccLambdaLayerVersionPermission_basic_byName
=== RUN   TestAccLambdaLayerVersionPermission_org
=== PAUSE TestAccLambdaLayerVersionPermission_org
=== RUN   TestAccLambdaLayerVersionPermission_account
=== PAUSE TestAccLambdaLayerVersionPermission_account
=== RUN   TestAccLambdaLayerVersionPermission_disappears
=== PAUSE TestAccLambdaLayerVersionPermission_disappears
=== RUN   TestAccLambdaLayerVersionPermission_skipDestroy
=== PAUSE TestAccLambdaLayerVersionPermission_skipDestroy
=== CONT  TestAccLambdaLayerVersionPermission_basic_byARN
=== CONT  TestAccLambdaLayerVersionPermission_account
=== CONT  TestAccLambdaLayerVersionPermission_skipDestroy
=== CONT  TestAccLambdaLayerVersionPermission_disappears
=== CONT  TestAccLambdaLayerVersionPermission_org
=== CONT  TestAccLambdaLayerVersionPermission_basic_byName
--- PASS: TestAccLambdaLayerVersionPermission_org (18.68s)
--- PASS: TestAccLambdaLayerVersionPermission_account (23.92s)
--- PASS: TestAccLambdaLayerVersionPermission_disappears (26.18s)
--- PASS: TestAccLambdaLayerVersionPermission_basic_byName (29.96s)
--- PASS: TestAccLambdaLayerVersionPermission_basic_byARN (41.02s)
--- PASS: TestAccLambdaLayerVersionPermission_skipDestroy (43.28s)
PASS
ok  	github.com/hashicorp/terraform-provider-aws/internal/service/lambda	47.670s
...

[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.

[Lerdson]

Hi guys, is this targeted against the correct branch? Cheers.