CS, EKS or Fargate: how to choose without becoming a Kubernetes specialist

Ricardo — Mon, 13 Jul 2026 22:25:42 +0000

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.

AWS, Azure or Google Cloud: how to choose for hosting your site or API

Ricardo — Mon, 13 Jul 2026 12:27:17 +0000

Anyone leaving a VPS or starting a project from scratch usually gets stuck on the same question: AWS, Azure or Google Cloud? The problem is not a lack of information, it is too much of it — none of the official docs answer the question that actually matters: which one should I pick, for my case, right now.

This is not another "what is AWS" explainer. It's a decision framework, a side-by-side comparison by scenario, and the mistakes that cost the most.

Why this decision gets stuck
All three clouds solve the same problems in different ways, with different names for similar services. That creates two traps: picking the best-known brand without evaluating the real use case, or trying to study all three in depth and never actually deciding.

Neither works well. The right choice depends on three factors, in this order of priority:

What your team already knows.
The type of workload you're running (static site, API, database, containers).
How much operational complexity you're willing to take on.
What each cloud actually is, in practice
AWS — the oldest, with the largest service catalog. Practical advantage: the most tutorials, the most Stack Overflow answers, the most people who already solved your exact problem. Downside: the sheer number of options makes it easier to pick the wrong service for a simple case.
Azure — strong for companies already on the Microsoft stack (Active Directory, Office 365, .NET). Managed services like App Service tend to be more straightforward for teams that just want something running without dealing with infrastructure.
Google Cloud — historically strongest in data and AI, but Cloud Run is today one of the simplest ways across all three clouds to get an API live without managing a machine or a cluster.
Side-by-side comparison by scenario
Hosting a static site (landing page, docs, SPA frontend):

AWS: S3 + CloudFront + Route 53 — the most documented combination, but three separate services to configure.
Azure: Static Web Apps — hosting, CDN and CI/CD bundled into one service.
GCP: Cloud Storage + Cloud CDN — similar setup to AWS, fewer ready-made examples.
Running an API without managing a server:

AWS: App Runner (simpler) or ECS with Fargate (more control, more configuration).
Azure: Container Apps — direct equivalent of Cloud Run.
GCP: Cloud Run — arguably the most direct path to a running container behind a public URL.
Managed database:

AWS: RDS (relational) or DynamoDB (NoSQL, high scale).
Azure: Azure SQL Database or Cosmos DB.
GCP: Cloud SQL or Firestore.
In all three, start relational unless you have a concrete technical reason to go NoSQL — that reason is an access pattern, not "it scales better."

A practical decision framework
Does your team already know one of the three? If so, start there. The learning cost of a new cloud rarely pays off for a small project.
What do you need to run right now? Static site, stateless API, or something already on Docker Compose changes the answer.
Do you have someone dedicated to infrastructure? Without that, default to the most managed option (Cloud Run, Container Apps, App Runner) over running your own Kubernetes cluster.
Is there an external requirement? A client, partner or compliance policy that already mandates a cloud settles the question.
If none of these point anywhere, the practical answer is usually: start with AWS, because it has the most documented ready-made solution for whatever comes up next. That's not a claim of technical superiority — it's the path of least friction.

Cost: how to compare without fooling yourself
Reference prices change constantly, so this article doesn't list fixed numbers — always confirm the current value in each cloud's official pricing calculator.

No cloud is always cheaper. It depends on the service, region, and usage volume.
The biggest source of surprise bills is usually data egress, not compute — anyone coming from a VPS with "included" bandwidth gets caught off guard by this.
Free tiers differ: some are time-limited (12 months), others are always-free up to a cap.
Set up a billing alert before any test, even a small one.
Common mistakes
Choosing the "most famous" cloud without considering what the team already knows.
Provisioning managed Kubernetes for a project that fits in a single serverless container.
Ignoring egress cost when migrating from a VPS.
Deciding on compute price alone, without simulating the full scenario.
Starting multi-cloud for a small project — added complexity with no real benefit at that stage.
Checklist before choosing
List what you need to run right now.
Check which cloud the team already knows, even partially.
Set up a billing alert before any test.
Test the simplest managed service available before jumping to Kubernetes.
Simulate the full cost, including egress, in the official calculator.
Document the reason for the choice.
Originally published on RM Porto Tech, where I write about practical backend, cloud and DevOps decisions for small teams.

DEV Community: Ricardo

CS, EKS or Fargate: how to choose without becoming a Kubernetes specialist

AWS, Azure or Google Cloud: how to choose for hosting your site or API