Lambda runs your code in response to events without you managing any servers. You upload your code, define what triggers it, and Lambda handles everything else — scaling, patching, infrastructure.
Trigger --> Lambda Function --> Response
Example Triggers:
S3 file uploaded --> Process image, generate thumbnail
API Gateway call --> Handle HTTP request, return JSON
DynamoDB change --> Update search index in OpenSearch
EventBridge rule --> Send daily report email at 9am
SNS message --> Send push notification to mobile app
SQS message --> Process order from queue| Setting | Range | Impact |
|---|---|---|
| Memory | 128MB to 10,240MB | CPU scales proportionally with memory |
| Timeout | 1 second to 15 minutes | Maximum function execution time |
| Concurrency | 0 to thousands | Max simultaneous executions |
| Deployment package | 50MB zip / 10GB container image | Code + dependencies size limit |
A cold start happens when Lambda creates a NEW execution environment — it must download your code and initialise the runtime before executing. This adds latency (100ms to 5 seconds depending on runtime).
| Mitigation | How | When to Use |
|---|---|---|
| Provisioned Concurrency | Pre-warm N containers — always ready | Latency-sensitive production APIs |
| Smaller package | Less to download and initialise | Always — keep dependencies minimal |
| Choose Python/Node.js | Faster cold start than Java | When cold starts matter |
| SnapStart (Java) | Snapshot initialised JVM — restore instead of init | Java Lambda with cold start issues |