Why install AWS SDK into AwsCustomResource Node.js Lambda - isn't it already there?

[mcalello]

The Question

Just noticed that the code behind one of my AwsCustomResources has the following in its log:
INFO Installing latest AWS SDK v2
which takes about 45 seconds to install.

Isn't AWS SDK preloaded in Node.js lambdas?

( Perhaps this is just an older artifact that can be removed, similar to #7047 )

[jogold]

This to install the latest v2 of AWS SDK JS so that the newest API calls are available.

[mcalello]

Thanks @jogold - can that be turned into an option? Rarely, do we need the very edge of functionality, and would be willing to tradeoff in favor of improving the performance.

[jogold]

We have decided not to when implementing this feature (#5442 (comment)). @eladb what do you think? Not sure that loosing time in a custom resource is critical compared to the "slowness" of CloudFormation...

[eladb]

@mcalello What do you say? Doesn’t seem like something many people are looking for. If this is a major use case for you, we’d love to learn about it.

[eladb]

Closing for now

[mcalello]

Thanks @eladb and @jogold. Sorry for the delay in writing back, but I wanted to test this and verify what we are seeing.

So if this was a one-time hit to download the latest (edge) version of the Node.js AWS-SDK-JS, I'd say it's only a 45 second delay, typically. But, what we are seeing is that it's downloading the SDK for each and every AwsCustomResource in our stacks. I just completed a test to have 2 different AwsCustomResource-backed custom constructs in the same stack, and they both download the SDK independently. So - for our large stacks this means we have to add 45 sec for each time we solve a problem with AwsCustomResource.

My suggestion:
Give users the choice to enable/disable this bootstrapping for when the preloaded version is good enough. I think this provides 2 benefits:

• No surprises with an edgier version of the SDK we may have not tested.
• Reduce the deployment time of our stacks

[jogold]

OK, this is because the custom resources are being executed in parallel so there's no Lambda "container reuse" and you pay the "installation penalty" each time... in the meantime you could "chain" your custom resources:

customResource2.node.addDependency(customResource1);

[skyrpex]

I would like to share my scenario: we need AWS Custom Resources to invoke another lambda asynchronously (in order to get some QueueUrls registered in a DynamoDB somewhere else).

The thing is that, in our scenario, we will deploy these custom resources very often, and the ~45s penalty for each of these deployments is going to cost deployment time and unwanted $$$... Would love to avoid that installation execution, if possible.

I still don't understand how different these custom resources lambdas are compared to the rest of the lambdas 🤔 Are the AWS SDK from common lambdas outdated?