Amazon ECS 실행 구조와 선택 기준 – 2부: 배포 전략과 네트워크, 설계 상한

이 글은 Amazon ECS 실행 구조와 선택 기준을 다루는 시리즈의 2부입니다. 1부에서는 launch type은 호환되는 실행 환경을 표시하는 용도로만 사용하고 실제 실행은 용량 공급자(capacity provider)로 구성한다는 원칙을 바탕으로, Fargate와 ECS Managed Instances, EC2에 걸친 컴퓨트 선택과 Express Mode부터 예약 Task까지의 실행 형태를 살펴봤습니다.

2부에서는 남은 선택지를 다룹니다. 6종으로 증가한 배포 전략에서 시작해 네트워크와 스토리지, 플랫폼 옵션을 살펴보고, 마지막에 두 편에서 다룬 선택 기준을 종합해서 상황별 선택 가이드와 설계 상한이 되는 서비스 쿼터로 제안해 봅니다.

1. 6종으로 증가한 배포 전략

새 리비전(revision)을 내보내는 방법은 Rolling, CodeDeploy Blue/Green, External 3종에서 6종으로 증가했습니다. 공식 문서의 구조는 배포 컨트롤러 3종(ECS, CodeDeploy, External) 입니다. 이 중에서 ECS 컨트롤러가 ROLLING, BLUE_GREEN, LINEAR, CANARY 4개 전략을 포함합니다. 모두 고려하면 6가지 방식이고 기본값은 Rolling입니다. 표 1은 6종 각각의 트래픽 전환 방식과 로드밸런서 요구 사항, 그리고 어떤 상황에 적합한지를 정리했습니다.

전략	컨트롤러	전환 방식	로드밸런서 요구	적합 상황
Rolling	ECS	Task 점진 교체. minimumHealthyPercent 하한과 maximumPercent 상한으로 속도 제어	불필요	점진적 트래픽 제어가 불필요한 대부분의 서비스. 기본값이며 로드밸런서를 요구하지 않는 전략
Blue/Green (내장)	ECS	그린 환경을 테스트 트래픽으로 선검증 후 프로덕션 트래픽 전량 즉시 전환	ALB/NLB 또는 Service Connect	즉시 전환과 신속 롤백이 필요한 서비스
Linear	ECS	동일 비율 증분으로 점진 전환. step 3.0~100.0%(0.1 단위), 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만	자체 배포 도구를 가진 조직

표 1. 배포 전략 6종 – 방식과 적합 상황

선택 기준에 대한 권고사항에 대해서 CodeDeploy Blue/Green 배포 문서에서 내장된 Blue/Green 사용을 권장한다고 밝힙니다. CodeDeploy 방식은 기존 파이프라인을 유지해야 하는 경우의 선택지로 남습니다.

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

내장 Blue/Green, Linear, Canary는 CodeDeploy 없이 ECS 컨트롤러가 직접 수행하며, 준비, 배포, 테스트, 트래픽 전환, 모니터링, 완료의 공통 6단계 구조를 공유합니다. 세부적으로는 11개 lifecycle stage로 나뉘고, 스테이지에는 배포 흐름에 사용자 로직을 삽입하는 두 종류의 훅(hook)을 걸 수 있습니다. 검증 로직을 자동 실행하는 AWS Lambda 훅에 더해, 일시 정지(pause) 훅은 ContinueServiceDeployment API로 계속 진행이나 롤백을 지시할 때까지 배포를 멈춥니다. 수동 승인 게이트가 필요한 팀에게는 이것이 직접적인 수단으로, 타임아웃(기본 24시간, 최대 14일)이 만료되면 지정한 동작을 수행하며 기본값은 롤백입니다. 트래픽 전환 후 배포 이전 버전인 구 리비전과 새로 배포한 신 리비전을 동시에 가동하며 지표를 지켜보는 구간인 bake time이 끝나야 기존 환경이 정리됩니다.

내장 Blue/Green, Linear, Canary가 공유하는 6단계 배포 흐름: 준비, 배포, 테스트, 트래픽 전환, 모니터링(bake time, 경보 발생 시 이전 서비스 리비전으로 롤백), 완료

