You’re building a service that has to read from a queue or a data stream all day, every day, and you need to decide where it runs. On Amazon Web Services (AWS), the two usual candidates are AWS Lambda and ECS Fargate. This post compares AWS Lambda vs ECS Fargate for continuous data consumption and shows you which one I’d pick, and why.

What are AWS Lambda and ECS Fargate?

AWS Lambda is a serverless compute service that runs your code in response to events. You upload a function, AWS runs it when something happens, and you never touch a server.

ECS Fargate is a way to run containers on Amazon ECS without managing the machines underneath. You give it a container image plus the CPU and memory you want, and AWS handles the rest.

Both remove server management from your plate. The big difference is how long your code is allowed to run and how much control you get over its environment.

Why Lambda struggles with continuous data consumption

AWS Lambda is built for short, event-triggered tasks, and it has a hard limit on how long one run can last. Each invocation can run for a maximum of 15 minutes, then AWS stops it.

That’s fine for resizing an image or handling an API call. For a consumer that should stay connected and process data without breaks, the limit gets in your way. You end up adding retries, checkpoints, and workarounds just to fake a process that never stops.

Why ECS Fargate fits long-running consumers

ECS Fargate is the better choice for continuous data consumption because a Fargate task can run for as long as you need. Your consumer starts, connects, and keeps working without interruptions.

Here’s what I like about Fargate for this kind of workload:

• Scaling: you can add or remove tasks to handle high data volumes and workloads that go up and down during the day.
• Resource control: you pick the exact CPU and memory for each task, so you can tune it to what your consumer actually needs.
• Custom environment: since everything runs in a container, you choose the runtime, libraries, and tools. If you already package apps with Docker, like in my Grafana with Docker Compose setup, the move to Fargate feels familiar.

AWS Lambda vs ECS Fargate: which costs less?

For always-on consumers, ECS Fargate usually gives you better cost and resource efficiency. The reason is the billing model.

AWS Lambda charges for the actual runtime of your functions. That’s great when your code runs a few seconds now and then. ECS Fargate charges for the CPU and memory your tasks reserve while they run. When your workload runs nonstop anyway, paying for steady resources you’ve sized yourself tends to be easier to manage and cheaper to scale.

Here’s a quick side-by-side:

	AWS Lambda	ECS Fargate
Model	Event-driven functions	Containers
Max run time	15 minutes per invocation	No fixed limit
Billing	Based on run duration	Based on reserved CPU and memory
Resource control	Limited	Fine-grained CPU and memory
Best for	Short, event-triggered tasks	Continuous, long-running workloads

Which one should you pick?

Pick AWS Lambda for short, event-driven jobs and ECS Fargate for anything that needs to run continuously with tight control over resources. That’s the short version.

Before you decide, look at three things in your app: how long each piece of work runs, how much your data volume swings, and what your bill looks like when the service runs 24/7. If the answer to the first one is “forever”, I’d go straight to Fargate and save myself the workarounds. If you’re also on Google Cloud, Cloud Run sits in a similar spot as a serverless way to run containers.

Hope this saves you some time picking the right tool. 🚀 Want more on AWS? Next, read the differences between API Gateway and CloudFront.