Include aws-sdk-js-v3 clients in the Lambda runtime.

[ghost]

Related Problem

Decrease the uploaded Lambda ZIP by providing the client libraries in the runtime container, just as aws-sdk v2

I have a Lambda function which is triggered with DynamoDB streams, and the following is the only import in my function:

import { DynamoDBClient } from '@aws-sdk/client-dynamodb'

The uploaded ZIP function takes 4.8 MB. This is too much and removes the benefit of using modularized v3. I just tried out excluding the packages if v3 is provided in the runtime environment just as v2, i.e., aws-sdk.

In that case, I cannot see a benefit of using aws-sdk v3.

[adcreare]

I couldn't agree more. If V3 is actually released and whats more, "recommended", then it should be in the lambda runtime by default, but that would require the lambda service team to do work plus I suspect the V3 sdk is still a little to "beta" right now.

[ghost]

@adcreare I guess we should basically provide our own container image for the Lambda, and instead of putting aws-sdk, we can put the relevant v3 packages that the running Lambda will need. Not an expert on this, but the size of the container affects the cold starts too, I guess decreasing it by removing the v2 and putting the necessary packages, it will be better.

[philiiiiiipp]

@omer-to Afaik adding a layer for the lambda function would not replace the image the lambda function is running in ( which contains the aws-sdk v2 ), it would just add another layer on top.

I googled a bit and found an article exploring cold starts and lambda layers, I don't think it says much for this use case because it is not clear what the layer does and it uses java, but at least it shows no immediate addition to the coldstart. I would assume though that no matter where the sdk is located it will add to the coldstart.

[ghost]

@philiiiiiipp I didn’t mention anything about adding a layer, but rather providing container image?

[philiiiiiipp]

Oh I see, for some reason I just assumed you meant layers. This is quite interesting, especially to check how the coldstart is affected by using this over their provided runtimes.

[adcreare]

my understanding is adding your own container image is also result in longer cold starts. AWS have cloud9 editor of building simple lambdas inside a lambda function, if the aws sdk wasn't included by default that wouldnt be possible.
My guess is they'll add an option or import both v2 and v3 into the lambda runtime.. I don't see how they can do anything else without changing a bunch of things and invalidating a bunch of documentation they had for authoring quick lambdas.
When that will happen? who knows....

[dphang]

This would be great to have, also hopefully in Lambda@Edge too (not sure if it's different, since I know Lambda@Edge has more limitations)

One current solution to the size problem we did (in our open source project): if you are just importing one client like DynamoDB, you can use something like Rollup to reduce the amount of code included by removing unused code for all other clients.

For example, for s3 client only it ended up including around 200 KB of code (uncompressed, unminified), which is still reasonable.

[kuhe]

AWS SDK JSv3 is available in Lambda's Node.js 18

https://aws.amazon.com/blogs/compute/node-js-18-x-runtime-now-available-in-aws-lambda/
https://aws.amazon.com/blogs/developer/why-and-how-you-should-use-aws-sdk-for-javascript-v3-on-node-js-18/

[github-actions]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs and link to relevant comments in this thread.