AWS Lambda – The Complete Guide to Serverless Functions (2026)

AWS Lambda introduced the idea of serverless computing to the mainstream: you write a function, AWS runs it on demand, and you never think about a server again. There is nothing to provision, patch, or scale — Lambda spins up compute when an event arrives, runs your code, and charges you only for the milliseconds it executes. When traffic spikes, it scales out automatically; when nothing is happening, you pay nothing.

This model has reshaped how modern applications are built. APIs, file-processing pipelines, scheduled jobs, real-time stream processors, and "glue" automation between AWS services are increasingly built on Lambda because it removes an entire category of operational work. But serverless also has its own rules — cold starts, time and size limits, and a stateless execution model — that you need to understand to use it well.

This guide is a complete, practical tour of Lambda: how it works under the hood, the events that trigger it, how to write and deploy functions, manage dependencies and configuration, control concurrency and cost, monitor in production, and design real architectures around it.

What Is AWS Lambda?

Lambda is a function-as-a-service (FaaS) platform. You upload a small unit of code — a handler — and tell Lambda what event should trigger it. When that event occurs, Lambda provisions a managed, isolated execution environment, runs your handler, and then keeps the environment warm for a while in case another event arrives. You are billed per request and per millisecond of execution, rounded to the nearest millisecond.

Crucially, Lambda is stateless: you should never rely on data persisting in memory or on disk between invocations. Persistent state belongs in services like S3, DynamoDB, or RDS.

How Lambda Works: The Execution Environment

When an event triggers your function, Lambda needs a place to run it. If a warm environment is available, it reuses it (a warm start). If not, it creates a fresh one — downloading your code, starting the runtime, and running any initialization (a cold start), which adds latency of tens to a few hundred milliseconds.

This is why you should initialize expensive resources — database connections, SDK clients, ML models — outside the handler, in the global scope. They are then reused across invocations on the same warm environment, dramatically improving performance.

Supported Runtimes

Lambda natively supports Python, Node.js, Java, Go, Ruby, and .NET. You can also run any other language using a custom runtime or by packaging your function as a container image (up to 10 GB), which is popular for large dependencies and ML workloads.

Anatomy of a Lambda Handler (Python)

Every Lambda has a handler function that receives two arguments: event (the input payload, shaped by whatever triggered it) and context (runtime info like the request ID and remaining time).

# file: app.py
import json

# Runs ONCE per cold start - reuse across warm invocations
print("cold start: initializing")

def lambda_handler(event, context):
    name = event.get("name", "World")
    return {
        "statusCode": 200,
        "body": json.dumps({"message": f"Hello, {name}!"}),
    }

Event Sources and Triggers

Lambda's power comes from how many AWS services can invoke it:

• Amazon API Gateway — turn a function into an HTTP/REST endpoint (serverless backends).
• Amazon S3 — run code when an object is uploaded (e.g. generate thumbnails).
• Amazon DynamoDB Streams / Kinesis — process data changes and event streams in real time.
• Amazon SQS / SNS — process queued messages and notifications.
• Amazon EventBridge — scheduled (cron) jobs and event-driven automation.

Deploying a Lambda Function

There are several ways to deploy: the Console editor (for tiny functions), a zip archive, a container image, or infrastructure-as-code (AWS SAM, CDK, Terraform) for real projects. Here's the zip + CLI flow:

# Package the code
zip function.zip app.py

# Create the function (needs an IAM execution role)
aws lambda create-function \
  --function-name hello \
  --runtime python3.12 \
  --handler app.lambda_handler \
  --timeout 10 \
  --memory-size 256 \
  --zip-file fileb://function.zip \
  --role arn:aws:iam::123456789012:role/lambda-exec-role

# Update code later
aws lambda update-function-code \
  --function-name hello --zip-file fileb://function.zip

# Invoke
aws lambda invoke --function-name hello \
  --payload '{"name": "Tushar"}' --cli-binary-format raw-in-base64-out out.json
cat out.json

Output:

{"statusCode": 200, "body": "{\"message\": \"Hello, Tushar!\"}"}

Dependencies and Layers

Need third-party libraries? Two options: bundle them into your deployment zip, or use a Lambda layer — a shared package of dependencies you attach to multiple functions. Layers keep your function packages small and let teams reuse common libraries. A function can use up to five layers, and the total unzipped size (code + layers) must stay under 250 MB.

Configuration: Environment Variables and Secrets

Pass configuration through environment variables rather than hard-coding it. For sensitive values (database passwords, API keys), store them in AWS Secrets Manager or SSM Parameter Store and fetch them at runtime — never commit secrets in code.

Key Limits to Know

