~/sph.sh
aws-lambda
serverless
cold-start

AWS Lambda Cold Start Optimization: 5 Years of Production Lessons

Real-world strategies for optimizing AWS Lambda cold starts based on 5 years of production experience, covering runtime selection, provisioned concurrency, and practical optimization techniques.

Working with AWS Lambda since 2019, I've learned that cold starts aren't just a theoretical problem—they're the difference between a smooth user experience and frustrated customers. Let me share what I've learned from optimizing hundreds of Lambda functions across different production environments.

The Reality of Cold Start Impact#

During our quarterly business review, our payment processing Lambda started timing out. The issue? We'd grown from 100 to 10,000 concurrent users, and cold starts were adding 2-3 seconds to payment processing. Not exactly the impression you want to make during a critical business moment.

This incident taught me that cold start optimization isn't just about performance—it's about business continuity.

Understanding Cold Start Fundamentals#

What Actually Happens During a Cold Start#

When AWS needs to create a new Lambda execution environment, it goes through several phases:

TypeScript
// This is what AWS does internally (simplified)
1. Download your deployment package
2. Initialize the runtime (Node.js, Python, etc.)
3. Run initialization code (imports, DB connections)
4. Execute your handler function

The total time varies significantly by runtime and package size:

  • Node.js 18: 200-800ms typical
  • Python 3.9: 300-1200ms typical
  • Java 11: 1-4 seconds (yes, really)
  • Go: 100-400ms (the speed champion)

Runtime Selection Strategy#

After testing all major runtimes in production, here's my practical recommendation:

For new projects:

  • Node.js 18/20: Best balance of performance and ecosystem
  • Go: Choose this if startup time is critical
  • Python: Only if your team expertise demands it

Avoid for latency-sensitive workloads:

  • Java: Unless you're willing to invest in SnapStart optimization
  • .NET: Cold starts can be unpredictable
JavaScript
// Node.js optimization example
// BAD: Heavy imports in handler
exports.handler = async (event) => {
  const AWS = require('aws-sdk'); // This runs on every cold start
  const moment = require('moment'); // Heavy library loaded every time
  // ... handler logic
};

// GOOD: Imports outside handler
const AWS = require('aws-sdk');
const moment = require('moment');

exports.handler = async (event) => {
  // Handler logic only
};

Provisioned Concurrency: When and How#

The Business Case for Provisioned Concurrency#

Use Provisioned Concurrency when:

  • User-facing APIs with SLA requirements
  • Functions triggered by human interaction
  • Peak traffic patterns are predictable
  • Cost of poor UX > provisioned concurrency cost

Skip Provisioned Concurrency for:

  • Async processing (SQS, EventBridge)
  • Batch jobs and data processing
  • Internal APIs with relaxed SLA
  • Functions with unpredictable traffic

Real-World Configuration#

Here's a CloudFormation configuration that saved us during Black Friday traffic:

YAML
# CloudFormation template
Resources:
  PaymentProcessorFunction:
    Type: AWS::Lambda::Function
    Properties:
      Runtime: nodejs18.x
      Handler: index.handler
      MemorySize: 1024  # Sweet spot for most workloads
      Timeout: 30

  # Provisioned Concurrency for peak hours
  ProvisionedConcurrency:
    Type: AWS::Lambda::ProvisionedConcurrencyConfig
    Properties:
      FunctionName: !Ref PaymentProcessorFunction
      ProvisionedConcurrencyAmount: 50  # Start conservative
      Qualifier: !GetAtt PaymentProcessorFunction.Version

  # Auto-scaling for traffic spikes
  ApplicationAutoScalingTarget:
    Type: AWS::ApplicationAutoScaling::ScalableTarget
    Properties:
      MaxCapacity: 200
      MinCapacity: 20
      ResourceId: !Sub 'function:${PaymentProcessorFunction}:provisioned'
      ScalableDimension: lambda:provisioned-concurrency:concurrency
      ServiceNamespace: lambda

Provisioned Concurrency Cost Reality Check#

Real numbers from our production workload:

  • Regular Lambda: $0.0001 per 100ms (1GB memory)
  • Provisioned Concurrency: $0.0000041667 per 100ms + $0.0000150000 per hour

