Just how expensive is the full AWS SDK?

You can become a serverless blackbelt. Enrol to my 4-week online workshop Production-Ready Serverless and gain hands-on experience building something from scratch using serverless technologies. At the end of the workshop, you should have a broader view of the challenges you will face as your serverless architecture matures and expands. You should also have a firm grasp on when serverless is a good fit for your system as well as common pitfalls you need to avoid. Sign up now and get 15% discount with the code yanprs15!

If you’re not familiar with how cold start works within the context of AWS Lambda, then read this post first.

update 24/03/2019: the tests include WebPack as well.

When a Node.js Lambda function cold starts, a number of things happen:

  • the Lambda service has to find a server with enough capacity to host the new container
  • the new container is initialized
  • the Node.js runtime is initialized
  • your handler module is initialized, which includes initializing any global variables and functions you declare outside the handler function

If you enable active tracing for a Lambda function, you will be able to see how much time is spent on these steps in X-Ray. Unfortunately, the time it takes to initialize the container and the Node.js runtime are not recorded as segments. But you can work out from the difference in durations.

Here, Initialization refers to the time it takes to initialize the handler module.

The above trace is for the function below, which requires the AWS SDK and nothing else. As you can see, this simple require added 147ms to the cold start.

const AWS = require('aws-sdk')
module.exports.handler = async () => {

Consider this the cost of doing business when your function needs to interact with AWS resources. But, if you only need to interact with one service (e.g. DynamoDB), you can save some initialization time with this one-liner.

const DynamoDB = require('aws-sdk/clients/dynamodb')
const documentClient = new DynamoDB.DocumentClient()

It requires the DynamoDB client directly without initializing the whole AWS SDK. I ran an experiment to see how much cold start time you can save with this simple change.

Credit goes to my colleague Justin Caldicott for piquing my interest and doing a lot of the initial analysis.

In addition to the AWS SDK, we often require the XRay SDK too and use it to auto-instrument the AWS SDK. Unfortunately, the aws-xray-sdk package also has some additional baggages that we don’t need. By default it supports Express.js apps, MySQL and Postgres. If you are only interested in instrumenting the AWS SDK and http/https modules then you only need the aws-xray-sdk-core.


I tested a number of configurations:

Each of these functions are traced by X-Ray. Sample rate set to 100% so we don’t miss anything. We are only interested in the duration of the Initialization segment as it corresponds to the time for initializing these dependencies.

The no AWS SDK case is our control group. We can see how much time each additional dependency adds to our Initialization duration.

To collect a statistically significant sample set of data, I decided to automate the process using Step Functions.

  • The state machine takes an input { functionName, count }.
  • The SetStartTime step adds the current UTC timestamp to the execution state. This is necessary as we need the start time of the experiment to fetch the relevant traces from X-Ray.
  • The Loop step triggers the desired number of cold starts for the specified function. To trigger cold starts, I programmatically updates an environment variable before invoking the function. That way, I ensure that every invocation is a cold start.

  • The Wait30Seconds step makes sure that all the traces are published to XRay before we attempt to analyze them.
  • The Analyze step fetches all the relevant traces in XRay and outputs several statistics around the Initialization duration.

Each configuration is tested over 1000 cold starts. Occasionally the XRay traces are incomplete (see below). These incomplete traces are excluded in the Analyze step.

where is the AWS::Lambda:Function segment?

Each configuration is also tested with WebPack as well (using the serverless-webpack plugin). Thanks to Erez Rokah for the suggestion in the comments.

The Results

These are the Initialization time for all the test cases.

Key observations:

  • WebPack improves the Initialization time across the board.
  • Without any dependencies, Initialization time averages only 1.72ms without WebPack and 0.97ms with WebPack.
  • Adding AWS SDK as the only dependency adds an average of 245ms without WebPack. This is fairly significant. Adding WebPack doesn’t improve things significantly either.
  • Requiring only the DynamoDB client (the one-liner change discussed earlier) saves up to 176ms! In 90% of the cases, the saving was over 130ms. With WebPack, the saving is even more dramatic.
  • The cost of requiring the XRay SDK is about the same as AWS SDK.
  • There’s no statistically significant difference between using the full XRay SDK and XRay SDK Core. With or without WebPack.
Liked this article? Support me on Patreon and get direct help from me via a private Slack channel or 1-2-1 mentoring.
Subscribe to my newsletter

Hi, I’m Yan. I’m an AWS Serverless Hero and I help companies go faster for less by adopting serverless technologies successfully.

Are you struggling with serverless or need guidance on best practices? Do you want someone to review your architecture and help you avoid costly mistakes down the line? Whatever the case, I’m here to help.

Hire me.

Skill up your serverless game with this hands-on workshop.

My 4-week Production-Ready Serverless online workshop is back!

This course takes you through building a production-ready serverless web application from testing, deployment, security, all the way through to observability. The motivation for this course is to give you hands-on experience building something with serverless technologies while giving you a broader view of the challenges you will face as the architecture matures and expands.

We will start at the basics and give you a firm introduction to Lambda and all the relevant concepts and service features (including the latest announcements in 2020). And then gradually ramping up and cover a wide array of topics such as API security, testing strategies, CI/CD, secret management, and operational best practices for monitoring and troubleshooting.

If you enrol now you can also get 15% OFF with the promo code “yanprs15”.

Enrol now and SAVE 15%.

Check out my new podcast Real-World Serverless where I talk with engineers who are building amazing things with serverless technologies and discuss the real-world use cases and challenges they face. If you’re interested in what people are actually doing with serverless and what it’s really like to be working with serverless day-to-day, then this is the podcast for you.

Check out my new course, Learn you some Lambda best practice for great good! In this course, you will learn best practices for working with AWS Lambda in terms of performance, cost, security, scalability, resilience and observability. We will also cover latest features from re:Invent 2019 such as Provisioned Concurrency and Lambda Destinations. Enrol now and start learning!

Check out my video course, Complete Guide to AWS Step Functions. In this course, we’ll cover everything you need to know to use AWS Step Functions service effectively. There is something for everyone from beginners to more advanced users looking for design patterns and best practices. Enrol now and start learning!