Bundling for Lambda requires unnecessary dependencies

[perpil]

Checkboxes for prior research

• I've gone through Developer Guide and API reference
• I've checked AWS Forums and StackOverflow.
• I've searched for previous similar issues and didn't find any solution.

Describe the bug

For Lambda coldstarts, it is well known creating a minified, tree-shaken bundle measurably improves performance vs. using the V3 JavaScript SDK version bundled with Lambda.

coldstart time (ms)	bundled/minified
675	no
241	yes

In a minified bundle, if you use any AWS client, credential-provider-node starts pulling in client-sso and other packages. These packages are unused but add > 32KB to the minified bundle. If you set the credentials parameter for the AWS client, it still pulls in client-sso and can't be tree-shaken out. Since loading credentials from environment variables is what most developers need for Lambda, there should be a way to only bundle the credential-provider-env credentials provider. Arguably this should be the default in the Lambda environment.

SDK version number

@aws-sdk/client-sts@3.454.0

Which JavaScript Runtime is this issue in?

Node.js

Details of the browser/Node.js/ReactNative version

v20.9.0

Reproduction Steps

1. Create a lambda with any AWS client, i.e. STS:

import { GetCallerIdentityCommand, STSClient } from '@aws-sdk/client-sts';

const stsClient = new STSClient({region: process.env.AWS_REGION});

export async function handler(event, context) {
  const result = await stsClient.send(new GetCallerIdentityCommand({}));
  return {
    statusCode: 200,
    body: JSON.stringify({
      result
    }),
    headers: {
      'Content-Type': 'application/json',
    },
  };
}

2. Minify, treeshake and create metafile with esbuild. If you use NodeJsFunction in the CDK your bundling looks like:

  bundling: {
        metafile: true, //use https://esbuild.github.io/analyze/ to analyze the bundle
        minify: true,
        treeshake: true,
        target: 'esnext',
        format: 'esm',
        platform: 'node',
        mainFields: ['module', 'main'],
        outputFileExtension: '.mjs',
        externalModules: [],
        banner:
          "const require = (await import('node:module')).createRequire(import.meta.url);const __filename = (await import('node:url')).fileURLToPath(import.meta.url);const __dirname = (await import('node:path')).dirname(__filename);",
  }

3. Review the metafile using the esbuild analyzer and note it includes packages like client-sso
   I've attached the metafile for the above so you can directly review it: index.meta.json
   Look at it in Flamechart mode and note the inclusion of these packages: client-sso, token-providers, credential-provider-sso
   Screenshot of why token-providers is not tree-shaken:

Observed Behavior

The packages client-sso, token-providers and credential-provider-sso get bundled unnecessarily and can't be tree-shaken out.

Expected Behavior

Either it uses credential-provider-env, or client config has some way of allowing me to omit credential-provider-node so the unnecessary packages can be tree-shaken out.

Possible Solution

No response

Additional Information/Context

No response

[perpil]

When I replaced the compiled version of this file with the contents below in my minified bundle, the sso code treeshook out and I saw a 41KB reduction in bundle size and a 39 ms reduction in cold start time:

import { fromEnv } from '@aws-sdk/credential-provider-env';
import {
  chain,
  CredentialsProviderError,
  memoize,
} from '@smithy/property-provider';
export const defaultProvider = (init = {}) =>
  memoize(
    chain(...[fromEnv()], async () => {
      throw new CredentialsProviderError(
        'Could not load credentials from any providers',
        false
      );
    }),
    (credentials) =>
      credentials.expiration !== undefined &&
      credentials.expiration.getTime() - Date.now() < 300000,
    (credentials) => credentials.expiration !== undefined
  );

The impact to coldstart is even greater if I use the sdk which is included on disk by the Lambda runtime. I have done a test where I minified everything but used what was on disk for client-sso, token-providers and credential-provider-sso and saw a 270-335 ms impact.

You can see how I benchmarked and repeat it yourself using this repo.

[RanVaknin]

Hi @perpil ,

Thanks for the reproduction. I can confirm the observed behavior. I'll discuss it with the team and get back to you.

All the best,
Ran~

[RanVaknin]

Hi @perpil ,

After discussing this with the team I got some more context about this.

We provide the entire credential provider chain so that the SDK code deployed can be platform agnostic, whether it runs on EC2, Lambda, EKS etc, it should just work. Since the bundling process happens prior to the deployment part, the bundler cannot know which platform its bundling for and so omitting the unnecessary providers is not possible.

You can probably use something like Yarn Patch, but I cannot officially recommend it.

Regarding this part

The impact to coldstart is even greater if I use the sdk which is included on disk by the Lambda runtime. I have done a test where I minified everything but used what was on disk for client-sso, token-providers and credential-provider-sso and saw a 270-335 ms impact.

Using the SDK provided by lambda is going to be less optimized because it fits an even greater array of use cases. Cold start times are in fact lower when bundling and minifying as shown in our own benchmarking.

Currently there is no way / plan to fix this.
Thank you for taking the time to raise the feature request, and I hope that this does not discourage you from engaging with us in the future.

All the best,
Ran~

[perpil]

Hi @RanVaknin

I understand the general purpose nature of the provider and the fact that bundling is not aware of the target platform. I am also aware that I can patch the provider myself and am successfully doing so using patch-package. The key point is that this is slowing down coldstarts for a large cross section of users (everyone using the V3 SDK and Lambda). The Lambda team would need to take incredible engineering effort to reduce coldstarts by 39 ms whereas making a change to the SDK comes at a much lower cost. There are multiple ways of solving this without breaking support for other platforms and maintaining backwards compatibility.

1. Lazy loading. Since fromEnv is one of the first in the chain, there is no need to load other providers if there is a hit. https://aaronstuyvenberg.com/posts/lambda-lazy-loading
2. Lazy loading based on environment variables. Either setting an environment variable for different behavior or autodetecting based on the presence of lambda specific environment variables.
3. Allowing the developer to specify a custom provider as config that completely overrides the provider being used.

Any of these options would be better than what we have. I encourage you to reach out to former Lambda principal David Yanacek or current principal Nik Pinski before making a final decision. I spoke to both of them at re:invent and they understand the positives that reducing the cold start for everyone would have. It may seem small for the SDK team, but would be a big win for the Lambda team.

[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.