For a function running 1 million times per month:

  • Without PC: ~$20/month
  • With PC (50 concurrent): ~$42/month
  • Cost increase: ~110%
  • Performance gain: 90% cold start reduction

The math only works if poor performance costs you more than $22/month.

Keep-Warm Strategies: The Good and Bad#

CloudWatch Events Keep-Warm (Legacy Approach)#

JavaScript
// Keep-warm implementation
exports.handler = async (event) => {
  // Handle keep-warm pings
  if (event.source === 'aws.events' && event['detail-type'] === 'Keep Warm') {
    return { statusCode: 200, body: 'Staying warm!' };
  }
  
  // Regular handler logic
  return processRequest(event);
};

Why I stopped using keep-warm:

  • Added complexity to every function
  • CloudWatch Events costs add up
  • Unreliable during traffic spikes
  • Provisioned Concurrency is more predictable

Modern Alternative: Lambda Extensions#

TypeScript
// Using Lambda Extensions for custom monitoring
// This runs as a separate process and can handle keep-warm logic
const EXTENSION_NAME = 'keep-warm-extension';

process.on('SIGINT', () => gracefulShutdown());
process.on('SIGTERM', () => gracefulShutdown());

// Register extension
const registerResponse = await fetch(
  `http://${AWS_LAMBDA_RUNTIME_API}/2020-01-01/lambda/extensions`,
  {
    method: 'POST',
    body: JSON.stringify({
      'lambda-extension-name': EXTENSION_NAME,
      'lambda-extension-events': ['INVOKE', 'SHUTDOWN']
    })
  }
);

Package Size Optimization#

Bundle Analysis That Actually Matters#

The deployment package size directly impacts cold start time. Here's how to optimize:

Bash
# Analyze your bundle
npm install -g webpack-bundle-analyzer
webpack-bundle-analyzer dist/

# Common bloated packages to watch out for
aws-sdk: 50MB+ (use AWS SDK v3 with selective imports)
moment: 232KB (use date-fns instead)
lodash: 528KB (import specific functions only)

Practical Bundling Strategy#

TypeScript
// BAD: Imports entire AWS SDK v2
import AWS from 'aws-sdk';
const dynamodb = new AWS.DynamoDB.DocumentClient();

// GOOD: Selective imports with AWS SDK v3
import { DynamoDBClient } from '@aws-sdk/client-dynamodb';
import { DynamoDBDocumentClient, GetCommand } from '@aws-sdk/lib-dynamodb';

const client = DynamoDBDocumentClient.from(new DynamoDBClient({}));

Webpack Configuration for Lambda#

JavaScript
// webpack.config.js optimized for Lambda
module.exports = {
  target: 'node',
  mode: 'production',
  entry: './src/index.ts',
  externals: {
    'aws-sdk': 'aws-sdk' // Don't bundle AWS SDK v2 (available in runtime)
  },
  optimization: {
    minimize: true,
    usedExports: true, // Tree shaking
    sideEffects: false
  },
  resolve: {
    extensions: ['.ts', '.js']
  }
};

Lambda Layers: Strategic Usage#

What Belongs in a Layer#

Good candidates for layers:

  • Shared business logic across functions
  • Heavy dependencies (analytics SDKs, etc.)
  • Custom runtimes or tools

Keep in function package:

  • Function-specific logic
  • Frequently changing code
  • Small utility libraries

Layer Performance Impact#

From my testing across different layer configurations:

Bash
# Cold start times with different layer strategies
No layers:              ~800ms
1 layer (30MB):        ~850ms
3 layers (total 45MB): ~1200ms
5+ layers:             ~2000ms+ (avoid!)

Rule of thumb: 1-2 layers maximum, keep total size under 50MB.

Connection Pooling and Initialization#

Database Connection Strategy#

TypeScript
// Connection pooling outside handler
import { Pool } from 'pg';

