ECS vs EKS, 무엇을 선택해야 할까?

AWS/운영 및 관리 2026. 1. 12. 16:57

흔히 "트래픽이 많아지면 EKS로 가야 한다"고 생각하지만, 이는 반은 맞고 반은 틀린 이야기입니다. ECS로도 초당 수만 건의 요청(RPS)을 처리하는 데엔 아무런 문제가 없습니다.

하지만 서비스(Service)의 개수가 늘어나고 배포 빈도가 잦아지면 이야기가 달라집니다.

ECS는 '단일 목적의 대규모 트래픽' 처리에 매우 강력합니다.

규모 예시:
- 트래픽: 일일 활성 사용자(DAU) 100만~500만 명 수준.
- RPS: 피크 타임 기준 20,000 ~ 50,000 RPS.
- 인프라: 컨테이너(Task) 개수 2,000개 미만.
적합한 시나리오:
- 게임 서버: 배틀그라운드 같은 게임의 로비 서버. 트래픽은 엄청나지만 서비스 로직 자체는 단순한 경우.
- 이커머스 이벤트: 블랙프라이데이 같은 트래픽 폭주 상황. 단순히 Scale-out만 빠르면 되는 경우.
- 콘텐츠 플랫폼: 넷플릭스 스타일의 스트리밍 중계 서버.

💡 Tip: "트래픽이 500만 명 이상으로 많다"는 이유만으로 ECS를 버릴 필요는 없습니다. AWS의 Service Quota(할당량)만 잘 관리하면 ECS는 여전히 최고의 가성비를 냅니다.

문제는 사용자가 아니라 개발팀과 마이크로서비스가 많아질 때 발생합니다. AWS API Rate Limit이라는 보이지 않는 벽에 부딪히기 때문입니다.

한계 상황 (Pain Point):
- 서비스 개수: 마이크로서비스가 100개 이상으로 쪼개질 때.
- 배포 빈도: 수십 개의 팀이 동시에 하루 수백 번씩 배포를 시도할 때.
- 문제점: "Task를 실행해줘"라는 요청 자체가 AWS API 호출 한계(Throttling)에 걸려 배포가 실패하거나 지연되기 시작합니다. (Service Discovery 등록 지연 등)

이때부터는 AWS가 관리해주는 영역(ECS Control Plane)을 벗어나, 우리가 직접 제어할 수 있는 Kubernetes(EKS)가 필요합니다.

규모 예시:
- 트래픽: 글로벌 단위, 수천만 명 이상의 사용자.
- 인프라: 파드(Pod) 개수 5,000개 ~ 10,000개 이상.
- 복잡도: 서비스 간 통신(Service Mesh)이 복잡하게 얽혀있고, 1초 단위의 정교한 오토스케일링이 필요한 경우.
적합한 시나리오:
- 슈퍼앱(Super App): 토스, 카카오, 우버 같이 하나의 앱 안에 수백 개의 기능이 섞여 있는 경우.
- 멀티 테넌트 SaaS: 고객사별로 격리된 네임스페이스와 정교한 리소스 할당이 필요한 경우.

결국 "사용자가 몇 명인가?"보다는
"우리 팀의 마이크로서비스 구조가 얼마나 복잡한가?"가 ECS와 EKS를 가르는 진짜 기준이 됩니다.

왼쪽 (ECS): AWS가 관리하는 숨겨진 Control Plane과 단순한 구조를 강조했습니다. 사용자는 Task 정의에만 집중하면 됩니다.
오른쪽 (EKS): 유료인 EKS Control Plane과 그 아래의 노드, 파드(Pod) 구조를 보여줍니다. 특히 우측 하단에 CNCF 생태계 도구(Helm, Prometheus 등)가 추가적으로 연결되어 확장성이 높음을 시각화했습니다.
공통: ALB와 ECR은 두 서비스 모두에서 공통적으로 사용됩니다.

Posted by South Korea Shuan

South Korea Shuan