Lambda Function Optimization: Cold Start Solutions to Memory Tuning

Key Takeaway

Lambda optimization essentials: Increasing memory also increases CPU, and cold starts are solved with Provisioned Concurrency or SnapStart. Initialize outside the handler and cache in /tmp to reduce execution time.

---

1. Understanding Lambda Execution Environment

Execution Environment Lifecycle

┌─────────────────────────────────────────────────────────┐
│           Lambda Execution Environment Lifecycle          │
├─────────────────────────────────────────────────────────┤
│                                                         │
│  [First Invocation - Cold Start]                        │
│  ┌──────────┐    ┌──────────┐    ┌──────────┐          │
│  │ Env Create│ → │Init Phase│ → │ Invoke   │           │
│  │(download) │    │(init)    │    │(handler) │           │
│  └──────────┘    └──────────┘    └──────────┘          │
│      Cold start latency        │  Actual execution     │
│  ─────────────────────────────┼───────────────          │
│                                                         │
│  [Subsequent Invocations - Warm Start]                  │
│  ┌──────────────────────────┐    ┌──────────┐          │
│  │   Reuse Environment (skip)│ → │ Invoke   │           │
│  └──────────────────────────┘    └──────────┘          │
│           Fast!                   Actual execution     │
└─────────────────────────────────────────────────────────┘

What is Cold Start?

Cold start is the latency that occurs when Lambda creates a new execution environment:

1. Download code
2. Start runtime environment
3. Execute init code (code outside handler)

Runtime	Average Cold Start Time
Python	~200ms
Node.js	~200ms
Go	~100ms
Java	~1-3 seconds
.NET	~500ms-1 second

---

2. Memory and CPU Relationship

Core Concept

In Lambda, increasing memory proportionally increases CPU. This is Lambda's most important characteristic.

┌─────────────────────────────────────────────────────────┐
│              Memory-CPU Proportional Relationship         │
├─────────────────────────────────────────────────────────┤
│                                                         │
│   Memory        CPU Performance      vCPU              │
│   ───────────────────────────────────────────           │
│   128 MB        Low                 ~0.1 vCPU           │
│   512 MB        Medium              ~0.4 vCPU           │
│   1,792 MB      1 vCPU              1 vCPU              │
│   3,008 MB      1.7 vCPU            ~2 vCPU             │
│   10,240 MB     6 vCPU              6 vCPU (max)        │
│                                                         │
│   1,769MB+: Multi-thread parallel processing possible    │
└─────────────────────────────────────────────────────────┘

Memory Tuning Strategy

Cost Optimization Formula:
Execution Time × Memory = Cost

Example:
- 128MB × 10 seconds = 1,280 MB-seconds
- 512MB × 2.5 seconds = 1,280 MB-seconds (same cost, faster!)

If execution time decreases proportionally with memory increase,
cost stays the same or may even decrease

AWS Lambda Power Tuning

A tool that automatically tests memory optimization:

# Test various memory settings with Step Functions
# Can test all combinations from 128MB to 10GB
# Result: Recommends optimal memory setting

Typical results:
- Performance improvement diminishes above 6GB
- Find the "sweet spot" on cost vs performance curve

---

3. Cold Start Solutions

Method 1: Provisioned Concurrency

Pre-initialize execution environments to completely eliminate cold starts.

┌─────────────────────────────────────────────────────────┐
│              Provisioned Concurrency                     │
├─────────────────────────────────────────────────────────┤
│                                                         │
│   Setting: Provisioned Concurrency = 100               │
│                                                         │
│   ┌────┐ ┌────┐ ┌────┐ ┌────┐ ... ┌────┐              │
│   │Env │ │Env │ │Env │ │Env │     │Env │              │
│   │ 1  │ │ 2  │ │ 3  │ │ 4  │     │100 │              │
│   └────┘ └────┘ └────┘ └────┘     └────┘              │
│        ↑                                                │
│   Pre-initialized and waiting (kept warm)               │
│                                                         │
│   Request → Immediate response (no cold start)          │
└─────────────────────────────────────────────────────────┘

Cost Considerations:

Example: 1,536MB memory, 100 concurrency, 24 hours
= ~$54/day = ~$1,620/month

Note: Continuous cost like EC2
→ Recommend Auto Scaling based on traffic patterns

Method 2: Lambda SnapStart (Java)

Saves a snapshot of Java function's Init phase to reduce cold start by up to 90%.

┌─────────────────────────────────────────────────────────┐
│                  SnapStart Operation                     │
├─────────────────────────────────────────────────────────┤
│                                                         │
│  [During Version Deployment]                            │
│  Run Init → Memory state snapshot → Encrypted storage   │
│                                                         │
│  [During Function Invocation]                           │
│  Load snapshot → Execute immediately (skip Init)        │
│                                                         │
│  Result: Java cold start 1-3 seconds → under 200ms      │
└─────────────────────────────────────────────────────────┘

Method 3: EventBridge Warmup

Periodically invoke Lambda every 5 minutes to keep execution environment alive.

