“Should we use Kubernetes?” is the wrong question.
The right question: “What problem are we solving, and what’s the simplest tool that solves it?”
The Options
AWS ECS (Elastic Container Service)
What it is: AWS’s proprietary container orchestration service.
Best for:
- Teams already on AWS
- Simple microservice architectures
- Teams that want managed infrastructure
Pros:
- Deep AWS integration (ALB, IAM, CloudWatch, Secrets Manager)
- Simpler than Kubernetes
- No control plane to manage
- Free (you only pay for compute)
Cons:
- AWS lock-in
- Less feature-rich than Kubernetes
- Smaller community and ecosystem
When to choose ECS:
- You’re on AWS and don’t need Kubernetes features
- Your team is small (<10 engineers)
- You want to ship features, not manage infrastructure
AWS Fargate
What it is: Serverless compute for containers (works with ECS or EKS).
Best for:
- Teams that don’t want to manage servers
- Variable or unpredictable workloads
- Startups moving fast
Pros:
- Zero server management
- Pay per task (scales to zero)
- Automatic scaling
- Great for bursty workloads
Cons:
- More expensive than EC2 (at scale)
- Less control over underlying compute
- Cold start times for scaling from zero
When to choose Fargate:
- You want simple container deployment
- Your workload is bursty (batch jobs, scheduled tasks)
- You’re willing to pay for convenience
Kubernetes (EKS, GKE, AKS, self-managed)
What it is: Open-source container orchestration, runs anywhere.
Best for:
- Multi-cloud or hybrid cloud strategies
- Complex applications with advanced requirements
- Large engineering teams
- Companies that need portability
Pros:
- Runs on any cloud (or on-prem)
- Massive ecosystem (Helm, operators, service meshes)
- Advanced features (stateful sets, custom resources, auto-scaling)
- Industry standard
Cons:
- Complex—steep learning curve
- Requires dedicated operations expertise
- Control plane management (even with EKS)
- More moving parts = more things to break
When to choose Kubernetes:
- You need multi-cloud portability
- You have platform/SRE teams to manage it
- You need advanced scheduling, networking, or storage
- You’re running >50 microservices
Decision Framework
Step 1: Assess Your Team
Small team (<10 engineers)?
→ Start with ECS + Fargate. Kubernetes is overkill.
Platform/SRE team?
→ Kubernetes makes sense. You have the expertise to operate it.
No ops team?
→ Fargate or managed ECS. Avoid Kubernetes.
Step 2: Assess Your Workload
Stateless web apps?
→ ECS or Fargate is fine.
Stateful applications (databases, queues)?
→ Kubernetes has better primitives (StatefulSets, persistent volumes).
Batch/scheduled jobs?
→ Fargate is cost-effective for sporadic workloads.
Real-time, low-latency?
→ EC2-based ECS or self-managed Kubernetes for maximum control.
Step 3: Assess Your Constraints
Multi-cloud requirement?
→ Kubernetes is the only real option.
AWS-only?
→ ECS is simpler and cheaper.
Budget-conscious?
→ ECS on EC2 is cheapest. Fargate costs ~30% more.
Tight deadline?
→ ECS + Fargate ships fastest.
Real-World Scenarios
Scenario 1: Startup with 5 Engineers
Workload: API, background jobs, database
Choice: ECS + Fargate
Why: Team is small, focus should be on product. Kubernetes is too much overhead.
# ECS task definition (simplified)
{
"family": "api",
"networkMode": "awsvpc",
"cpu": "256",
"memory": "512",
"containerDefinitions": [{
"name": "api",
"image": "myapp:latest",
"portMappings": [{
"containerPort": 8080
}],
"environment": [{
"name": "DB_HOST",
"value": "mydb.amazonaws.com"
}]
}]
}
Deploy with a single command. Focus on features, not infrastructure.
Scenario 2: Mid-Size Company, 50+ Services
Workload: Microservices, some stateful components, multi-region
Choice: EKS (managed Kubernetes)
Why: Complexity justifies Kubernetes. Platform team can manage it. Need advanced routing, service mesh, and multi-region failover.
# Kubernetes deployment
apiVersion: apps/v1
kind: Deployment
metadata:
name: api
spec:
replicas: 3
selector:
matchLabels:
app: api
template:
metadata:
labels:
app: api
spec:
containers:
- name: api
image: myapp:latest
ports:
- containerPort: 8080
resources:
requests:
memory: "256Mi"
cpu: "250m"
limits:
memory: "512Mi"
cpu: "500m"
---
apiVersion: v1
kind: Service
metadata:
name: api
spec:
selector:
app: api
ports:
- port: 80
targetPort: 8080
type: LoadBalancer
Scenario 3: Enterprise, Multi-Cloud Strategy
Workload: Core services must run on AWS and GCP
Choice: Kubernetes (EKS + GKE)
Why: Portability matters. Kubernetes manifests work on both clouds. Avoid cloud-specific services (like ECS).
Migration Paths
ECS → Kubernetes
You can migrate incrementally:
- Deploy Kubernetes alongside ECS
- Move one service at a time
- Decommission ECS once migration is complete
We’ve done this for multiple clients. Timeline: 3-6 months for 20-30 services.
Fargate → EC2
If costs become an issue:
- Benchmark workload cost on Fargate vs EC2
- If savings >20%, switch to EC2-based ECS
- Use Spot instances for batch workloads (60-90% savings)
EC2 → Fargate
When operational burden > cost savings:
- Move non-critical services first (batch jobs, internal tools)
- Monitor cost vs. benefit
- Migrate core services if ROI is positive
Cost Comparison
Example: Running 10 containers, each needing 1 vCPU, 2GB RAM:
Fargate:
~$0.04 per vCPU-hour + $0.004 per GB-hour
= ~$35/day = ~$1,050/month
ECS on EC2 (t3.large):
t3.large: 2 vCPU, 8GB RAM = $0.0832/hour
5 instances (to run 10 containers) = $300/month
Savings: 70% with EC2
But with EC2, you manage:
- OS patches
- Scaling
- Instance failures
Is $750/month worth your team’s time? Sometimes yes, sometimes no.
The Verdict
Start simple. Kubernetes is not a requirement.
Most teams should start with ECS + Fargate and migrate to Kubernetes only when they hit real limitations.
Red flags that you need Kubernetes:
- Multi-cloud is a hard requirement
- You’re running 50+ microservices
- You need advanced networking (service meshes, complex routing)
- You have dedicated platform engineers
Red flags you don’t need Kubernetes:
- Team <20 engineers
- All workloads are stateless
- You’re AWS-only
- “Everyone else is doing it”
Choose the tool that fits your team’s size, skills, and constraints. Not the one with the most hype.