3장 EKS를 쓰지 않아도 되는 경우부터 판단한다

Kubernetes는 많은 workload를 선언적으로 배치하고 복구하는 강력한 platform이다. 동시에 API version, scheduling, network, identity, policy, observability, upgrade를 운영해야 한다. 작은 단일 웹 앱이라면 AWS App Runner, ECS/Fargate, Lambda가 더 단순할 수 있다.

다음 질문에서 “예”가 많을수록 EKS의 이유가 생긴다.

• 여러 팀이 공통 deployment policy와 platform API를 써야 하는가?
• 여러 종류의 long-running service·worker·scheduled job을 운영하는가?
• Kubernetes ecosystem이나 portable workload contract가 필요한가?
• traffic·resource·placement를 세밀하게 제어해야 하는가?
• cluster lifecycle과 incident response를 맡을 platform owner가 있는가?

“요즘 대세”는 선택 근거가 아니다. EKS를 택했다면 ADR에 대안과 비용을 남긴다.

ADR-001: FlowNote lab은 EKS Auto Mode를 사용한다.
상황: 팀은 Kubernetes deployment contract를 학습해야 한다.
선택: EKS Auto Mode + eksctl + ALB Ingress.
대안: ECS/Fargate가 더 단순하지만 Kubernetes API 학습 목표를 충족하지 않는다.
결과: AWS가 node와 핵심 networking component를 더 관리하지만,
      application availability·security·cost·manifest는 팀 책임이다.