┌─────────────────────────────────────────────────────────┐
│               EventBridge Warmup Strategy                │
├─────────────────────────────────────────────────────────┤
│                                                         │
│   EventBridge Rule: rate(5 minutes)                     │
│           │                                             │
│           ▼                                             │
│   Lambda function invocation (warmup event)             │
│           │                                             │
│           ▼                                             │
│   Execution environment maintained (reused up to 15min)  │
│                                                         │
│   Pros: Cheap (invocation cost only)                    │
│   Cons: Only maintains concurrency of 1, not perfect    │
└─────────────────────────────────────────────────────────┘

---

4. Performance Optimization Best Practices

Initialize Outside Handler

# ❌ Wrong: Initialize on every invocation
def handler(event, context):
    client = boto3.client('dynamodb')  # Created each time
    return client.get_item(...)

# ✅ Correct: Initialize outside handler
client = boto3.client('dynamodb')  # Created once, reused

def handler(event, context):
    return client.get_item(...)  # Reuse existing connection

/tmp Directory Caching

import os

CACHE_FILE = '/tmp/cached_data.json'

def handler(event, context):
    # Check cache
    if os.path.exists(CACHE_FILE):
        with open(CACHE_FILE) as f:
            data = json.load(f)
    else:
        # Load and cache data
        data = load_expensive_data()
        with open(CACHE_FILE, 'w') as f:
            json.dump(data, f)

    return process(data)

Optimization Checklist

┌─────────────────────────────────────────────────────────┐
│              Lambda Optimization Checklist               │
├─────────────────────────────────────────────────────────┤
│                                                         │
│  ✅ Initialize SDK clients outside handler              │
│  ✅ Create DB connections outside handler (reuse)       │
│  ✅ Cache static assets in /tmp (512MB limit)           │
│  ✅ Remove unnecessary packages (minimize deployment)    │
│  ✅ Optimize memory with AWS Lambda Power Tuning        │
│  ✅ Minimize VPC connections (only when necessary)      │
│  ✅ Use Provisioned Concurrency only when needed        │
└─────────────────────────────────────────────────────────┘

---

5. VPC Connection Considerations

VPC Lambda Latency Issues

Connecting Lambda to VPC can cause additional latency due to ENI creation.

Past (before 2019):
VPC Lambda cold start: +10-30 seconds

Current (after Hyperplane):
VPC Lambda cold start: Similar to regular Lambda

When VPC Connection is Needed

Needed	Not Needed
RDS/Aurora access	DynamoDB access
ElastiCache access	S3 access
Private subnet resources	SQS, SNS access
EC2 instance communication	API Gateway calls

---

6. Cost Optimization

Lambda Cost Structure

Total Cost = Request Cost + Compute Cost

Request Cost: $0.20 / 1 million requests
Compute Cost: $0.0000166667 / GB-second

Example: 512MB, 1 second execution, 1 million invocations/month
= $0.20 + (0.5GB × 1 second × 1,000,000 × $0.0000166667)
= $0.20 + $8.33 = $8.53/month

Cost Reduction Strategies

Strategy	Description
Memory Optimization	Find optimal memory with Power Tuning
Reduce Execution Time	Initialize outside handler, caching
Graviton2	20% cost savings with ARM processor
Provisioned Optimization	Auto Scaling for just enough capacity

Graviton2 (ARM) Usage

Graviton2 vs x86_64:
- Price: 20% cheaper
- Performance: Up to 34% improvement
- Migration: Architecture change needed (arm64)

Supported Runtimes:
- Python, Node.js, Ruby, Java, .NET, Go

---

Exam Focus Points

Common Question Types

1. Cold Start Related

   • "How to reduce Java Lambda cold start?" → SnapStart
   • "How to completely eliminate cold start?" → Provisioned Concurrency

2. Performance Optimization

   • "Lambda execution time too long?" → Increase memory (CPU increases too)
   • "How to reduce Lambda initialization time?" → Initialize outside handler

3. Cost Optimization

   • "How to reduce Lambda cost?" → Graviton2, memory optimization
   • "Provisioned Concurrency cost characteristics?" → Continuous cost

---

FAQ

Q1: Does increasing memory always increase cost?

No. Increasing memory also increases CPU, reducing execution time. If execution time decreases proportionally, total cost stays the same or may decrease. Use Lambda Power Tuning to find optimal memory.

Q2: What's the difference between Provisioned Concurrency and Reserved Concurrency?

• Provisioned Concurrency: Pre-initialized environments maintained (eliminates cold start, costs money)
• Reserved Concurrency: Limits maximum concurrent executions (no cost, cold starts still occur)

Q3: Is SnapStart available for all runtimes?

No. Only available for Java 11/17 and above. For Python, Node.js, and other runtimes, use Provisioned Concurrency.

Q4: What's the /tmp directory size limit?

Default is 512MB, expandable up to 10GB (additional cost). /tmp data persists while the execution environment is reused.

Q5: Does VPC connection affect performance?

Currently, Hyperplane technology means VPC connection has minimal additional latency. In the past, ENI creation took 10-30 seconds, but now it's similar to regular Lambda.

---

Summary

Key points for Lambda optimization:

1. Memory = CPU: Increasing memory also increases CPU
2. Initialize outside handler: Reuse SDK and DB connections
3. Solve cold starts: Provisioned Concurrency or SnapStart
4. Cost optimization: Graviton2, Power Tuning

For exams, remember: "Lambda performance improvement" → increase memory, "Eliminate cold start" → Provisioned Concurrency.