2.1.1. AWS Lambda Fundamentals

💡 First Principle: What if you could write a function, deploy it, and never think about the server running it? Lambda inverts the traditional model — instead of provisioning capacity and waiting for requests, your code only exists when an event triggers it. This means you reason about functions and events, not instances and scaling policies.

Loading diagram...

Lambda runs your code in response to events — an API call, a file upload, a database change — and disappears when the work is done. No idle servers, no capacity planning, no patching.

• Execution Model: Code runs in response to events (e.g., S3 object creation, API Gateway request, DynamoDB stream changes).
• Serverless: No servers to provision, manage, or patch. AWS handles underlying infrastructure.
• Pay-per-use: Billed per invocation and compute duration (GB-seconds). No cost when idle.
• Automatic Scaling: Scales automatically to handle traffic spikes.
• Execution Environment: Lambda provides a secure and isolated environment for your code, including runtime support for popular languages (Node.js, Python, Java, C#, Go, Ruby, PowerShell).

Scenario: You need to build a backend service that runs a piece of code only when a specific event occurs, such as a new file being uploaded to an Amazon S3 bucket. You want to avoid provisioning and managing servers for this task.

⚠️ Exam Trap: Lambda's 15-minute timeout is a maximum, not a default. The default is 3 seconds. If a question describes a function timing out, check whether the configured timeout is sufficient before looking at code issues.