AWS · Amazon Web Services

What Is AWS Lambda? Serverless Computing Explained (2026)

Last verified: June 17, 2026  ·  Format: Breakdown

AWS Lambda is a serverless compute service that runs your code without you provisioning or managing any servers, and you pay only for the number of requests and the compute duration. If you have been asking what AWS Lambda is in practical terms, picture a single function that sits idle at no cost, wakes up the instant an event arrives, runs your code, and then goes quiet again. There is no virtual machine to size, patch, or keep running, and there is no charge while nothing is happening. That event-driven, pay-per-use model is what makes Lambda one of the defining building blocks of AWS serverless architecture.

This breakdown is plain and practical. We start with what Lambda actually is, explain how the serverless model works, walk through the events that trigger functions and the runtimes they support, lay out the request and GB-second pricing alongside the free tier, and close with when Lambda is the right tool. Pricing and service details below are drawn from AWS documentation and were checked on June 17, 2026; always confirm current figures on the AWS site before you commit. For the bigger picture, see our what is AWS overview, which places Lambda inside the wider AWS catalog.

What AWS Lambda Is

AWS Lambda is AWS's flagship serverless compute service. In plain terms, you upload a unit of code (a function), tell Lambda what should trigger it, and AWS takes care of everything underneath: the servers, the operating system, the scaling, and the availability. You do not rent a machine by the hour the way you would with a virtual server. Instead, Lambda runs your function on demand, scales automatically as more events arrive, and charges you only for the requests it handles and the time your code actually runs.

Two ideas define Lambda. First, it is event-driven: a function does nothing until something happens (a file lands in storage, a request hits an API, a message arrives on a queue), and then it runs in response to that event. Second, it is serverless: there are no servers for you to provision or manage, so the operational work of capacity planning and patching is Amazon's, not yours. You control how much memory a function gets (configurable from 128 MB to 10,240 MB in 1 MB increments, with CPU scaling alongside memory), and AWS handles the rest.

It helps to place Lambda next to the alternative. With Amazon EC2 you rent a virtual server you control down to the operating system, and you pay for it while it is running whether or not it is busy. With Lambda there is no always-on machine: the function exists, costs nothing when idle, and bills only when it runs. If you want the standards-body framing behind the whole on-demand, metered model, our what is cloud computing guide covers the foundations Lambda is built on.

How the Serverless Model Works

The word "serverless" does not mean there are no servers. It means you never see, size, or manage them. Behind the scenes AWS runs your code on its own fleet, spinning up an execution environment when an event arrives and tearing it down when it is no longer needed. From where you sit, the unit you reason about is the function and the event that triggers it, not the machine it runs on.

A Lambda function has a simple life cycle. An event source (an API call, a new object in storage, a message on a queue) invokes the function. AWS allocates an execution environment with the memory you configured, runs your code, and returns or routes the result. If many events arrive at once, Lambda runs many copies of your function in parallel, scaling out automatically without you adding capacity. When the events stop, the function goes idle and you stop paying for compute.

That model has direct consequences for how you design and budget. Because functions are short-lived and stateless by default, persistent data belongs elsewhere, often in object storage such as Amazon S3 or a managed database, with the function acting as the glue between events and stored state. And because billing tracks the compute duration your code uses, efficient functions that finish quickly cost less. AWS rounds duration up to the nearest 1 ms, so the time your code runs is measured finely rather than in coarse blocks.

AWS Lambda Triggers and Runtimes

A Lambda function is only useful once something invokes it, so two questions matter early: what can trigger a function, and what languages can you write it in. AWS answers both with a broad list, and recognizing the common ones makes the service much less abstract.

Triggers (event sources)

Many AWS services can invoke a Lambda function directly. Common event sources include Amazon API Gateway (turn an HTTP request into a function call), Amazon SNS and Amazon SQS (notifications and queued messages), Amazon EventBridge (event-bus and scheduled events), Amazon Kinesis and Apache Kafka / Amazon MSK (streaming data), Amazon S3 (run code when an object is created or changed), Amazon CloudWatch Logs, and AWS Step Functions (orchestrate functions into workflows). Each of these lets you wire an event in one part of AWS to code that reacts to it, with no server sitting in between.

Runtimes (languages)

Lambda supports a range of managed runtimes, including Python, Java, .NET, and Node.js / JavaScript, and you can bring a custom runtime when you need a language that is not managed out of the box. AWS also publishes language SDKs (Python, Java, PHP, .NET, and JavaScript among them) so your function code can call other AWS services. This list is a representative set rather than an exhaustive one; check the AWS Lambda documentation for the full, current set of supported runtimes.

The pattern is consistent: pick the service that produces your event, point it at a function, and write only the code that reacts. The plumbing between the event and your code is Lambda's responsibility, which is much of why teams reach for it.

AWS Lambda Pricing and the Free Tier

Cost is a big part of understanding Lambda, and its pricing rests on two metered components: the number of requests and the compute duration your code uses. You pay for both, you pay nothing while a function is idle, and there is no always-on server racking up charges in the background. That is the appeal, and the discipline, of the model.

Here is how the two components break down on the on-demand model:

• Requests: $0.20 per million requests. Every time your function is invoked counts as one request.
• Compute duration (x86): $0.0000166667 per GB-second, where a GB-second is one second of run time at 1 GB of allocated memory. Duration is rounded up to the nearest 1 ms.
• Compute duration (Arm / Graviton2): $0.0000133334 per GB-second. Running functions on the Arm/Graviton2 architecture can deliver up to 34% better price-performance than x86.
• Memory drives cost: you set memory from 128 MB to 10,240 MB, and because GB-seconds scale with allocated memory (and CPU scales with it too), the memory you choose directly affects both speed and price.
• Savings: Compute Savings Plans can save up to 17% on Lambda for steady, predictable usage.

The free tier is the natural on-ramp. Every month AWS includes 1,000,000 free requests and 400,000 GB-seconds of compute (aggregate across the x86 and Graviton2 architectures), plus 100 GiB of HTTP response streaming. For learning, prototypes, and small workloads, that allowance often covers everything you do at no cost. Two caveats: the free tier does not apply to Provisioned Concurrency, and free allowances have edges that are easy to drift past, so set a budget and watch usage. Because rates and allowances change, treat every figure here as a starting point and confirm the current numbers on the AWS Lambda pricing page before you plan around them.

When to Use AWS Lambda

We have covered what Lambda is and how it bills; the last question is when to reach for it. Lambda shines when work is event-driven, bursty, or intermittent, and when you would rather not pay for or operate an always-on server. The use cases below are the ones AWS highlights, and they map cleanly onto common needs.

Honest Trade-offs

Serverless is powerful, but Lambda comes with trade-offs to plan for. Lambda is an excellent fit for event-driven work, and the points below are not reasons to avoid it. They are reasons to adopt it with clear eyes.

Frequently Asked Questions