AWS 컨테이너 서비스: ECS, EKS, Fargate
ECS, EKS, Fargate, ECR을 오케스트레이션과 실행 엔진 두 층으로 나눠 선택 기준을 정리합니다.
Contents
ECS, EKS, Fargate는 컨테이너를 어디서 어떻게 띄울지 나누는 오케스트레이터와 실행 엔진의 조합입니다.
오케스트레이터와 실행 엔진은 다른 층
AWS 컨테이너 서비스는 오케스트레이션과 이미지 레지스트리로 나뉩니다. 오케스트레이션은 Amazon ECS와 Amazon EKS가 맡고, 이미지 저장은 Amazon ECR이 맡습니다. ECS는 Elastic Container Service, EKS는 Elastic Kubernetes Service의 약자입니다. ECR은 Elastic Container Registry의 약자입니다.
여기에 실행 엔진으로 AWS Fargate가 따로 있습니다. Fargate는 ECS와 EKS 양쪽에서 쓰는 서버리스 컴퓨트 엔진이라, 오케스트레이터를 고른 뒤에도 실행 기반을 다시 선택합니다. 그래서 'ECS냐 EKS냐'와 'Fargate냐 EC2냐'는 서로 다른 층의 질문입니다.
- Amazon ECS: AWS 독자 API 기반 오케스트레이터로 개념이 적습니다.
- Amazon EKS: 관리형 Kubernetes로 오픈소스 생태계와 호환됩니다.
- Amazon ECR: 컨테이너 이미지를 저장·배포하는 레지스트리입니다.
레지스트리는 오케스트레이터와 독립이라, ECS와 EKS 어느 쪽이든 ECR을 함께 씁니다.
ECS와 EKS의 차이
ECS는 클러스터, 서비스, 태스크 정의라는 적은 수의 개념으로 동작합니다. 태스크 정의는 컨테이너 실행 명세이고, 서비스는 그 태스크를 장기 실행으로 유지하는 단위입니다. 개념이 적어 학습 곡선이 낮습니다.
EKS는 Kubernetes를 관리형으로 제공합니다. 컨트롤 플레인(API 서버, etcd, 스케줄러)은 AWS가 운영하고, 사용자는 워커 노드와 그 위의 파드만 관리합니다. 오픈소스 Kubernetes와 호환되어 다른 클라우드로 옮기기 쉽습니다.
두 서비스의 갈림길은 표준과 운영 부담입니다.
| 기준 | Amazon ECS | Amazon EKS |
|---|---|---|
| 표준 | AWS 독자 API | Kubernetes(오픈소스) |
| 학습 곡선 | 낮음 | 높음 |
| 유연성 | 보통 | 매우 높음 |
| 멀티클라우드 | AWS 전용 | 가능 |
| 적합 대상 | AWS 중심 팀 | Kubernetes 경험 있는 팀 |
AWS 안에서 빠르게 띄우는 것이 목표라면 ECS가 부담이 적습니다. 반대로 Kubernetes 생태계나 멀티클라우드 이식성이 필요하면 EKS가 맞습니다.
Fargate와 EC2
오케스트레이터를 골랐어도 컨테이너가 실제로 도는 기반은 따로 정합니다. 선택지는 EC2 인스턴스와 Fargate 두 가지이고, Fargate는 ECS와 EKS 모두에서 쓰는 서버리스 컴퓨트 엔진입니다.
Fargate에서는 서버 프로비저닝, 패치, 스케일링을 직접 하지 않고 컨테이너 단위로 비용을 냅니다. 운영 부담이 줄지만 호스트 수준의 세밀한 제어는 포기합니다. 커널 파라미터나 GPU, 특수 인스턴스 타입이 필요하면 EC2가 맞습니다.
| 기준 | EC2 | Fargate |
|---|---|---|
| 운영 부담 | 노드 직접 관리 | 서버 관리 없음 |
| 제어 수준 | 호스트까지 세밀하게 | 컨테이너 단위 |
| 과금 | 인스턴스 단위 | 태스크 자원 단위 |
| 적합 상황 | 특수 하드웨어·튜닝 | 빠른 운영·가변 부하 |
제어가 필요하면 EC2, 운영을 덜고 싶으면 Fargate입니다. 두 방식을 한 클러스터에서 섞어 쓰는 구성도 가능합니다.
ECS Express Mode
ECS로 프로덕션 서비스를 띄우려면 보통 VPC, 서브넷, 보안 그룹, ALB, 타깃 그룹, IAM을 엮어야 합니다. ECS Express Mode는 이 과정을 컨테이너 이미지와 IAM 역할만으로 줄인 배포 방식이며, 2025년 re:Invent에서 발표됐습니다.
ALB는 Application Load Balancer로, HTTP 경로·호스트 기준으로 트래픽을 분산하는 로드 밸런서입니다. Express Mode는 이미지를 주면 아래 리소스를 자동으로 만듭니다.
- ECS 클러스터, 태스크 정의, 서비스
- 여러 서비스가 공유하는 ALB와 HTTPS, 도메인·인증서
- 오토스케일링 정책과 최소 권한 보안 그룹
- 4XX/5XX 급증을 감지해 자동 롤백하는 알람
핵심은 ALB를 서비스마다 새로 만들지 않고 하나로 공유하는 구조입니다. 하나의 ALB가 호스트 헤더로 여러 서비스를 가르며, 2025년 발표 기준 최대 25개까지 묶습니다. ALB 하나의 고정 요금(월 약 16달러, 추정)을 서비스 수만큼 아낄 수 있어, 작은 마이크로서비스가 많을수록 절감이 커집니다.
EKS의 최근 보강 기능
2025년 re:Invent은 EKS에 플랫폼 운영, 컨트롤 플레인 성능, 네트워크 관측 기능을 더했습니다.
EKS Capabilities는 Argo CD, ACK, KRO 같은 플랫폼 도구를 AWS가 직접 운영하는 관리형 애드온입니다. ACK는 AWS Controllers for Kubernetes, KRO는 Kube Resource Orchestrator의 약자입니다. 이 도구들은 사용자 워커 노드가 아니라 AWS 소유 계정에서 돌아, API 서버나 UI가 사용자 VPC에 직접 노출되지 않습니다.
대표 사례인 Managed Argo CD는 GitOps 도구를 관리형으로 제공합니다. GitOps는 Git에 적은 목표 상태를 클러스터에 자동 반영하는 배포 방식입니다. 고가용성 Redis 구성이나 Repo-server 확장 같은 운영을 AWS가 맡아 공격 표면이 줄어듭니다. 요금은 클러스터당 시간 요금에 Application 수 비례 요금이 붙습니다(시간당 약 0.0277달러 + App당 약 0.00136달러, 추정).
Provisioned Control Plane은 컨트롤 플레인 용량을 미리 확보해 트래픽 급증에도 API 서버 성능을 일정하게 유지하는 기능입니다. EBS Provisioned IOPS와 비슷한 발상입니다. 표준 티어는 부하에 반응해 늘리고, Provisioned 티어는 선제적으로 확보하며, 둘 사이를 다운타임 없이 전환합니다.
| 항목 | Standard | Provisioned |
|---|---|---|
| 스케일링 | 반응형 | 선제적 |
| 비용 | 기본 포함 | 티어별 추가 요금 |
| 적합 워크로드 | 일반 웹·마이크로서비스 | 대규모 AI·배치·멀티테넌트 |
이 기능은 단일 클러스터에 노드가 매우 많거나 파드 생성·삭제가 잦은 환경에 맞습니다. 수천 GPU 파드를 동시에 띄우는 학습 작업에서도 컨트롤 플레인 병목을 막습니다.
Enhanced Network Observability는 eBPF로 파드 수준 네트워크를 추적합니다. eBPF는 커널에서 안전하게 코드를 실행해 트래픽을 관측하는 리눅스 기술입니다. 서비스 맵과 플로우 테이블, 세분화된 메트릭을 제공합니다. DNS 지연이나 TCP 재전송 같은 신호로 네트워크 문제와 서버 부하를 구분합니다.
ECR과 이미지 서명
Amazon ECR은 컨테이너 이미지를 저장·배포하는 관리형 레지스트리입니다. IAM 기반 접근 제어와 push 시 취약점 스캔, 태그 덮어쓰기를 막는 Immutable Tags를 제공합니다. 여기에 멀티 리전 복제와 외부 레지스트리 캐싱(Pull-Through Cache)도 지원합니다.
2025년에는 공급망 보안용으로 Managed Image Signing이 더해졌습니다. 이미지를 ECR에 push하면 AWS Signer가 자동으로 서명하고, 배포 시 그 서명을 검증해 신뢰할 수 없는 이미지를 막습니다.
| 항목 | 기존(Cosign·Notation) | ECR 관리형 서명 |
|---|---|---|
| 서명 도구 | 클라이언트에 별도 설치 | push 시 자동 |
| 키 관리 | 직접 PKI 운영 | AWS Signer가 생성·저장·로테이션 |
| 설정 | 파이프라인 구성 필요 | 콘솔 또는 단일 API 호출 |
직접 Cosign이나 Notation으로 서명 파이프라인을 짜던 작업을 관리형으로 옮긴 셈입니다. 키 관리와 로테이션을 AWS가 맡아 운영 부담이 줄어듭니다.
선택 기준
오케스트레이터를 먼저 고르고, 실행 엔진과 이미지 신뢰를 그 위에 채웁니다.
- AWS 안에서 빠르게 띄우고 운영을 덜고 싶다 → ECS, 가능하면 Express Mode
- Kubernetes 생태계·멀티클라우드·세밀한 제어가 필요하다 → EKS
- 노드 운영을 피하고 싶다 → Fargate, 특수 하드웨어·튜닝이 필요하다 → EC2
- 이미지 출처를 보장해야 한다 → ECR Managed Image Signing
대규모 트래픽이나 AI 학습처럼 컨트롤 플레인 부하가 큰 경우에는 EKS의 Provisioned Control Plane을 더합니다. 네트워크 장애를 빨리 짚어야 하면 Enhanced Network Observability를 켭니다.
정리
AWS 컨테이너 서비스는 오케스트레이션(ECS·EKS)과 레지스트리(ECR), 그리고 실행 엔진(Fargate·EC2)이라는 두 층의 선택으로 정리됩니다. ECS는 개념이 적어 빠르고, EKS는 Kubernetes 생태계와 이식성에서 강하며, Fargate는 노드 운영을 없앱니다. 2025년 추가된 Express Mode와 EKS Capabilities는 배포 편의와 플랫폼 운영을 맡습니다. Provisioned Control Plane과 Managed Image Signing은 성능 보장과 공급망 보안을 더합니다. 결국 선택은 표준이 필요한지, 운영을 얼마나 덜고 싶은지, 어느 규모를 견뎌야 하는지라는 세 질문으로 좁혀집니다.