• Timeout: maximum 15 minutes per invocation.
• Memory: 128 MB to 10,240 MB — CPU scales proportionally with memory, so more memory can mean faster and cheaper.
• Deployment package: 50 MB zipped (direct upload), 250 MB unzipped; up to 10 GB as a container image.
• /tmp ephemeral storage: 512 MB by default, configurable up to 10 GB.
• Default concurrency: 1,000 concurrent executions per account (can be increased on request).

Concurrency: Reserved and Provisioned

Lambda scales automatically, but you can shape it. Reserved concurrency caps how many instances a function can use (protecting downstream databases from being overwhelmed). Provisioned concurrency keeps a set number of environments pre-warmed, eliminating cold starts for latency-sensitive APIs — at an extra cost.

Pricing Model (in detail)

You pay for two things: the number of requests and the compute duration measured in GB-seconds (memory allocated × execution time). Because CPU scales with memory, a function with more memory can finish faster and sometimes cost less overall — so it's worth tuning the memory setting. The generous Free Tier includes 1 million requests and 400,000 GB-seconds per month, enough to run many small workloads at no cost.

Monitoring and Debugging

Every Lambda automatically streams logs to Amazon CloudWatch Logs — anything you print() ends up there. CloudWatch also tracks invocations, errors, duration, and throttles as metrics. For tracing across services (e.g. API Gateway → Lambda → DynamoDB), enable AWS X-Ray to see where time is spent.

Real-World Architectures

• Serverless REST API — API Gateway → Lambda → DynamoDB, with no servers to manage and pay-per-request scaling.
• Image pipeline — user uploads to S3 → S3 event triggers Lambda → Lambda creates thumbnails and writes them back.
• Scheduled cleanup — EventBridge cron → Lambda deletes stale records nightly.
• Stream processing — Kinesis/DynamoDB Streams → Lambda aggregates events in real time.

Lambda vs EC2 vs Fargate

A frequent question is which compute service to pick. The three sit on a spectrum from most-managed to most-control:

• Lambda — event-driven, sub-15-minute tasks with zero server management and pay-per-millisecond billing. Best for APIs, automation, and spiky or unpredictable workloads.
• AWS Fargate — run containers without managing servers, with no 15-minute limit. Best for long-running services and existing containerized apps that still want serverless operations.
• EC2 — full control over the operating system and the cheapest option for steady, high-utilization workloads. Best when you need custom software, GPUs, or predictable always-on compute.

Many real systems use all three: Lambda for glue and APIs, Fargate for services, and EC2 for specialized or cost-sensitive compute.

Versions, Aliases, and Safe Deployments

Lambda supports immutable versions (a numbered snapshot of your code and configuration) and aliases (a movable pointer like prod or staging that targets a version). Aliases enable safe rollouts: you can shift a percentage of traffic to a new version (canary/weighted deployment) and roll back instantly by repointing the alias if errors spike. Tools like AWS SAM and CodeDeploy automate this gradual, low-risk release process.

Best Practices

• Initialize clients and connections outside the handler to benefit from warm starts.
• Keep functions small and single-purpose.
• Grant the least-privilege IAM role each function needs.
• Use provisioned concurrency for user-facing latency-sensitive endpoints.
• Set sensible timeouts and use dead-letter queues for failed async events.

Common Mistakes to Avoid

• Trying to run long jobs — anything over 15 minutes needs Step Functions, Fargate, or EC2.
• Heavy initialization inside the handler — move it to global scope.
• Ignoring cold starts on latency-critical paths.
• Over-broad IAM permissions — scope each role tightly.
• Database connection storms — thousands of concurrent Lambdas can exhaust a database; use RDS Proxy or reserved concurrency.

Frequently Asked Questions

What language should I use? Python and Node.js have the smallest cold starts and richest ecosystem for Lambda; Java/.NET are fine but cold-start heavier.

How do I reduce cold starts? Use provisioned concurrency, keep the package small, and choose a lightweight runtime.

Can Lambda call other AWS services? Yes — via the SDK, using its IAM execution role for permissions.

Is Lambda always cheaper? For spiky or low-volume workloads, usually. For steady high-throughput compute, a right-sized EC2/Fargate setup can be cheaper.

Summary Table

Reference

This article follows the official AWS documentation. Read the full reference here: AWS Lambda documentation.

Conclusion

Lambda lets you ship logic without ever managing a server: write a handler, attach an event source, and it scales and bills by the millisecond. The art of using it well lies in respecting its stateless model and limits, minimizing cold starts, scoping permissions tightly, and pairing it with the right event sources and data stores. For event-driven workloads, APIs, and automation, it is one of the most productive tools in the entire cloud.