Serverless vs Servers on AWS: What's the Difference and When Should You Use Each?

isola pelumi — Mon, 19 Oct 2026 23:22:22 +0000

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.

🚨 Cron Jobs Don’t “Catch Up” and This Can Break Your App

isola pelumi — Sat, 17 Jan 2026 20:23:21 +0000

One thing many developers misunderstand about cron jobs & schedulers is how they behave when a server goes down.

If your server is down, cron jobs DO NOT run.
When the server comes back up, cron does NOT replay missed jobs.

Those jobs are simply gone.
How cron actually works
Cron doesn’t track time or remember history.
It simply: Wakes up, Checks the current system time, Runs jobs that match now and Goes back to sleep. No memory, no backlog, no forgiveness.

A common mistake
Relying on cron for exact execution:
“At 12:00 AM, expire subscriptions”
“At midnight, generate reports”
“At 9 AM, send reminders”
If the server is down at that moment nothing happens.

How production systems handle this
The fix isn’t “better cron”.
The fix is better design.
Cron should be a trigger not the source of truth.
Instead of:
Cron → Do the job

Use:
Cron → Check database state → Process pending work

Example:
Run cron every 5 minutes
Query the DB for records that should have been processed
Handle them safely

If the server was down:
Data still exists
Job runs when the server is back
Nothing is lost
Key production principles
i. Cron is stateless
ii. Jobs must be idempotent
ii. Time should be UTC
iii. Business logic should rely on data state, not exact timing
iv. Heavy work belongs in queues, not cron

Mental model
Cron is like an alarm clock without memory If you’re asleep when it rings, it won’t remind you later.

If you’re building: Subscription systems, Payment retries, Reports, Background jobs, AI batch processing and you rely purely on cron timing you’re risking silent failures.

Design for downtime, not perfection.
In my next post I will be discussing CRON VS Queue.

hashtag#BackendEngineering hashtag#SystemDesign hashtag#NodeJS hashtag#CronJobs hashtag#DistributedSystems hashtag#SoftwareEngineering.

DEV Community: isola pelumi