If you're new to AWS, two words come up constantly: servers and serverless. They sound like opposites, and in some ways they are. But the real difference isn't about hardware. It's about who manages what.
In this post we'll cover what each one is, how they differ in scaling, cost, and operations, and how to choose between them.
What is a "server" in AWS?
A server is a computer that runs your code and responds to requests. On AWS, the classic server is an Amazon EC2 instance: a virtual machine you rent from AWS.
When you use EC2, you choose:
- The instance type (CPU, memory, network)
- The operating system (Amazon Linux, Ubuntu, Windows)
- The storage and networking setup
- The software that runs on it (Node.js, Python, Nginx, a database)
Then you are responsible for:
- Patching the operating system and keeping it secure
- Installing and updating your runtime and dependencies
- Scaling it, either manually or with Auto Scaling groups and load balancers
- Monitoring it and replacing it when it breaks
The key point is that the server keeps running, and you pay for it, whether anyone is using your app or not.
Other server-based AWS services:
- Amazon ECS / EKS on EC2: container orchestration where you manage the underlying instances
- Amazon RDS: managed databases that still run on provisioned instances you size yourself
- Elastic Beanstalk: easier deployment, but it still runs on EC2 under the hood
What is "serverless" in AWS?
Here's the first thing to clear up: serverless does not mean there are no servers. Of course there are servers. You just don't manage them.
In a serverless model, AWS takes care of provisioning, patching, scaling, and availability. You focus on your code and your data. Serverless services typically share these traits:
- No server management. You never SSH into a machine.
- Automatic scaling. From zero requests to thousands, the service scales for you.
- Pay for what you use. You're billed for actual usage (requests, execution time, data stored or read), not for idle capacity.
- Built-in high availability. The services run across multiple Availability Zones by default.
Core serverless services on AWS:
| Need | Serverless service |
|---|---|
| Run code | AWS Lambda |
| Run containers | AWS Fargate (with ECS or EKS) |
| Build APIs | Amazon API Gateway |
| Store files | Amazon S3 |
| NoSQL database | Amazon DynamoDB |
| Messaging and queues | Amazon SQS, SNS, EventBridge |
| Workflows | AWS Step Functions |
| Authentication | Amazon Cognito |
Here's the difference at a glance. The coral boxes are what you manage. The teal boxes are what AWS manages for you.
With servers, you manage most of the stack. With serverless, you manage your code.
A tiny example: the same API, two ways
Server approach (EC2)
You launch an instance, install Node.js, copy your app over, and keep it running:
// server.js - runs continuously on an EC2 instance
const express = require("express");
const app = express();
app.get("/hello", (req, res) => {
res.json({ message: "Hello from a server!" });
});
app.listen(3000, () => console.log("Listening on port 3000"));
You also need to configure security groups, set up a process manager like PM2 or systemd, and handle scaling and patching.
Serverless approach (Lambda)
You write just the function:
# lambda_function.py
import json
def lambda_handler(event, context):
return {
"statusCode": 200,
"body": json.dumps({"message": "Hello from serverless!"})
}
Put API Gateway in front of it, and you have a working API. There is no machine to patch, and it scales from one request to many without any configuration from you.
Here's a minimal AWS SAM template that defines it:
AWSTemplateFormatVersion: '2010-09-09'
Transform: AWS::Serverless-2016-10-31
Resources:
HelloFunction:
Type: AWS::Serverless::Function
Properties:
Handler: lambda_function.lambda_handler
Runtime: python3.12
Events:
HelloApi:
Type: Api
Properties:
Path: /hello
Method: get
Head-to-head comparison
| Factor | Servers (EC2) | Serverless (Lambda, etc.) |
|---|---|---|
| Management | You manage OS, patching, scaling | AWS manages the infrastructure |
| Scaling | Configured by you (Auto Scaling) | Automatic and fine-grained |
| Pricing model | Pay for provisioned time, even when idle | Pay per request and execution time |
| Idle cost | You pay while it runs | Often close to zero |
| Startup | Always on, no cold starts | Possible cold starts on first invocation |
| Execution limits | Essentially none | Lambda has a maximum duration (15 minutes) and other limits |
| Control | Full control of OS and environment | Limited to the runtime and settings offered |
| Best for | Long-running, steady, or highly customized workloads | Event-driven, spiky, or unpredictable workloads |
The trade-offs in more detail
1. Cost
Serverless shines when traffic is unpredictable or low. If your app gets 100 requests a day, you pay for roughly 100 requests, not a machine sitting idle 24/7.
But the math can flip. If you have steady, high, constant traffic, a well-utilized EC2 instance (especially with Savings Plans or Reserved Instances) can be cheaper than paying per-invocation at very high volume.
Illustrative only, not real AWS prices. A server costs the same whether it's busy or idle. Serverless cost grows with usage, so it wins at low or spiky traffic and can lose at very high, steady traffic.
Always model your real usage using the AWS Pricing Calculator rather than assuming either option is cheaper.
2. Scaling
With EC2, scaling means setting up Auto Scaling groups, load balancers, health checks, and scaling policies, and then tuning them. New instances take time to boot.
With Lambda, each incoming request can trigger a new execution environment automatically, so scaling is largely hands-off. There are still account-level concurrency limits to be aware of.
3. Cold starts
When a Lambda function hasn't been invoked recently, AWS needs to spin up a fresh execution environment, which adds latency to that first request. This is called a cold start. For many applications it's barely noticeable, but for latency-sensitive workloads it matters. Options like Provisioned Concurrency and lighter runtimes can reduce the impact.
Servers don't have this problem because they're already running.
4. Limits and control
Lambda has constraints, including a maximum execution time of 15 minutes, limits on memory, and limits on deployment package size. You also can't install arbitrary system-level software the way you can on EC2.
If you need a long-running process, a specialized OS configuration, GPU access, or software that needs deep system control, servers are usually the better fit.
5. Operational burden
This is serverless's biggest selling point. Fewer things to patch, fewer things to wake up for at 3 a.m. Your team spends time on features instead of infrastructure.
That said, serverless isn't "ops-free." You still need to handle monitoring, logging, permissions (IAM), and debugging distributed, event-driven systems, which can be trickier than debugging one server.
So which should you choose?
Choose serverless when:
- Traffic is spiky, unpredictable, or low
- You're building event-driven workflows (file uploads, queue processing, webhooks)
- You're building an MVP and want to move fast
- You have a small team that doesn't want to manage infrastructure
- Your tasks are short-lived
Choose servers when:
- You have steady, predictable, high-volume traffic
- You need long-running processes
- You need full control over the environment, OS, or networking
- You're migrating a legacy application that expects a traditional server
- You have specialized hardware requirements
And don't forget the middle ground. AWS Fargate lets you run containers without managing servers, which is a good option when you want container flexibility with a serverless-style operating model.
You don't have to pick just one
Most real-world architectures are hybrid. A typical setup might look like this:
- A React frontend hosted on S3 + CloudFront (serverless)
- An API built with API Gateway + Lambda (serverless)
- A message queue on Amazon SQS to hand off slow jobs (serverless)
- A long-running background worker on ECS or EC2 (server-based)
- A relational database on Amazon RDS (server-based)
A typical hybrid: serverless for the frontend and API, servers for long-running work and the relational database.
Use serverless where it fits naturally, and servers where you need control or predictable cost.
Key takeaways
- Server (EC2) means you rent and manage a virtual machine. You get maximum control, but also maximum responsibility.
- Serverless (Lambda, Fargate, DynamoDB, and more) means AWS manages the infrastructure, and you pay for what you use.
- "Serverless" doesn't mean no servers. It means you don't manage them.
- Serverless excels at spiky, event-driven workloads. Servers excel at steady, long-running, or highly customized ones.
- The best architectures often combine both.
If you're just starting out, build something small with Lambda and API Gateway. It's one of the fastest ways to understand the difference firsthand.
Top comments (0)