ECS 관련 인터뷰 예시
한 스타트업이 Node.js 백엔드와 큐 처리 워커를 운영하려고 한다. 운영 부담(Ops Overhead)을 0으로 만들고 싶어 Fargate 기반 ECS에 배포했다.
ECS를 선택한 이유: 복잡한 오케스트레이션이 필요 없고, ECS + Fargate는 비용 효율이 높으며 설정도 간단하기 때문이다.
EKS 관련 인터뷰 예시
한 핀테크 앱은 수백 개의 마이크로서비스를 운영하며, 엄격한 컴플라이언스·모니터링·서비스 메시가 필요하다. ArgoCD, Prometheus, Kubernetes 기반 CI/CD를 사용하기 위해 EKS에 배포했다.
EKS를 선택한 이유: Kubernetes와의 깊은 통합, 멀티 리전 안정성, GitOps 활용이 가능하기 때문이다.
단일 컨테이너 앱이라면 ECS vs EKS?
ECS 선택
- 단순함: Kubernetes 전문 지식이 필요 없음
- 단일 워크로드 관리에 최적
- EKS는 쿠버네티스 도구나 멀티 앱 오케스트레이션이 필요하지 않다면 불필요하게 복잡
ECS → EKS 마이그레이션 가능성
- 직접적 전환은 불가능
- ECS(Task/Service)와 EKS(Pod/Deployment)는 추상화 계층이 다름
- ECS 태스크 정의를 Kubernetes 매니페스트로 변환해야 하며, 서비스 구조와 스케일링 방식도 재설계 가능성 있음
왜 Fargate on EKS가 Fargate on ECS보다 비쌀 수 있는가?
- EKS는 Kubernetes 컨트롤 플레인 비용이 별도 발생
- Pod에 Sidecar, kube-proxy 등 부가 컴포넌트가 있어 오버헤드 증가
- ECS + Fargate는 이런 데몬 프로세스가 없어 단위당 효율이 높음
배치 잡(Batch Job) 실행 시 선택
- 간단·이벤트 기반 작업 → ECS + Fargate (저렴하고 설정 간단)
- 잡 의존성·재시도·복잡한 워크플로우 필요 → EKS + Kubernetes Job 또는 Argo Workflows (더 유연)
온프레미스 실행 가능 여부
- EKS: Kubernetes 기반이므로, K8s 호환 온프레 환경에 이식 가능
- ECS: AWS 전용 서비스 → ECS Anywhere를 사용해야 하며 AWS 자격증명 필요, 기능 제한 존재
하이브리드 워크로드(온프레 + AWS)
- EKS: 동일한 Kubernetes API로 클라우드와 온프레를 표준화 가능
- ECS: 하이브리드 기본 지원 없음, ECS Anywhere로 일부 가능하지만 제한적
면접에서의 팁
- ECS: 운영 단순성 강조
- EKS: 확장성·유연성 강조
- Fargate가 두 플랫폼 모두에서 동작한다는 점 언급
- 비용, 팀 역량, CI/CD 도구 지원 여부를 결정 요소로 설명
- 벤더 종속성(Vendor Lock-in) 언급: ECS는 AWS 전용, EKS는 Kubernetes 표준