Lambda Optimization | Domain 4 — AWS Dev Associate

❄️ Cold Starts — The #1 Lambda Latency Problem

When a Lambda function is invoked, AWS needs to set up an execution environment. If there's an existing warm environment available, the function starts immediately. If not, AWS must create a new one — this is a cold start.

Cold Start vs Warm Invocation — What Happens

📨Request Arrives

→

🔍Find warm env?

✅YES — WarmSkip to handler — fast!

|

❌NO — Cold Start

📥Download code50–500ms

→

🔧Init runtimePython/Node/Java

→

🏗️Run init codeYour module-level code

→

▶️Run handler

⏱️ Cold Start Duration by Runtime

Runtime	Typical Cold Start	Notes
Python	50–300ms	Fast — interpreted, minimal JVM-like initialization
Node.js	50–300ms	Fast — similar to Python
Java	500ms–3 seconds	Slow — JVM startup is heavy. Use GraalVM native image to reduce.
.NET (C#)	400ms–2 seconds	Moderate — .NET CLR initialization

💡 Cold Start Reduction Strategies

Provisioned Concurrency: Best solution — pre-initializes environments, zero cold starts (see below)
Keep functions warm: Use EventBridge to ping the function every few minutes (workaround, not recommended for production)
Reduce package size: Smaller deployment packages = faster download = faster cold start
Use faster runtimes: Python/Node instead of Java for latency-sensitive functions
Minimize init code: Move initialization code outside handler when possible (it runs once per environment)
Avoid large dependencies: Only import what you need

🔄 Lambda Concurrency — Three Types You Must Know

Concurrency in Lambda means: how many instances of your function are running at the same time. Lambda scales horizontally — each concurrent request gets its own execution environment.

Account-Level Concurrency Limit

By default, AWS limits each account to 1,000 concurrent Lambda executions per region. This is shared across ALL Lambda functions in the account. If one function uses all 1,000, other functions get throttled (HTTP 429 TooManyRequests). You can request an increase from AWS.

1️⃣ Unreserved Concurrency

The default. A function uses whatever concurrency is available from the shared account pool. No guarantees — if other functions eat up all the concurrency, this function gets throttled.

2️⃣ Reserved Concurrency

Reserved Concurrency

You assign a specific maximum number of concurrent executions to ONE function. This has two effects simultaneously: (1) Guarantees that many concurrent executions are ALWAYS available for this function, and (2) Caps the function so it can NEVER exceed that number (even if the account has more concurrency available).

📌 Example

You have a critical payment Lambda and a non-critical report Lambda. By default, the report Lambda could consume all 1000 concurrency slots, causing the payment Lambda to throttle.

Solution: Set Reserved Concurrency = 800 on the payment Lambda (guarantees it always has capacity) and set Reserved Concurrency = 50 on the report Lambda (caps it from consuming too much).

Result: Payment Lambda always has 800 slots. Report Lambda can use at most 50. Everyone gets their share.

Cost: No extra charge for Reserved Concurrency — you only pay for actual function execution.

3️⃣ Provisioned Concurrency

Provisioned Concurrency

Pre-initializes a specific number of Lambda execution environments. These environments are always running, fully initialized, and ready to handle requests with zero cold start latency. Think of them as Lambda functions that are always "awake" and waiting.

✅ Provisioned Concurrency — Good for

Latency-sensitive applications (API responses, real-time processing)
Functions with heavy initialization (Java, loading large ML models)
Predictable traffic patterns (enable during business hours, disable at night)
When consistent response times are required (user-facing APIs)

⚠️ Provisioned Concurrency — Watch out

You pay for provisioned concurrency even when the function isn't invoked
Cost = (provisioned count × duration × per-GB-second rate)
Not needed for batch jobs, background tasks, or tolerant of occasional latency spikes
Use Application Auto Scaling to scale provisioned concurrency up/down with traffic

🎯 Critical Exam Distinction

Reserved Concurrency: Controls MAX concurrent executions. Used to LIMIT a function or GUARANTEE capacity. NO extra cost. Does NOT prevent cold starts.

Provisioned Concurrency: Pre-warms environments. Used to ELIMINATE cold starts. DOES cost extra (even when idle). Provides consistent low-latency responses.

💥 Burst Concurrency — How Lambda Scales

When traffic suddenly spikes, Lambda needs to scale up quickly. But it can't scale infinitely and instantly — there are limits.

Burst Limit

The initial maximum number of concurrent executions Lambda can reach IMMEDIATELY in response to a traffic burst. The burst limit is 3,000 (in most regions). After reaching this burst limit, Lambda can add 500 more concurrent executions per minute until it hits the account concurrency limit.

Lambda Scaling During a Traffic Burst

Normal Traffic~50 concurrent

→

Traffic Spike!10,000 requests/sec

→

Burst to 3,000Immediately

+500/minuteScale continues

→

Hits 3,500After 1 minute

→

Hits account limitThrottling begins

If requests come in faster than Lambda can scale, excess requests are throttled (return HTTP 429). For synchronous invocations (API Gateway), the caller receives a throttle error immediately. For asynchronous invocations (SQS, SNS), Lambda retries automatically.

⚡ Lambda Power Tuning — Find the Optimal Memory

Lambda memory can be set from 128MB to 10,240MB (10GB). More memory = more CPU = faster execution. But more memory = higher per-ms cost. The optimal setting depends on your specific function. Lambda Power Tuning finds it for you automatically.

🛠️ How Lambda Power Tuning Works

1

Deploy Power Tuning Tool

Lambda Power Tuning is an open-source AWS Step Functions state machine. Deploy it to your account (takes 2 minutes via SAM/CloudFormation).

2

Run the State Machine

Provide your function ARN and a list of memory sizes to test (e.g., 128, 256, 512, 1024, 2048, 3008 MB). Also provide a sample event payload.

3

Automated Testing

Power Tuning invokes your function multiple times at each memory configuration. It measures execution time and calculates cost (time × memory price).

4

View Results

Returns a graph showing cost vs performance for each memory setting. You choose: optimize for speed (lowest latency), cost (cheapest), or balanced. Often more memory = faster AND cheaper because the shorter duration more than offsets the higher per-ms cost.

📌 Typical Result

Function tested: Order processing Lambda
128MB: Takes 3400ms → costs $0.0000712 per invocation
512MB: Takes 820ms → costs $0.0000344 per invocation ← cheaper AND faster!
2048MB: Takes 340ms → costs $0.0000286 per invocation ← fastest and cheapest!
Conclusion: The 128MB setting is 52% more expensive AND 10x slower. Increasing memory helps both performance and cost.

🎯 Exam Tip

Lambda Power Tuning answers: "how do I find the optimal memory setting for Lambda?" and "how do I balance cost vs performance for Lambda?". It's NOT the same as Provisioned Concurrency (which eliminates cold starts). Power Tuning is about finding the best memory size; Provisioned Concurrency is about eliminating cold starts.

💡 Lambda Best Practices — Developer Exam Focus

📦 Initialize Outside the Handler

Code at the module level (outside the handler function) runs once when the execution environment is created — not on every invocation. Use this for expensive initialization:

        Python — Best Practice
import boto3
import json

# ✅ GOOD — runs ONCE per execution environment (not every invocation)
dynamodb = boto3.resource('dynamodb')    # create once, reuse
table = dynamodb.Table('OrdersTable')     # create once, reuse

# Load config from SSM Parameter Store once at cold start
ssm = boto3.client('ssm')
config = json.loads(ssm.get_parameter(
    Name='/myapp/config'
)['Parameter']['Value'])

def lambda_handler(event, context):
    # ✅ table and config already initialized — no setup cost here!
    response = table.get_item(Key={'orderId': event['orderId']})
    return response

# ❌ BAD — this creates DynamoDB client on EVERY invocation
def lambda_handler_bad(event, context):
    dynamodb = boto3.resource('dynamodb')    # expensive! runs every time
    table = dynamodb.Table('OrdersTable')
    response = table.get_item(Key={'orderId': event['orderId']})
    return response
      

🔑 Key Lambda Optimization Tips

Optimization	What to Do	Benefit
SDK client initialization	Move outside handler (module level)	Reused across invocations → saves 50-200ms
Database connections	Use RDS Proxy for connection pooling	Prevents connection exhaustion during Lambda scaling
Package size	Only bundle required libraries, use Lambda Layers for common deps	Faster cold starts (less to download)
Memory size	Use Lambda Power Tuning to find optimal	Can reduce both cost and latency simultaneously
Cold starts (critical workloads)	Enable Provisioned Concurrency	Zero cold start latency
Timeout	Set appropriate timeout (not too long)	Faster failure detection, cost control
Concurrent scale protection	Set Reserved Concurrency limits	Protects account-wide concurrency pool