Lambda Power Tuning: Find the Exact Memory Size That Minimizes Cost and Latency

Lambda Power Tuning: Find the Exact Memory Size That Minimizes Cost and Latency

Most Lambda functions run at the default 128MB memory, which is almost never the optimal setting. Lambda allocates CPU proportionally to memory — more memory means more CPU, which means faster execution and fewer billable seconds. The optimal memory setting varies wildly by workload. Lambda Power Tuning finds it automatically.

TL;DR: AWS Lambda Power Tuning is an open-source Step Functions state machine that invokes your function at every memory level (128MB–10GB), measures actual cost and duration, and produces a visualization of the exact trade-off curve. Run it once per function and stop leaving money on the table.

Why the CPU-memory relationship matters

// Lambda CPU allocation by memory:
// 128MB  → ~0.08 vCPU
// 512MB  → ~0.32 vCPU
// 1024MB → ~0.64 vCPU
// 1769MB → 1 full vCPU (threshold!)
// 3538MB → 2 vCPUs
// 10240MB → ~6 vCPUs

// Counterintuitive result for CPU-bound code:
// 128MB,  500ms → cost = 128 × 0.5 × $0.0000166667 = $0.00000107/invoke
// 512MB,  120ms → cost = 512 × 0.12 × $0.0000166667 = $0.00000102/invoke
// 512MB is BOTH faster (120ms vs 500ms) AND cheaper than 128MB
// This sweet spot is what Power Tuning finds automatically

Deploy and run Lambda Power Tuning

# Deploy via AWS SAR (easiest — one click):
# https://serverlessrepo.aws.amazon.com/applications/arn:aws:serverlessrepo:us-east-1:451282441545:applications~aws-lambda-power-tuning

# Or via AWS CLI:
aws cloudformation deploy   --template-url https://s3.amazonaws.com/power-tuning/latest/template.yml   --stack-name lambda-power-tuning   --capabilities CAPABILITY_IAM

# Run a test:
aws stepfunctions start-execution   --state-machine-arn arn:aws:states:us-east-1:ACCOUNT:stateMachine:powerTuningStateMachine   --input '{
    "lambdaARN": "arn:aws:lambda:us-east-1:ACCOUNT:function:my-api",
    "powerValues": [128, 256, 512, 1024, 1769, 3008],
    "num": 20,
    "payload": {"httpMethod": "GET", "path": "/users"},
    "parallelInvocation": true,
    "strategy": "balanced"
  }'
# strategy: "cost" | "speed" | "balanced"

Real benchmark results by workload type

# Python REST API (DynamoDB reads, JSON response):
# 128MB  | 312ms | $0.668/1M  → baseline
# 512MB  | 134ms | $0.574/1M  ← SWEET SPOT (balanced)
# 1024MB | 98ms  | $0.841/1M
# Insight: 512MB is faster AND cheaper than 128MB

# Node.js image resizing (CPU-intensive sharp library):
# 128MB  | 4200ms | $9.00/1M
# 1769MB | 340ms  | $2.13/1M  ← SWEET SPOT (1 full vCPU threshold)
# 3008MB | 320ms  | $2.48/1M
# Insight: CPU-bound work needs exactly 1769MB for sweet spot

# Python ML inference (scikit-learn):
# 128MB  | 2100ms | $4.50/1M
# 1769MB | 248ms  | $3.20/1M  ← cheapest AND fastest
# Insight: ML hits the vCPU threshold hardest

Power tuning in CI/CD — automate for every deploy

# GitHub Actions workflow:
- name: Run Lambda Power Tuning
  run: |
    EXEC=$(aws stepfunctions start-execution       --state-machine-arn $POWER_TUNING_ARN       --input '{"lambdaARN":"$FUNCTION_ARN","powerValues":[128,512,1024,1769],"num":10,"strategy":"balanced"}'       --query executionArn --output text)
    
    # Wait for completion
    while [ "$(aws stepfunctions describe-execution --execution-arn $EXEC --query status -o text)" = "RUNNING" ]; do
      sleep 10
    done
    
    # Get optimal memory recommendation
    aws stepfunctions get-execution-history --execution-arn $EXEC       --query 'events[-1].executionSucceededEventDetails.output'
  • ✅ Always run Power Tuning after major code changes — the optimal memory changes with the workload
  • ✅ Run separately for ARM64 and x86 — optimal memory differs between architectures
  • ✅ Use “balanced” strategy for most APIs, “speed” for latency-sensitive, “cost” for batch jobs
  • ✅ Run with realistic payloads — cold start warm-up affects results
  • ❌ Never trust the default 128MB without testing — it is almost never optimal

Run Power Tuning after switching to ARM64 Graviton3 — the optimal memory level changes between architectures. For Java functions, tune after enabling SnapStart since restore overhead shifts the curve. Official reference: AWS Lambda Power Tuning on GitHub.

Master AWS Lambda

AWS Solutions Architect Course on Udemy — The most comprehensive AWS course covering Lambda, serverless patterns, and production architecture.

AWS Certified Solutions Architect Study Guide — Deep Lambda chapter covering cold starts, VPC, layers, and SnapStart.

Sponsored links. We may earn a commission at no extra cost to you.


Discover more from CheatCoders

Subscribe to get the latest posts sent to your email.

Comments

No comments yet. Why don’t you start the discussion?

Leave a Reply