What is AWS Lambda? A plain-English explainer
AWS Lambda is serverless compute: you upload a function, tell it what event should trigger it, and AWS runs that code without you provisioning, patching or scaling any server yourself. There is no instance sitting idle waiting for work — Lambda starts your code when something happens, runs it, and stops, and you are billed only for that execution rather than for time the function was not running. That model is a genuine shift from services like Amazon EC2, where you keep a server running continuously whether or not it is busy. Lambda is the flagship example of AWS’s serverless computing category and one of the most frequently asked-about AWS services, because “run this code when X happens, and nothing else” is such a common need. Here is what it does, when it is the right tool, and where its honest limits are.
What “serverless” means here
Serverless does not mean there are no servers — it means you never see or manage them. AWS provisions the compute capacity behind the scenes, runs your function, and tears the environment down afterwards; from your side, the unit of work is the function, not the machine it runs on. Our what-is-serverless-computing explainer covers that idea in general terms across providers; Lambda is AWS’s implementation of it for arbitrary code.
The practical consequence is that Lambda scales by itself. If one event triggers your function, one instance of it runs; if a thousand events arrive at once, AWS runs many instances of that function in parallel without you configuring auto-scaling rules. You write the function as if it only ever handles one event at a time, and Lambda takes care of concurrency.
What triggers a Lambda function
Lambda is event-driven: a function does nothing until something invokes it, and that “something” can be almost any activity elsewhere in AWS or outside it — a file uploaded to a storage bucket, a new row written to a database, a scheduled time, an API call from a web or mobile client, or a message arriving on a queue. This is what makes Lambda feel less like “a server” and more like glue code that reacts to events across an architecture, running only exactly when needed.
That event-driven shape is also why Lambda pairs so naturally with the rest of AWS: it is rarely the whole application on its own, but the piece that responds when something changes elsewhere — resizing an image the moment it lands in storage, processing a record the moment it is written, or handling one request in an API without a server sitting between requests doing nothing.
When you would use Lambda — and when you would not
Lambda suits work that is short-lived and driven by discrete events: processing uploaded files, responding to API requests, running small scheduled jobs, transforming data as it moves between systems. It is a poor fit for anything that needs to run continuously, hold long-lived state in memory between requests, or execute for an extended, unpredictable duration — that is what a server, whether EC2 or a container, is for.
Containers sit between the two: a more portable, more controllable unit than a Lambda function, but still lighter-weight than a full virtual machine, and they can themselves run in a serverless mode. Our serverless-vs-containers explainer covers how to choose between running code as functions versus containers when a workload could reasonably go either way.
The honest limits
Two characteristics of Lambda are worth knowing plainly rather than glossing over. First, every function invocation has a maximum execution time — there is a limit, and if your code has not finished by then it is stopped; check AWS’s current Lambda documentation for the exact figure rather than relying on a number that may change. This is precisely why Lambda suits short tasks and not long-running processes.
Second, a function that has not run recently may experience a “cold start” — a small extra delay the first time it is invoked after being idle, while AWS prepares an execution environment. Frequently invoked functions rarely notice this; latency-sensitive applications sometimes need to account for it. Neither limit is a flaw so much as the trade-off that makes the pay-only-when-it-runs model possible.
How you pay for Lambda
Lambda follows a strict pay-for-use model: you are charged based on how often your function runs and how long each run takes, and nothing when it is idle — there is no baseline cost for a function that never gets invoked. Exact rates change over time, so this article does not quote them; AWS’s Lambda pricing page has the current detail. The concept to take from this is that Lambda cost scales with actual usage, which is very different from paying for a server’s uptime regardless of how busy it is.
Where Lambda appears in certification study
Lambda is core material on AWS Certified Developer – Associate, which covers writing, deploying and integrating functions in real applications, and it appears in architectural context on AWS Certified Solutions Architect – Associate, which tests when serverless is the right architectural choice versus EC2 or containers. AWS Cloud Practitioner introduces it at a conceptual level as the canonical serverless example. Our /revision library covers Lambda’s syllabus depth lesson by lesson for each of these certifications.
Original practice questions, timed mock exams and revision notes. No card, nothing to pay.