Skip to content

Lambda

1. Why This Service Exists (The Real Problem)

The Problem: I just want to run a 10-line Python script to resize an image when it's uploaded. - Server Overhead: I have to launch an EC2, patch Linux, install Python, keep it running 24/7 (paying $10/mo) just for a script that runs for 1 second a day. - Waste: 99.99% of the CPU cycles are idle.

The Solution: "Serverless" Compute. You upload the code. AWS runs it only when triggered. You pay $0.0000002.

2. Mental Model (Antigravity View)

The Analogy: The Uber Driver vs Owning a Car. - EC2: Buying a car (You pay insurance/gas whether you drive or not). - Lambda: Uber/Lyft (You pay strictly for the distance and time of the trip. No trip = $0).

One-Sentence Definition: An event-driven compute service where you run code without provisioning or managing servers.

3. Core Components (No Marketing)

  1. Function: Your code + dependencies (ZIP file or Docker Image).
  2. Trigger: What starts the code? (e.g., S3 Upload, API Gateway Request, DynamoDB Insert, Cron Job).
  3. Handler: The entry point function (e.g., def lambda_handler(event, context):).
  4. Runtime: The language environment (Python 3.9, Node.js 18, Java 11).
  5. Layers: Shared libraries (e.g., pandas, numpy) that multiple functions can use, so you don't have to zip them every time.

4. How It Works Internally (Simplified)

  1. Cold Start:
    • Event arrives.
    • AWS finds a free worker slot.
    • It downloads your code (from S3).
    • It starts a microVM (Firecracker).
    • It initializes the runtime.
    • It runs your handler. (Latency: 100ms - 2s).
  2. Warm Start:
    • The next event arrives 1 second later.
    • The microVM is already running.
    • It runs your handler immediately. (Latency: 5ms).
  3. Scale Out:
    • 1000 events arrive simultaneously.
    • AWS spins up 1000 separate microVMs in parallel. (Concurrency).

5. Common Production Use Cases

  • REST APIs: API Gateway -> Lambda -> DynamoDB. (The "Serverless Stack").
  • File Processing: User uploads photo to S3 -> Lambda triggers -> Resizes thumbnail -> Saves to S3.
  • Glue Code: "If CloudWatch Alarm triggers, run Lambda to post to Slack."
  • Cron Jobs: EventBridge (Scheduler) -> Lambda runs every night at 3 AM to clean up DB.

6. Architecture Patterns

The "Fan-Out" Pattern

Don't process 10,000 items in a single Lambda (it will timeout after 15 mins). Do Fan-Out.

Architecture: 1. Source: S3 Bucket with 1GB CSV file. 2. Lambda 1 (Dispatcher): Reads CSV, splits into 1000 chunks, pushes messages to SQS. 3. SQS Queue: Buffers the work. 4. Lambda 2 (Worker): Scales up to 50 concurrent instances, each processing one message from SQS.

The "Saga Pattern" (Orchestration)

Don't chain Lambdas (Lambda A calls Lambda B calls Lambda C). This is brittle and hard to debug. Do use Step Functions. - Step Functions creates a state machine visualizer (Start -> Task A -> Choice -> Task B or C -> End).

7. IAM & Security Model

  • Execution Role: The IAM Role the Lambda assumes when it runs. If your code reads from S3, this Role needs s3:GetObject.
  • Resource Policy: Who is allowed to invoke the Lambda? (e.g., "Allow S3 to call this function").

8. Cost Model (Very Important)

  • Requests: $0.20 per 1 million requests. (Dirt cheap).
  • Duration: Price per GB-second. (Running 1GB RAM for 1 second costs $X).
  • Ephemeral Storage: /tmp directory storage (512MB free, pay for more).

Cost Trap: - Recursive Loops: S3 Upload -> Triggers Lambda -> Lambda writes to same S3 Bucket -> Triggers Lambda... -> $10,000 bill in 24 hours. Always use different buckets for Input and Output.

9. Common Mistakes & Anti-Patterns

  • The "Monolith" Lambda: Putting your entire Django/Express app in one function.
    • Why bad: huge cold starts, hard to debug, breaks the "single responsibility" principle.
  • DB Connections: Opening a new Connection mysql.connect() inside the handler.
    • Why bad: 1000 concurrent Lambdas = 1000 DB connections = DB crashes.
    • Fix: Initialize connection outside the handler (Global scope) to reuse it in Warm starts, or use RDS Proxy.
  • Heavy Computation: Using Lambda to train ML models or process video (Long running). use EC2/Fargate or AWS Batch. Lambda times out at 15 minutes hard limit.

10. When NOT to Use This Service

  • Long Running Tasks: Any process > 15 minutes.
  • Predictable High Load: If you have constant 10k requests/sec 24/7, EC2/Fargate is cheaper than Lambda.
  • Low Latency (HFT): If you need < 5ms guaranteed latency, cold starts will kill you.

11. Interview-Level Summary

  • Timeout: What is the max duration? 15 Minutes.
  • Concurrency: How many run at once? Default 1000 per region (Soft limit, can raise).
  • Cold Start: What is it? Initialization of the container. VPNs/Java make it slower.
  • VPC: Does Lambda run in VPC? By default NO (access to internet, but not private RDS). You must attach it to VPC to reach private subnet resources.