AMAZON ECS / FEATURE ANALYSIS

ECS는 무엇으로 어떻게 실행되나 - 컴퓨트, 배포, 네트워크 형태 전부 정리

launch type은 선언용이고 실제 실행은 capacity provider로 구성하라는 권고가 Amazon ECS의 가장 중요한 변화입니다. 이 프레임 전환을 축으로 2026-08 기준 ECS의 컴퓨트, 실행, 배포, 네트워크, 스토리지 선택지를 한 문서에 정리합니다.

01. 작성 기준일 - 2026-08-26

02. 적용 대상 - Amazon ECS로 컨테이너 워크로드를 운영하거나 도입을 검토하는 팀

03. 문서 범위 - 컴퓨트/실행/배포/네트워크/스토리지 축, 2026-08 기준

04. 주 출처 - ECS 개발자 가이드(1차 확인 4건)와 AWS What's New/블로그(본문 사전 검증)

요약

01가장 중요한 변화 - 선언과 실행의 분리

"ECS는 무엇으로 실행되나"에 대한 답은 이제 두 겹입니다. launch type은 태스크 정의가 어떤 실행 환경과 호환되는지 밝히는 선언이고, capacity provider는 태스크를 올릴 컴퓨트 용량을 실제로 공급하고 스케일링하는 실행 수단입니다. ECS 개발자 가이드는 launch type을 태스크 정의의 requiresCompatibilities 필드(호환되는 실행 환경을 선언하는 파라미터) 용도로만 쓰고, 실제 실행은 capacity provider로 구성하라고 권고합니다.

두 축은 1:1로 대응하지 않습니다. 표 1처럼 온프레미스용 EXTERNAL은 launch type에만 있고, 개발자 가이드가 capacity provider 전용이라고 언급하는 Spot Fleet은 launch type 목록에 없습니다. 다만 Spot Fleet 표기는 공식 문서 안에서 상충하므로 표 아래에 유보를 달았습니다.

표 1. launch type 4종과 capacity provider 4종의 대응 관계
컴퓨트 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의 Spot Fleet 행은 공식 문서 내 표기가 상충하므로 유보가 필요합니다. 개발자 가이드에는 "Spot Fleet은 capacity provider로만 제공된다"는 문장이 있으나, 같은 문단의 지원 열거 (FARGATE / FARGATE_SPOT / Auto Scaling group / ECS Managed Instances)에는 빠져 있고, CreateCapacityProvider API도 Auto Scaling group과 Managed Instances 두 종류의 생성만 지원합니다.

표 1의 FARGATE_SPOT은 중단 특성을 설계에 반영해야 합니다. Spot 중단 시 태스크 중지 2분 전에 경고가 오는데, EventBridge로 가는 task state change 이벤트와 실행 중인 태스크에 대한 SIGTERM 시그널 두 경로로 전달됩니다. 컨테이너가 SIGTERM을 처리하지 못하면 stopTimeout(기본 30초, Spot에서는 120초 이하 권장)이 지난 뒤 SIGKILL을 받아 데이터 유실이 생길 수 있고, 용량 부족 시 ECS는 Spot을 온디맨드로 대체하지 않고 용량이 생길 때까지 기동을 재시도합니다.

혼합 규칙은 계층에 따라 다릅니다. 하나의 클러스터에는 모든 종류의 capacity provider를 혼합해 등록할 수 있지만, 하나의 capacity provider strategy(태스크를 어느 provider에 어떤 비중으로 배치할지 정하는 규칙) 안에서는 서로 다른 종류를 섞을 수 없습니다.

1.1 서비스 전환 매트릭스

이 구분이 실무에서 갈리는 지점은 이미 돌아가는 서비스의 전환 가능성입니다. 표 2는 UpdateService로 바꿀 수 있는 방향과 없는 방향을 정리한 것입니다.

표 2. 서비스 전환 매트릭스 - launch type과 capacity provider 사이
전환 방향 가능 여부 세부
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으로만 복귀 가능
주의 - 전환 규칙이 만드는 함정

launch type으로 시작한 서비스는 다른 launch type으로 바꿀 길이 없습니다. capacity provider로 옮기는 것은 언제든 가능하지만, 반대 방향은 launch type으로 생성했던 서비스가 UpdateService에 빈 capacityProviderStrategy를 넘겨 원래 값으로 복귀하는 한 가지 경로뿐입니다.

즉 launch type 사이의 이동이 필요해 보이는 상황(예: EC2에서 Fargate로)의 실제 해법은 launch type 전환이 아니라 Fargate capacity provider로의 전환입니다. 실행을 capacity provider로 구성해 두면 이후 어떤 capacity provider로든 옮길 수 있으므로, 신규 서비스는 처음부터 capacity provider로 만드는 것이 안전합니다.

02ECS Managed Instances - Fargate와 EC2 사이

ECS의 컴퓨트 선택은 오랫동안 양자택일이었습니다. 인프라를 전부 맡기는 대신 인스턴스 선택권이 없는 Fargate, 선택권을 갖는 대신 OS 패치까지 떠안는 EC2 두 갈래여서, GPU는 필요하지만 패치는 맡기고 싶은 팀이 설 자리가 없었습니다. ECS Managed Instances는 이 빈칸을 채우는 세 번째 관리형 컴퓨트입니다.

인스턴스는 고객 계정에 생성되지만 소프트웨어와 OS 패치, 인스턴스 스케일링, 유지보수는 AWS가 담당합니다. 동시에 EC2 전체 기능에 접근할 수 있어 인스턴스 타입 선택과 GPU 사용이 가능합니다. 표 3은 컴퓨트 4종의 책임 분담을 비교한 것입니다.

표 3. 컴퓨트 4종 비교 - 소유, 책임, 선택권
컴퓨트 인프라 소유 OS/패치 책임 인스턴스 타입 선택 GPU, 특수 하드웨어
Fargate AWS AWS 불가 (vCPU/메모리만 지정) 불가
ECS Managed Instances 고객 계정 AWS 가능 (유연 선택) 가능
EC2 (Auto Scaling group) 고객 고객 가능 가능
External (온프레미스) 고객 (온프레미스) 고객 해당 없음 가능

표 3에서 Fargate의 "vCPU/메모리만 지정"도 자유 조합이 아닙니다. 0.25 vCPU에서 32 vCPU까지 CPU 티어별로 허용 메모리 대역이 고정된 이산 조합만 유효하고(예: 0.25 vCPU는 512 MiB / 1 GB / 2 GB 3가지), 조합을 벗어난 값은 RegisterTaskDefinition 단계에서 에러로 거부됩니다.

2.1 언제 선택하나 - 문서가 제시하는 기준 5가지