그림 1. 내장 Blue/Green, Linear, Canary가 공유하는 6단계 배포 흐름 – 11개 lifecycle stage와 훅 구성은 간략화

역할 구분이 중요합니다. 내장 Blue/Green의 프로덕션 전환은 전량 즉시(all-at-once)이므로, 점진적인 전환이 필요하다면 선택지는 Linear나 Canary입니다.

1.2 Rolling의 세부 규칙

Rolling의 교체 속도는 배포 중 Task 수가 지켜야 할 하한과 상한으로 정해지며, 두 값 모두 서비스의 목표 Task 수인 desiredCount 대비 백분율로 지정합니다. 하한인 minimumHealthyPercent는 유지해야 하는 정상 Task 수를 올림으로 계산하고, 상한인 maximumPercent는 동시에 실행될 수 있는 전체 Task 수를 내림으로 계산합니다. 예를 들어 min 75%에 desired 2면 올림 결과가 2라서 어떤 Task도 중지할 수 없습니다.

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

1.3 2026년의 배포 관측성 개선

전략 확장과 함께 배포 관측성도 좋아졌습니다. 2026년 7월 1일부터 ECS 콘솔 서비스의 Deployments 탭에서 라이브 배포 타임라인, 서킷 브레이커 상태, Task 실패 실시간 추적, 실패 Task에서 AWS CloudTrail로 이어지는 딥링크를 제공합니다. 다만 이 실시간 배포 관측성은 Rolling 배포 유형 서비스에만 해당하고, Blue/Green 등 다른 전략은 이번 발표 범위 밖입니다.

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

2. 네트워크 형태

Task가 네트워크에 붙는 방식은 컨테이너의 네트워크 연결 방식을 정하는 Task definition 파라미터인 네트워크 모드(network mode)가 정합니다. 모드는 5종이지만 OS에 따라 쓸 수 있는 조합이 다릅니다. 표 2는 EC2 기준으로 모드별 지원 OS와 특징을 정리했습니다.

모드	Linux on EC2	Windows on EC2	특징
awsvpc	가능	가능	Task가 전용 ENI(Elastic Network Interface)와 사설 IP를 받습니다. 권장 모드
bridge	가능	불가	Docker bridge 드라이버 사용. Linux 기본값
host	가능	불가	호스트 ENI에 포트 직결. 동적 포트 매핑 불가, hostPort 명시 필수. 같은 Task definition을 한 인스턴스에서 여러 개 실행 불가
none	가능	불가	외부 네트워크 연결 없음
default	불가	가능	Docker nat 드라이버 사용. Windows 기본값

표 2. 네트워크 모드 5종 – EC2 기준 Linux/Windows 지원과 특징

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

2.1 IPv6-only 구성의 전제 조건

Task 네트워킹은 IPv4, IPv4와 IPv6를 함께 쓰는 듀얼스택(dual-stack), IPv6-only 세 가지 IP 구성을 지원합니다. IPv6-only는 서울 리전에서도 지원되지만, 세 구성 가운데 전제 조건이 가장 많습니다.

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

2.2 서비스 간 연결: Service Connect, Cloud Map, 로드밸런서

서비스 사이를 연결하는 공식 옵션은 Service Connect, Cloud Map 기반 DNS인 Service discovery, 서비스 간 연결을 관리형으로 제공하는 Amazon VPC Lattice 3종입니다. 별도로 ALB나 NLB 로드밸런싱을 사용할 수 있습니다. Service Connect는 서비스 디스커버리와 서비스 메시를 ECS 구성만으로 함께 제공하는 기능입니다. Task마다 프록시 컨테이너를 주입해 짧은 이름(short name)과 표준 포트로 서비스 간 통신을 처리하고, 기능 자체는 추가 요금이 없습니다. 다만 프록시는 Task 안에서 실행되어 Task의 vCPU와 메모리를 워크로드와 나눠 쓰므로, 요금이 없다는 것과 리소스를 쓰지 않는다는 것은 구분해야 합니다.

