도커(Docker)를 로컬에서 띄우는 건 그리 어렵지 않다. 그런데 막상 실제 개발 환경에서 여러 컨테이너를 안정적으로 운영하려고 하면 이야기가 달라진다.
- 이 컨테이너가 죽으면 어떻게 되지?
- 트래픽이 몰리면 어떻게 늘리지?
- 여러 서버에 어떻게 분산하지?
같은 질문들이 바로 머릿속에 떠오른다.
이걸 해결하는 것이 컨테이너 오케스트레이션(Container Orchestration) 이다. 그리고 AWS에서 제공하는 그 답이 바로 Amazon ECS다.
1. Amazon ECS란?
Amazon ECS (Elastic Container Service) 는 Docker 컨테이너 애플리케이션을 쉽게 배포하고 운영할 수 있도록 지원하는 완전 관리형 컨테이너 오케스트레이션 서비스다.
ECS는 Kubernetes와 같은 컨테이너 오케스트레이션 범주에 속한다. 그러나 Kubernetes에 비해 학습 곡선이 낮고, 소/중 규모 프로젝트에서 운영 비용 및 관리 부담도 적다는 점에서 많이 활용된다.
핵심적인 특징을 정리하면 다음과 같다.
| 특징 | 설명 |
|---|---|
| 완전 관리형 | AWS가 컨트롤 플레인(Control Plane, 오케스트레이션 두뇌 역할)을 관리한다 |
| Serverless 가능 | Fargate를 사용하면 EC2 인스턴스(가상 서버)를 직접 관리할 필요가 없다 |
| AWS 생태계 통합 | ECR, IAM, CloudWatch, ALB 등 AWS 서비스와 자연스럽게 연동된다 |
| Auto Scaling | 트래픽 변화에 따라 컨테이너 수를 자동으로 조절한다 |
2. ECS의 구조
ECS를 이해하려면 구성 요소들의 계층 관계를 먼저 파악하는 것이 중요하다.
ECR (이미지 저장소)
↓
ECS Cluster (컨테이너 실행 환경)
└── ECS Service (실행 그룹)
└── ECS Task (실제 컨테이너)2-1. ECR (Elastic Container Registry)
Docker 이미지를 저장하는 AWS 전용 컨테이너 이미지 저장소다. Docker Hub와 동일한 역할이지만, AWS 내부 서비스와 보안 정책(IAM) 기반으로 접근 제어가 가능하다.
2-2. ECS Cluster
컨테이너를 실행하기 위한 인프라 묶음이다. 여러 인스턴스(EC2 서버)로 이루어지며, 이 위에서 Docker 컨테이너들이 분산 실행된다. Fargate(서버리스) 방식을 선택하면 인스턴스를 직접 구성하거나 관리할 필요가 없다.
2-3. ECS Service
Task들의 실행 그룹이다. "이 Task를 몇 개 유지할 것인가"를 정의하고, 장애 발생 시 자동으로 재시작(Self-healing)하거나, 로드밸런서와 연동하는 역할도 담당한다.
2-4. ECS Task & Task Definition
ECS의 최소 실행 단위가 Task다. Task는 실제로 실행되는 Docker 컨테이너이며, Service는 Task가 두 개 이상 묶인 개념으로 이해하면 된다.
Task Definition은 Task를 어떻게 실행할지에 대한 설계도(명세서) 다.
Task Definition에는 다음과 같은 정보가 담긴다.
- 어떤 Docker 이미지를 사용할 것인가
- 몇 개의 컨테이너를 실행할 것인가
- 어느 포트를 사용할 것인가
- CPU / 메모리 리소스 할당량은 얼마인가
- 환경변수, 볼륨 마운트 등 실행 옵션
// Task Definition 예시 (간략화)
{
"family": "my-app",
"containerDefinitions": [
{
"name": "web",
"image": "123456789.dkr.ecr.ap-northeast-2.amazonaws.com/my-app:latest",
"cpu": 256,
"memory": 512,
"portMappings": [
{
"containerPort": 8080,
"protocol": "tcp"
}
]
}
]
}3. 실행 방식 선택 — Fargate vs EC2
ECS에서 컨테이너를 어떤 인프라 위에서 실행할지 선택하는 것을 Launch Type(실행 유형) 이라 부른다. 크게 두 가지 방식이 있다.
Fargate (서버리스 방식) — 권장 시작점
AWS가 서버 프로비저닝(Provisioning, 인프라 자원 할당 및 준비), 패칭, 스케일링을 모두 담당한다. 개발자는 CPU와 메모리 요구량만 지정하면 된다.
- 서버 관리 불필요
- 태스크 단위로 초 단위 과금
- 빠른 배포 시작에 적합
EC2 Launch Type (직접 관리 방식)
EC2 인스턴스를 직접 프로비저닝하여 그 위에서 컨테이너를 실행하는 방식이다. 운영 부담은 크지만, GPU 활용이나 특수 인스턴스 타입이 필요한 경우에 선택한다.
비교 요약
| 항목 | Fargate | EC2 Launch Type |
|---|---|---|
| 서버 관리 | AWS 담당 | 직접 관리 |
| 비용 구조 | 태스크 리소스 단위 과금 | 인스턴스 단위 과금 |
| 시작 용이성 | 높음 | 상대적으로 복잡 |
| 세밀한 제어 | 제한적 | 자유로움 |
| GPU 지원 | 제한적 | 가능 |
| 추천 상황 | 소/중 규모, 초기 설계 | 대규모, 고성능 특수 요건 |
2026년 현재 AWS 공식 문서에서는 Capacity Provider 방식을 통한 실행을 더 권장한다. Launch Type 직접 지정 방식보다 리소스 관리 유연성이 높다.
4. ECS와 함께 동작하는 요소들
ECS는 단독으로 쓰이지 않는다. 실제 개발 환경에서는 아래 요소들과 함께 사용된다.
- 로드밸런서 (ALB, Application Load Balancer) : 외부 트래픽을 여러 Task에 고르게 분산한다
- Auto Scaling : 부하에 따라 Task 수를 자동 증감한다
- CloudWatch : 컨테이너 로그 수집 및 모니터링을 담당한다
- IAM : Task에 AWS 서비스 접근 권한을 부여한다
5. 2025~2026 주요 업데이트 내용
ECS Managed Instances (2025년 9월 출시)
기존에는 "Fargate(편리하지만 비쌈) vs EC2(저렴하지만 관리 부담)" 구도였다. 2025년 9월, AWS는 이 사이를 채우는 ECS Managed Instances를 발표했다.
- EC2 수준의 비용 효율성
- Fargate 수준의 운영 편의성 (인프라 관리는 AWS가 담당)
- GPU 인스턴스 등 다양한 EC2 타입 지원
- 관리 수수료: 인스턴스 시간당 약 $0.02 추가
GPU 워크로드가 필요하거나, EC2 비용 절감을 원하지만 인프라 관리는 맡기고 싶은 팀에게 유용한 선택지다.
Capacity Provider 우선 권장
AWS는 이제 태스크/서비스 실행 시 Launch Type 직접 지정보다 Capacity Provider Strategy 사용을 공식 권장하고 있다. 여러 인프라 유형을 혼합하거나 가중치 기반 분산이 가능해 더 유연하다.
마무리 — ECS를 바라보는 시각
처음 ECS를 접하면 용어들이 생소해서 당황스럽다. 하지만 한 줄로 정리하면 이렇다.
"Task Definition(설계도)으로 Task(컨테이너)를 찍어내고, Service가 그것을 원하는 수만큼 유지하며, 이 모든 것이 Cluster 위에서 돌아간다."
레거시 환경에서는 여전히 EC2 Launch Type 기반의 ECS가 많이 운영되고 있다. 따라서 Fargate만이 정답은 아니며, 서비스의 규모와 요구사항에 맞는 선택이 중요하다. 처음 시작한다면 Fargate로 구조를 익힌 후, 필요에 따라 EC2 방식으로 확장하는 흐름이 현실적이다.
참고 자료
