Choosing where to run code on AWS should be an architecture decision, but in practice many teams default to habit: “we used the same thing on the last project.” The problem is that EKS, ECS and Lambda solve different problems, and picking the wrong one shows up later in operations, cost or delivery speed.
This guide compares the three AWS compute options with decision criteria built for CTOs and technology leaders, not just the infrastructure team.
The three options in one sentence
- AWS Lambda: event-driven serverless compute. You upload code, AWS runs it when something happens, and you pay only for the time it actually runs. No servers or clusters to manage.
- Amazon ECS (Elastic Container Service): AWS’s own container orchestrator. Runs your Docker containers as long-running services, with native integration into the rest of AWS and fewer moving parts than Kubernetes.
- Amazon EKS (Elastic Kubernetes Service): Kubernetes managed by AWS. The same orchestration engine you’d use on any other cloud or on-premises data center, with the control plane operated by AWS.
All three can run with or without servers you manage directly: Lambda is always serverless; ECS and EKS can run on your own EC2 instances or on AWS Fargate, which removes server management while keeping the container model.
The criteria that actually decide
1. Workload type
Lambda fits short, event-triggered processes: an API that responds in milliseconds, a file that arrives and gets processed, an integration between systems. Each Lambda invocation has a 15-minute execution cap. ECS and EKS are built for long-running services — an API handling constant traffic, an in-memory stateful process, a worker that runs continuously — where keeping the container running is more efficient than restarting compute on every event.
2. Team expertise
This is the most underestimated criterion. Kubernetes has a real learning curve: concepts like pods, deployments, services, ingress and namespaces aren’t intuitive for a team just starting out. ECS uses AWS’s own mental model — task definitions, services, clusters — with fewer new concepts to learn. If your team already runs Kubernetes elsewhere (on-premises, another cloud), EKS reuses that knowledge. If not, ECS is usually faster to get into production with good results.
3. Portability and operational lock-in
An application on Kubernetes (EKS) uses standard APIs and manifests that — with some nuance — work the same way on Google Cloud, Azure or a self-managed cluster. That matters if your strategy includes multi-cloud, if you’re coming from a hybrid environment, or if portability is a business requirement. ECS and Lambda are AWS-native services: no issue if your strategy is “AWS as the primary cloud,” but migrating those workloads to another cloud means more rework.
4. Fine-grained control of the runtime environment
Lambda manages the runtime environment for you, with the limitations that implies (maximum execution time, memory configurable within ranges, supported runtimes). Containers on ECS or EKS — especially with your own EC2 instances instead of Fargate — give full control over the operating system, installed libraries and hardware (specific GPUs, for example), which matters for compute-intensive workloads or very particular compliance requirements.
5. Cost and operating model (at a high level, no rates)
Lambda charges per invocation and execution time: no traffic, no compute cost. It’s efficient for intermittent workloads and relatively costly if a process runs nearly constantly — a container running without pause is usually more efficient there. ECS and EKS on Fargate charge for the compute resources reserved while the container runs, regardless of how much traffic it handles; with your own EC2, cost depends on the instances you keep running. The right way to compare isn’t “which is cheaper” in the abstract, but modeling the real traffic pattern of each workload.
Direct comparison
| Criterion | AWS Lambda | Amazon ECS | Amazon EKS |
|---|---|---|---|
| Model | Serverless, event-driven | AWS-managed containers | Managed Kubernetes |
| Typical workload duration | Seconds to 15 min max | Long-running services | Long-running services |
| Learning curve | Low | Medium | High |
| Multi-cloud portability | Low (AWS-native service) | Low (AWS-native service) | High (standard Kubernetes API) |
| Server management | Never | Optional (Fargate removes it) | Optional (Fargate removes it) |
| Fine-grained environment control | Limited | High (with EC2) | High (with EC2) |
| Best for | Event-driven APIs, integrations, automations, scheduled tasks | AWS-first services without portability needs | Teams with Kubernetes expertise or portability needs |
| Scale to zero (no traffic = no compute cost) | Yes | No (Fargate/EC2 stays reserved) | No (Fargate/EC2 stays reserved) |
Simplified decision tree
- Is the workload short and triggered by an event (a file, a message, a one-off API request)? → Start with Lambda.
- Is it a long-running service and your team already knows Kubernetes or needs multi-cloud portability? → EKS.
- Is it a long-running service, your team is AWS-first, and you want the simplest path? → ECS (with Fargate if you also want to avoid managing servers).
- Does your architecture combine all three? → That’s the most common case: Lambda for the event-driven part, containers on ECS or EKS for the core services. It’s not an all-or-nothing decision. And to connect those pieces without coupling them, the messaging is chosen with SQS vs SNS vs EventBridge.
How Caleidos helps
At Caleidos, as an AWS Advanced Tier Services Partner, we define this compute architecture as part of our Cloud Native Apps practice: we evaluate the real traffic pattern of each component, your team’s expertise and portability requirements before recommending Lambda, ECS or EKS — or a combination of the three — and take it to production with observability and FinOps from day one. If you already run Kubernetes or are evaluating it, we go deeper on Amazon EKS; if your case is serverless, on AWS Lambda.
Evaluating what compute to use for your next AWS project?
Let’s talk about your architecture: in 30 minutes we’ll give you a concrete recommendation on whether your workload fits Lambda, ECS or EKS.
