What is Serverless?

Serverless is a way of building applications where you write code and AWS runs it for you, without you ever launching, patching, or sizing a server. You hand AWS a small unit of work (a function, a queue, a table) and AWS handles where it runs, how many copies run, and when to turn them off. You pay only for what you actually use, often down to the millisecond. This matters because it removes a huge amount of routine operations work and lets a small team ship and scale fast.

What “serverless” really means

Serverless does not mean there are no servers. There absolutely are servers, lots of them, running in Amazon’s data centers. The word “serverless” means you do not see, choose, or manage those servers. AWS owns that layer completely.

Three ideas define serverless:

No server management. You never SSH (Secure Shell, a way to log into a machine) into anything, never apply OS (operating system) patches, and never size a fleet. There is no instance to keep alive.
Automatic scaling. When 1 request arrives, AWS runs 1 copy. When 10,000 arrive at once, AWS runs many copies in parallel. When traffic drops to zero, it scales down to zero, and you stop paying.
Pay-per-use. You are billed for actual execution (for example, requests handled and milliseconds of compute used), not for idle servers sitting on standby.

The big trade-off: serverless trades operational control for managed scaling. You give up the ability to tune the host, install custom kernels, or keep a long-lived process warm. In exchange, AWS handles capacity, availability, and scaling for you.

The core AWS serverless services

Serverless is not one product; it is a family of managed services you wire together. These are the building blocks you will use most.

Service	What it is	Common job
AWS Lambda	Runs your code in response to events	Business logic, glue code, APIs
Amazon API Gateway	A managed front door for HTTP APIs	Turn a Lambda into a public REST/HTTP endpoint
Amazon DynamoDB	A managed NoSQL (non-relational) database	Store and read app data at any scale
Amazon SQS	Simple Queue Service, a managed message queue	Buffer work so producers and consumers decouple
Amazon EventBridge	A managed event bus	Route events between services by rules
AWS Step Functions	A managed workflow engine	Coordinate many steps into one reliable flow

A typical serverless app looks like this: a request hits API Gateway, which invokes a Lambda function, which reads and writes DynamoDB, and drops a message on SQS for slower background work. EventBridge routes events between features, and Step Functions orchestrates anything multi-step. None of these require you to run a server.

A first taste: create a Lambda function

The smallest possible serverless app is one Lambda function. Here is how to create one both ways.

In the AWS Management Console:

Open the Lambda console and choose Create function.
Select Author from scratch.
Give it a name like hello-serverless.
Choose a runtime (the language stack), for example Node.js 22.x or Python 3.13.
Click Create function, then paste your code in the inline editor and choose Deploy.

The equivalent with the AWS CLI (Command Line Interface) v2. First zip your code, then create the function (the --role is an IAM execution role, the permissions the function runs with):

zip function.zip index.mjs

aws lambda create-function \
  --function-name hello-serverless \
  --runtime nodejs22.x \
  --handler index.handler \
  --zip-file fileb://function.zip \
  --role arn:aws:iam::123456789012:role/lambda-basic-exec

Output:

{
    "FunctionName": "hello-serverless",
    "FunctionArn": "arn:aws:lambda:us-east-1:123456789012:function:hello-serverless",
    "Runtime": "nodejs22.x",
    "Handler": "index.handler",
    "State": "Pending",
    "PackageType": "Zip"
}

That is a full serverless deployment. There is no instance ID, no security group, no disk to manage. AWS will run it on demand and scale it for you.

When to use serverless (and when not to)

Use serverless when:

Your traffic is spiky or unpredictable, so paying per-request beats paying for idle servers.
You want minimal operations and a small team, with no patching or fleet management.
The work is event-driven: respond to an upload, a queue message, a schedule, or an HTTP call.
You are building a new feature fast and want to scale to zero when nobody is using it.

Avoid or reconsider serverless when:

You have steady, high-volume, always-on traffic. At sustained high load, a fixed t3.medium EC2 (Elastic Compute Cloud) instance running 24/7 can be cheaper than millions of paid invocations.
You need very long-running jobs. Lambda caps a single run at 15 minutes.
You need predictable low latency with no cold starts (the small delay when AWS spins up a fresh copy of an idle function).
You depend on special hardware, custom OS tuning, or large local state on disk.

Cost gotcha: “serverless = cheaper” is a myth. Serverless is cheapest when load is variable and often idle. A function handling 200 requests per second every second of the day may cost more than one small always-on EC2 box doing the same work. Always model your real traffic before assuming it saves money.

Serverless vs always-on servers

	Serverless (Lambda)	Always-on (EC2)
You manage	Just your code	OS, patches, scaling, the instance
Scaling	Automatic, to zero	Manual or Auto Scaling groups
Billing	Per request + per ms	Per second the instance runs
Idle cost	None	You pay even at 0 traffic
Best for	Spiky, event-driven work	Steady, high-volume workloads

Best practices

Keep functions small and single-purpose. One function, one job, makes scaling and debugging far easier.
Make handlers stateless. Store state in DynamoDB or S3 (Simple Storage Service), never on the function’s local disk, because copies are temporary.
Set sensible timeouts and memory. Right-sizing memory also tunes CPU and directly affects both speed and cost.
Decouple with queues and events. Put SQS or EventBridge between components so a slow or failing consumer never blocks the producer.
Model your cost before committing. Estimate real request volume and compare against a small EC2 instance for sustained load.
Grant least privilege. Give each function an IAM role with only the permissions it needs, nothing more.
Watch cold starts. For latency-sensitive paths, keep packages small and consider provisioned concurrency.