AWS Lambda¶

Introduction¶

AWS Lambda is a serverless compute service that runs code in response to events and automatically manages the underlying compute resources. You pay only for the compute time consumed.

Key Features¶

No servers to manage - Focus on code, not infrastructure
Automatic scaling - Scales from zero to thousands of concurrent executions
Pay per use - Charged per request and compute duration
Event-driven - Triggered by AWS services or HTTP requests
Multiple runtimes - Python, Node.js, Java, Go, Ruby, .NET, custom runtimes

When to Use¶

Ideal Use Cases¶

API backends - Via API Gateway or Function URLs
Data processing - S3 uploads, Kinesis streams, DynamoDB streams
Scheduled tasks - Cron jobs via EventBridge
Real-time file processing - Image resizing, video transcoding
IoT backends - Process IoT device data
Chatbots - Lex fulfillment
Automation - Infrastructure automation, CloudWatch alarms response

Signs Lambda is Right for You¶

Workloads are event-driven
Traffic is variable or unpredictable
You want to minimize operational overhead
Execution time is under 15 minutes
You need rapid scaling from zero

Execution Model¶

Invocation Types¶

Type	Description	Use Case
Synchronous	Wait for response	API Gateway, direct invoke
Asynchronous	Fire and forget	S3, SNS, EventBridge
Event Source Mapping	Poll-based	SQS, Kinesis, DynamoDB Streams

Cold Start vs Warm Start¶

Lambda Cold vs Warm Start

What to Be Careful About¶

Limits and Constraints¶

Execution timeout - Max 15 minutes
Memory - 128 MB to 10,240 MB
Package size - 50 MB zipped, 250 MB unzipped (layers included)
Concurrent executions - 1,000 default (can be increased)
Payload size - 6 MB sync, 256 KB async
/tmp storage - 512 MB to 10,240 MB

Cost Management¶

Invocation costs - $0.20 per 1M requests
Duration costs - Based on memory allocation and time
Over-provisioned memory - Paying for unused memory
Unnecessary invocations - Ensure proper error handling to avoid retries
Provisioned concurrency - Costs even when not used

Cold Starts¶

VPC Lambda - Longer cold starts (though improved with Hyperplane ENIs)
Large packages - More code = longer cold start
Heavy initialization - SDK/database connections in init phase
Mitigation - Provisioned Concurrency, keep functions warm

Security¶

IAM execution role - Follow least privilege
Environment variables - Use KMS encryption for secrets
VPC considerations - No internet access without NAT Gateway
Resource policies - Control who can invoke your function

Architecture¶

Stateless - Don't rely on local state between invocations
Idempotency - Functions may be invoked multiple times
Timeout handling - Graceful handling of approaching timeout
Dead letter queues - Configure for async failures

Key Components¶

Layers¶

Reusable code/libraries across functions
Up to 5 layers per function
Reduce deployment package size
Share common dependencies

Versions and Aliases¶

Version - Immutable snapshot of function code and config
Alias - Pointer to a version (e.g., "prod" → v5)
Traffic shifting - Weighted aliases for canary deployments

Destinations¶

Configure where results go for async invocations: - On Success: SQS, SNS, Lambda, EventBridge - On Failure: SQS, SNS, Lambda, EventBridge

Environment Variables¶

Key-value pairs available to function
Can be encrypted with KMS
Max 4 KB total size

Pricing Model¶

Component	Cost
Requests	$0.20 per 1 million requests
Duration	$0.0000166667 per GB-second
Provisioned Concurrency	$0.000004646 per GB-second
Free Tier	1M requests, 400,000 GB-seconds/month

Example: 1M invocations, 1 GB memory, 200ms average - Requests: $0.20 - Duration: 1M × 0.2s × 1GB × $0.0000166667 = $3.33 - Total: ~$3.53/month

Common Interview Questions¶

How do you handle Lambda cold starts?
Use Provisioned Concurrency for consistent latency
Keep initialization code outside handler
Use smaller deployment packages
Choose faster runtimes (Node.js, Python vs Java)
Avoid VPC if not necessary
How do you make Lambda functions secure?
Least privilege IAM execution role
Encrypt environment variables with KMS
Use Secrets Manager for sensitive data
Enable X-Ray for tracing
Use VPC for private resource access
What's the difference between sync and async invocation?
Sync: Caller waits for response, errors returned immediately
Async: Fire and forget, Lambda handles retries (2 times), use DLQ
How does Lambda scale?
Automatic scaling based on concurrent requests
Each instance handles one request at a time
Burst capacity of 500-3000 (region dependent)
After burst, scales at 500 instances/minute
How do you share code between Lambda functions?
Lambda Layers for shared libraries
Deploy common code as a layer
Each function can use up to 5 layers

Alternatives¶

AWS Alternatives¶

Service	When to Use Instead
EC2	Long-running processes, full OS control
Fargate	Containerized workloads, longer execution
App Runner	Containerized web services
Step Functions	Complex workflows orchestrating multiple Lambdas
Batch	Large-scale batch computing jobs

External Alternatives¶

Provider	Service
Google Cloud	Cloud Functions, Cloud Run
Azure	Azure Functions
Cloudflare	Workers
Vercel	Serverless Functions

Best Practices¶

Keep functions focused - Single responsibility
Minimize package size - Faster cold starts
Reuse connections - Initialize SDK clients outside handler
Use environment variables - Don't hardcode configuration
Set appropriate timeout - Don't use max unless needed
Right-size memory - More memory = more CPU
Enable X-Ray - Distributed tracing
Use structured logging - JSON format for CloudWatch Insights
Implement idempotency - Handle duplicate invocations
Monitor with CloudWatch - Alarms on errors, duration, throttles

Event Sources¶

Source	Invocation Type	Notes
API Gateway	Sync	REST/HTTP APIs
S3	Async	Object events
DynamoDB Streams	Event Source Mapping	Table changes
Kinesis	Event Source Mapping	Stream processing
SQS	Event Source Mapping	Queue processing
SNS	Async	Pub/sub messages
EventBridge	Async	Scheduled/event rules
CloudWatch Logs	Async	Log subscriptions
Cognito	Sync	Auth triggers
ALB	Sync	Load balancer target