One of the AWS questions I keep coming back to when designing backend systems is:
Should this run on Lambda, or should I put it in a container on ECS?
At first glance, the two can look like competing choices. Both let you run applications without directly managing traditional servers, both can scale, and both fit nicely into modern AWS architectures.
But once you actually build with them, the differences become pretty clear.
Lambda is built around functions and events. ECS is built around containers and services.
And that difference matters more than the marketing terms around them.
Lambda feels very different from running a service
With AWS Lambda, you usually think in terms of a function responding to something:
HTTP Request
↓
API Gateway
↓
Lambda
↓
Response
Or:
S3 Upload
↓
Lambda
↓
Process File
Or:
SQS Message
↓
Lambda
↓
Process Message
You don't normally worry about keeping the application running.
AWS takes care of provisioning and scaling the execution environment.
This makes Lambda particularly attractive for event-driven and unpredictable workloads. AWS describes Lambda as an event-driven compute service where AWS manages the underlying compute resources.
And there is something really nice about that model.
If your application receives 10 requests and then nothing for an hour, you aren't maintaining an always-running application just waiting for traffic.
ECS is a different mental model
With ECS, you're thinking about a containerized application.
For example:
Internet
↓
Application Load Balancer
↓
ECS Service
↓
Docker Container
↓
Your Application
Your container keeps running as a service.
You can run ECS tasks using Fargate, where AWS manages the underlying infrastructure, or using EC2 capacity. ECS therefore gives you considerably more control over how your containerized application runs.
This is especially useful when your application isn't naturally a short-lived function.
Maybe you're running:
Django
FastAPI
Node.js
Spring Boot
a background worker
a WebSocket service
a custom Docker image
If you already have a Dockerized application, ECS can feel very natural.
The biggest difference: how your application runs
This is the part I would focus on first.
AWS Lambda Amazon ECS
Basic model Function Container
Typical workload Event-driven Service-based
Runtime Up to 15 minutes per invocation Long-running
Scaling Managed automatically You configure service scaling
Scale to zero Yes Not typical for services
Runtime control More constrained Much more control
Containers Supported as packaging Native model
Best for Bursty/event-driven workloads Long-running services
AWS currently describes Lambda as a function deployment and ECS as a container orchestrator. AWS also recommends ECS for workloads that need to run longer than 15 minutes or need environments outside AWS Regions.
Where Lambda really shines
I particularly like Lambda when the workload is naturally event-driven.
Imagine you have a file processing system:
User uploads PDF
↓
S3
↓
Lambda
↓
Process PDF
↓
Save result
You don't need a server sitting there all day waiting for someone to upload a PDF.
Lambda wakes up when there's work.
The same pattern works nicely for:
scheduled jobs
queue processing
image processing
notifications
lightweight APIs
database events
S3 events
automation workflows
It's also useful when traffic is unpredictable.
You might have almost no requests at 3 AM and suddenly receive thousands during the day. Lambda is designed to handle that kind of changing demand without you having to manually provision capacity ahead of time.
But Lambda isn't always the answer
This is where I think developers sometimes get carried away with serverless.
Just because Lambda can run your code doesn't mean your entire backend should become a collection of Lambda functions.
Consider a Django application.
You may have:
Django
PostgreSQL
Redis
Celery
WebSocket
Background Workers
Trying to force every component into Lambda can introduce unnecessary complexity.
You may also have a process that needs to run for longer than Lambda's maximum invocation duration.
Or perhaps your application needs a custom runtime, native dependencies, persistent connections, or more control over the container environment.
That's where ECS starts becoming much more attractive.
AWS specifically points to ECS for long-running workloads, custom runtimes, and applications that need more control over their container environment.
What about cost?
This is probably the most misunderstood part of the Lambda vs ECS discussion.
People often ask:
Which one is cheaper?
The honest answer is:
It depends on your workload.
Lambda charges based on invocations and execution duration.
ECS pricing depends on how you run it. With Fargate, you pay for the requested compute resources while the tasks are running. With ECS on EC2, you're paying for the underlying EC2 capacity.
So imagine two applications.
Application A
It receives occasional requests:
10 requests
↓
Nothing
↓
50 requests
↓
Nothing
↓
20 requests
Lambda can be very attractive here because you aren't keeping an application running continuously just to handle occasional traffic.
Application B
It receives steady traffic all day:
████████████████████████
████████████████████████
████████████████████████
Now an always-running ECS service can become much more attractive.
AWS's own recent FinOps guidance makes the same point: workload characteristics, traffic patterns, operational requirements and actual cost modeling should drive the decision rather than assuming one compute model is always cheaper.
So don't choose based on a generic "Lambda is cheaper" or "containers are cheaper" statement.
Run the numbers for your workload.
You don't actually have to choose one
This is probably my favorite part of the whole discussion.
You can use Lambda and ECS together.
For example:
Users
|
v
Application / API
|
v
ECS
|
┌───────────┴───────────┐
| |
Database Queue
|
v
Lambda
|
v
Background Job
Your main API might run continuously on ECS.
Then Lambda handles things that are naturally event-driven:
processing uploaded files
sending notifications
scheduled cleanup
queue processing
generating reports
AWS itself notes that many applications use both approaches in production because they solve different problems.
And honestly, this is often a much better architecture than trying to force everything into one compute model.
What would I choose?
I would start with the workload rather than the AWS service.
If I'm building something that is:
Event-driven + unpredictable + relatively short-lived
I'd look at Lambda first.
If I'm building:
A long-running application + custom Docker environment + steady traffic
I'd look at ECS.
If I'm building a larger application?
I'd probably consider both.
For example:
ECS
→ Main API
Lambda
→ Background processing
SQS
→ Decouple workloads
RDS
→ Relational data
S3
→ Files
CloudWatch
→ Monitoring
The architecture becomes more about using each service where it makes sense rather than trying to find one AWS service that does everything.
One practical rule I use
When I'm unsure between two infrastructure options, I ask:
What is the natural lifecycle of this workload?
If the answer is:
"It wakes up, does something, and finishes."
Lambda is probably worth considering.
If the answer is:
"This application needs to stay available and continuously serve requests."
ECS starts making more sense.
And if the answer is:
"Some parts do both."
Use both.
Final thoughts
Lambda and ECS aren't really direct replacements for each other.
They're different execution models.
Lambda gives you functions, events, automatic scaling and very little infrastructure to manage.
ECS gives you containers, long-running services and much more control over the application environment.
The right choice depends on traffic, runtime requirements, application architecture, cost, and how much control your team needs.
And don't forget that the decision isn't permanent. AWS architectures can evolve as workloads change.
If you're currently deciding between the two, I wrote a more detailed comparison covering runtime limits, cold starts, scaling, Docker support, cost, and practical use cases:
👉 Read the full guide:
https://www.onlinetoolkithub.com/blog/aws-lambda-vs-ecs
Top comments (0)