What does “serverless” actually mean?

AWS Lambda is described in one line: a serverless compute service that runs code. You hand over a function, and AWS provisions whatever it needs to execute it — you never see the server it ran on. That description only makes sense once you understand what “serverless” really means, so let’s back up.

Serverless is a spectrum, not a switch

Every AWS service sits somewhere on a spectrum of operational overhead — how much of the plumbing you own versus how much AWS handles. Three tiers cover almost everything.

1. 01Unmanaged. AWS takes care of the underlying physical infrastructure, but you’re responsible for setting up, securing, and maintaining the operating system, network configurations, and applications on your instances. Classic EC2 lives here.
2. 02Managed. AWS handles much of the operational overhead — patching, backups, failover — but you may still need to do some provisioning or configuration depending on the service. Think managed databases like RDS.
3. 03Fully managed. The serverless end. There are no servers to provision or manage at all. The infrastructure is entirely AWS’s problem, so you can focus on writing and deploying code.

Serverless doesn’t mean there are no servers. It means they stopped being your problem.

Where Lambda fits

Lambda sits at the fully managed end. Instead of a capacity plan, you ship a function and AWS scales it on demand, charging you only for the execution time you actually use. You never touch an instance, a kernel, or a patch window — you write a function and the platform takes care of the rest. When the goal is shipping logic with as little infrastructure thinking as possible, that’s the tier you reach for.