ECS · Fargate — 컨테이너 매니지드 실행
ECS · Fargate — 컨테이너 매니지드 실행
컨테이너 이미지를 만들고 나면 어디서 실행할지가 다음 질문입니다. EC2 위에 직접 docker 를 돌리는 길도 있지만, 매니지드로 컨테이너 라이프사이클·헬스체크·롤링 배포·서비스 디스커버리를 맡기는 길이 있습니다.
1. ECS 에 대한 이야기
| 시기 | 사건 |
|---|---|
| 2014 | ECS GA — Kubernetes 가 표준이 되기 전 자리. |
| 2015 | ECR (컨테이너 레지스트리). |
| 2017 | Fargate (서버리스 launch type). |
| 2018 | EKS (관리형 Kubernetes). |
| 2019 | Fargate Spot. |
| 2021 | ECS Anywhere · EKS Anywhere. |
핵심 객체:
- Cluster — 컨테이너를 실행하는 논리 그룹.
- Task Definition — 한 묶음의 컨테이너 + 자원 요구사항 + IAM 역할 사양 (JSON).
- Task — Task Definition 의 한 실행 인스턴스.
- Service — 같은 Task 를 N 개 유지하고 ALB · 헬스체크 · 롤링 배포 관리.
Cluster
├── Service A (Task Def v3, desired=3)
│ ├── Task 1 (Container X + Y)
│ ├── Task 2
│ └── Task 3
└── Service B (desired=1)
└── Task 1 (Container Z)
2. Launch Type — EC2 vs Fargate
EC2 Launch Type — 사용자가 EC2 인스턴스를 미리 띄우고, ECS Agent 가 클러스터에 등록. 인스턴스의 OS · 보안 · 패치는 사용자 책임.
- 인스턴스 단위 비용 (Reserved · Spot 활용).
- 호스트 접근 가능 (디버깅).
- GPU · 특수 인스턴스 사용 가능.
Fargate Launch Type — EC2 가 보이지 않습니다. Task 단위로 자원 (vCPU · 메모리) 을 선언하면 AWS 가 실행 환경을 띄우고 빌링.
- 운영 부담 거의 없음.
- 격리 (Firecracker 기반) 강함.
- Task 수만큼만 비용.
- vCPU·메모리 단가가 EC2 직접보다 높은 자리.
- 호스트 접근 불가 (ECS Exec 으로 제한적 디버깅).
작은~중간 규모는 Fargate 가 운영 단순성에서 유리. 큰 규모·꾸준한 부하·특수 인스턴스가 필요하면 EC2.
3. Task Definition
{
"family": "web",
"networkMode": "awsvpc",
"cpu": "512",
"memory": "1024",
"containerDefinitions": [{
"name": "app",
"image": "1234.dkr.ecr.ap-northeast-2.amazonaws.com/web:abc123",
"portMappings": [{ "containerPort": 8080 }],
"essential": true,
"logConfiguration": {
"logDriver": "awslogs",
"options": {
"awslogs-group": "/ecs/web",
"awslogs-region": "ap-northeast-2",
"awslogs-stream-prefix": "app"
}
}
}],
"executionRoleArn": "arn:aws:iam::1234:role/ecsTaskExecutionRole",
"taskRoleArn": "arn:aws:iam::1234:role/web-task"
}
- executionRoleArn — ECS 가 이미지를 pull · 로그를 쓸 때.
- taskRoleArn — 컨테이너 안에서 AWS API 를 호출할 때.
- networkMode —
awsvpc가 표준. Task 마다 ENI 와 사설 IP.
4. Service · 배포
Service 는 Task 의 desired count 를 유지하고, ALB Target Group 에 자동 등록·해제합니다.
| 전략 | 메모 |
|---|---|
| Rolling | 기본. 새 버전을 점진적으로 띄우고 옛 버전 점진 삭제. |
| Blue/Green (CodeDeploy) | 두 Target Group 으로 한 번에 트래픽 전환. 즉시 롤백. |
aws ecs update-service \
--cluster prod \
--service web \
--task-definition web:42 \
--force-new-deployment
5. ECR · App Mesh · ECS Anywhere
ECR — 매니지드 Docker 레지스트리 (2015). IAM 인증, 이미지 스캔, lifecycle policy.
aws ecr get-login-password --region ap-northeast-2 \
| docker login --username AWS --password-stdin 1234.dkr.ecr.ap-northeast-2.amazonaws.com
docker push 1234.dkr.ecr.ap-northeast-2.amazonaws.com/web:abc123
App Mesh — Envoy 기반 service mesh. Task 마다 사이드카로 Envoy 를 붙여 트래픽 라우팅 · 재시도 · 관찰. 작은 규모에서는 과한 도구.
ECS Anywhere (2021) — 온프레미스 또는 다른 클라우드의 자체 호스트를 ECS 클러스터에 등록.
6. EKS — 관리형 Kubernetes
| 항목 | ECS | EKS |
|---|---|---|
| API | AWS 전용 | Kubernetes 표준 |
| 학습 곡선 | 낮음 | 높음 |
| 이식성 | AWS 종속 | 다른 K8s 클러스터 이식 가능 |
| 생태계 | AWS 통합 | Helm · Operator · OSS |
| 컨트롤 플레인 비용 | 무료 | 시간당 단가 (~$0.10/hr) |
ECS 가 단순한 자리, EKS 가 표준·생태계가 필요한 자리. Fargate 는 둘 다 가능 (EKS Fargate 는 일부 제약).
7. 다른 옵션 비교
| 플랫폼 | 모델 | 강점 | 한계 |
|---|---|---|---|
| ECS + Fargate | 매니지드 컨테이너 | AWS 통합 · 단순 | AWS 종속 |
| EKS | 매니지드 K8s | 표준 · 생태계 | 학습 곡선 · 비용 |
| Cloud Run (2019) | 컨테이너 서버리스 | 콜드 스타트 짧음 · scale-to-zero | GCP 종속 |
| Fly.io | Firecracker microVM | 글로벌 분산 · anycast | 매니지드 책임 분담 |
| Railway · Render | PaaS | 단순 시작 | 큰 트래픽 보고 적음 |
| Kubernetes (자체) | 자체 K8s | 완전한 자유도 | 운영 부담 매우 큼 |
8. Auto Scaling · 비용 · 보안
ecs:service-autoscaling 으로 desired count 를 메트릭 기반 조절:
- CPU 평균 60% 초과 → +1
- 요청 수 1000/분 초과 → +1
비용 구조:
- Fargate — vCPU 시간 + 메모리 GB-시간.
- EC2 Launch Type — EC2 인스턴스 비용만 (ECS 는 무료).
- EKS — 컨트롤 플레인 시간 + 워커 노드 비용.
- ECR — 저장 GB-월 + Egress.
보안 기본값:
- Private 서브넷 + NAT 또는 VPC Endpoint 로 ECR · CloudWatch · Secrets Manager 도달.
- Task Role 로 최소 권한.
- ALB 만 인터넷 노출, Task 자체는 사설 서브넷.
- Secrets Manager · SSM Parameter Store 로 비밀 주입.
9. 자주 걸리는 자리
Task IP 부족 — awsvpc 모드는 Task 마다 ENI 가 필요. 작은 인스턴스 타입은 ENI 한도가 빠르게 차서 Task 가 더 안 뜨는 사례.
ALB Target Group 의 deregistration delay — 배포 시 옛 Task 가 일정 시간 트래픽을 받음. 너무 짧으면 in-flight 끊김, 너무 길면 배포 느림.
Fargate 의 SSH 부재 — 직접 접근 불가. ECS Exec 로 제한적 디버깅.
로그 폭주 — CloudWatch Logs 비용이 큽니다. 로그 레벨 · 보존 기간 · S3 export 검토.
이미지 platform mismatch — M1/M2 Mac 에서 빌드한 ARM 이미지가 EC2 x86 에 안 뜸. docker buildx build --platform linux/amd64 명시.
Spot 의 회수 — Fargate Spot · EC2 Spot 모두 회수 가능. graceful shutdown 필요.
하고픈 말
ECS + Fargate 는 작은~중간 컨테이너 워크로드의 자연스러운 답입니다. EKS 의 표준 생태계는 매력적이지만 운영 부담이 큰 만큼 명확한 이식성·도구 요구가 있을 때 도입합니다. 작은 팀의 첫 선택은 PaaS · 단일 VPS · ECS Fargate 중 하나가 안전합니다.
Next
- localstack-and-ministack
- supabase-self-hosted
ECS 사용자 가이드 · Fargate · ECR · EKS · Cloud Run · Fly.io · Kubernetes · AWS Copilot 을 참고합니다.