ECS, EKS, or Lambda in 2025: A Decision Framework

The decision tree we used in 2020 (Lambda for event work, ECS for “we don’t want Kubernetes,” EKS for “we have a platform team”) no longer cleanly applies.

Three things changed:

• ECS feature parity with EKS has improved substantially (Service Connect, blue/green via CodeDeploy, better scaling, more mature observability integrations).
• Lambda’s ephemeral-storage ceiling moved to 10 GB a few years back, which expanded what’s reasonable to run there beyond the small-payload defaults of the early Lambda days.
• Fargate pricing has come down enough that the operational simplicity is hard to ignore.

This post is our updated framework, with examples from recent client work.

The framework

Three questions, in order:

1. Is the work really event-driven and short-lived?

Lambda still wins for event-driven work that completes in under fifteen minutes, doesn’t need persistent state, and benefits from the per-invocation pricing model. The fit hasn’t changed, but the boundary of “really event-driven” has moved.

We now happily put workloads on Lambda that we’d have moved to ECS in 2020:

• Image processing pipelines (with the 10 GB ephemeral storage)
• Data transformations (within the 15-minute ceiling)
• Webhook handlers with non-trivial logic
• Internal admin tools with low traffic

The boundary we still hold: anything with persistent connections (websockets, long-running streams), unbounded execution time, or payloads above Lambda’s 6 MB synchronous / 256 KB async limits goes elsewhere.

2. Are you running Kubernetes everywhere else?

If your organization already runs EKS for other workloads (or runs Kubernetes on-prem and wants the abstraction to match), EKS is the right choice. The operational overhead is real, but the consistency value is also real, and once you’re paying the EKS tax there’s no incremental cost to adding workloads.

We don’t recommend EKS for organizations not already in Kubernetes. The complexity isn’t worth it for the overwhelming majority of workloads.

3. Otherwise, ECS

For everything else, the long tail of services that need to run continuously, take HTTP traffic, talk to a database, and don’t have unusual scheduling requirements, ECS on Fargate is now our default.

The reasons:

• Operational surface is small. No control plane to manage, no node groups to patch, no autoscaler tuning.
• Scaffolding is fast. Whether via the AWS Console, CDK L3 constructs, or a small CloudFormation library, you can stand up a production-shaped ECS service in a day.
• Costs are predictable. Fargate pricing has stabilized and Savings Plans cover it.
• Feature parity is close enough. Service Connect, blue/green deploys via CodeDeploy, autoscaling, observability: all there.

A note on AWS Copilot: it’s been a popular CLI for ECS scaffolding (we used it for Firstech’s Heroku migration), but AWS has moved Copilot into maintenance mode and announced end-of-support in mid-2026. For new ECS work today we recommend CDK L3 constructs, the ECS console wizard, or hand-authored CloudFormation depending on team preference.

Where the decision still gets hard

Three cases require more thought:

Stateful workloads. Databases, caches, and queues: none of these belong on Lambda or in ephemeral containers without careful design. The right answer is usually a managed service (RDS, ElastiCache, SQS), not a compute platform decision.

GPU workloads. Lambda has limited GPU support; ECS supports it but operationally; EKS has the most mature ecosystem for ML training. For GPU inference, increasingly the answer is Bedrock or a managed inference service, not your own compute.

Mixed batch and online workloads. If a single application has both real-time API traffic and large batch jobs, splitting across Lambda + ECS is common but adds operational complexity. AWS Batch is sometimes the right consolidation point.

A worked example

A client recently asked us to choose a runtime for a new application: a SaaS backend with HTTP APIs, scheduled batch jobs, and a webhook ingestion path.

Our recommendation:

• HTTP APIs → ECS on Fargate (continuous traffic, sub-second response budget)
• Webhook ingestion → Lambda (bursty, event-driven, short-lived)
• Scheduled batch → ECS scheduled tasks (existing image, longer than Lambda’s 15-minute ceiling)

Three runtimes, but each picked for the workload pattern rather than for runtime preference. The team owns one Dockerfile, one infrastructure repo, and a small set of Lambda functions.

Closing

The right runtime in 2025 is rarely the one with the most exciting feature list. It’s the one where the operational surface fits your team’s bandwidth and the cost model fits your traffic shape.

If you’re trying to figure out the right mix for your workloads, we’d be glad to help.