fix(stepfunctions): lambda invoke grant all versions

[Y-JayKim]

Issue # (if applicable)

Closes #17515 .

Reason for this change

AWS CDK-generated Step Function roles break in-flight Step Function executions when using versioned Lambda functions. During deployment, the Step Function’s IAM role is updated to include permissions for the new Lambda version but removes permissions for the previous version. This causes lambda:InvokeFunction permission failures in in-flight executions that were started before the deployment and are still trying to invoke the previous Lambda version.

This issue is particularly problematic when using Step Function Aliases with deployment preferences for traffic shaping, as a percentage of new executions are directed to the previous version of the state machine, which attempts to invoke a Lambda version it no longer has permissions for.

Description of changes

Implemented a feature flag STEPFUNCTIONS_TASKS_LAMBDA_INVOKE_GRANT_ALL_VERSIONS to control IAM permissions granted when using Lambda versions with Step Functions:

Added a new feature flag in cx-api/lib/features.ts with detailed documentation
Modified LambdaInvoke task implementation to check for this flag:
When enabled: grants permissions to both the specific Lambda version AND all versions using a wildcard pattern (function-arn:*)
When disabled (default behavior): maintains current behavior of granting permission only to the specific version
Updated API documentation to clearly explain the feature flag usage
Updated the README.md to include examples showing how to enable the feature flag
This approach maintains backward compatibility while giving users an opt-in solution to prevent in-flight executions from failing during deployments.

Describe any new or updated permissions being added

When the feature flag is enabled, the Step Function's IAM role will now include an additional IAM permission that grants access to all versions of the Lambda function using a wildcard pattern, e.g.:

• Before: "Resource": ["arn:aws:lambda:region:account:function:name:version"]
• After: "Resource": ["arn:aws:lambda:region:account:function:name:version", "arn:aws:lambda:region:account:function:name:*"]

Description of how you validated changes

• Added comprehensive unit tests that verify both behaviors (with feature flag enabled and disabled)
• Updated integration tests to demonstrate both scenarios with and without the feature flag
• Created test suites to verify behavior with both versioned Lambda functions and non-versioned Lambda functions

Checklist

• My code adheres to the CONTRIBUTING GUIDE and DESIGN GUIDELINES

---

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license

[aws-cdk-automation]

The pull request linter fails with the following errors:

❌ Fixes must contain a change to an integration test file and the resulting snapshot.

If you believe this pull request should receive an exemption, please comment and provide a justification. A comment requesting an exemption should contain the text Exemption Request. Additionally, if clarification is needed, add Clarification Request to a comment.

[aws-cdk-automation]

AWS CodeBuild CI Report

• CodeBuild project: AutoBuildv2Project1C6BFA3F-wQm2hXv2jqQv
• Commit ID: 2476873
• Result: SUCCEEDED
• Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

[gasolima]

I like this proposed solution, but i'm a bit confused cause i expected it to be implemented in this CR, what's the reason of not implementing it?

[shikha372]

we had team discussion regarding this and decided its better to do more permissible permissions(if no concerns with security team)than adding a new prop, as it can be confusing for end customers and adds to maintenance burden.

[gasolima]

is this file will be committed to the repo? when is it needed to create files like this? what's the purpose of it?

[shikha372]

i don't think this is meant for repo, should be removed from this commit.

[gasolima]

Not related to this file, but shouldn't we have the same issue in the ECS here

[paulhcsun]

Closing as a duplicate of #34398

[github-actions]

Comments on closed issues and PRs are hard for our team to see.
If you need help, please open a new issue that references this one.