[Compute] ECS 컨셉 노트
시험 빈출 ECS 컨셉 노트
Amazon ECS (with Fargate) for SAA-C03
One-Line Summary
ECS는 Docker 컨테이너의 배포·스케줄링·스케일링·헬스체크를 대신 해주는 AWS 관리형 컨테이너 오케스트레이션이다. 시험에서는 대부분 컨테이너를 어디에 띄울지 — 내가 관리하는 EC2 위(EC2 Launch Type)인가, 서버 관리가 없는 Fargate인가 를 묻는다.
Why It Exists
컨테이너를 여러 대 운영하려면 "어느 서버에, 몇 개를, 죽으면 어떻게 재시작할지"를 계속 관리해야 한다. 이를 손으로 하면 부담이 크다.
ECS는 이 문제를 해결한다.
컨테이너 직접 운영
-> 어느 서버에 배치할지, 몇 개 띄울지, 죽으면 재시작할지 전부 수동
ECS
-> Task Definition(설계도)만 주면 배치/개수 유지/재시작/ALB 연동을 자동
-> EC2 위에 띄울지, 서버 없는 Fargate로 띄울지 선택
시험 감각:
"AWS에서 Docker 컨테이너를 운영" = ECS(또는 EKS). 거기서 "서버 관리는 하기 싫다"가 붙으면 = Fargate.
Abbreviations
| 약어 | 풀네임 | 의미 |
|---|---|---|
ECS | Elastic Container Service | AWS 관리형 Docker 컨테이너 오케스트레이션 |
EKS | Elastic Kubernetes Service | AWS 관리형 Kubernetes 서비스 |
ECR | Elastic Container Registry | Docker 이미지를 저장하는 AWS 이미지 저장소 |
Fargate | Fargate | 서버 관리 없이 컨테이너를 실행하는 서버리스 엔진 |
Task | Task | 실제로 떠 있는 컨테이너 실행 단위 |
ALB | Application Load Balancer | ECS Service 앞단 트래픽 분산용 L7 로드 밸런서 |
구성 요소
ECS는 아래 개념으로 컨테이너 운영을 자동화한다.
Task Definition (설계도) -> Task (실제 실행) -> Service (원하는 개수 유지) -> Cluster (실행 그룹)
| 개념 | 의미 |
|---|---|
| Task Definition | 컨테이너 실행 설계도(이미지, CPU/메모리, 포트, 환경변수) |
| Task | 설계도로 실제 떠 있는 컨테이너(들) |
| Service | 원하는 Task 개수를 유지·자동 복구, ALB 연동 |
| Cluster | Task가 배치되는 논리적 그룹 |
두 가지 실행 방식(Launch Type) — 시험 핵심
ECS는 컨테이너를 어디에 띄울지로 두 가지 방식이 있다.
| 구분 | EC2 Launch Type | Fargate Launch Type |
|---|---|---|
| 서버(EC2) 관리 | 사용자가 직접 (프로비저닝·패치·스케일링) | AWS가 관리 (서버 개념 없음) |
| 형태 | 내가 띄운 EC2 클러스터 위에 컨테이너 배치 | 컨테이너 스펙만 정의하면 AWS가 실행 |
| 관리 부담 | 큼 | 거의 없음 |
| 비용 모델 | EC2 인스턴스 요금(켜둔 만큼) | 컨테이너가 쓴 vCPU/메모리 × 실행 시간 |
| 적합 | 인스턴스 세밀 제어, GPU 등 특수 인스턴스, 이미 EC2 여유 용량 | 서버 관리 없이 빠르게, 가변적·드문 워크로드 |
AWS Fargate
Fargate는 서버(EC2)를 프로비저닝·관리하지 않고 컨테이너를 실행하는 서버리스 컴퓨트 엔진이다. 별도 오케스트레이터가 아니라 ECS/EKS의 실행 방식으로 붙여 쓴다. 사용자는 컨테이너 스펙(이미지·CPU·메모리)만 정의하고, 서버 준비·패치·스케일 인/아웃은 AWS가 한다.
| 항목 | 의미 |
|---|---|
| 정체 | ECS/EKS의 서버리스 실행 엔진 |
| 관리 | 서버 프로비저닝/패치/스케일링 전부 AWS |
| 확장 | Task 단위로 자동 축소·확장 |
| 과금 | 컨테이너가 사용한 vCPU/메모리 × 실행 시간 |
| 대표 키워드 | serverless containers, no EC2 to manage, no server provisioning |
시험 감각:
"reduce operational overhead / no servers to manage" + 컨테이너 = Fargate.
IAM 역할 — Task Role vs Task Execution Role (빈출)
ECS의 IAM 역할은 두 개가 목적이 완전히 다르다. 시험에서 자주 헷갈리게 낸다.
| 역할 | 누가 쓰나 | 용도 |
|---|---|---|
| Task Role | 컨테이너 안의 애플리케이션 | 앱이 다른 AWS 서비스 호출 (예: S3 읽기, DynamoDB 접근) |
| Task Execution Role | ECS 에이전트/Fargate | 이미지 pull(ECR), 로그 전송(CloudWatch Logs), Secrets 주입 |
Task Role : "내 앱이 S3 버킷을 읽어야 한다" -> 앱에 부여할 권한
Execution Role : "ECS가 ECR에서 이미지를 당기고 로그를 CloudWatch에 보낸다" -> 실행 인프라 권한
시험 감각:
"컨테이너 앱이 S3/DynamoDB에 접근해야 한다" = Task Role에 권한. "이미지 pull이나 로그 전송이 실패한다" = Task Execution Role 문제.
확장과 비용 최적화 (Auto Scaling · Spot)
| 항목 | 내용 |
|---|---|
| Service Auto Scaling | Service의 Task 개수를 CPU/메모리/요청수 기준 Target Tracking으로 자동 조절 |
| Cluster Capacity Provider | EC2 Launch Type에서 클러스터의 EC2 용량을 워크로드에 맞춰 자동 확보/축소 |
| Fargate Spot | 중단 감내 가능한 워크로드를 Fargate에서 최대 ~70% 저렴하게 |
| EC2 Spot | EC2 Launch Type에서 Spot 인스턴스로 컨테이너 비용 절감 |
시험 감각:
"컨테이너 워크로드를 최저 비용, 중단 감내 가능" = Fargate Spot / EC2 Spot. "부하에 따라 태스크 수 자동 조절" = Service Auto Scaling.
영속·공유 스토리지 연동 (EFS)
컨테이너는 기본적으로 stateless다. Task가 죽으면 컨테이너 로컬 데이터도 사라진다. 재시작해도 유지되거나 여러 Task가 공유해야 하는 데이터는 EFS를 마운트한다.
| 요구사항 | 해법 |
|---|---|
| Task 재시작/교체에도 데이터 유지 | EFS 볼륨 마운트 |
| 여러 Task/여러 AZ가 같은 파일 공유 | EFS (Fargate도 EFS 지원) |
| 임시 작업 공간(캐시 등) | Task 임시 스토리지(ephemeral) |
시험 감각:
"컨테이너에 영속적/공유 스토리지가 필요하다" = EFS (Fargate + EFS 조합도 출제).
네트워킹 모드 (awsvpc)
Fargate는 항상 awsvpc 모드를 쓴다. 각 Task가 자기 ENI와 사설 IP를 가져 VPC 내 다른 리소스처럼 보안 그룹을 붙일 수 있다. Task 단위로 네트워크를 격리·제어할 수 있는 것이 핵심이다.
ECS vs EKS
| 구분 | ECS | EKS |
|---|---|---|
| 오케스트레이터 | AWS 자체(간단, AWS 통합 쉬움) | Kubernetes(표준, 이식성·생태계) |
| 러닝커브 | 낮음 | 상대적으로 높음 |
| 실행 방식 | EC2 / Fargate | EC2 / Fargate |
| 고를 때 | AWS 안에서 간단히 | 기존 K8s 자산·멀티클라우드·K8s 표준 필요 |
참고: Docker 이미지는
ECR(Elastic Container Registry)에 저장·버전관리한다.
Common Wrong Directions
| 오답 방향 | 왜 부족한가 |
|---|---|
| 컨테이너인데 서버 관리를 줄이려고 EC2 Launch Type 선택 | 서버 관리 최소화면 Fargate가 정답 |
| GPU/인스턴스 세밀 제어가 필요한데 Fargate 선택 | 인스턴스 단위 제어·특수 인스턴스는 EC2 Launch Type |
| K8s가 꼭 필요 없는데 EKS 선택 | AWS 안에서 간단하면 ECS가 러닝커브 낮음 |
| 짧은 이벤트 처리에 ECS 클러스터 구성 | 이벤트 기반 짧은 코드는 Lambda가 더 간단·저렴 |
| 앱의 S3 접근 권한을 Execution Role에 부여 | 앱 권한은 Task Role, Execution Role은 이미지 pull/로그용 |
| 컨테이너 재시작 후 데이터 유지에 로컬 스토리지 사용 | 영속·공유 데이터는 EFS 마운트 |
| 중단 감내 컨테이너를 On-Demand Fargate로만 운영 | 비용 최적화는 Fargate Spot / EC2 Spot |
Exam Triggers
| 문제에서 이런 표현이 나오면 | 떠올릴 것 |
|---|---|
| "run Docker containers on AWS" | ECS (또는 EKS) |
| "run containers without managing servers/EC2" | Fargate |
| "reduce operational overhead", "no server provisioning" (컨테이너) | Fargate |
| "need GPU / instance-level control" (컨테이너) | ECS on EC2 |
| "already use Kubernetes / portability" | EKS |
| "store/version Docker images" | ECR |
| "container app needs access to S3/DynamoDB" | Task Role |
| "image pull / log delivery fails", "grant ECS pull from ECR" | Task Execution Role |
| "auto scale number of tasks by CPU/requests" | Service Auto Scaling |
| "lowest cost containers, interruption tolerant" | Fargate Spot / EC2 Spot |
| "persistent/shared storage for containers" | EFS |
| "each task needs its own ENI / security group" | awsvpc 네트워킹 모드 |
Memory Sentence
ECS는 AWS 관리형 컨테이너 오케스트레이션. 서버(EC2)를 내가 관리하면 EC2 Launch Type, 서버 관리가 아예 없으면 Fargate. K8s 표준이 필요하면 EKS, 이미지 저장은 ECR. 앱 권한은 Task Role·인프라(이미지/로그) 권한은 Execution Role, 영속/공유 데이터는 EFS, 비용은 Spot, 확장은 Service Auto Scaling.
References
댓글
아직 댓글이 없습니다.