(`aws-stepfunctions-tasks/evaluate-expression`): Support configuring the lambda architecture

[BalmungSan]

Describe the feature

Currently, the EvaluateExpression supports specifying the desired Runtime for the underlying Lambda, but not Architecture; which defaults to x86_64.
Thus, the proposal is to allow configuring the underlying Lambda Architecture.

Use Case

We are currently migrating all our lambdas to run on arm64, and this is the only kind of Lambdas that we can't control.
And while this does not matter that much when deploying the real infrastructure, it does affect our integration test using localstack.

We run those on a private arm64 GHA runner, and all lambdas but these ones run without issues.
Right now, we are able to circumvent the issue by using the LAMBDA_IGNORE_ARCHITECTURE configuration, but we would rather have control over this for consistency and simplicity.

Proposed Solution

It's just a matter of exposing an optional property on the EvaluateExpressionProps and in the EvalNodejsSingletonFunctionProps to configure the Architecture, and default to x86_64 to maintain compatibility.

I will open a PR shortly with a sketch of the solution: #34975

Other Information

No response

Acknowledgements

• I may be able to implement this feature request
• This feature might incur a breaking change

AWS CDK Library version (aws-cdk-lib)

2.203.1

AWS CDK CLI version

2.1020.1

Environment details (OS name and version, etc.)

Linux / Mac | ARM64

[pahud]

Hi @BalmungSan,

Thank you for this detailed feature request! You're absolutely right - while EvaluateExpression allows configuring the Lambda runtime, it currently lacks support for architecture specification, which defaults to x86_64.

Your solution approach is spot-on and would provide valuable consistency for teams migrating to arm64 architecture.

Given your mention that you're willing to implement this feature, we'd love to review a PR! This would be a great addition that maintains full backward compatibility while giving users control over architecture choice.

When ready, please:

• Include tests for both architecture scenarios
• Update the README to document the new parameter
• Ensure the default remains x86_64 as proposed

Looking forward to your contribution! 🚀

[BalmungSan]

Hi @pahud I already made the PR, I thought it had everything it needed but I just realized that this file: https://github.com/aws/aws-cdk/blob/main/packages/%40aws-cdk/custom-resource-handlers/test/custom-resources-framework/expected/singleton-function-eval-nodejs.ts is not the real source code, but rather just a test. Since the real file is being generated, this just validates the generation.

I don't understand the mechanism that generates that file, nor could I find where I would need to make the change.

Thus, I will leave the PR as it is, and hope someone from the aws-cdk team can pick it up and finish it.

[BalmungSan]

Hi @pahud, any chance anyone from the aws-cdk team can pick up and finish the PR? As I explained above and in the PR itself, I simply do not know how to proceed with the file generation.
At work, we really would like to see this fixed and thus proceed with the migration to ARM.

[pahud]

@BalmungSan For some reason Github is returning 500 errors when opening every PR page. I'll take a look and see how to assist you to move it forward.

[BalmungSan]

Hi @pahud, the PR got automatically closed due to inactivity.
I nonetheless will remain attentive in case anyone from the aws-cdk team wants to either re-open the PR or try to fix the problem from scratch and help in any way I can :)

As I said, this would be very useful for our team, since we really want to migrate all lambdas to ARM64.