Skill 24 · Architect For Startups
Subchapter 24.14
references/eks.mdMarkdown5 KBView on GitHub
EKS is a Series B+ decision. The Kubernetes tax is real:
Choose EKS only when:
The $73/month control plane for dev/staging: Many startups create 3 clusters (dev/staging/prod) = $219/month in control planes alone before a single pod runs. At pre-Series A, use namespaces on a single cluster for isolation. Add dedicated clusters at Series B.
Managed node groups with oversized instances: Default tutorials use m5.large nodes. A startup running 3-5 microservices needs maybe 2-4 vCPUs total. Use t3.medium nodes or Karpenter with tight resource limits.
Add-on sprawl: Each add-on (cert-manager, external-dns, ArgoCD, Datadog, Istio) runs pods that consume node resources. A “production-ready” cluster with common add-ons needs 2-4 vCPUs just for platform components. Budget this separately.
Karpenter consolidation disabled: Karpenter defaults to not consolidating nodes. Enable consolidationPolicy: WhenEmptyOrUnderutilized immediately — it’s the primary mechanism for right-sizing your fleet and avoiding paying for idle capacity.
Load Balancer per service: Each Kubernetes Service type: LoadBalancer creates an NLB (~$16/month). Use an Ingress controller (ALB Controller or nginx) to share one load balancer across services.
kubectl apply driftECS to EKS migration is easier than EKS to ECS. If unsure, start with ECS. If you later need K8s, your containers and Dockerfiles transfer unchanged — only the orchestration layer changes. The reverse (EKS → ECS) requires removing all K8s-specific config (Helm charts, CRDs, operators).
A well-run ECS setup is operationally simpler AND cheaper than EKS until $20K/month compute. The K8s ecosystem flexibility only pays off when you have enough services and team size to leverage it.
Don’t use Helm for everything. Early startups over-invest in templating 3-5 services with complex Helm charts. Plain Kubernetes manifests + Kustomize overlays are more readable and debuggable for small teams. Switch to Helm when you have 10+ services with shared patterns.
Fargate on EKS is worse than Fargate on ECS. EKS Fargate has more limitations (no DaemonSets, no persistent volumes, no GPUs, higher per-pod overhead, slower scheduling). If you want Fargate simplicity, use ECS. If you want EKS, use managed node groups with Karpenter.
| Signal | Why Now |
|---|---|
| >15 engineers, multiple teams deploying independently | Namespace isolation, RBAC per team |
| Monthly compute > $20K, need optimization | Karpenter’s bin-packing saves 30-40% |
| Need GPU sharing across workloads | K8s device plugin + time-slicing |
| Hiring pipeline is primarily K8s-experienced | Developer experience matters |
| Need advanced traffic management | K8s ecosystem (Istio, Cilium) is richer |