ECS vs EKS: 컨테이너 오케스트레이터 선택 기준

인프라 AWS 쿠버네티스
5 분 소요

컨테이너 실행 기반(Fargate냐 EC2냐)을 정했다면 남는 선택은 오케스트레이터입니다. ECS와 EKS는 둘 다 컨테이너를 배포·복구·확장해 주지만, 하나는 AWS 전용 서비스이고 하나는 관리형 Kubernetes라는 점에서 성격이 다릅니다. 결론을 먼저 적으면, AWS 안에서 서비스를 돌리는 것이 목적이면 ECS가 기본값이고, Kubernetes 생태계·이식성·조직 표준이라는 명시적 요구가 있을 때 EKS를 선택합니다. 실행 기반 선택은 ECS Fargate vs EC2에서 다뤘고, 이 글은 그 위층의 선택입니다.

겉보기 요금 차이: 컨트롤 플레인 월 $73 #

과금 구조의 차이는 단순합니다. ECS 컨트롤 플레인은 무료이고, 태스크가 쓰는 컴퓨팅만 냅니다. EKS는 클러스터당 시간당 $0.10, 월로 약 $73입니다. 프로덕션·스테이징·개발로 클러스터를 나누면 3배가 됩니다.

월 $73 자체는 큰 부하의 컴퓨팅 요금에 비하면 소액입니다. 함정은 다른 곳에 있습니다. EKS의 Kubernetes 버전은 표준 지원이 14개월이고, 그 안에 업그레이드하지 않으면 연장 지원으로 넘어가며 클러스터 요금이 시간당 $0.60, 월 약 $438로 6배가 됩니다. Kubernetes는 1년에 세 번쯤 새 버전이 나오므로, EKS를 쓴다는 것은 연 1〜2회의 클러스터·애드온·워크로드 호환성 검증 작업을 상시 일정에 넣는다는 뜻입니다. 이 업그레이드 노동이 EKS의 실제 고정비입니다.

운영 모델의 차이: 무엇을 AWS가 하고 무엇이 남나 #

ECS는 스케줄러, API, 통합이 전부 AWS 서비스로 닫혀 있습니다. 태스크 정의를 쓰고 서비스로 배포하면, ALB 연결, IAM 권한(태스크 롤), CloudWatch 로그·지표가 별도 부품 없이 붙습니다. 버전 업그레이드라는 개념 자체가 없고, 배울 것은 태스크 정의와 서비스 개념 정도입니다. 대가는 선택지의 좁음입니다. 스케줄링 정책, 배포 전략, 네트워크 모델 모두 AWS가 정한 방식 안에서 움직입니다.

EKS는 표준 Kubernetes API를 제공하고, 그 위는 Kubernetes 세계의 규칙을 따릅니다. Helm 차트로 배포하고, Ingress 컨트롤러를 고르고, HPA·오퍼레이터·CRD를 씁니다. AWS가 관리해 주는 것은 컨트롤 플레인(etcd, API 서버)까지이고, 애드온(CNI, CoreDNS, 메트릭, 인그레스)과 노드 운영, 버전 호환성은 사용자 몫입니다. 2024년 말에 나온 Auto Mode는 노드 프로비저닝·패치·통합(로드밸런싱, 스토리지)을 AWS가 대신하는 구성으로, 이 몫을 상당 부분 줄여 줍니다. 대가는 관리 노드의 인스턴스 요금에 약 10% 안팎이 얹히는 추가 요금입니다. Auto Mode를 써도 워크로드 쪽 Kubernetes 지식(매니페스트, RBAC, 업그레이드 검증)은 그대로 필요합니다.

