ECS or Lambda for a product that is still changing

This question comes up in week one of almost every AWS engagement, and it is usually framed as a cost comparison. That framing is wrong, because at early-product traffic both options are cheap enough that the difference is rounding.

The real question is which decision you can change your mind about later.

What Lambda actually asks of you

Lambda is excellent and it is not free of commitment. Choosing it shapes your code in ways that are hard to unpick.

Your handlers become entry points with a particular signature. Your dependency graph gets tuned around cold start. Anything that needs a persistent connection, a background worker, or a request longer than the timeout needs a workaround, and those workarounds accumulate. By the time you have three of them you have built a distributed system by accident.

Local development diverges from production, which is a slow tax that nobody puts on the comparison sheet but everybody pays.

None of this is a reason to avoid Lambda. It is a reason to be honest that "we can always move later" is less true than it sounds.

What containers ask of you

A container running on ECS Fargate asks for more setup and less adaptation. You write an ordinary application, you put it in a Dockerfile, and it runs the same way on your machine as it does in production.

The cost is that you now own a task definition, a service, a load balancer, health checks, and a scaling policy. That is genuinely more infrastructure surface than a Lambda function, and for a truly small workload it is overkill.

What you get back is portability. A container that runs on Fargate runs on EC2, on another cloud, or on a developer laptop. The decision is reversible in a way that a codebase shaped around a function-as-a-service runtime is not.

How we actually decide

For a product still finding its shape, we default to containers for the main application and Lambda for the edges.

The main application is the thing whose architecture will change repeatedly over the next year. Keep it boring and portable so those changes are cheap.

The edges are the things whose shape is already settled: an image resize, a webhook receiver, a scheduled report, a queue consumer with a bounded job. These are ideal Lambda workloads precisely because they are small, well-defined, and unlikely to grow into something that fights the runtime.

For a workload with genuinely spiky and unpredictable traffic, or one that is idle most of the day, Lambda wins outright and it is not close.

The question to ask instead

Rather than asking which is cheaper, ask what happens if this service triples in complexity next quarter.

If the answer is that you would be fine, pick either. If the answer involves the phrase "we would have to restructure", pick the option that makes restructuring a refactor rather than a rewrite. At the stage most products are at when this question gets asked, that is containers, and the extra week of setup buys a year of optionality.