AWS Lambda

What AWS Lambda actually is

AWS Lambda is the service that started the serverless category: announced at re:Invent on November 13, 2014 as a preview that ran your code in response to events with no server to size or patch, and generally available since April 2015. You upload a function, connect it to triggers, and AWS provisions, scales, patches and retires execution environments on its own. You are billed for requests and compute time, nothing while idle.

A decade on, "Lambda" covers several form factors. Lambda Event Functions is the classic model — event-driven functions billed per request and GB-second, with memory from 128 MB to 10,240 MB in 1 MB increments and proportional CPU. Lambda Web Functions targets HTTP APIs with multi-concurrency across warm execution environments (fewer cold starts) and active-CPU billing — you pay for compute time rather than wall-clock duration, which changes the arithmetic for I/O-bound handlers waiting on databases. Lambda MicroVMs offer VM-level isolation billed per instance-second, and Lambda Managed Instances let you run current-generation EC2 instance types under the Lambda programming model with EC2 Savings Plans plus a management fee (the pricing page's example: 15% of the instance rate). Durable functions, tenant isolation mode and SnapStart round out a platform that has grown well past "run this on S3 upload."

Managed runtimes cover Node.js (22/24/26), Python (3.10 through 3.15), Java (8 through 25), .NET (8/9/10), Ruby (3.3 through 4.0), plus an OS-only runtime and container image support for anything else — comfortably past the "15+ runtimes" our database claimed, and far past the Node.js-only preview. Triggers span S3, DynamoDB, SQS, Kinesis, Kafka, API Gateway, EventBridge and more. Deployment tooling is mature: SAM, the CDK, Terraform, container images up to 10 GB, and CI/CD pipelines that treat a function as a build artifact rather than a server to configure. For a small team, that deployment story is half the value.

The second half is what you stop doing: no AMI hygiene, no patch Tuesdays, no capacity planning for a traffic spike, no paying for a dev server that answers a hundred requests a day. In our view the honest framing of Lambda's price is that you are buying back operations time; the metered compute is often the smaller half of the trade.

Triggers span S3, DynamoDB, SQS, Kinesis, Kafka, API Gateway, EventBridge and more.

Pricing: what you really pay

The classic meter is two numbers. Requests: $0.20 per million. Compute: $0.0000166667 per GB-second on x86, $0.0000133334 per GB-second on Graviton (Arm) — the Arm discount is roughly 20% for the same memory allocation. The free tier includes one million requests and 400,000 GB-seconds per month. Ephemeral storage beyond the included 512 MB runs $0.0000000309 per GB-second.

AWS's own worked example is the cleanest reality check in any serverless pricing page: three million requests per month, 120 ms average duration, 1,536 MB allocated, x86. That is 540,000 GB-seconds, minus 400,000 free, leaving 140,000 billable GB-seconds at $2.33, plus two million billable requests at $0.40 — $2.73 per month total. For spiky or low-volume workloads, nothing in this batch of tools beats that.

Where the arithmetic changes: sustained high volume. The same pricing page walks through a 100-million-request API on Lambda Managed Instances — $20/month in request charges, $91.40 in instance charges under a three-year Compute Savings Plan, plus a $48.96 management fee. And a steady always-on workload that never idles will generally cost more on Lambda than on a right-sized EC2 instance or VPS; the product is priced for variable load. Per-millisecond billing (1 ms granularity after the 60-second minimum invocation... Lambda bills per ms with a 1 ms minimum) makes short runs honest. Provisioned concurrency and SnapStart add paid levers for cold-start-sensitive workloads; we would rather pay for provisioned concurrency than apologize for latency.

Performance & infrastructure

Lambda runs in every AWS region — 124 Availability Zones across 39 geographic regions — and spreads automatically across AZs within a region. There is no capacity planning: the platform scales from a few requests per day to thousands per second, and concurrency limits (account-level, raisable) are the only throttle you configure. Memory allocation drives CPU share, so "tuning" a Lambda means choosing memory and measuring, not picking instance types — and for most functions, slightly more memory means proportionally more CPU and a lower duration bill.

We have not benchmarked Lambda against Cloudflare Workers or Google Cloud Functions in our /benchmarks runs, so we keep performance claims at the architectural level. What we can say from operating it: performance is generally a function of your initialization code and memory choice, not of the platform, and the biggest wins we see come from trimming dependencies and raising memory until the duration bill falls faster than the GB-second bill rises. What is well documented: cold starts remain the characteristic trade-off — language runtime startup plus your initialization code can add hundreds of milliseconds to several seconds (Java and .NET on the slow end, Node.js and Python on the fast end), mitigated by provisioned concurrency, SnapStart, Web Functions' multi-concurrency, or just steady traffic that keeps environments warm. The 99.95% SLA is per-region, with service credits of 10%, 25% or 100%, which is a reasonable commitment for a managed platform that already hides the servers.

Where it falls short

Cost at scale is the first honest complaint, and AWS agrees — it built Savings Plans and Managed Instances precisely because customers outgrew pure per-request pricing. If your workload runs 24/7 at high utilization, Lambda's GB-second rate is expensive against committed compute; the right migration point is a real architectural decision, not a footnote.

The second is operational opacity. When a function throttles, errors, or times out, you are reading CloudWatch logs and X-Ray traces across ephemeral execution environments; debugging distributed event chains (a DynamoDB stream into a Lambda into an SQS queue into another Lambda) takes tooling and discipline. Cold starts are real, they are uneven across runtimes, and provisioned concurrency — the clean fix — is an extra meter.

Third, lock-in. Event source mappings, IAM invocation policies, Step Functions orchestration and Lambda-specific configuration are deeply AWS-shaped. Porting a nontrivial Lambda architecture to another cloud means re-writing the event plumbing, not the functions. And as the form factor list grows (Event Functions, Web Functions, MicroVMs, Managed Instances), the pricing model gets harder to explain to finance — the opposite of what "serverless" promised.

Security and isolation have improved but deserve reading. IAM governs every invocation path, environment variables can be encrypted with KMS, and tenant isolation mode now gives per-tenant execution environments (billed per environment creation) for multi-tenant SaaS running untrusted code. MicroVMs go further with no shared kernel between tenants. That said, the shared-responsibility line is still yours: dependency hygiene in a Lambda bundle, least-privilege IAM policies, and secrets management are the common failure points we see.

Finally, execution limits are real: a 15-minute maximum execution time and payload limits mean Lambda is wrong for long-running jobs. Durable functions address some of this now, but batch workloads still belong on containers or EC2.

Who should pick this

Our pick for event-driven workloads with variable traffic: webhooks, image and document processing, scheduled jobs, API backends behind API Gateway, IoT ingestion, and glue between AWS services. It is also the right default for small teams that would rather write handlers than operate infrastructure — the free tier covers prototypes and small products outright, and the $2.73/month example is a real workload.

We would pick Graviton (Arm) functions by default where the language allows it — the per-GB-second rate is meaningfully lower and most runtimes are Arm-clean. And we would pick Web Functions for HTTP APIs that need multi-concurrency and active-CPU billing.

We would not pick Lambda for steady high-utilization compute (price it against EC2 with a Savings Plan first), for long-running or GPU workloads, or for teams without AWS debugging habits. In our view it is at its best as part of an AWS-native architecture, not as a generic compute substitute.

Key takeaways

• The original FaaS, launched November 13, 2014 (preview) at re:Invent; billed per request and compute time with zero idle cost.
• $0.20 per million requests plus $0.0000166667 per GB-second (x86) or $0.0000133334 (Graviton); free tier of 1M requests and 400,000 GB-seconds monthly.
• AWS's own example: 3M requests/month at 120 ms and 1,536 MB costs $2.73/month — unmatched for spiky workloads.
• SLA 99.95% per region (10/25/100% service credits); runs across 124 AZs in 39 regions with automatic multi-AZ spreading.
• Now three form factors (Event Functions, Web Functions with active-CPU billing, MicroVMs) plus Managed Instances with EC2 pricing options.
• Cold starts, 15-minute execution limits and per-request costs at scale are the real boundaries — steady workloads belong on committed compute.

Sources

• https://aws.amazon.com/lambda/pricing/
• https://aws.amazon.com/lambda/sla/
• https://aws.amazon.com/lambda/
• https://docs.aws.amazon.com/lambda/latest/dg/lambda-runtimes.html
• https://aws.amazon.com/about-aws/global-infrastructure/
• https://aws.amazon.com/shield/pricing/
• https://press.aboutamazon.com/2014/11/amazon-web-services-announces-aws-lambda
• https://en.wikipedia.org/wiki/Amazon_Web_Services