Two teams propose Amazon ECS and Amazon EKS for the same containerized inspection app. When should the city prefer EKS?
Select an answer to reveal the explanation.
Short Explanation
Need real Kubernetes APIs and tooling? Pick EKS. ECS is excellent AWS-native orchestration, but if Kubernetes compatibility is non-negotiable for the inspection app, EKS is the lane. Neither choice means 'no containers' or 'host on S3 only.'
Full Explanation
When two teams propose Amazon ECS and Amazon EKS for the same containerized inspection app, the city should prefer EKS when upstream Kubernetes API compatibility is a hard requirement. EKS exists so organizations can run Kubernetes on AWS with a managed control plane and use Kubernetes tooling, YAML, operators, and hiring profiles that assume Kubernetes. ECS is excellent as an AWS-native orchestrator, but it is not Kubernetes.
Preferring EKS is wrong when the app must avoid containers entirely, when the only need is static website hosting on S3, or when the city wants to eliminate all orchestration. Those scenarios call for other services (Lambda/EC2 without containers, S3/CloudFront, or simpler compute) rather than EKS.
Exam caveat: Kubernetes required → EKS. AWS-native container orchestration without Kubernetes → ECS. No servers to manage → Fargate on either platform.
Operational check: confirm the inspection app’s delivery pipeline truly depends on Kubernetes APIs (Helm, operators, existing manifests). If yes, proceed with EKS and IRSA; if the need is only “run containers on AWS,” reconsider ECS for lower control-plane complexity before locking the city into Kubernetes operations.