EKS가 정답인 조건 #

  • Kubernetes 생태계가 실제로 필요한 경우: 특정 오퍼레이터(데이터베이스, 메시징, ML 파이프라인), 서비스 메시, Argo CD 같은 GitOps 도구, 조직이 이미 쓰는 Helm 차트 자산이 여기 해당합니다. “쓸 수 있다"가 아니라 “이것 없이는 안 된다"가 기준입니다.
  • 이식성·멀티클라우드 요구: 온프레미스나 타 클라우드와 같은 매니페스트로 운영해야 하는 조직, 혹은 특정 클라우드 종속을 계약상 피해야 하는 경우입니다.
  • 조직 표준이 Kubernetes인 경우: 이미 k8s를 운영하는 팀이 있고 채용·교육·도구가 그쪽으로 정렬되어 있다면, ECS를 별도로 배우는 쪽이 오히려 비용입니다.

이 조건에 해당하지 않는 소규모 팀이 EKS를 고르면, 서비스 개발보다 클러스터 운영(업그레이드, 애드온 버전 맞추기, 네트워크 문제)에 시간이 흘러갑니다. 거꾸로 위 조건에 해당하는데 ECS를 고르면, 생태계 도구를 하나씩 자체 구현하게 됩니다.

갈아타기는 생각보다 큽니다 #

ECS와 EKS는 배포 단위(태스크 정의 vs 매니페스트), 권한 모델(태스크 롤 vs IRSA·Pod Identity), 네트워크 모델이 전부 달라서, 이동은 재작성에 가깝습니다. 그래서 “일단 ECS로 시작하고 크면 EKS로"라는 계획은 성립하지만 싸지 않습니다. 조직이 2〜3년 안에 Kubernetes 표준으로 갈 것이 확실하면 처음부터 EKS로 시작하는 쪽이 이동 비용을 아끼고, 그 확신이 없으면 ECS로 시작해 필요가 증명될 때 옮기는 쪽이 맞습니다. EKS를 고른다면 클러스터 구축·IRSA·애드온 실무는 K8s 실전 #1에서, Kubernetes 자체 입문은 K8s 기초에서 다뤘습니다.

선택 순서 #

  1. 생태계 요구를 검증합니다: 필요한 것이 컨테이너 실행·확장·복구뿐이면 ECS로 충분합니다. 오퍼레이터·GitOps·메시 중 “없으면 안 되는 것"이 있으면 EKS입니다.
  2. 운영 인력을 셉니다: 클러스터 업그레이드를 연 1〜2회 수행할 담당이 없다면 EKS는 연장 지원 요금(6배)으로 새는 길입니다. 그래도 EKS가 필요하면 Auto Mode로 노드 운영 몫을 줄입니다.
  3. 실행 기반과 조합합니다: ECS든 EKS든 Fargate와 EC2 기반을 고르는 축은 별도 기준이 그대로 적용됩니다. EKS의 Fargate는 데몬셋 불가 같은 제약이 있어 주로 보조 용도입니다.
  4. 클러스터 수를 계획합니다: EKS는 클러스터당 과금이므로 환경 분리 수만큼 고정비가 늘어납니다. 소규모라면 네임스페이스 분리로 클러스터 수를 줄이는 것도 선택지입니다.

정리 #

  • 과금 차이는 컨트롤 플레인(ECS 무료, EKS 월 약 $73)이지만, 실제 고정비는 EKS의 버전 업그레이드 노동입니다. 방치하면 연장 지원으로 클러스터 요금이 6배가 됩니다.
  • ECS는 AWS 통합이 완결된 닫힌 서비스, EKS는 표준 Kubernetes API를 주는 열린 플랫폼입니다. 자유도와 운영 부담이 같이 움직입니다.
  • EKS의 근거는 세 가지입니다. 없으면 안 되는 k8s 생태계 도구, 이식성·멀티클라우드 요구, Kubernetes로 정렬된 조직 표준입니다.
  • Auto Mode는 노드 운영을 AWS에 넘기는 대신 인스턴스 요금에 약 10%를 얹습니다. 워크로드 쪽 k8s 지식은 그대로 필요합니다.
  • 둘 사이 이동은 재작성에 가깝습니다. 2〜3년 내 k8s 표준화가 확실하면 처음부터 EKS, 아니면 ECS로 시작해 필요가 증명될 때 옮깁니다.
X