Optimizing AWS Lambda Cold Starts: Reduce Init Duration and Bundle Size

With over 5 years of experience and 50+ serverless optimization projects, we deliver guaranteed results. Let’s start with a specific case: a fintech application with 50 Lambda functions. After a 30-second timeout, clients complained about delays. An audit revealed init duration up to 800 ms due to a monolithic bundle of 8 MB. We applied tree-shaking, lazy loading, and migrated from AWS SDK v2 to v3. Init duration dropped to 90 ms, and execution costs decreased by 20%. How to achieve this? Let’s break down the methods.

Why Cold Start Matters

A cold start consists of three phases: container creation (100–500 ms), runtime initialization (50–200 ms), and init code execution. AWS manages the first two; the third is your responsibility. Measure the delay via CloudWatch Logs: the Init Duration line in the report. According to AWS, init duration can reach several seconds with a large bundle.

A typical Express app with aws-sdk v2 weighs 8–15 MB zip. After optimization — 500 KB–2 MB. Initialization time drops from 500 ms to 80 ms. We once optimized a Lambda function handling 100k requests per month. The original bundle was 8 MB, init duration 700 ms. After tree-shaking and lazy loading, the bundle was 1.2 MB, cold start dropped to 90 ms, and monthly execution costs decreased by 25%. That’s a 7x faster cold start.

Methods to Reduce Cold Start Latency

Our cold start optimization techniques address Lambda cold start latency through bundle reduction, lazy loading, and RDS Proxy integration, significantly improving serverless performance and reducing serverless latency.

Reduce Bundle Size

Use esbuild with external: ["@aws-sdk/*"] and minification. AWS SDK v3 is modular — import only the clients you need:

import { S3Client, GetObjectCommand } from '@aws-sdk/client-s3'; import { DynamoDBClient } from '@aws-sdk/client-dynamodb'; import { DynamoDBDocumentClient, GetCommand } from '@aws-sdk/lib-dynamodb'; const s3 = new S3Client({ region: process.env.AWS_REGION }); const dynamo = DynamoDBDocumentClient.from(new DynamoDBClient({})); 

Lazy Load Heavy Modules

Move imports of rare dependencies inside the handler using dynamic import():

export const handler = async (event) => { if (event.type === 'generate-pdf') { const { PDFDocument } = await import('pdf-lib'); const pdf = await PDFDocument.create(); } }; 

Initialize Outside Handler

DB clients, environment variables, and settings that don’t change between invocations should be outside export const handler:

import { DynamoDBDocumentClient } from '@aws-sdk/lib-dynamodb'; import { DynamoDBClient } from '@aws-sdk/client-dynamodb'; const client = new DynamoDBClient({ requestHandler: { requestTimeout: 3000, httpsAgent: { keepAlive: true, maxSockets: 50 } }, }); const dynamo = DynamoDBDocumentClient.from(client); const TABLE_NAME = process.env.TABLE_NAME!; export const handler = async (event) => { const result = await dynamo.send(new GetCommand({ TableName: TABLE_NAME, Key: { pk: event.userId, sk: 'profile' } })); return result.Item; }; 

Comparison of Optimization Methods

How to Properly Configure Database Connections

A conventional connection pool in serverless leads to thousands of concurrent connections during scaling. The solution is RDS Proxy (AWS-managed connection pooler) or HTTP-based databases like Neon. RDS Proxy supports up to 100,000 connections but saves up to 80% of connections compared to direct connections. Configuration is straightforward:

import { Pool } from 'pg'; const pool = new Pool({ host: process.env.RDS_PROXY_ENDPOINT, max: 1, idleTimeoutMillis: 0, }); 

When Provisioned Concurrency Makes Sense

Provisioned Concurrency keeps N Lambda instances warm. Init executes in advance. Cost: you pay for idle. We only use it for critical endpoints requiring <100 ms latency. Configuration via SAM or Serverless Framework is simple.

Architecture: arm64 vs x86

Switch your architecture to Graviton2 (arm64) — it gives a 10–20% init speedup and 20% cost savings. The only constraint: native .node modules need recompilation. All other TS/JS code runs without changes.

Step-by-Step Optimization Process

1. Audit: measure init duration of all functions via CloudWatch Logs and Lambda Insights.
2. Analyze bundle: identify heavy dependencies and duplicates.
3. Reduce bundle: apply esbuild with tree-shaking, extract AWS SDK v3.
4. Lazy loading: move rare modules (PDF, images) outside init.
5. Set up RDS Proxy: for functions with direct DB connections.
6. Configure Provisioned Concurrency: for critical endpoints.
7. Test: compare init duration before and after.

What’s Included in Optimization

• Audit of current functions: init duration measurement, bundle analysis
• Package size reduction: esbuild, tree-shaking, AWS SDK extraction
• Initialization optimization: lazy loading, client caching
• RDS Proxy or alternative DB setup
• Provisioned Concurrency and auto-scaling configuration
• Architecture recommendations (arm64, environment variables)
• Detailed documentation, access to optimized code repositories, team training, and 30 days of support included.

Timelines and Pricing

Audit and basic optimization — from 1 day. Full cycle with RDS Proxy and Provisioned Concurrency — up to 1 week. Basic optimization package starts at $500; full setup from $2,000. Pricing is determined individually after estimating scope. Contact us for a free audit and get a detailed analysis of your cold starts today.