feat(stepfunctions-tasks): add architecture support to EvaluateExpression

[claypack]

Issue # (if applicable)

Closes #34974

Reason for this change

Adding an optional architecture parameter to EvaluateExpressionProps which allows users to specify their desired architecture when using the EvaluateExpression construct. This enables support for ARM64 Lambda functions, which can provide better price-performance for certain workloads.

Description of changes

• Add optional architecture parameter to EvaluateExpressionProps
• Support ARM_64 and X86_64 Lambda architectures
• Add comprehensive unit and integration tests
• Update documentation with usage examples
• Pass architecture parameter through to EvalNodejsSingletonFunction

Describe any new or updated permissions being added

No new or updated IAM permissions are required. The existing Lambda invoke permissions remain unchanged as the architecture parameter only affects the Lambda function configuration, not the required permissions.

Description of how you validated changes

• Added unit tests covering both ARM_64 and X86_64 architectures
• Created integration tests for ARM64, X86_64, and default (no value specified) architecture scenarios
• Verified CloudFormation templates generate correct architecture specifications
• Tested that existing functionality remains unchanged when architecture is not specified (defaults to X86_64)

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

[TheRealAmazonKendra]

Thank you for your contribution! Just a quick question on this: I see that the props that you are adding this to already has once optional field runtime. Are there combinations of architecture and runtime that are incompatible? I also notice that you didn't set both in any of the test cases you created. I assume that both can be set at the same time, though? We want to be careful about adding fields that are either mutually exclusive or that have incompatibilities that may result in deployment time failures.

I tried to take a quick look into this and came across this page that mentions that ARM_64 isn't available in some regions so we would definitely want a docstring comment added letting users know that so they don't try to use this option in regions where it's not yet available. Those error messages aren't always super clear so it can cause confusion for customers.

One last note: thank you for adding thorough integ tests here!

Pull request has been modified.

[claypack]

Hey @TheRealAmazonKendra

Thanks for the comments. I answered your questions below and I also implemented a new change which I would like you to review if possible.

1. ARM_64 Region Support
   I've added a comment on the architecture property specifying that you should verify ARM64 support in your deployment region before using Architecture.ARM_64.

2. Architecture and Runtime Compatibility
   According to the Lambda documentation [1], "All supported Lambda runtimes support both x86_64 and arm64 architectures," so there shouldn't be any incompatible combinations when specifying both together.

3. New Integration Test and UUID Collision Fix
   I added a new integration test called integ.evaluate-expression-mixed-arch which demonstrates that both architecture and runtime can be specified simultaneously. During testing that, I noticed using both x86_64 and arm64 with the EvaluateExpression constructs in the same stack caused UUID collisions as the UUIDs were only based on runtime and didn't account the architecture.

To resolve this, I created a separate UUID map specifically for ARM functions (nodeJsArmGuids).

I did this to maintain backward compatibility with existing x86_64 functions. When x86_64 is specified or no architecture (which defaults to x86_64) it will use the same UUID map as before. But if arm64 is used the new UUID map will be used.

4. Testing and Validation
   In addition to the new integ.evaluate-expression-mixed-arch test, I verified that all existing integration tests pass unchanged, confirming backward compatibility is preserved:

• integ.evaluate-expression
• integ.evaluate-expression-x86
• integ.evaluate-expression-nodejs22
• integ.evaluate-expression-default
• integ.evaluate-expression-default-runtime
• integ.evaluate-expression-arm64 (Updated to use new ARM UUID)

Please let me know if you have any thoughts on these additions. Thanks!

References
[1] - https://docs.aws.amazon.com/lambda/latest/dg/lambda-runtimes.html