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.
