Updated 26 Aug 2026 • 5 mins read
What Is AWS Lambda? How It Works and What It Costs
AWS Lambda is Amazon's serverless compute service: upload a function, and Lambda runs it in response to events, scales automatically, and bills per request and per millisecond of execution with nothing to pay while idle. This answer-first explainer covers what a function is, how invocation and cold starts work, when to use it, its limits, and the pricing.
AWS Lambda is Amazon's serverless compute service: you upload a function, and Lambda runs it whenever an event tells it to, creating the compute to run it on demand, scaling to thousands of parallel executions without configuration, and billing only for the requests it served and the milliseconds the code ran, with nothing to provision and nothing to pay while idle. A Lambda function is the thing you upload, code plus configuration, and an invocation is one run of it. That is the whole model, and it is why Lambda is both the cheapest compute on AWS for intermittent work and the most surprising at scale.
This explainer answers what Lambda is, what a function is, how invocation, scaling, and cold starts work, when it is the right choice and when it is not, its limits, and what it costs, with rates from the official pricing page as of October 2026. For serverless as a category, see our guide to what serverless computing is; to price a function of your own, our Lambda cost calculator.
The short answer: AWS Lambda is a serverless compute service that runs your code in response to events without servers to manage. You package a function, a handler in Node.js, Python, Java, Go, .NET, Ruby, or a container image, with its memory (128 MB to 10 GB), timeout (up to 15 minutes), and triggers, and Lambda runs it when an event arrives: an HTTP request via API Gateway, an object in S3, a message on SQS, a schedule, a stream. It creates an isolated execution environment on demand (a cold start, tens of milliseconds to a few seconds), reuses it while warm, and scales by creating more, up to account concurrency limits. Pricing in US East is $0.20 per million requests plus $0.0000166667 per GB-second of duration on x86 (20 percent less on Arm), billed per millisecond, with a permanent free tier of 1 million requests and 400,000 GB-seconds a month; a 512 MB function running 200 milliseconds costs about $1.87 per million invocations. It suits event-driven, intermittent, and spiky work and not long-running, steady, or GPU workloads.
What a Lambda Function Is
A Lambda function is a deployment unit with four parts: the code, a handler that receives an event and a context object and returns a result, written in one of Lambda's managed runtimes or packaged as a container image up to 10 GB; the configuration, memory from 128 MB to 10 GB with CPU allocated in proportion, a timeout up to 15 minutes, environment variables, and an IAM execution role that defines what the function may call; the triggers, which are the event sources that invoke it; and optional layers, shared libraries attached to the function. Versions and aliases let you deploy new code and shift traffic gradually. A function is stateless by design: anything it needs to remember between invocations lives in S3, DynamoDB, a database, or a cache.
How Lambda Works
Lambda works by invoking your function in response to an event, in an execution environment it creates and manages.
| Stage | What happens | What it means for you |
|---|---|---|
| 1. Event | A trigger fires: an API Gateway request, an S3 object created, an SQS message, an EventBridge schedule, a DynamoDB or Kinesis stream record, a direct SDK call | Lambda is glue between AWS services; most functions are invoked by other services, not by people |
| 2. Environment | If no warm environment exists, Lambda creates one: downloads the package, starts the runtime, runs initialization code (the cold start). If one is warm, it is reused | Cold starts add latency; keeping initialization small and using provisioned concurrency for latency-sensitive paths manages it |
| 3. Execution | The handler runs with the event as input, up to the timeout, with the memory and CPU configured | Memory sets both performance and the GB-second rate; more memory often finishes faster and can cost the same or less |
| 4. Response | Synchronous invocations return the result to the caller; asynchronous ones queue the event and retry twice on failure; stream and queue sources poll and batch | Retries bill every attempt; failure handling and dead-letter queues matter for cost as well as correctness |
| 5. Scaling | Each concurrent invocation gets its own environment; Lambda adds them as traffic rises, up to the account concurrency limit (1,000 by default, raisable) | Scaling is automatic and bills per invocation; a burst to 5,000 concurrent executions is 5,000 billed durations |
| 6. Teardown | Idle environments are frozen and eventually removed; nothing bills while no invocation runs | The reason Lambda costs nothing idle and the reason state cannot live in the function |
When to Use Lambda, and When Not To
| Use Lambda for | Why | Use containers or servers for | Why |
|---|---|---|---|
| Event-driven processing: files, streams, queues, webhooks | Pays only per event; scales with the event rate | Long-running processes over 15 minutes | Lambda's hard timeout |
| APIs with variable or low traffic | Zero idle cost; scales for spikes | Steady, high-throughput services | Per-millisecond billing exceeds an always-on server above roughly 20 percent continuous utilization |
| Scheduled and periodic jobs | No server waiting between runs | GPU, large memory, or large local state | Lambda caps at 10 GB memory and ephemeral storage, no GPUs |
| Glue between AWS services | Native triggers from most services | Latency-critical paths that cannot tolerate cold starts | Unless provisioned concurrency is affordable |
| Prototypes and internal tools | Minimal operations | Workloads needing persistent connections or sessions | Stateless, short-lived environments |
The cost crossover is the one most teams get wrong in both directions. A function that runs 200 milliseconds a million times a month costs about $2 in Lambda; the same work on the smallest always-on instance costs more. A function configured at 8 GB that runs continuously costs about $350 a month against $70 for an equivalent EC2 instance. Our guide to cloud pricing models treats serverless as a different shape of bill rather than a discount, which is the right way to think about it.
What Lambda Costs
US East, October 2026.
| Line | Rate | Notes |
|---|---|---|
| Requests | $0.20 per million | Every invocation, including failures and retries |
| Duration, x86 | $0.0000166667 per GB-second; tiered down above 6 billion GB-seconds a month | Memory in GB times seconds, per millisecond; includes initialization since August 2025 |
| Duration, Arm (Graviton) | $0.0000133334 per GB-second | 20 percent less; most runtimes run on Arm unchanged |
| Free tier | 1 million requests and 400,000 GB-seconds a month | Permanent |
| Provisioned concurrency | About $0.0000041667 per GB-second kept warm, plus a reduced duration rate | Removes cold starts; bills whether or not invoked |
| Ephemeral storage above 512 MB | $0.0000000309 per GB-second | Up to 10 GB |
| Around the function | API Gateway $1.00 (HTTP) or $3.50 (REST) per million; CloudWatch Logs $0.50 per GB; NAT Gateway $0.045 per GB from a VPC; egress $0.09 per GB | Often larger than the Lambda line |
A function at 512 MB running 200 milliseconds consumes 0.1 GB-seconds per invocation: 10 million invocations a month is 1 million GB-seconds, about $10 of duration after the free tier, plus $1.80 of requests, about $12. The HTTP API in front of it is $10 and its logs about $5, so the function is under half of its own bill, which is the usual pattern and the reason to price the whole path.
Limits That Decide the Architecture
- 15-minute maximum execution time per invocation.
- 128 MB to 10 GB of memory, with CPU allocated in proportion; up to 6 vCPUs at the top.
- 6 MB synchronous and 256 KB asynchronous request and response payloads.
- 10 GB of ephemeral /tmp storage; no persistent local state.
- 250 MB unzipped deployment package, or a 10 GB container image.
- 1,000 concurrent executions per account per region by default, raisable on request; reserved and provisioned concurrency per function.
- No GPUs, no inbound persistent connections, and VPC access requires NAT or endpoints to reach the internet.
How Lambda Compares
| Option | What it is | Billing | Best for |
|---|---|---|---|
| AWS Lambda | Functions run on events | Per request and per GB-second | Event-driven and intermittent work |
| AWS Fargate | Containers without servers | Per vCPU-hour and GB-hour while the task runs | Long-running or steady containers |
| Amazon EC2 | Virtual machines | Per instance-hour | Steady, large, or specialized workloads |
| Azure Functions | Azure's function service | Per execution and GB-second; Premium and Flex plans | Event-driven work on Azure |
| Google Cloud Run functions | Google's function service | Per vCPU-second, GiB-second, and request | Event-driven work on Google Cloud |
How Opslyft Helps
Lambda's bill is the one line that grows with success rather than provisioning, spread across the function, the gateway, the logs, and the network, with no feature named on any of them. Opslyft shows Lambda cost by function, team, and feature beside the API Gateway, CloudWatch, and NAT charges the same workload incurs, so a serverless feature's real cost is one number; to estimate one before you build it, use our AWS Lambda cost calculator.
The Bottom Line
AWS Lambda is compute that exists only while your code runs: a function, a trigger, an execution environment created on demand and billed by the millisecond, scaling from zero to thousands without a server to manage. It is the right choice for event-driven, intermittent, and spiky work, where paying per invocation beats paying for a server that waits, and the wrong choice for long-running, steady, or GPU workloads, where its limits bind and its per-millisecond rate exceeds an always-on instance. Price the whole path, function, gateway, logs, and network, choose memory on measured duration, fix retries before scaling, and keep initialization small. The wider category is in our guide to serverless computing; the container alternative is priced in our Fargate pricing calculator.
FAQs
AWS Lambda is Amazon's serverless compute service: you upload a function, code plus its dependencies in one of the supported runtimes or a container image, and Lambda runs it in response to events, scaling from zero to thousands of concurrent executions automatically and billing only for the requests served and the time the code ran, measured in GB-seconds. There are no servers to provision, patch, or pay for while idle.
A Lambda function is the unit of deployment: your handler code, its runtime (Node.js, Python, Java, Go, .NET, Ruby, or a custom runtime in a container image), its configuration (memory from 128 MB to 10 GB, timeout up to 15 minutes, environment variables, IAM role), and the triggers that invoke it. Each invocation runs in an isolated execution environment that Lambda creates on demand and may reuse for subsequent invocations.
An event, an HTTP request through API Gateway, a file landing in S3, a message on SQS, a schedule, a DynamoDB stream, invokes the function. Lambda provisions an execution environment if none is warm (a cold start), runs the handler with the event as input, returns the result, and keeps the environment warm for a while for the next invocation. Concurrency scales by creating more environments, up to account limits; billing starts when execution begins and, since August 2025, includes the initialization phase.
$0.20 per million requests plus duration at $0.0000166667 per GB-second on x86 ($0.0000133334 on Arm) in US East, billed per millisecond, with a permanent free tier of 1 million requests and 400,000 GB-seconds a month. A function at 512 MB running 200 milliseconds costs about $1.87 per million invocations. Provisioned concurrency, ephemeral storage above 512 MB, and the API Gateway, CloudWatch Logs, and data transfer around the function bill separately.
For event-driven, intermittent, or spiky workloads where paying only while code runs beats paying for an always-on server: API backends with variable traffic, file and stream processing, scheduled jobs, webhooks, glue between AWS services. For steady high-throughput workloads, long-running processes over 15 minutes, or workloads needing GPUs or large local state, containers on Fargate or EC2 are usually cheaper or the only option.
The latency added when Lambda has to create a new execution environment before running your code: downloading the package, starting the runtime, and running initialization code outside the handler. It ranges from under 100 milliseconds for small Node.js and Python functions to several seconds for large Java or container-image functions. Provisioned concurrency keeps environments warm for a per-GB-second fee; SnapStart reduces it for Java and some other runtimes.