After deciding to host a static site, the next practical problem is usually: how do I run an API in a container in the cloud? AWS answers with an alphabet soup — ECS, EKS, Fargate — that's confusing enough on its own, before even comparing it to Azure and Google Cloud.
The most common mistake: these are not three equivalent options
The most frequent confusion is treating ECS, EKS and Fargate as three alternatives at the same level. In practice, they're two separate decisions:
Orchestrator: ECS (AWS-proprietary, simpler) vs. EKS (AWS-managed Kubernetes, the same standard used anywhere else).
Execution mode: Fargate (serverless, no server to manage) vs. EC2 (you manage the instances).
Fargate does not compete with ECS or EKS — it's a way to run either one without provisioning a server. The real combinations are ECS+Fargate, ECS+EC2, EKS+Fargate or EKS+EC2 (or managed node groups).
ECS vs EKS: the decision that actually matters
ECS — AWS's own orchestrator. Smaller learning curve, tighter integration with other AWS services (IAM, CloudWatch, ALB). Good fit if the team has no prior Kubernetes experience and doesn't need to run the same stack outside AWS.
EKS — AWS-managed Kubernetes. Makes sense when the team already knows Kubernetes, there's a real need for multi-cloud/on-premise portability, or the project depends on Kubernetes ecosystem tooling (Helm charts, specific operators).
For most small teams running an API with no multi-cloud requirement, ECS + Fargate delivers with less operational complexity than EKS. Kubernetes only pays off with a concrete technical reason — not because "it's the industry standard."
Equivalents on Azure and Google Cloud
Azure Container Apps — direct equivalent of ECS+Fargate. Deploy the container, the platform handles scaling and networking.
AKS — equivalent of EKS. Same logic: only choose it with real Kubernetes experience or portability needs.
Google Cloud Run — equivalent of ECS+Fargate/Container Apps, arguably the simplest of the three, scaling down to zero automatically.
GKE — equivalent of EKS/AKS. Worth noting Google created Kubernetes, so GKE tends to be seen as the most mature managed implementation, even though EKS has the broadest ecosystem due to AWS's market size.
Decision framework
Does the team already know Kubernetes? If not, start with the simplest serverless option (Fargate, Container Apps, Cloud Run).
Is there a real portability requirement? Kubernetes avoids a rewrite later, since it's an open standard.
Does the project depend on Kubernetes-specific tooling? If yes, the choice is already made.
Can the API tolerate cold starts? Scale-to-zero options add latency on the first request after idle — if not acceptable, keep a minimum instance count (which changes the cost math).
Cost and complexity: managed doesn't mean simple
"Managed" reduces infrastructure maintenance work, but it doesn't reduce Kubernetes' conceptual complexity — you still need to understand pods, services, deployments and RBAC even on EKS, AKS or GKE.
Serverless container options (Fargate, Container Apps, Cloud Run) charge a premium for simplicity: cost per vCPU/memory is usually higher than the equivalent EC2/VM capacity. You're paying to not manage a server.
Common mistakes
Choosing Kubernetes "because it's the industry standard," without real team experience to operate it.
Migrating a docker-compose.yml straight to Kubernetes without understanding the different networking/storage model.
Assuming serverless is always cheaper — it's simpler, not necessarily cheaper at high constant scale.
Ignoring cold start on an API that always needs a fast response.
Comparing ECS to EKS as direct competitors, missing that Fargate is a separate dimension.
Checklist before choosing
Confirm real (not theoretical) Kubernetes experience on the team.
Assess a concrete multi-cloud/on-premise portability need.
Check dependency on Kubernetes-specific ecosystem tooling.
Test the simplest serverless option before jumping to managed Kubernetes.
Simulate the full cost (including cold start, if applicable) in the official calculator.
Document the decision and the reason.
Originally published on RM Porto Tech, where I write about practical backend, cloud and DevOps decisions for small teams.
Top comments (0)