fix(custom-resources): fails to use latest SDK version

[moelasmar]

Issue # (if applicable)

Closes #29891

Reason for this change

When setting AwsCustomResource with installLatestAwsSdk: true it fails to upgrade aws-sdk to latest version. The Lambda function created to support the custom resource usually time out after 120 seconds, and for some cases it get time out even after 900 seconds.

Description of changes

Update the Lambda function created for the custom resource to set its MemorySize to be 512 in case if installLatestAwsSdk flag is true instead of the default value 128.

Also, this change will expose the MemorySize to the AwsCustomResource construct, so customers can customize the MemorySize of the Lambda function to fulfill use cases that requires higher memory, CPU, or I/O performance.

Description of how you validated changes

I added the unit test cases, and updated the integration test cases.

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 has failed. See the aws-cdk-automation comment below for failure reasons. 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.

[TheRealAmazonKendra]

I'm not a fan of this change unless we really understand what's going on and why this suddenly started. It seems more like a bandaid than an actual fix.

We need to understand why this issue just started. We didn't see it prior to last week and, from what I know, there were no changes on our end.

Did Lambda do something that is impacting this on their end? Or, is there actually a change we made that is related. Is npm experiencing outages and latency issues? Regardless, we shouldn't just make an update without understanding root cause as we are seeing this issue independent of the cdk version a customer is using.

@colifran was also doing some experiments around this issue on Friday and can confirm that was independent of cdk version.

[TheRealAmazonKendra]

I also commented this is the issue but just to make sure the comment doesn't get lost:

I'm going to suspect there's something going on with the SDK and/or npm here. On https://www.npmjs.com/package/@aws-sdk/client-s3 it says the most recent version is from 9 days ago and lists 3.556.0 as the most up-to-date version. On https://github.com/aws/aws-sdk-js-v3 latest is 3.562.0 published 12 hours ago.

[mrgrain]

This is interesting. I tend to agree with you @moelasmar that 128MB memory is not a good choice for this function. Lambda Functions use memory as a proxy configuration for other resources. In particular, with higher memory the Function also receives increased CPU and I/O performance.

CPU performance is extremely relevant to cryptographic code, e.g. TLS connections. In the context of making AWS API requests, this is highly relevant. Not only is it using TLS to connect to APIs, it will also sign requests for authentication. You might find existing literature on this; from personal experience crypto performance starts to plateau around 768MB.

I/O performance will be relevant mostly for npm install because that is going to write a LOT of files to disk.

✅ Updated pull request passes all PRLinter validations. Dismissing previous PRLinter review.

[mergify]

Thank you for contributing! Your pull request will be updated from main and then merged automatically (do not update manually, and be sure to allow changes to be pushed to your fork).

[aws-cdk-automation]

AWS CodeBuild CI Report

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

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

[mergify]

Thank you for contributing! Your pull request will be updated from main and then merged automatically (do not update manually, and be sure to allow changes to be pushed to your fork).