서비스 메시를 계획할 때 확인해야 할 일정이 하나 있습니다. AWS App Mesh는 2026년 9월 30일에 지원이 종료되므로 신규 아키텍처에서 제외해야 합니다. 기존 App Mesh 기반 구성은 Service Connect나 VPC Lattice로 마이그레이션해야 합니다.

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

namespace 자체에도 상한이 있습니다. 하나의 namespace에서 실행할 수 있는 서비스는 300개로 고정입니다. 서비스가 많은 App Mesh를 이전할 때는 mesh 하나를 namespace 하나로 그대로 옮기지 말고, 도메인 단위로 namespace를 나누는 분할 설계를 먼저 검토해야 합니다. Service discovery도 별도 상한이 있습니다. service discovery를 구성한 서비스는 Cloud Map의 서비스당 인스턴스 쿼터 때문에 서비스당 Task가 1,000개로 제한됩니다.

3. 스토리지와 플랫폼 옵션

3.1 스토리지: 임시에서 지속까지

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

Amazon EBS – Task당 볼륨을 자동 프로비저닝합니다. 지속성은 실행 형태에 따라 달라지는데, 서비스가 관리하는 Task에서는 Task 종료와 함께 삭제되는 임시 볼륨이지만 단독 실행(standalone) Task에서는 볼륨을 유지할 수 있습니다. Fargate, EC2, Managed Instances 3종 컴퓨트를 모두 지원합니다
Amazon EFS – Linux Task용 지속 공유 스토리지. Fargate, EC2, Managed Instances 지원
Amazon FSx for Windows File Server – Windows Task용 지속 스토리지. EC2 전용
Docker volume – Linux와 Windows용 지속 볼륨. EC2 전용
bind mount – 컨테이너 수명에 묶이는 임시(ephemeral) 볼륨. Fargate에서는 호스트 경로 마운트 대신 Task에 할당된 임시 스토리지(기본 20GiB, 최대 200GiB)를 Task 안 컨테이너끼리 공유하는 용도로 사용합니다. 호스트 경로를 지정하는 host의 sourcePath는 EC2 호스팅 Task 전용입니다. (Fargate, EC2, Managed Instances 지원)

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

3.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가 기본값이고, 새 Task는 항상 해당 버전의 최신 revision에서 기동합니다
ECS Exec – 실행 중인 컨테이너에 셸로 접근하는 디버깅 도구. IPv6-only 구성에서는 지원되지 않습니다
Task 배치 – 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종만 허용합니다. Fargate는 둘 다 지원하지 않습니다. Managed Instances와 Fargate의 가용 영역 분산은 플랫폼이 자동으로 처리합니다
스케일링 2계층 – Task 수는 서비스 오토스케일링(target tracking, step, scheduled, predictive 4종)이, Task를 올릴 용량은 capacity provider의 클러스터 오토스케일링이 담당합니다. 이 가운데 predictive scaling은 서비스 수준 기능으로, 컴퓨트(EC2, Fargate) 용량의 스케일링과 독립적으로 서비스의 Task 계층만 스케일합니다

스케일링 2계층 가운데 Task 계층의 서비스 오토스케일링은 2026년 6월 18일부터 반응 속도가 개선되었습니다. scale-out 트리거까지 걸리는 시간이 363초에서 86초로 76% 줄었고, 신규 Task 프로비저닝을 포함한 전체 스케일 시간은 386초에서 109초로 72% 줄었습니다. 20초 간격 고해상도 메트릭 기반이고 Fargate, ECS Managed Instances, EC2 모두 대상이 됩니다. 고해상도 메트릭에는 표준 CloudWatch 요금이 적용됩니다.

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

4. 상황별 선택 가이드와 설계 상한

표 3은 1부의 컴퓨트/실행 형태부터 이번 편의 배포 및 연결까지, 두 편에서 살펴본 선택 기준을 상황별 권장 조합으로 제안해 드립니다.

