AWS 기술 블로그
Amazon ECS 실행 구조와 선택 기준 – 1부: 컴퓨트와 실행 형태
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 쪽에만 이름이 올라 있습니다. 다만 Spot Fleet 행은 유보가 필요합니다. 개발자 가이드에는 “Spot Fleet은 capacity provider로만 제공된다”는 문장이 있지만, 같은 문단의 지원 목록(FARGATE, FARGATE_SPOT, Auto Scaling group, ECS Managed Instances)에는 빠져 있고, CreateCapacityProvider API 역시 Auto Scaling group과 Managed Instances 두 종류만 생성할 수 있습니다. 공식 문서 안에서도 표기가 엇갈리는 항목이므로 설계의 전제로 고려하지 않는 것이 안전합니다.
FARGATE SPOT을 쓴다면 중단 특성을 설계에 반영해야 합니다. Spot 중단 시 Task가 중지되기 2분 전에 경고가 오는데, Amazon EventBridge로 가는 Task 상태 변경 이벤트와 실행 중인 Task에 대한 SIGTERM 시그널 두 경로로 전달됩니다. 컨테이너가 SIGTERM을 처리하지 못하면 stopTimeout(기본 30초, Spot에서는 120초 이하 권장)이 지난 뒤 SIGKILL을 받아 데이터가 유실될 수 있습니다. 용량이 부족할 때 ECS가 Spot을 온디맨드로 대체해 주지 않습니다. 용량이 생길 때까지 시작을 재시도할 뿐입니다.
혼합 규칙은 계층에 따라 다릅니다. 하나의 클러스터에는 모든 종류의 capacity provider를 함께 등록할 수 있지만, Task를 어느 provider에 어떤 비중으로 배치할지 정하는 capacity provider strategy 안에서는 서로 다른 종류를 혼용할 수 없습니다. 클러스터 하나에 연결할 수 있는 capacity provider는 최대 20개이며, 이 값은 상향 조정 대상이 아닙니다.
1.1 서비스 전환 매트릭스
이 구분이 실무에서 차이를 만드는 지점은 이미 운영되고 있는 서비스를 마이그레이션 할 수 있는지에 대한 판단입니다. 표 2는 UpdateService API로 바꿀 수 있는 방향과 바꿀 수 없는 방향을 정리했습니다.
| 전환 방향 | 가능 여부 | 세부 |
|---|---|---|
| capacity provider → capacity provider | 가능 | 종류에 관계없이 전부 가능 |
| launch type → capacity provider | 가능 | 전부 가능 |
| launch type → launch type | 불가 | EC2 launch type에서 Fargate launch type으로 직접 전환 불가. 문서는 Fargate capacity provider 사용을 안내 |
| capacity provider → launch type | 불가 (예외 1건) | launch type으로 생성했던 서비스에 한해 capacityProviderStrategy를 비어있는 리스트로 넘기면 원래 launch type으로만 복귀 가능 |
표 2. launch type과 capacity provider 사이의 서비스 전환 매트릭스
핵심은 비대칭성입니다. launch type으로 시작한 서비스는 다른 launch type으로 변경할 방법이 없습니다. capacity provider로 이전하는 것은 언제든 가능하지만, 반대 방향으로 이전은 launch type으로 생성했던 서비스가 UpdateService에 비어있는 capacityProviderStrategy를 넘겨 원래 값으로 복귀하는 한 가지 경로뿐입니다.
따라서 EC2에서 Fargate로 옮기고 싶은 경우처럼 launch type 사이의 이동이 필요해 보이는 상황의 실제 방법은, launch type 전환이 아니라 Fargate capacity provider로의 전환입니다. 실행을 capacity provider로 구성해 두면 이후 어떤 capacity provider로든 이전 할 수 있기 때문에, 신규 서비스는 처음부터 capacity provider로 만드는 것이 AWS 권고이자 안전한 기본값입니다.
2. Fargate와 EC2 사이: ECS Managed Instances
ECS의 컴퓨트 선택은 오랫동안 둘 중 하나를 선택해야 하는 문제였습니다. 인프라를 AWS에 전부 위임하는 대신 인스턴스 선택권이 없는 Fargate와 고객이 선택권을 가져가는 대신 OS 패치까지 해야 하는 EC2로 나뉘어 있었습니다. GPU는 필요하지만 패치는 맡기고 싶은 고객은 선택지가 없었습니다. ECS Managed Instances는 이 공백을 채우는 세 번째 관리형 컴퓨트입니다.
인스턴스는 고객 계정에 생성되지만 소프트웨어와 OS 패치, 인스턴스 스케일링, 유지보수는 AWS가 담당합니다. 동시에 EC2 전체 기능에 접근할 수 있기 때문에 인스턴스 타입 선택과 GPU 사용이 가능합니다. 표 3은 컴퓨트 4종의 책임 분담과 과금 구조를 비교합니다.
| 컴퓨트 | 인프라 소유 | OS/패치 책임 | 인스턴스 타입 선택 | GPU, 특수 하드웨어 | 과금 |
|---|---|---|---|---|---|
| Fargate | AWS | AWS | 불가 (vCPU/메모리만 지정) | 불가 | Task가 요청한 vCPU/메모리/스토리지 기준, 초 단위 (최소 1분) |
| ECS Managed Instances | 고객 계정 | AWS | 가능 (속성 기반 선택) | 가능 | EC2 인스턴스 요금 + 인스턴스 타입별 관리 요금, 초 단위 (최소 1분) |
| EC2 (Auto Scaling group) | 고객 | 고객 | 가능 | 가능 | EC2 등 기반 리소스 요금만 (ECS 오케스트레이션 무료) |
| External (온프레미스) | 고객 (온프레미스) | 고객 | 해당 없음 | 가능 | 등록 인스턴스당 $0.01025/시간 (최소 1시간) |
표 3. 컴퓨트 4종 비교 – 소유, 책임, 선택권, 과금
External(ECS Anywhere)은 ELB 로드밸런싱과 awsvpc 모드 등이 지원되지 않는 기능 제약을 전제로 선택해야 하며, 제약 목록은 2부의 상황별 선택 가이드에서 다시 다룹니다.
표 3에서 Fargate의 “vCPU/메모리만 지정”도 제약 없는 조합은 아닙니다. 0.25 vCPU에서 32 vCPU까지 CPU 티어별로 허용되는 메모리 값이 정해진 조합만 유효하고(예를 들어 0.25 vCPU는 512MiB, 1GB, 2GB 세 가지), 조합을 벗어난 값은 RegisterTaskDefinition 단계에서 에러로 거부됩니다.
Managed Instances의 과금은 두 가지로 구성됩니다. 표준 EC2 인스턴스 요금에 인스턴스 타입별로 다른 관리 요금이 더해지고, 두 요금 모두 초 단위로 계산되며 최소 1분이 적용됩니다. 관리 요금은 EC2 구매 옵션과 무관해서 Savings Plans, 예약 인스턴스, Spot 할인은 EC2 요금 쪽에만 적용됩니다. 자세한 과금은 Amazon ECS 요금 페이지에서 확인할 수 있습니다.
2.1 Managed Instances를 선택하는 5가지 상황
ECS 개발자 가이드는 Managed Instances를 선택할 상황을 다섯 가지로 제시합니다.
- Fargate에 없는 가속 컴퓨트, 특정 CPU 명령어 집합, 고성능 네트워크, 대용량 메모리가 필요한 워크로드
- NVIDIA 또는 AMD GPU 워크로드
- EC2 용량을 사전 예약하는 Capacity Reservation이 필요한 미션 크리티컬 워크로드
- Linux 커널 안에서 검증된 프로그램을 실행하는 eBPF 기반 모니터링처럼 OS 수준의 권한이 필요한 보안, 관측 도구
- 대형 인스턴스에 여러 Task를 배치해 활용률을 높이는 비용 최적화
이미 Fargate에서 운영 중이라면 Managed Instances 마이그레이션 가이드를 참고해 기존 워크로드를 옮길 수 있습니다.
2.2 운영 파라미터: launch template, 용량, 모니터링, 태그
Managed Instances에서는 EC2 인스턴스 시작 설정을 담는 launch template을 ECS가 직접 생성합니다. 인스턴스 프로파일, 네트워크, 스토리지, 용량 옵션, 인스턴스 요건이 모두 이 템플릿으로 관리됩니다. 표 3의 “속성 기반 선택”은 인스턴스 타입을 하나씩 고르는 대신 vCPU 수와 메모리 크기 범위(필수), 가속기 요건(선택) 같은 속성을 정의하면 ECS가 부합하는 타입을 자동으로 고르는 방식입니다. 특정 타입 지정은 특수 하드웨어가 필요한 워크로드로 한정하라는 것이 문서의 권고입니다.
- 용량 옵션 3종 – On-Demand, Spot, Capacity Reservation
- 모니터링 2종 – 기본(대부분 지표 5분 간격, 상태 확인은 1분, 무료)과 상세(전 지표 1분 간격)
- 태그 전파(tag propagation)를
CAPACITY_PROVIDER로 켜면 관리형 인스턴스, 컨테이너 인스턴스, launch template, 볼륨, ENI가 동일한 태그를 공유합니다
2.3 Managed daemons: 에이전트의 중앙 관리
2026년 4월 1일에 발표된 Managed daemons는 모니터링, 로깅, 추적 에이전트를 플랫폼 팀이 중앙에서 관리하는 구성입니다. 애플리케이션 팀과 조율 없이 독립적으로 배포하고 업데이트할 수 있으며, ECS Managed Instances capacity provider 전용입니다. 뒤에서 다룰 서비스의 DAEMON 배치 전략과는 이름만 비슷할 뿐 다른 기능입니다.
데몬 프로세스는 인스턴스당 1개 실행됩니다. 애플리케이션 Task보다 먼저 시작되고 마지막에 종료되어 관측 연속성을 보장합니다. 데몬 전용 Task definition으로 별도 관리하고 롤링 방식으로 자동 업데이트합니다. 기능 자체는 추가 요금 없이 데몬 Task의 컴퓨트 리소스만 과금됩니다.
2.4 ECS 밖으로 확장: AWS Batch 지원
2026년 8월 25일부터 AWS Batch가 ECS Managed Instances를 신규 컴퓨트 옵션으로 지원합니다. GPU 가속과 컴퓨트 집약 배치 워크로드를 실행하면서 AMI 업데이트, 보안 패치, 인스턴스 라이프사이클은 AWS가 자동으로 수행합니다. 시작 경로는 Batch 콘솔 또는 CreateComputeEnvironment API이고, 용량 옵션은 On-Demand, Spot, 예약 인스턴스입니다.
3. 서비스와 Task 실행 형태
컴퓨트를 정했으면 다음 질문은 Task를 어떤 형태로 돌릴 것인가입니다. 선택지는 네 가지입니다. 가장 빠르게 시작하는 Express Mode, 표준 장기 실행인 표준 서비스, 일회성 실행인 RunTask, 정기 실행인 예약 Task입니다. 상시 서빙 워크로드는 Express Mode나 표준 서비스로, 배치성 작업은 RunTask나 예약 Task로 나뉩니다.
3.1 Express Mode: 입력 3개로 서비스 완성
Express Mode는 컨테이너 이미지, Task 실행 역할, 인프라 역할 3개만 주면 나머지를 ECS가 자동으로 구성하는 실행 형태입니다. Fargate 서비스, 고유 접근 URL, SSL/TLS 로드밸런서, 오토스케일링, 모니터링, 네트워킹이 한 번에 만들어지고, 퍼블릭과 프라이빗 HTTPS를 모두 지원합니다.
비용 구조는 단순합니다. Express Mode 자체는 추가 요금이 없고 생성된 하위 리소스만 과금됩니다. 또한 동일한 네트워킹 구성의 Express 서비스끼리는 ALB를 공유해 비용을 줄입니다.
제약은 줄어드는 추세입니다. 2026년 7월 1일부터 커스텀 Task definition을 지원해 보안 사이드카, 헬스 체크, Linux 런타임 설정, FireLens 로그 라우팅 같은 Task 수준 커스터마이징이 가능해졌으며, 기존 CI/CD와 IaC의 Task definition도 그대로 재사용할 수 있습니다. 생성된 리소스가 모두 고객 계정에 있으므로 언제든 직접 관리로 전환할 수 있습니다. 한 가지 고려해 둘 상한도 있습니다. Task definition 하나에 담을 수 있는 container definition은 10개로 고정이기 때문에, 보안 사이드카를 여러 개 붙이거나 프록시 컨테이너가 주입되는 Service Connect 구성처럼 Task 내부에 컨테이너가 증가하는 설계라면 이 한도를 계산에 넣어야 합니다.
3.2 표준 서비스: REPLICA와 DAEMON
서비스의 schedulingStrategy 유효값은 REPLICA와 DAEMON 2종이고 기본값은 REPLICA입니다. REPLICA는 원하는 수의 Task를 클러스터에 유지하며 기본적으로 가용 영역에 분산 배치합니다. DAEMON은 배치 제약을 충족하는 활성화된 컨테이너 인스턴스마다 Task를 정확히 1개씩 배포하므로 서비스가 유지할 목표 Task 수인 desiredCount와 오토스케일링 설정이 필요 없습니다.
DAEMON의 제약은 컴퓨트와 배포 컨트롤러 양쪽에 해당됩니다. 개발자 가이드는 Fargate Task뿐 아니라 CODE_DEPLOY, EXTERNAL 배포 컨트롤러를 쓰는 Task도 DAEMON 전략을 지원하지 않는다고 명시합니다. 컴퓨트가 EC2 계열이어도 CodeDeploy Blue/Green 파이프라인을 유지하는 서비스라면 DAEMON을 만들 수 없습니다.
3.3 일회성 실행과 정기 실행: RunTask와 EventBridge Scheduler
상시 유지가 필요 없는 작업은 서비스 없이 Task를 직접 실행합니다. 큐에 작업이 들어올 때 프로세스가 RunTask를 호출하는 일회성 실행이 대표적입니다. RunTask API 호출 한 번으로 기동할 수 있는 Task는 최대 10개로 고정이므로, 그 이상은 호출을 나누어 실행합니다.
정기 실행은 일정 기반으로 Task를 기동하는 Amazon EventBridge Scheduler가 담당합니다. 고정 간격(rate)이나 cron 표현식으로 지정한 시각에 클러스터의 Task를 하나 이상 실행합니다. 현재 문서는 범용 EventBridge 규칙 대신 EventBridge Scheduler를 명시하므로, 신규 구성은 Scheduler 기준으로 잡는 것이 정확합니다.
4. 마치며
글머리의 고민 가운데 두 가지는 이번 편에서 가이드가 제시되었습니다. EC2에서 Fargate로 이전하고 싶다면 launch type을 바꾸는 대신 Fargate capacity provider로 전환하는 것이 올바른 선택입니다. 처음 시작할 때 신규 서비스를 capacity provider로 만들어 두면 이 고민 자체가 생기지 않습니다. GPU는 필요한데 패치는 맡기고 싶다면 Fargate와 EC2 사이에 새로운 옵션 ECS Managed Instances가 그 공백을 채웁니다.
컴퓨트 선택을 판단 순서로 정리하면 다음과 같습니다.
그림 2. 컴퓨트 선택 판단 플로우 – 실행 형태와 배포 전략까지 아우른 전체 조합은 2부의 상황별 선택 가이드에서 다룹니다
이제 남은 고민은 배포입니다. 2부에서는 6종으로 증가한 배포 전략에서 시작해 네트워크와 스토리지, 플랫폼 옵션을 살펴보고, 두 편에서 다룬 선택 기준을 종합해서 상황별 선택 가이드와 설계 상한이 되는 서비스 쿼터로 구현합니다.
참조
- Amazon ECS launch type과 capacity provider 비교 (개발자 가이드)
- Fargate capacity provider (개발자 가이드)
- Amazon ECS Managed Instances (개발자 가이드)
- Fargate Task의 CPU와 메모리 유효 조합 (개발자 가이드)
- Amazon ECS 요금
- Fargate에서 Amazon ECS Managed Instances로 마이그레이션 (개발자 가이드)
- Amazon ECS Managed Instances의 Managed daemons 지원 발표 (AWS 블로그)
- AWS Batch의 ECS Managed Instances 지원 (What’s New)
- Amazon ECS Express Mode (개발자 가이드)