AI 시대로 전환이 가속화되면서 Amazon ECS가 다시 주목받고 있습니다. 모델 추론 서버부터 AI 에이전트와 에이전트가 호출하는 도구까지 컨테이너로 배포되는 워크로드가 증가했고, GPU 컴퓨트와 급격한 트래픽 변화를 감당하는 일들이 컨테이너 운영의 일상이 되었기 때문입니다. 하지만 ECS로 컨테이너 워크로드를 운영하다 보면 비슷한 고민과 마주치게 됩니다. EC2에서 제공되던 서비스를 Fargate로 이전할 때 시작 유형(launch type)이 변경되지 않아 어려움을 […] ||
AI 시대로 전환이 가속화되면서 Amazon ECS가 다시 주목받고 있습니다. 모델 추론 서버부터 AI 에이전트와 에이전트가 호출하는 도구까지 컨테이너로 배포되는 워크로드가 증가했고, GPU 컴퓨트와 급격한 트래픽 변화를 감당하는 일들이 컨테이너 운영의 일상이 되었기 때문입니다. 하지만 ECS로 컨테이너 워크로드를 운영하다 보면 비슷한 고민과 마주치게 됩니다. EC2에서 제공되던 서비스를 Fargate로 이전할 때 시작 유형(launch type)이 변경되지 않아 어려움을 겪거나, GPU 인스턴스는 필요하지만 OS 패치 운영까지 직접 챙기기는 부담스럽습니다. 또한 6종으로 증가한 배포 전략 가운데 무엇을 선택해야 할지 판단하기 어렵습니다.
기업이 겪는 이 고민의 답은 한 가지 원칙으로 귀결됩니다. launch type은 이제 호환되는 실행 환경을 표시하는 용도로만 남기고, 실제 실행은 용량 공급자(capacity provider)로 구성하라는 것입니다. 두 편에 걸쳐 이 선택지들을 정리합니다. 1부인 이 글에서는 원칙이 무엇을 의미하는지에서 시작해서 2026년 8월 기준 Amazon ECS의 컴퓨트와 실행 형태를 살펴보고, 2부에서 배포 전략과 네트워크, 스토리지를 거쳐 상황별 선택 가이드를 제시합니다.
1. 선언과 실행의 분리: launch type과 capacity provider
“ECS Task는 무엇으로 실행되는가”라는 질문에 대한 권고답변은 이제 두 가지 흐름으로 나뉩니다. launch type은 Task의 설계도 격인 Task definition이 어떤 실행 환경과 호환되는지를 나타내는 값입니다. capacity provider는 Task를 올릴 컴퓨트 용량을 실제로 공급하고 스케일링하는 실행 수단입니다. Amazon ECS 개발자 가이드는 launch type을 Task definition의 requiresCompatibilities 필드, 즉 호환되는 실행 환경을 선언하는 파라미터 용도로만 사용할 것을 권고합니다. 그리고 실제 실행은 capacity provider로 구성하라고 권고합니다.
그림 1. launch type(선언)과 capacity provider(실행)의 분리 – EXTERNAL과 Spot Fleet 예외는 표 1 참고
launch type과 capacity provider가 1:1로 짝을 이루지는 않습니다. 표 1은 컴퓨트별 대응 관계와 함께, 어느 한쪽에만 존재하는 항목이 무엇인지 보여줍니다.
컴퓨트
launch type (선언)
capacity provider (실행)
Fargate
FARGATE
FARGATE / FARGATE_SPOT – ECS가 모든 클러스터에 자동 생성, 별도 생성 불필요
자체 관리 EC2
EC2
Auto Scaling group
ECS Managed Instances
MANAGED_INSTANCES
ECS Managed Instances
온프레미스 (ECS Anywhere)
EXTERNAL
없음 – launch type으로만 지정
EC2 Spot Fleet
없음 – capacity provider 전용
Spot Fleet (표기 상충, 아래 설명 참고)
표 1. launch type 4종과 capacity provider의 대응 관계
온프레미스용 EXTERNAL은 launch type으로만 존재하고, Spot Fleet은 반대로 capacity provider 쪽에만 이름이 올라 있