This post is about raising awareness of a performance penalty when initializing the AWS SDK for .NET.

This is a startup tax incurred by all AWS Lambda functions using .NET. Fortunately, it's trivial to make it happen during the INIT phase where it's free. However, there is no way of avoiding it during a cold start. I can't help but think the initialization overhead should be much lower.

For this benchmark, our code is almost identical with the baseline function, except that we initialize an S3 client in the constructor.

using System.IO;
using System.Threading.Tasks;
using Amazon.S3;

namespace Benchmark.AwsSdk {

    public sealed class Function {

        //--- Fields ---
        private IAmazonS3? _s3Client;

        //--- Constructors ---
        public Function() {

            // initialize S3 client
            _s3Client = new AmazonS3Client();
        }

        //--- Methods ---
        public async Task<Stream> ProcessAsync(Stream request) {
            return Stream.Null;
        }
    }
}

Cold Start Durations

The following table shows the new measurements using .NET 6, Tiered Compilation, and ReadyToRun with 3 different memory configurations: 1,024 MB, 1,769 MB, and 5,120 MB.

Initializing the AWS SDK for .NET adds a 120+ ms penalty to the cold start duration. The impact remains the same, no matter the memory configuration since the initialization is happening during the INIT phase.

Potential Cause

Looking at the code for the AWS SDK for .NET, I suspect the culprit of the slow initialization is the endpoints.js file. This 700+ KB megalodon JSON file is parsed every time the AWS SDK is initialized. Since this happens in the AWS Core assembly, this penalty is incurred by all AWS service clients.

I hope this is something the AWS team fixes in the future. As a clueless layman, I would expect the endpoint definitions to belong to their respective packages. This would also produce a smaller Lambda deployment package as the current AWSSDK.Core.dll assembly size is an eyewatering 1.5 MB!

What's Next

In the next post, I'm benchmarking the impact of using top-level statements with Lambda functions. This new way of writing Lambda code is aesthetically pleasing, but does it have a hidden cost?