ECS 개발자 가이드는 Managed Instances를 선택할 상황을 다섯 가지로 제시합니다.

  1. Fargate에 없는 가속 컴퓨트, 특정 CPU 명령어 집합, 고성능 네트워크, 대용량 메모리가 필요한 워크로드
  2. NVIDIA 또는 AMD GPU 워크로드
  3. Capacity Reservation(EC2 용량 사전 예약)이 필요한 미션 크리티컬 워크로드
  4. eBPF(Linux 커널 안에서 검증된 프로그램을 실행하는 기술) 기반 모니터링처럼 OS 특권 접근이 필요한 보안/관측 도구
  5. 대형 인스턴스에 여러 태스크를 배치해 활용률을 끌어올리는 비용 최적화

이미 Fargate에서 운영 중이라면 Managed Instances로의 마이그레이션을 다루는 전용 가이드 문서가 있습니다.

2.2 운영 파라미터 - launch template, 용량, 모니터링, 태그

Managed Instances에서는 ECS가 launch template(EC2 인스턴스 시작 설정을 담는 템플릿)을 직접 생성합니다. 이 템플릿으로 인스턴스 프로파일, 네트워크, 스토리지, 용량 옵션, 인스턴스 요건을 관리합니다.

  • 용량 옵션 3종 - On-Demand / Spot / Capacity Reservation
  • 모니터링 2종 - 기본(5분 간격, 무료) / 상세(전 지표 1분 간격)
  • tag propagation을 CAPACITY_PROVIDER로 켜면 관리형 인스턴스, 컨테이너 인스턴스, launch template, 볼륨, ENI가 동일한 태그를 공유합니다

2.3 Managed daemons - 에이전트의 중앙 관리

2026-04-01에 발표된 Managed daemons는 모니터링, 로깅, 추적 에이전트를 플랫폼 팀이 중앙에서 관리하는 구성체입니다. 애플리케이션 팀과 조정 없이 독립적으로 배포하고 업데이트할 수 있으며, ECS Managed Instances capacity provider 전용입니다. 서비스의 schedulingStrategy: DAEMON(3.2절)과는 이름만 비슷할 뿐 별개 기능입니다.

데몬 프로세스는 인스턴스당 정확히 1개 실행됩니다. 애플리케이션 태스크보다 먼저 시작되고 마지막에 종료되어 관측 연속성을 보장합니다. 별도의 daemon task definition으로 관리하고 롤링 방식으로 자동 업데이트하며, 기능 자체는 추가 요금 없이 데몬 태스크의 컴퓨트 리소스만 과금됩니다.

2.4 ECS 밖으로 - AWS Batch 지원

2026-08-25부터 AWS Batch가 ECS Managed Instances를 신규 컴퓨트 옵션으로 지원합니다. GPU 가속과 컴퓨트 집약 배치 워크로드를 실행하면서 AMI 업데이트, 보안 패치, 인스턴스 라이프사이클은 AWS가 자동 처리합니다.

시작 경로는 Batch 콘솔 또는 CreateComputeEnvironment API이고, 용량 옵션은 On-Demand / Spot / Reserved Instances입니다.

03서비스와 태스크 실행 형태

컴퓨트를 정했으면 다음 질문은 태스크를 어떤 형태로 돌릴 것인가입니다. 선택지는 가장 빠르게 시작하는 Express Mode, 표준 장기 실행인 서비스, 단발 실행인 RunTask, 정기 실행인 예약 태스크 네 가지입니다. 그림 1은 네 형태의 선택 분기입니다.

