Skip to content

SYSTEM Cited by 8 sources

AWS EKS (Elastic Kubernetes Service)

Amazon EKS (Elastic Kubernetes Service) is AWS's managed Kubernetes control plane — AWS runs the API server, etcd, and the core controllers; customers run worker nodes (on EC2 or Fargate) and their own workloads.

From a system-design posture, EKS is the managed-control-plane equivalent of self-hosted Kubernetes with the same data-plane abstractions (Pods, Services, StatefulSets, Ingress, etc.), the same xDS / API / Helm ecosystem, and the same CNCF toolbox (systems/karpenter, systems/keda, systems/envoy, systems/kyverno, systems/cilium).

Stub page — minimal viable for the Figma ECS→EKS migration ingest. Expand on future EKS-internals sources.

Contrast with ECS

Figma's 2024 migration post enumerates the EKS advantages that drove their ECS→EKS cutover:

  • StatefulSets for stateful workloads — Kubernetes primitive that gives pods stable network identities across restarts. ECS doesn't have this; Figma had written custom container-startup code to dynamically update etcd cluster membership, which was "fragile and hard to maintain." StatefulSets is the standard way to run etcd on Kubernetes.
  • Helm charts ecosystem — easy install / upgrade of OSS software (Figma specifically called out systems/temporal). On ECS, the equivalent required hand-porting each service to systems/terraform.
  • Graceful node cordon-and-drain. Cordoning a bad EC2 node on EKS lets the API server move pods off respecting shutdown hooks. ECS on EC2 has no equivalent.
  • CNCF auto-scaling — systems/keda for pod-level (with custom metrics like SQS queue depth), systems/karpenter for node-level. ECS has some auto-scaling but the CNCF offerings are more flexible.
  • Service-mesh availability — Istio (Envoy-based) is trivial to adopt on EKS; on ECS, building equivalent functionality (custom filters, mTLS) would require building in-house what Istio ships.
  • Vendor-agnostic user base drives more external investment than ECS (AWS-only).

Seen in

EKS's role axis across ingested sources

Same platform, substantially different roles per case study:

Customer EKS's role
Figma Application compute tier (multi-cluster active-active)
Convera Backend zero-trust compute tier (per-pod AVP reval)
Santander Infrastructure control plane (ArgoCD + OPA + Crossplane)
Generali Multi-tenant app compute tier under Auto Mode
SageMaker HyperPod LLM-inference-platform substrate (EKS add-on packaging)
Conversational observability blueprint AI-troubleshooting target (self-built RAG + MCP variants)
AWS DevOps Agent AI-troubleshooting target (AWS-managed variant)
Salesforce Extreme-scale multi-tenant platform (1,000+ clusters, 1,180+ node pools, Karpenter-driven)

This spread is what makes EKS a load-bearing canonical node in the wiki — the same primitive reappears in very different architectures.

Last updated · 200 distilled / 1,178 read