const pool = new Pool({
  host: process.env.DB_HOST,
  database: process.env.DB_NAME,
  user: process.env.DB_USER,
  password: process.env.DB_PASSWORD,
  max: 1, // Important: Lambda = single concurrent execution
  idleTimeoutMillis: 30000,
  connectionTimeoutMillis: 10000,
});

export const handler = async (event: any) => {
  try {
    const client = await pool.connect();
    // Use client for queries
    const result = await client.query('SELECT NOW()');
    client.release();
    return result.rows;
  } catch (error) {
    console.error('Database error:', error);
    throw error;
  }
};

AWS Service Client Reuse#

TypeScript
// Service client reuse pattern
import { DynamoDBClient } from '@aws-sdk/client-dynamodb';
import { S3Client } from '@aws-sdk/client-s3';

// Initialize outside handler
const dynamoClient = new DynamoDBClient({});
const s3Client = new S3Client({});

export const handler = async (event: any) => {
  // Reuse clients across invocations
  // AWS SDK v3 handles connection pooling internally
};

Monitoring Cold Starts in Production#

Essential CloudWatch Metrics#

TypeScript
// Custom metric for cold start detection
import { CloudWatch } from 'aws-sdk';
const cloudwatch = new CloudWatch();

const isColdStart = !global.isWarm;
global.isWarm = true;

if (isColdStart) {
  await cloudwatch.putMetricData({
    Namespace: 'Lambda/Performance',
    MetricData: [{
      MetricName: 'ColdStart',
      Value: 1,
      Unit: 'Count',
      Dimensions: [{
        Name: 'FunctionName',
        Value: context.functionName
      }]
    }]
  }).promise();
}

X-Ray Tracing Setup#

TypeScript
// Enable X-Ray tracing for cold start visibility
import AWSXRay from 'aws-xray-sdk-core';

// Trace cold start initialization
const initSegment = AWSXRay.getSegment()?.addNewSubsegment('initialization');
// ... initialization code
initSegment?.close();

export const handler = AWSXRay.captureAsyncFunc('handler', async (event) => {
  // Handler logic with automatic tracing
});

Common Cold Start Pitfalls#

Pitfall 1: Over-Engineering Warm-Up Logic#

I've seen teams spend weeks building complex keep-warm systems that ultimately cost more than Provisioned Concurrency and work less reliably.

Pitfall 2: Ignoring Memory Impact#

Memory doesn't just affect execution time—it affects cold start time. A 128MB function with a 50MB package will cold start slower than a 1GB function with the same package.

Pitfall 3: Wrong Runtime Choice#

Choosing Java for a user-facing API without understanding the cold start implications. Unless you're prepared to use SnapStart and tune extensively, stick with Node.js or Python.

Pitfall 4: Dependency Bloat#

Adding npm packages without considering bundle impact. Every dependency adds to cold start time, especially transitive dependencies.

What's Next: Performance Deep Dive#

Cold start optimization is just the beginning. In the next part of this series, we'll dive deep into memory allocation strategies and performance tuning techniques that can make your Lambda functions not just start faster, but run more efficiently.

We'll cover:

  • Memory vs CPU allocation strategies
  • Real-world benchmarking techniques
  • Performance profiling tools
  • Cost analysis frameworks

Key Takeaways#

  1. Runtime choice matters: Node.js and Go offer the best cold start performance
  2. Provisioned Concurrency isn't always the answer: Do the cost-benefit math first
  3. Package size optimization: Can reduce cold start time by 30-50%
  4. Connection pooling: Essential for database-connected functions
  5. Monitor what matters: Track cold start frequency, not just duration

Cold start optimization is an ongoing process, not a one-time fix. Start with the biggest impact changes (runtime, package size) before moving to complex solutions like Provisioned Concurrency.

AWS Lambda Production Guide: 5 Years of Real-World Experience

A comprehensive guide to AWS Lambda based on 5+ years of production experience, covering cold start optimization, performance tuning, monitoring, and cost optimization with real war stories and practical solutions.

Progress1/4 posts completed
First post in series
Next
Memory Allocation and Performance Tuning
View series →
Loading...

Comments (0)

Join the conversation

Sign in to share your thoughts and engage with the community

No comments yet

Be the first to share your thoughts on this post!

Related Posts