flowchart TD Q{"태스크를 어떻게 돌릴 것인가"} Q -->|"가장 빠른 시작"| E["Express Mode
이미지 + 역할 2개로 자동 구성"] Q -->|"표준 장기 실행"| S["서비스
REPLICA / DAEMON"] Q -->|"단발 작업"| R["RunTask
독립 태스크"] Q -->|"정기 실행"| V["EventBridge Scheduler 예약
rate / cron"]
그림 1. 태스크 실행 형태 선택 분기. 상시 서빙 워크로드는 Express Mode 또는 서비스로, 배치성 작업은 RunTask 또는 예약 태스크로 갈립니다.

3.1 Express Mode - 입력 3개로 서비스 완성

Express Mode는 컨테이너 이미지, 태스크 실행 역할, 인프라 역할 3개만 주면 나머지를 ECS가 자동 구성하는 실행 형태입니다. Fargate 서비스, 고유 접근 URL, SSL/TLS 로드밸런서, 오토스케일링, 모니터링, 네트워킹이 한 번에 만들어지고, 퍼블릭과 프라이빗 HTTPS를 모두 지원합니다.

비용 구조는 단순합니다. Express Mode 자체는 추가 요금이 없고 생성된 하위 리소스만 과금되며, 동일한 네트워킹 구성의 Express 서비스끼리는 ALB를 공유해 비용을 줄입니다.

제약은 줄고 있습니다. 2026-07-01부터 커스텀 태스크 정의를 지원해 보안 사이드카, 헬스 체크, Linux 런타임 설정, FireLens 로그 라우팅 같은 태스크 수준 커스터마이징과 기존 CI/CD, IaC의 태스크 정의를 그대로 재사용할 수 있습니다. 생성된 리소스가 모두 고객 계정에 있으므로 언제든 직접 관리로 전환할 수 있습니다.

3.2 표준 서비스 - REPLICA와 DAEMON

서비스의 schedulingStrategy 유효값은 REPLICA와 DAEMON 2종이고 기본값은 REPLICA입니다. REPLICA는 원하는 수의 태스크를 클러스터에 유지하며 기본적으로 가용 영역에 분산 배치합니다. DAEMON은 배치 제약을 충족하는 활성 컨테이너 인스턴스마다 태스크를 정확히 1개씩 배포하므로 desiredCount와 오토스케일링 설정이 필요 없습니다.

DAEMON은 EC2 계열 전용입니다. 개발자 가이드는 Fargate 태스크가 DAEMON 전략을 지원하지 않는다고 명시합니다.

3.3 단발과 정기 - RunTask와 EventBridge Scheduler

상시 유지가 필요 없는 작업은 서비스 없이 태스크를 직접 실행합니다. 큐에 작업이 들어올 때 프로세스가 RunTask를 호출하는 단발 실행이 대표적입니다.

정기 실행은 EventBridge Scheduler(일정 기반으로 태스크를 기동하는 스케줄링 서비스)가 담당합니다. 고정 간격(rate) 또는 cron 표현식으로 지정한 시각에 클러스터의 태스크를 하나 이상 실행합니다. 현행 문서가 범용 EventBridge 규칙이 아니라 EventBridge Scheduler를 명시하므로, 신규 구성은 Scheduler 기준으로 잡는 것이 정확합니다.

04배포 전략 6종

새 리비전을 내보내는 방법은 Rolling / CodeDeploy Blue/Green / External 3종에서 6종으로 늘었습니다. 공식 문서의 구조는 배포 컨트롤러 3종(ECS / CodeDeploy / External)이고, 이 중 ECS 컨트롤러가 ROLLING / BLUE_GREEN / LINEAR / CANARY 4개 전략을 품습니다. 합산하면 6가지 방식이고 기본값은 Rolling입니다.

표 4는 6종 각각의 전환 방식과 로드밸런서 요구, 적합한 상황을 정리한 것입니다.

표 4. 배포 전략 6종 - 방식과 적합 상황
전략 컨트롤러 전환 방식 로드밸런서 요구 적합 상황
Rolling ECS 태스크 점진 교체. minimumHealthyPercent 하한과 maximumPercent 상한으로 속도 제어 불필요 점진적 트래픽 제어가 불필요한 대부분의 서비스. 기본값이며 로드밸런서를 요구하지 않는 전략
Blue/Green (내장) ECS 그린 환경을 테스트 트래픽으로 선검증 후 프로덕션 트래픽 전량 즉시 전환 ALB/NLB 또는 Service Connect 즉시 전환과 신속 롤백이 필요한 서비스
Linear ECS 동일 비율 증분으로 점진 전환. step 3.0~100.0%, step bake 0~1,440분 ALB/NLB 또는 Service Connect 트래픽을 조금씩 옮기며 지표를 확인해야 하는 서비스
Canary ECS 2단계 전환 - 소량 트래픽 선검증 후 나머지 일괄 전환 ALB/NLB 또는 Service Connect 신버전을 소량 트래픽으로 먼저 검증하고 싶은 서비스
Blue/Green (CodeDeploy) CODE_DEPLOY CodeDeploy 사전 정의 구성으로 canary / linear / all-at-once 전환 ALB/NLB 필수, NLB는 all-at-once만 기존 CodeDeploy 파이프라인을 유지해야 하는 팀
External EXTERNAL 서드파티 컨트롤러가 task set의 scale 값으로 직접 제어 선택. 쓰면 ALB/NLB만 자체 배포 도구를 가진 조직

선택 기준에 대한 AWS의 입장은 명확합니다. CodeDeploy Blue/Green 배포 문서는 제목 바로 아래 첫 문단에서 내장 Blue/Green 사용을 권장한다고 명시합니다. CodeDeploy 방식은 기존 파이프라인 유지가 필요한 경우의 선택지로 남습니다.

4.1 내장 고급 배포의 공통 구조 - 6단계와 bake time

내장 Blue/Green, Linear, Canary는 CodeDeploy 없이 ECS 컨트롤러가 직접 수행하며, 준비 → 배포 → 테스트 → 트래픽 전환 → 모니터링 → 완료의 공통 6단계(phase) 구조를 공유합니다. 세부적으로는 11개 lifecycle stage로 나뉘고, 스테이지에 따라 Lambda 훅(Hook)을 걸 수 있습니다. bake time(트래픽 전환 후 구 리비전과 신 리비전을 동시에 가동하며 지표를 지켜보는 구간)이 끝나야 구 환경이 정리됩니다.

역할 구분이 중요합니다. 내장 Blue/Green의 프로덕션 전환은 전량 즉시(all-at-once)이고, 점진 전환이 필요하면 Linear 또는 Canary를 선택해야 합니다. 세 전략 모두 2026-07-21부터 AWS European Sovereign Cloud에서도 제공됩니다.

4.2 Rolling의 세부 규칙

Rolling은 desiredCount 대비 백분율 2개로 교체 속도를 제어합니다. minimumHealthyPercent는 정상 태스크 수의 하한으로 올림 계산하고, maximumPercent는 상한으로 내림 계산합니다. 예를 들어 min 75%에 desired 2면 올림 결과가 2라서 어떤 태스크도 중지할 수 없습니다.

배포 중 비정상이 된 태스크는 자신이 속한 것과 동일한 서비스 리비전으로 교체됩니다. 실패 감지는 태스크 기동 실패를 잡는 deployment circuit breaker와 애플리케이션 지표를 보는 CloudWatch alarms 2종을 병용할 수 있고, 둘 다 이전 서비스 리비전으로의 롤백을 지원합니다.

4.3 2026년의 관측성과 스케일링 개선

전략 확장과 함께 배포 관측성도 개선되었습니다. 2026-07-01부터 ECS 콘솔 서비스의 Deployments 탭에서 라이브 배포 타임라인, 서킷 브레이커 상태, 태스크 실패 실시간 추적, 실패 태스크에서 CloudTrail로 이어지는 딥링크를 제공합니다.

2026-07-21에 발표된 Action Logs는 서비스 배포와 Managed daemon 업데이트 중 ECS가 고객 대신 수행한 동작을 타임스탬프 기록으로 남깁니다. 이벤트 이름, 로그 레벨(INFO/WARN/ERROR), 리소스 ARN, 상태 이유가 담기며, CloudWatch Logs / S3 / Kinesis Data Firehose로 전송하고 Amazon Q 통합으로 배포 문제의 근본 원인 분석을 지원합니다.

참고 - 두 관측성 기능의 적용 범위

실시간 배포 관측성은 Rolling 배포 유형 서비스만 해당하고, Blue/Green 등 다른 전략은 이번 발표 범위가 아닙니다. Action Logs는 클러스터 레벨 옵트인이며, 전송 대상 (CloudWatch Logs / S3 / Firehose)의 표준 요금이 적용됩니다.

배포와 별개로 서비스 오토스케일링 속도도 2026-06-18에 개선되었습니다. scale-out 트리거까지 걸리는 시간이 363초에서 86초로 76% 줄었고, 신규 태스크 프로비저닝을 포함한 전체 스케일 시간은 386초에서 109초로 72% 줄었습니다. 20초 간격 고해상도 메트릭 기반이고 Fargate / ECS Managed Instances / EC2 모두 대상이며, 고해상도 메트릭에는 표준 CloudWatch 요금이 적용됩니다.

05네트워크 형태

태스크가 네트워크에 붙는 방식은 태스크 정의의 network mode(컨테이너의 네트워크 연결 방식을 정하는 파라미터)가 정합니다. 모드는 5종이지만 OS에 따라 쓸 수 있는 조합이 갈립니다. 표 5는 EC2 기준 모드별 지원 OS와 특징을 정리한 것입니다.

표 5. 네트워크 모드 5종 - EC2 기준 Linux/Windows 지원과 특징
모드 Linux on EC2 Windows on EC2 특징
awsvpc 가능 가능 태스크가 전용 ENI와 사설 IP를 받습니다. 권장 모드
bridge 가능 불가 Docker bridge 드라이버 사용. Linux 기본값
host 가능 불가 호스트 ENI에 포트 직결. 동적 포트 매핑 불가, hostPort 명시 필수. 같은 태스크 정의를 한 인스턴스에서 여러 개 실행 불가
none 가능 불가 외부 네트워크 연결 없음
default 불가 가능 Docker nat 드라이버 사용. Windows 기본값

Fargate에는 선택지가 없습니다. 서비스 정의 문서는 Fargate 사용 시 awsvpc 모드가 필수라고 명시합니다. awsvpc 모드의 태스크는 EC2 인스턴스가 아니라 자기 ENI에 연결되므로, 로드밸런서 타겟 그룹도 ip 타입을 사용합니다.

5.1 IP 버전 - IPv6-only의 전제 조건

태스크 네트워킹은 IPv4, 듀얼스택, IPv6-only 세 가지 IP 구성을 지원합니다. IPv6-only는 서울 리전에서도 지원되지만, 세 구성 중 전제 조건 목록이 가장 깁니다.

참고 - IPv6-only 구성의 제약 목록
  • 듀얼스택 로드밸런서와 IPv6 타겟 그룹 필수
  • Windows 미지원. ECS 최적화 Linux AMI와 컨테이너 에이전트 1.99.1 이상 필수
  • 인스턴스 기동 시 --enable-primary-ipv6 필수. 누락하면 host/bridge 모드 태스크가 로드밸런서와 Cloud Map에 등록되지 않습니다
  • IPv4 엔드포인트와 통신하려면 DNS64/NAT64 필요. ECR은 듀얼스택 URI 사용
  • ECS Exec 미지원

5.2 서비스 간 연결 - Service Connect, Cloud Map, 로드밸런서

서비스 사이를 잇는 공식 옵션은 Service Connect, Service discovery(Cloud Map 기반 DNS), VPC Lattice 3종이고, 별도로 ALB/NLB 로드밸런싱을 씁니다. Service Connect는 서비스 디스커버리와 서비스 메시를 ECS 구성만으로 함께 제공하는 기능입니다. 태스크마다 프록시 컨테이너를 주입해 짧은 이름(short name)과 표준 포트로 서비스 간 통신을 처리하고, 기능 자체는 추가 요금이 없습니다.

서비스 메시 계획에는 마감일이 하나 걸려 있습니다. App Mesh는 2026-09-30에 지원이 종료되므로 신규 아키텍처에서 제외해야 하고, ECS의 서비스 메시 경로는 Service Connect 또는 VPC Lattice로 수렴합니다. 전환 실무는 App Mesh에서 VPC Lattice로 전환한 실측 기록 게시물에서 측정값 기준으로 다뤘습니다.

Service Connect로의 전환은 설정 변경이 아니라 서비스 재생성 이벤트입니다. 하나의 ECS 서비스는 App Mesh의 mesh와 Service Connect namespace에 동시에 속할 수 없어 서비스를 다시 만들어야 하고, 무중단이 필요하면 서비스 복제본을 만들어 트래픽을 점진 이전하는 blue/green 방식이 AWS 공식 권고입니다.

06스토리지, 플랫폼 축과 선택 가이드

남은 축은 데이터를 어디에 두는가와 플랫폼 세부 옵션입니다. 이 절에서 스토리지와 플랫폼 축을 정리하고, 표 6의 상황별 선택 가이드로 문서 전체를 묶습니다.

6.1 스토리지 - 임시에서 지속까지

태스크는 기본으로 임시 스토리지를 받고, 지속성이 필요하면 볼륨을 연결합니다. 개발자 가이드의 데이터 볼륨 옵션 가운데 다섯 갈래가 중심입니다.

  • Amazon EBS - 태스크당 볼륨을 자동 프로비저닝하고 태스크 종료 시 삭제합니다. Fargate / EC2 / Managed Instances 3종 컴퓨트를 모두 지원하고, 2026-05-18부터 AWS GovCloud (US) 리전으로 확장되었습니다
  • Amazon EFS - Linux 태스크용 지속 공유 스토리지. Fargate / EC2 / Managed Instances 지원
  • FSx for Windows File Server - Windows 태스크용 지속 스토리지. EC2 전용
  • Docker volume - Linux / Windows 지속 볼륨. EC2 전용
  • bind mount - 컨테이너 수명에 묶이는 임시(ephemeral) 볼륨. Fargate에서는 호스트 경로 마운트가 아니라 태스크에 할당된 임시 스토리지(기본 20 GiB, 최대 200 GiB)를 태스크 안 컨테이너끼리 공유하는 용도이고, 호스트 경로를 지정하는 host / sourcePath는 EC2 호스팅 태스크 전용입니다. Fargate / EC2 / Managed Instances 지원

현행 공식 문서의 볼륨 옵션 표에는 FSx for NetApp ONTAP과 Amazon S3 Files까지 총 7종이 올라 있습니다. Amazon S3 Files는 S3 데이터를 파일 시스템 인터페이스로 빠르게 캐시 접근하는 지속 볼륨으로, Fargate와 Managed Instances의 Linux 태스크를 지원합니다. 볼륨마다 지원 컴퓨트가 다르므로, FSx for Windows File Server와 Docker volume이 EC2 전용이라는 점을 포함해 공식 표에서 조합을 확인하고 설계하는 것이 안전합니다.

6.2 플랫폼 축 - OS, 아키텍처, GPU, 운영 도구

컴퓨트와 스토리지 바깥에도 선택을 좌우하는 축이 여섯 개 있습니다.

  • OS와 아키텍처 - Linux / Windows, x86_64 / ARM64(Graviton). ARM64는 Linux 전용이고 Fargate에서는 platform version 1.4.0 이상이 필요합니다
  • GPU - NVIDIA / AMD. Fargate는 GPU 미지원이므로 Managed Instances 또는 EC2에서 씁니다
  • Fargate platform version - 커널과 컨테이너 런타임 버전의 조합. 미지정 시 LATEST가 기본값이고, 새 태스크는 항상 해당 버전의 최신 revision에서 기동합니다
  • ECS Exec - 실행 중인 컨테이너에 셸로 접근하는 디버깅 도구. IPv6-only 구성에서는 미지원
  • 태스크 배치 - EC2는 placement strategy(binpack / random / spread)와 constraint를 모두 지원하고, Managed Instances는 strategy 없이 constraint만 지원하되 빌트인 attribute 가운데 ecs.subnet-id / ecs.availability-zone / ecs.instance-type / ecs.cpu-architecture 4종 subset만 허용하며, Fargate는 둘 다 지원하지 않습니다. Managed Instances와 Fargate의 가용 영역 분산은 플랫폼이 알아서 수행합니다
  • 스케일링 2층 - 태스크 수는 서비스 오토스케일링 (target tracking / step / scheduled / predictive 4종)이, 태스크를 올릴 용량은 capacity provider의 클러스터 오토스케일링이 담당합니다

스케일링 2층 가운데 용량 층을 EC2 Auto Scaling group capacity provider로 운영할 때의 관리 노브는 세 가지입니다. managed scaling을 켜면 ECS가 CapacityProviderReservation 메트릭과 target tracking 정책을 만들어 인스턴스의 scale-in/out을 대신 관리합니다. target capacity(유효 범위 1~100%)를 100 미만으로 두면 그만큼 여유 용량을 상시 확보해 후속 태스크 기동이 빨라지고, managed termination protection은 태스크가 실행 중인 인스턴스가 scale-in으로 종료되지 않게 보호합니다(ASG의 instance scale-in protection 활성화가 전제 조건).

6.3 상황별 선택 가이드

표 6은 이 문서의 축들을 상황별 권장 조합으로 요약한 것입니다.

표 6. 상황별 선택 가이드 - 컴퓨트, 실행, 배포, 연결
상황 권장 선택
웹 서비스를 가장 빠르게 올리고 싶다 Express Mode - 입력 3개로 자동 구성, 이후 직접 관리로 전환 가능
인프라 운영을 최소화한 표준 서비스 Fargate capacity provider
GPU나 특수 하드웨어는 필요하지만 패치는 맡기고 싶다 ECS Managed Instances capacity provider
OS와 인스턴스를 완전히 통제해야 한다 EC2 Auto Scaling group capacity provider
온프레미스 하드웨어를 그대로 쓴다 EXTERNAL launch type (ECS Anywhere)
단발 배치 작업 / 정기 실행 RunTask / EventBridge Scheduler 예약 태스크
점진적 트래픽 제어가 필요 없는 대부분의 서비스, 로드밸런서 없는 서비스 Rolling - 기본값이며 로드밸런서를 요구하지 않는 전략
신버전을 검증하며 트래픽을 옮기고 싶다 점진 전환은 Linear 또는 Canary, 선검증 후 즉시 전환은 내장 Blue/Green
서비스 메시가 필요하다 Service Connect 또는 VPC Lattice. App Mesh는 2026-09-30 지원 종료로 제외

표 6의 EXTERNAL(ECS Anywhere)은 기능 제약을 전제로 선택해야 합니다. ELB 로드밸런싱, service discovery, awsvpc 네트워크 모드, capacity provider, EFS 볼륨이 지원되지 않으므로, 공식 문서도 인바운드 트래픽을 받는 웹 서비스류 워크로드에는 비효율적이라고 명시합니다.

6.4 설계 상한 - 핵심 서비스 쿼터

마지막 축은 설계 상한이 되는 서비스 쿼터입니다. 표 7은 리전별 기본값 기준의 대표 수치입니다.

표 7. 대표 서비스 쿼터 - 리전별 기본값
쿼터 기본값 상향 조정
계정당 클러스터 수 10,000 가능
클러스터당 서비스 수 5,000 불가
서비스당 태스크 수 (desired count) 5,000 불가
클러스터당 컨테이너 인스턴스 수 5,000 불가
task definition family당 revision 수 1,000,000 불가

두 가지 함정이 있습니다. task definition revision은 등록 해제하거나 삭제해도 1,000,000 한도 계산에서 빠지지 않습니다. Fargate 쿼터는 태스크 수가 아니라 vCPU 개수 기준이고, 신규 계정은 낮은 초기값에서 시작해 사용량에 따라 자동 상향됩니다.

결론: 한 문장으로 요약하면, 선언은 태스크 정의의 requiresCompatibilities에 맡기고 실행은 capacity provider로 구성하며, 컴퓨트는 Fargate / Managed Instances / EC2의 책임 분담에서 고르고, 배포는 6종 전략 중 트래픽 전환 요구에 맞는 것을 선택하는 것이 2026-08 기준 ECS의 기본기입니다.

인터랙티브 아키텍처 맵 전체 이미지 - launch type 선언과 capacity provider 실행의 분리 구조
그림 2. 인터랙티브 아키텍처 맵 전체 보기. 이미지를 클릭하면 노드 탐색, 경로 추적, 다크/라이트 테마를 지원하는 인터랙티브 버전 ↗이 열립니다.

--참고 자료

핵심 출처 (본문 1차 확인)

공식 문서와 발표

AMAZON ECS / FEATURE ANALYSIS

What Runs ECS, and How - Compute, Deployment, and Network Models in One Place

The most important change in Amazon ECS is the guidance that launch type is for declaration and actual execution should be configured with capacity providers. Around this frame shift, this document organizes ECS compute, execution, deployment, network, and storage options as of 2026-08 in a single place.

01. Written as of - 2026-08-26

02. Audience - teams running container workloads on Amazon ECS or evaluating adoption

03. Scope - the compute / execution / deployment / network / storage axes, as of 2026-08

04. Primary sources - the ECS Developer Guide (4 primary checks) and AWS What's New / blog posts (verified against the guide before use)

TL;DR

01The most important change - separating declaration from execution

The answer to "what runs ECS" now has two layers. The launch type is a declaration of which execution environments a task definition is compatible with, and the capacity provider is the execution vehicle that actually supplies and scales the compute capacity tasks run on. The ECS Developer Guide recommends using the launch type only for the task definition's requiresCompatibilities field (the parameter that declares compatible execution environments) and configuring actual execution with capacity providers.

The two axes do not map 1:1. As Table 1 shows, EXTERNAL for on-premises exists only as a launch type, and Spot Fleet, which the Developer Guide mentions as capacity-provider-only, is absent from the launch type list. However, the Spot Fleet notation conflicts within the official documentation, so a reservation is noted below the table.

Table 1. Mapping between the 4 launch types and the 4 capacity providers
Compute launch type (declaration) capacity provider (execution)
Fargate FARGATE FARGATE / FARGATE_SPOT - auto-created by ECS for every cluster, no separate creation needed
Self-managed EC2 EC2 Auto Scaling group
ECS Managed Instances MANAGED_INSTANCES ECS Managed Instances
On-premises (ECS Anywhere) EXTERNAL None - specified only as a launch type
EC2 Spot Fleet None - capacity provider only Spot Fleet (conflicting notation - see note below the table)

The Spot Fleet row in Table 1 needs a reservation because the notation conflicts within the official documentation. The Developer Guide contains the sentence that Spot Fleet is available only as a capacity provider, yet the supported enumeration in the same passage (FARGATE / FARGATE_SPOT / Auto Scaling group / ECS Managed Instances) omits it, and the CreateCapacityProvider API also supports creating only two kinds - Auto Scaling group and Managed Instances.

FARGATE_SPOT in Table 1 requires designing for its interruption behavior. On a Spot interruption, a warning arrives 2 minutes before the task stops, delivered through two paths: a task state change event to EventBridge and a SIGTERM signal to the running task. If the container does not handle SIGTERM, it receives SIGKILL after stopTimeout (default 30 seconds; 120 seconds or less recommended on Spot) and data loss can follow, and when capacity runs short ECS does not replace Spot with On-Demand - it retries launching until capacity becomes available.

Mixing rules differ by layer. A single cluster can register every kind of capacity provider together, but within a single capacity provider strategy (the rule that decides which providers tasks are placed on and in what proportion), different kinds cannot be mixed.

1.1 The service switching matrix

Where this distinction bites in practice is whether an already-running service can be switched. Table 2 summarizes which directions UpdateService can and cannot change.

Table 2. Service switching matrix - between launch types and capacity providers
Direction Possible Details
capacity provider → capacity provider Yes All possible, regardless of kind
launch type → capacity provider Yes All possible
launch type → launch type No No direct switch from the EC2 launch type to the Fargate launch type. The docs point to using the Fargate capacity provider
capacity provider → launch type No (1 exception) Only a service originally created with a launch type can return to that launch type, by passing an empty capacityProviderStrategy list
Caution - the trap the switching rules create

A service started with a launch type has no path to another launch type. Moving to a capacity provider is always possible, but the reverse direction has exactly one route: a service originally created with a launch type can pass an empty capacityProviderStrategy to UpdateService and return to its original value.

In other words, when a move between launch types seems necessary (e.g. from EC2 to Fargate), the actual solution is not a launch type switch but a switch to the Fargate capacity provider. Once execution is configured with capacity providers, you can move to any capacity provider later, so creating new services with capacity providers from the start is the safe choice.

02ECS Managed Instances - between Fargate and EC2

For a long time, ECS compute was a binary choice: Fargate, which takes over all infrastructure but offers no instance choice, or EC2, which offers the choice but saddles you with OS patching. Teams that needed GPUs but wanted patching handled had nowhere to stand. ECS Managed Instances is the third managed compute that fills this gap.

Instances are created in the customer account, but AWS handles software and OS patching, instance scaling, and maintenance. At the same time you get access to the full EC2 feature set, so instance type selection and GPU use are possible. Table 3 compares the division of responsibility across the 4 compute options.

Table 3. The 4 compute options compared - ownership, responsibility, choice
Compute Infrastructure ownership OS/patching responsibility Instance type selection GPU, special hardware
Fargate AWS AWS No (vCPU/memory only) No
ECS Managed Instances Customer account AWS Yes (flexible) Yes
EC2 (Auto Scaling group) Customer Customer Yes Yes
External (on-premises) Customer (on-premises) Customer N/A Yes

Even Fargate's "vCPU/memory only" in Table 3 is not a free-form combination. From 0.25 vCPU to 32 vCPU, only discrete combinations with fixed allowed memory bands per CPU tier are valid (e.g. 0.25 vCPU allows 3 choices: 512 MiB / 1 GB / 2 GB), and values outside the combinations are rejected with an error at the RegisterTaskDefinition stage.

2.1 When to choose it - the 5 criteria the docs give

The ECS Developer Guide lists five situations that call for Managed Instances.

  1. Workloads needing accelerated compute, specific CPU instruction sets, high-performance networking, or large memory not available on Fargate
  2. NVIDIA or AMD GPU workloads
  3. Mission-critical workloads that need Capacity Reservations (pre-reserved EC2 capacity)
  4. Security/observability tools that need privileged OS access, such as eBPF-based monitoring (a technology that runs verified programs inside the Linux kernel)
  5. Cost optimization that raises utilization by packing multiple tasks onto large instances

If you already run on Fargate, there is a dedicated guide covering migration to Managed Instances.

2.2 Operational parameters - launch template, capacity, monitoring, tags

With Managed Instances, ECS creates the launch template (the template holding EC2 instance start settings) itself. It manages the instance profile, network, storage, capacity options, and instance requirements through this template.

  • 3 capacity options - On-Demand / Spot / Capacity Reservation
  • 2 monitoring levels - basic (5-minute interval, free) / detailed (all metrics at 1-minute interval)
  • Setting tag propagation to CAPACITY_PROVIDER makes managed instances, container instances, the launch template, volumes, and ENIs share the same tags

2.3 Managed daemons - central management of agents

Managed daemons, announced on 2026-04-01, is a construct that lets platform teams centrally manage monitoring, logging, and tracing agents. They can be deployed and updated independently, without coordinating with application teams, and are exclusive to the ECS Managed Instances capacity provider. It shares only the name with a service's schedulingStrategy: DAEMON (section 3.2) - the two are separate features.

Exactly 1 daemon process runs per instance. It starts before application tasks and stops last, guaranteeing observability continuity. It is managed as a separate daemon task definition and auto-updates in a rolling fashion; the feature itself carries no extra charge - only the daemon task's compute resources are billed.

2.4 Beyond ECS - AWS Batch support

Since 2026-08-25, AWS Batch supports ECS Managed Instances as a new compute option. You run GPU-accelerated and compute-intensive batch workloads while AWS automatically handles AMI updates, security patches, and the instance lifecycle.

The entry path is the Batch console or the CreateComputeEnvironment API, and the capacity options are On-Demand / Spot / Reserved Instances.

03Service and task execution models

Once compute is settled, the next question is what form the tasks should run in. There are four choices: Express Mode for the fastest start, a service for standard long-running work, RunTask for one-off runs, and scheduled tasks for recurring runs. Figure 1 shows the decision branches across the four forms.

flowchart TD Q{"How should the task run"} Q -->|"Fastest start"| E["Express Mode
auto-configured from an image + 2 roles"] Q -->|"Standard long-running"| S["Service
REPLICA / DAEMON"] Q -->|"One-off job"| R["RunTask
standalone task"] Q -->|"Recurring"| V["Scheduled via EventBridge Scheduler
rate / cron"]
Figure 1. Decision branches for task execution forms. Always-on serving workloads go to Express Mode or a service; batch-style jobs go to RunTask or a scheduled task.

3.1 Express Mode - a full service from 3 inputs

Express Mode is an execution form where you supply only 3 things - a container image, a task execution role, and an infrastructure role - and ECS configures the rest automatically. A Fargate service, a unique access URL, an SSL/TLS load balancer, auto scaling, monitoring, and networking are created in one shot, and both public and private HTTPS are supported.

The cost structure is simple. Express Mode itself carries no extra charge and only the created downstream resources are billed; Express services with the same networking configuration share an ALB to reduce cost.

The constraints keep shrinking. Since 2026-07-01 it supports custom task definitions, so task-level customization such as security sidecars, health checks, Linux runtime settings, and FireLens log routing - as well as task definitions from your existing CI/CD and IaC - can be reused as-is. Since the created resources all live in the customer account, you can switch to direct management at any time.

3.2 Standard services - REPLICA and DAEMON

The valid values for a service's schedulingStrategy are REPLICA and DAEMON, with REPLICA as the default. REPLICA maintains the desired number of tasks across the cluster, spreading them across Availability Zones by default. DAEMON deploys exactly 1 task on each active container instance that meets the placement constraints, so desiredCount and auto scaling settings are unnecessary.

DAEMON is EC2-family only. The Developer Guide states that Fargate tasks do not support the DAEMON strategy.

3.3 One-off and recurring - RunTask and EventBridge Scheduler

Jobs that need no always-on presence run tasks directly, without a service. The typical case is a one-off run where a process calls RunTask when work arrives in a queue.

Recurring runs are handled by EventBridge Scheduler (a scheduling service that starts tasks on a schedule). It runs one or more of the cluster's tasks at a fixed interval (rate) or at times given by a cron expression. The current documentation names EventBridge Scheduler rather than generic EventBridge rules, so it is accurate to build new setups on Scheduler.

04The 6 deployment strategies

The ways to roll out a new revision grew from the 3 of Rolling / CodeDeploy Blue/Green / External to 6. The official documentation is structured around 3 deployment controllers (ECS / CodeDeploy / External), and the ECS controller among them carries the 4 strategies ROLLING / BLUE_GREEN / LINEAR / CANARY. That adds up to 6 methods, and the default is Rolling.

Table 4 summarizes how each of the 6 strategies shifts traffic, its load balancer requirements, and where it fits.

Table 4. The 6 deployment strategies - method and fit
Strategy Controller Shift method Load balancer requirement Fits
Rolling ECS Gradual task replacement. Speed is controlled by the minimumHealthyPercent floor and the maximumPercent ceiling Not required Most services that need no gradual traffic control. The default, and a strategy that requires no load balancer
Blue/Green (built-in) ECS Pre-validates the green environment with test traffic, then shifts all production traffic at once ALB/NLB or Service Connect Services that need instant cutover and fast rollback
Linear ECS Gradual shift in equal increments. step 3.0~100.0%, step bake 0~1,440 minutes ALB/NLB or Service Connect Services that need to move traffic bit by bit while watching metrics
Canary ECS 2-stage shift - pre-validate with a small share of traffic, then shift the rest at once ALB/NLB or Service Connect Services that want to validate the new version on a small share of traffic first
Blue/Green (CodeDeploy) CODE_DEPLOY canary / linear / all-at-once shifts via CodeDeploy predefined configurations ALB/NLB required; NLB is all-at-once only Teams that must keep an existing CodeDeploy pipeline
External EXTERNAL A third-party controller drives it directly through task set scale values Optional. If used, ALB/NLB only Organizations with their own deployment tooling

AWS's position on how to choose is clear. The CodeDeploy Blue/Green deployment documentation states, in the first paragraph right below the title, that it recommends using the built-in Blue/Green. The CodeDeploy approach remains the option for cases that must keep an existing pipeline.

4.1 The shared structure of the built-in advanced deployments - 6 phases and bake time

Built-in Blue/Green, Linear, and Canary are performed directly by the ECS controller without CodeDeploy, and share a common 6-phase structure: preparation → deployment → test → traffic shift → monitoring → completion. In detail this breaks down into 11 lifecycle stages, and Lambda hooks can be attached depending on the stage. The old environment is cleaned up only after the bake time (the window after the traffic shift where the old and new revisions run side by side while metrics are watched) has ended.

The division of roles matters. The built-in Blue/Green production shift is all-at-once; if you need gradual shifting, choose Linear or Canary. All three strategies are also available in the AWS European Sovereign Cloud as of 2026-07-21.

4.2 Rolling's detailed rules

Rolling controls replacement speed with 2 percentages relative to desiredCount. minimumHealthyPercent is the floor on the number of healthy tasks, computed by rounding up, and maximumPercent is the ceiling, computed by rounding down. For example, with min 75% and desired 2, rounding up yields 2, so no task can be stopped at all.

A task that becomes unhealthy during a deployment is replaced with the same service revision it belongs to. For failure detection you can combine 2 mechanisms - the deployment circuit breaker, which catches task launch failures, and CloudWatch alarms, which watch application metrics - and both support rolling back to the previous service revision.

4.3 Observability and scaling improvements in 2026

Deployment observability improved along with the strategy expansion. Since 2026-07-01, the Deployments tab of a service in the ECS console provides a live deployment timeline, circuit breaker status, real-time tracking of task failures, and deep links from a failed task into CloudTrail.

Action Logs, announced on 2026-07-21, keeps a timestamped record of the actions ECS performed on the customer's behalf during service deployments and Managed daemon updates. Entries carry the event name, log level (INFO/WARN/ERROR), resource ARN, and status reason; they can be delivered to CloudWatch Logs / S3 / Kinesis Data Firehose, and the Amazon Q integration supports root-cause analysis of deployment problems.

Note - scope of the two observability features

Real-time deployment observability applies to services with the Rolling deployment type only; other strategies such as Blue/Green are outside the scope of this announcement. Action Logs is a cluster-level opt-in, and standard charges for the delivery destinations (CloudWatch Logs / S3 / Firehose) apply.

Separately from deployments, service auto scaling speed also improved on 2026-06-18. The time to a scale-out trigger dropped 76% from 363 seconds to 86 seconds, and the total scale time including new task provisioning dropped 72% from 386 seconds to 109 seconds. It is based on high-resolution metrics at 20-second intervals, covers Fargate / ECS Managed Instances / EC2 alike, and standard CloudWatch charges apply to high-resolution metrics.

05Network models

How a task attaches to the network is determined by the task definition's network mode (the parameter that decides how containers connect to the network). There are 5 modes, but which combinations are usable depends on the OS. Table 5 summarizes the supported OSes and characteristics of each mode on EC2.

Table 5. The 5 network modes - Linux/Windows support on EC2 and characteristics
Mode Linux on EC2 Windows on EC2 Characteristics
awsvpc Yes Yes The task gets a dedicated ENI and a private IP. Recommended mode
bridge Yes No Uses the Docker bridge driver. Linux default
host Yes No Ports bind directly to the host ENI. No dynamic port mapping; hostPort must be explicit. The same task definition cannot run more than one copy on a single instance
none Yes No No external network connectivity
default No Yes Uses the Docker nat driver. Windows default

Fargate offers no choice. The service definition documentation states that awsvpc mode is required when using Fargate. Because a task in awsvpc mode attaches to its own ENI rather than to an EC2 instance, load balancer target groups also use the ip type.

5.1 IP versions - prerequisites for IPv6-only

Task networking supports three IP configurations: IPv4, dual-stack, and IPv6-only. IPv6-only is supported in the Seoul Region as well, but of the three it has the longest list of prerequisites.

Note - constraints of the IPv6-only configuration
  • A dual-stack load balancer and an IPv6 target group are required
  • Windows is not supported. The ECS-optimized Linux AMI and container agent 1.99.1 or later are required
  • --enable-primary-ipv6 is required at instance launch. If omitted, host/bridge mode tasks are not registered with load balancers or Cloud Map
  • DNS64/NAT64 is needed to reach IPv4 endpoints. ECR uses dual-stack URIs
  • ECS Exec is not supported

5.2 Connecting services - Service Connect, Cloud Map, load balancers

The official options for connecting services are Service Connect, Service discovery (Cloud Map-based DNS), and VPC Lattice - 3 in total - with ALB/NLB load balancing used separately. Service Connect is a feature that delivers service discovery and a service mesh together through ECS configuration alone. It injects a proxy container into each task to handle service-to-service traffic via short names and standard ports, and the feature itself carries no extra charge.

One deadline hangs over service mesh plans. App Mesh support ends on 2026-09-30, so it must be excluded from new architectures, and the ECS service mesh path converges on Service Connect or VPC Lattice. The hands-on migration is covered, with measured values, in the post A measured record of migrating from App Mesh to VPC Lattice.

Migrating to Service Connect is a service re-creation event, not a configuration change. A single ECS service cannot belong to an App Mesh mesh and a Service Connect namespace at the same time, so the service must be re-created; if zero downtime is required, the AWS official recommendation is a blue/green approach that creates a replica of the service and shifts traffic over gradually.

06Storage, platform axes, and a selection guide

The remaining axes are where the data lives and the platform detail options. This section organizes the storage and platform axes, then ties the whole document together with the situation-based selection guide in Table 6.

6.1 Storage - from ephemeral to persistent

Tasks receive ephemeral storage by default and attach volumes when persistence is needed. Among the data volume options in the Developer Guide, five branches are central.

  • Amazon EBS - automatically provisions a volume per task and deletes it when the task stops. Supports all 3 compute types - Fargate / EC2 / Managed Instances - and expanded to the AWS GovCloud (US) Regions on 2026-05-18
  • Amazon EFS - persistent shared storage for Linux tasks. Supports Fargate / EC2 / Managed Instances
  • FSx for Windows File Server - persistent storage for Windows tasks. EC2 only
  • Docker volume - persistent volumes for Linux / Windows. EC2 only
  • bind mount - an ephemeral volume tied to the container lifetime. On Fargate it is not a host path mount but a way for containers in a task to share the ephemeral storage allocated to the task (20 GiB by default, up to 200 GiB), and host / sourcePath, which name a host path, are exclusive to EC2-hosted tasks. Supports Fargate / EC2 / Managed Instances

The volume options table in the current official documentation lists a total of 7 types, up to and including FSx for NetApp ONTAP and Amazon S3 Files. Amazon S3 Files is a persistent volume that provides fast, cached access to S3 data through a file system interface, supporting Linux tasks on Fargate and Managed Instances. Supported compute differs per volume, so it is safest to verify combinations against the official table when designing - including the fact that FSx for Windows File Server and Docker volume are EC2 only.

6.2 Platform axes - OS, architecture, GPU, operational tools

Beyond compute and storage, six more axes shape the choice.

  • OS and architecture - Linux / Windows, x86_64 / ARM64 (Graviton). ARM64 is Linux only, and on Fargate it requires platform version 1.4.0 or later
  • GPU - NVIDIA / AMD. Fargate does not support GPUs, so use Managed Instances or EC2
  • Fargate platform version - a combination of kernel and container runtime versions. LATEST is the default when unspecified, and new tasks always launch on the latest revision of that version
  • ECS Exec - a debugging tool that gives shell access into a running container. Not supported in IPv6-only configurations
  • Task placement - EC2 supports both placement strategies (binpack / random / spread) and constraints, while Managed Instances supports constraints only, without strategies, allowing just the 4-attribute subset of built-in attributes ecs.subnet-id / ecs.availability-zone / ecs.instance-type / ecs.cpu-architecture, and Fargate supports neither. Managed Instances and Fargate handle Availability Zone spreading on their own
  • Two scaling layers - the number of tasks is handled by service auto scaling (4 kinds: target tracking / step / scheduled / predictive), and the capacity to run tasks on is handled by the capacity provider's cluster auto scaling

When the capacity layer of the two scaling layers runs on an EC2 Auto Scaling group capacity provider, there are three management knobs. Turning on managed scaling makes ECS create the CapacityProviderReservation metric and a target tracking policy, managing instance scale-in/out on your behalf. Setting target capacity (valid range 1~100%) below 100 keeps that much spare capacity available at all times so subsequent task launches start faster, and managed termination protection keeps instances with running tasks from being terminated by scale-in (enabling the ASG's instance scale-in protection is a prerequisite).

6.3 A situation-based selection guide

Table 6 condenses this document's axes into recommended combinations per situation.

Table 6. Situation-based selection guide - compute, execution, deployment, connectivity
Situation Recommended choice
I want to stand up a web service as fast as possible Express Mode - auto-configured from 3 inputs, can switch to direct management later
A standard service with minimal infrastructure operations Fargate capacity provider
I need GPUs or special hardware but want patching handled for me ECS Managed Instances capacity provider
I must fully control the OS and instances EC2 Auto Scaling group capacity provider
I run on-premises hardware as is EXTERNAL launch type (ECS Anywhere)
One-off batch jobs / recurring runs RunTask / EventBridge Scheduler scheduled tasks
Most services that need no gradual traffic control, services without a load balancer Rolling - the default, and a strategy that requires no load balancer
I want to move traffic while validating the new version Linear or Canary for gradual shifting; built-in Blue/Green for pre-validation then instant cutover
I need a service mesh Service Connect or VPC Lattice. App Mesh is excluded - support ends 2026-09-30

Choosing EXTERNAL (ECS Anywhere) from Table 6 must be premised on its feature constraints. ELB load balancing, service discovery, the awsvpc network mode, capacity providers, and EFS volumes are not supported, and the official documentation states it is inefficient for web-service-style workloads that receive inbound traffic.

6.4 Design ceilings - key service quotas

The last axis is the service quotas that set design ceilings. Table 7 lists representative figures based on per-Region defaults.

Table 7. Representative service quotas - per-Region defaults
Quota Default Adjustable
Clusters per account 10,000 Yes
Services per cluster 5,000 No
Tasks per service (desired count) 5,000 No
Container instances per cluster 5,000 No
Revisions per task definition family 1,000,000 No

There are two traps. Task definition revisions do not leave the 1,000,000-limit count even when deregistered or deleted. Fargate quotas are counted in vCPUs rather than tasks, and new accounts start from low initial values that are raised automatically with usage.

Conclusion: in one sentence - leave declaration to the task definition's requiresCompatibilities, configure execution with capacity providers, pick compute from the Fargate / Managed Instances / EC2 division of responsibility, and choose whichever of the 6 deployment strategies matches your traffic-shift requirements. That is the ECS baseline as of 2026-08.

Full interactive architecture map - how launch-type declaration separates from capacity-provider execution
Figure 2. Full view of the interactive architecture map. Click the image to open the interactive version ↗ with node exploration, path tracing, and dark/light themes.

--References

Key sources (verified first-hand for the body)

Official documentation and announcements