Skilled Coder Blog
Technology Explained

How AWS Lambda (or Serverless) Works

  1. You write a function – like handler(event, context) – and upload it to AWS Lambda (or deploy it using tools like Serverless Framework, SAM, or CDK).

  2. AWS packages your function (code + dependencies) into a deployment bundle and stores it in its infrastructure – usually in an internal S3 bucket.

  3. You set a trigger – this could be an HTTP request (via API Gateway), a message (SQS), a DB update (DynamoDB), a file upload (S3), or a scheduled event (CloudWatch).

  4. When the trigger happens, AWS checks if there’s already a warm execution environment (a container) available for your function.

  5. If not, AWS performs a cold start:

    • a. Creates a secure sandboxed environment (usually a container).
    • b. Downloads and extracts your function code + runtime (Node, Python, Java, etc.).
    • c. Initializes the language runtime and runs your function’s “init” logic (global scope).

  6. AWS then invokes your handler function, passing the event and context.

  7. Your code runs, uses memory/CPU within your configured limits (e.g., 512 MB, 1 vCPU), and must finish within the timeout (default 3 sec, max 15 min for AWS).

  8. If your function calls external services (e.g., S3, DynamoDB), it goes through the Lambda VPC or public internet, depending on config.

  9. Once execution completes:

    • a. AWS returns the result to the caller (e.g., API Gateway returns HTTP response).
    • b. The container is kept warm for a few minutes (to reuse in case of more invocations).

  10. If more requests come in parallel, AWS spins up more containers to scale out – each with its own isolated environment.

  11. AWS handles:

  • a. Auto-scaling (you don’t provision or scale anything).
  • b. Security isolation (each container is sandboxed).
  • c. Monitoring (logs go to CloudWatch).
  • d. Fault tolerance and retries (depending on trigger type).

  1. You pay only for the time your function runs – measured in milliseconds – and for the memory you allocate.

  2. After a while, unused containers are destroyed. If another request comes later → cold start again.

NOTE: The content below is additional technical knowledge and not necessary for basic understanding. Feel free to stop here if you're looking for just the essential process.

AWS Lambda: Technical Deep Dive

Deployment & Packaging

  • Functions are uploaded as deployment packages (ZIP, JAR, or container images).
  • AWS stores these in S3 and manages versioning and rollbacks.
  • You can deploy via AWS Console, CLI, CI/CD, or frameworks (Serverless, SAM, CDK).

Triggers & Event Sources

  • API Gateway: HTTP(S) endpoints for REST/GraphQL APIs.
  • S3: File uploads, deletions, or changes trigger functions.
  • SQS/SNS: Message queues and notifications.
  • DynamoDB Streams: React to DB changes.
  • CloudWatch Events: Scheduled/cron jobs.
  • Other AWS Services: Many AWS services can trigger Lambda.

Cold Starts vs. Warm Starts

  • Cold Start: New container is created, runtime initialized, code loaded. Takes longer (100ms–1s+).
  • Warm Start: Existing container reused. Much faster (few ms).
  • Optimization: Keep functions small, use lighter runtimes, and avoid heavy global initialization.

Execution Environment

  • Each function runs in a secure, isolated container (Firecracker microVMs).
  • Environment variables, IAM roles, and VPC config are injected at startup.
  • Temporary storage (/tmp, up to 512MB) is available per container.

Scaling & Concurrency

  • Lambda automatically scales by running more containers in parallel.
  • Default concurrency limit per account/region (can be increased).
  • Each invocation is independent and stateless.

Monitoring & Logging

  • All logs are sent to CloudWatch Logs automatically.
  • Metrics: invocation count, duration, errors, throttles, concurrency.
  • X-Ray integration for distributed tracing.

Security & Isolation

  • Each container is sandboxed (Firecracker VM isolation).
  • IAM roles control what resources/functions can access.
  • VPC integration for private networking.

Pricing Model

  • Pay per request (number of invocations).
  • Pay for compute time (GB-seconds) and memory allocated.
  • Free tier: 1M requests and 400,000 GB-seconds per month.

Example: Simple AWS Lambda Function (Node.js)

// handler.js
exports.handler = async (event, context) => {
  console.log("Event received:", event);
  return {
    statusCode: 200,
    body: JSON.stringify({ message: "Hello from Lambda!" })
  };
};

When to Use Lambda (and When Not To)

Best for:

  • Event-driven workloads (APIs, file processing, scheduled jobs)
  • Spiky or unpredictable traffic
  • Prototyping and microservices
  • Glue code between AWS services

Not ideal for:

  • Long-running jobs (max 15 min per invocation)
  • Heavy compute or memory workloads
  • Low-latency, high-throughput APIs (cold starts can add latency)
  • Stateful applications (functions are stateless)

Summary

AWS Lambda (and serverless in general) abstracts away server management, scaling, and much of the operational overhead. It’s a powerful tool for building scalable, event-driven applications, but comes with trade-offs around cold starts, execution time, and statelessness. Understanding how Lambda works under the hood helps you design better cloud-native systems.