TL;DR: Decide how much operational surface you want, then match the workload shape. Lambda for event-driven bursts, Fargate-backed ECS for steady containers with no cluster to run, EKS when you need Kubernetes or already have it, EC2 when you need the machine. Fargate is a capacity mode for ECS and EKS, not an alternative to them.
How to approach it
Clear up the Fargate confusion in the first minute, because candidates routinely list it as a fifth option alongside ECS and EKS and it is orthogonal to both. Then give two or three decision criteria rather than a feature table, and be willing to name what you would default to.
A strong answer
EC2 is a virtual machine. You own the operating system, patching, the agent estate and the scaling configuration. You reach for it when something needs the machine: a specific kernel, a GPU driver you manage, licensed software tied to a host, or a workload nobody has containerised and nobody is going to.
ECS is AWS's own container orchestrator. Far simpler than Kubernetes, tightly integrated with IAM, ALB, CloudWatch and VPC networking, and there is nothing to upgrade. The cost is that it is AWS-only and its ecosystem is small, so anything Kubernetes gets from the community you build yourself.
EKS is managed Kubernetes. You get the whole ecosystem: operators, Helm charts, the same manifests that run elsewhere, and the skills market. You also get a control plane bill, cluster upgrades on AWS's support calendar, and the genuine complexity of Kubernetes. Worth it when you already run Kubernetes, need multi-cloud portability, or need something the ecosystem provides.
Fargate is the part that needs clarifying. It is not an orchestrator. It is a capacity mode for ECS and for EKS, where AWS runs the underlying host and you never see or patch a node. You still define an ECS task or a Kubernetes pod. The trade is that you stop managing nodes, stop right-sizing an instance fleet, and pay a premium per vCPU-hour, with some constraints: no daemonsets in the EKS case, limited storage options, and per-task resource shapes rather than arbitrary instance types. For steady, modest workloads it is usually cheaper once you count the engineer who was managing the node group.
Lambda is request-shaped compute with no server at all. You are billed per invocation and per millisecond, it scales to zero, and it scales up automatically. The constraints are the ones that decide it: an execution time limit measured in minutes, a cold start on the first invocation into a new execution environment, and a per-invocation model that makes database connections awkward, which is why connection pooling in front of a relational database is a standard requirement rather than an optimisation.
The decision I would state:
Event-driven, spiky, short: Lambda. An API called a few hundred times a day costs almost nothing and needs no capacity planning at all.
Steady containerised services: ECS on Fargate if you are AWS-only and want the least to operate. That is the default I would argue for in most organisations, because it removes the node fleet without introducing Kubernetes.
Kubernetes-shaped needs: EKS. You already run it, you need the ecosystem, or portability is a real requirement rather than an aspiration.
Something that needs the machine: EC2, deliberately, with a reason written down.
The cost shape matters as much as the features. Lambda is cheapest at low and spiky volume and becomes expensive at sustained high throughput, where a container running constantly is far cheaper. Fargate costs more per unit of compute than EC2 and less than the engineer time it replaces, until the fleet is large enough that a dedicated team is justified anyway.
What interviewers probe next
"When does Lambda stop making sense?" Sustained high traffic, where per-invocation pricing exceeds a running container. Workloads longer than the execution limit. Anything needing a persistent connection or in-process state between requests.
"How do you handle cold starts?" Provisioned concurrency for the latency-sensitive path, a smaller deployment package, and avoiding heavy initialisation. Also worth asking whether the latency actually matters, because for an asynchronous consumer it usually does not.
"ECS or EKS if you are starting fresh on AWS?" ECS, unless you have a Kubernetes reason. Most teams choosing EKS for a handful of services take on cluster upgrades and complexity they never needed, and say so when asked honestly.
Common mistakes
Listing Fargate as an alternative to ECS and EKS rather than as a capacity mode for both.
Choosing EKS because Kubernetes is the default answer, then owning upgrades for three services.
Putting a long-running batch job on Lambda and meeting the execution limit in production.
Ignoring that Lambda's connection model breaks relational databases at concurrency without a pooler in front.