상황	권장 선택
웹 서비스를 가장 빠르게 올리고 싶다	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 예약 Task
점진적 트래픽 제어가 필요 없는 대부분의 서비스, 로드밸런서 없는 서비스	Rolling – 기본값이며 로드밸런서를 요구하지 않는 전략
새로운 버전을 검증하며 트래픽을 옮기고 싶다	점진적인 전환은 Linear 또는 Canary, 선검증 후 즉시 전환은 내장 Blue/Green
서비스 메시가 필요하다	Service Connect 또는 VPC Lattice. App Mesh는 2026년 9월 30일 지원 종료로 제외

표 3. 상황별 선택 가이드 – 컴퓨트, 실행, 배포, 연결

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

4.1 핵심 서비스 쿼터

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

쿼터	기본값	상향 조정
계정당 클러스터 수	10,000	가능
클러스터당 서비스 수	5,000	불가
서비스당 Task 수 (desired count)	5,000	불가
클러스터당 컨테이너 인스턴스 수	5,000	불가
Task definition family당 revision 수	1,000,000	불가
Fargate On-Demand vCPU 수	6 (Spot은 별도 6)	가능

표 4. 대표 서비스 쿼터 – 리전별 기본값

표 4의 기본값은 AWS가 설정한 초기 쿼터이며, 계정에 실제 적용된 값(applied quota)이나 요청 가능한 최대값과는 별개입니다. 또한 service discovery를 구성한 서비스는 앞서 살펴본 Cloud Map 쿼터 때문에 서비스당 Task가 1,000개로 제한되어, 표의 서비스당 Task 수 5,000보다 먼저 제한됩니다.

Task 기동 속도에도 상한이 있습니다. ECS 스케줄러가 서비스당 1분에 프로비저닝할 수 있는 Task 수는 Fargate 기준 주요 리전 500개, 그 외 리전(2025년 5월 20일 이후 신설 리전 포함) 125개이며 이 쿼터는 조정할 수 없습니다. EC2와 External 인스턴스도 서비스당 분당 500개입니다. 계정 레벨에서는 Fargate On-Demand 기동 속도가 지속(sustained) 초당 20개, 버스트 100개로 별도 제한됩니다(주요 리전 기본값, 상향 요청 가능). 수백 Task 규모의 대량 스케일아웃에서는 오토스케일링의 반응 속도보다 이 기동 상한이 먼저 걸립니다.

두 가지 함정이 있습니다. Task definition revision은 등록을 해제하거나 삭제해도 1,000,000 한도 계산에서 빠지지 않습니다. 그리고 Fargate 쿼터는 Task 수가 아니라 vCPU 개수 기준이고, On-Demand vCPU 초기값은 6에 불과합니다(Spot은 별도로 6). 1 vCPU Task 기준 동시 6개면 한도에 닿는 수준이므로, 신규 계정에서는 첫 부하 테스트나 본 배포 전에 상향을 신청해 두는 것이 좋습니다. 이 값은 상향 요청이 가능하고, Fargate가 리전별 사용량을 관찰해 자동으로 올리기도 합니다.

5. 마치며

1부 글머리에서 언급한 세 번째 고민, 무엇으로 배포할 것인가로 돌아가 보겠습니다. 점진적 트래픽 제어가 필요 없으면 기본값인 Rolling, 소량 검증 후 점진적인 전환이면 Linear나 Canary, 선검증 후 즉시 전환이면 내장 Blue/Green을 선택하면 됩니다. AWS는 CodeDeploy 방식보다 내장 Blue/Green을 권장하고 있습니다.

이제 두 편을 정리해 봅니다.

1/ 선언은 Task definition의 requiresCompatibilities에 맡기고, 실행은 capacity provider로 구성합니다.

2/ 컴퓨트는 Fargate, Managed Instances, EC2의 책임 분담에서 선택합니다.

3/ 배포는 6종 전략 중 트래픽 전환 요구에 맞는 것을 선택하는 것이 2026년 8월 기준 Amazon ECS의 기본입니다.

본문의 수치와 기본값은 작성 시점 기준이므로, 최신 값은 본문에 링크한 공식 문서에서 확인하시기 바랍니다.

AWS 기술 블로그