기준: SAP-C02 시험 가이드오류 제보
"Fargate가 비싸다"는 말은 절반만 맞다. 단가표 위 숫자만 보면 EC2보다 vCPU당 약 2배가량 비싼 게 사실이지만, 거기엔 노드 운영비·유휴 자원·Bin Packing 비효율이 빠져 있다. 평균 노드 사용률 30%로 돌아가는 EC2 클러스터와, 100%에 가깝게 채워지는 Fargate Task를 단순 비교하면 결과가 뒤집힐 수 있다. SAP 시험은 이 미묘한 분기점을 정확히 짚어내는 시나리오를 한 도메인당 두세 문제씩 깐다. "트래픽이 가변인데 24/7 운영"·"피크가 평소의 10배"·"GPU 추론 작업"이 들어오는 순간 정답이 EC2·Fargate·Lambda 사이에서 갈린다.
이 글에서는 Fargate의 과금 구조를 초 단위로 뜯어보고, vCPU·메모리 조합이 왜 이상한 매트릭스 형태로 정해져 있는지를 본다. 그 다음 Fargate Spot·Compute Savings Plans·Graviton ARM의 세 가지 할인 레버를 어떻게 조합하면 총 단가를 절반 이하로 떨어뜨릴 수 있는지를 본다. 마지막으로 Image Pull의 콜드 스타트, SOCI lazy loading, Lambda·EC2와의 비용 분기점을 다룬다. 다음 글의 서비스 메시 주제로 넘어가기 전에 "Fargate를 언제 쓰면 안 되는가"의 감각을 만드는 게 목표다.
Fargate는 vCPU·시간과 메모리·시간을 별도로 청구한다. 대략 us-east-1 기준 단가는 vCPU 0.04048 USD/h, 메모리 0.004445 USD/GB-h 정도다. 청구는 초 단위로 잘리되 최소 1분이 적용된다. 즉 30초만 돌고 종료된 Task도 1분으로 잡힌다.
여기서 발생하는 첫 번째 비용 함정이 이미지 Pull 시간이 과금에 포함된다는 점이다. Fargate는 노드 캐시가 없어서 매 Task마다 ECR에서 이미지를 내려받는데, 큰 이미지는 30~60초가 걸린다. 트래픽이 들어와도 응답하지 못하는 시간 동안 vCPU·메모리 단가가 흘러간다. 짧은 잡(예: 배치 처리 30초)에 큰 이미지(2GB)를 쓰면 Pull 비용이 본 작업보다 크다.
[Task 시작]
│ (1) micro VM 부팅 ~3초 ← 과금 시작
│ (2) ECR 이미지 Pull 30~60초 ← 과금 흐름
│ (3) 컨테이너 실행 + 잡 처리 ← 본업
│ (4) graceful shutdown ← 과금 끝
[Task 종료]
클라우드 컨테이너 서비스의 과금 모델은 fine-grained billing의 한 사례다. EC2는 시간 단위, Lambda는 1ms 단위, Fargate는 초 단위(1분 최소). 이 차이는 워크로드 형태에 따라 결정적이다. 1ms 단위인 Lambda는 짧고 빈번한 호출(요청당 100ms)에 압도적으로 유리하고, 시간 단위인 EC2는 장시간 일정 부하(24/7)에 유리하다. Fargate는 그 사이의 "분~시간 단위로 살아 있다가 사라지는 워크로드"에 최적화되어 있다. 이 과금 모델의 진화는 AWS의 "Serverless Architectures with AWS Lambda" 백서와 NSDI 2020 Firecracker 논문에서 잘 다뤄진다.
Fargate Task Definition을 처음 작성할 때 가장 헷갈리는 부분이 vCPU·메모리 조합이다. 임의의 값이 안 되고 정해진 매트릭스만 허용된다.
| vCPU | 허용 메모리 |
|---|---|
| 0.25 | 0.5, 1, 2 GB |
| 0.5 | 1~4 GB (1GB 단위) |
| 1 | 2~8 GB (1GB 단위) |
| 2 | 4~16 GB (1GB 단위) |
| 4 | 8~30 GB (1GB 단위) |
| 8 | 16~60 GB (4GB 단위) |
| 16 | 32~120 GB (8GB 단위) |
이게 왜 이렇게 정해졌느냐면, Fargate가 내부적으로 EC2 인스턴스 family 위에서 동작하기 때문이다. AWS가 m5/c5/r5 같은 family의 vCPU-메모리 비율(1:2, 1:4, 1:8)을 그대로 노출한 것이다. 8 vCPU에 64GB(1:8) 같은 메모리 우세 조합은 가능하지만, 0.25 vCPU에 32GB 같은 비현실적 조합은 거부된다.
이 매트릭스를 모르고 "32GB 메모리 + 0.5 vCPU"를 쓰려 하면 등록 자체가 실패한다. 메모리를 더 쓰려면 vCPU를 같이 늘려야 하고, 그러면 단가가 비례해서 오른다. 이게 일부 워크로드에서 Fargate가 EC2보다 비싸지는 이유 중 하나다. 메모리만 많이 필요한 워크로드(예: in-memory cache, JVM heap)에서 vCPU를 강제로 함께 사야 한다.
🔍 더 깊이: 이 매트릭스 제약을 우회하는 패턴이 multi-container Task다. 한 Task에 메인 컨테이너(0.25 vCPU, 0.5GB)와 사이드카(0.25 vCPU, 1.5GB)를 합쳐 Task 전체로 0.5 vCPU·2GB를 신청하고, 컨테이너 정의에서
memoryReservation으로 메모리만 한쪽에 몰아주는 방법. 단 EC2 Launch Type에서만 잘 동작하고, Fargate에서는 컨테이너 간 자원 격리가 더 엄격해 효과가 제한적이다. SAP 시험은 이 정도 디테일은 안 묻지만 실무에서 자주 보는 패턴이다.
Fargate Spot은 표준 Fargate의 약 70% 할인이다. 대신 AWS가 용량을 회수할 권리를 가지며, 회수 시 2분 전 SIGTERM으로 알려준다. 이 2분 안에 graceful shutdown(in-flight 요청 마무리, 큐에 메시지 다시 넣기, 캐시 flush)을 끝내야 한다.
[Spot Task 정상 동작]
│
[AWS 용량 부족 감지 → 회수 결정]
│
[Task에 SIGTERM 전송] ← 2분 카운트다운 시작
│
[애플리케이션이 graceful shutdown:
- ALB Target Group에서 deregistration
- 진행 중 요청 응답 마무리
- 메시지 큐 visibility timeout 해제]
│
[2분 경과 → SIGKILL]
[Task 강제 종료]
Fargate Spot이 잘 맞는 워크로드:
부적합한 워크로드:
ECS Service의 Capacity Provider에서 가중치(weight)와 베이스(base)로 혼합한다. 예: base=2, FARGATE weight=1, FARGATE_SPOT weight=4 → 첫 2개 Task는 항상 On-Demand, 그 뒤로는 20:80 비율.
aws ecs put-cluster-capacity-providers \
--cluster prod \
--capacity-providers FARGATE FARGATE_SPOT \
--default-capacity-provider-strategy \
'capacityProvider=FARGATE,weight=1,base=2' \
'capacityProvider=FARGATE_SPOT,weight=4'Spot 인스턴스의 원리는 이자율 가격 발견(price discovery) 메커니즘이다. AWS 데이터센터에는 항상 일정 비율의 유휴 용량(buffer capacity)이 있고, 이걸 정가로 팔면 수요가 부족하다. 그래서 시장 가격(spot price)으로 할인 판매하되, 정가 수요가 갑자기 늘면 회수하는 옵션을 가진다. 회수 알림 시간(SIGTERM 2분)은 사용자가 graceful shutdown을 할 수 있는 최소 시간으로 산정된 것이다. EC2 Spot은 회수율이 평균 5% 이하지만, Fargate Spot은 capacity 풀 자체가 작아 회수율이 약간 더 높을 수 있다(공식 수치 비공개).
2023년 Pinterest는 일부 백엔드 워크로드를 ECS Fargate + Fargate Spot 80% 혼합으로 전환해 컨테이너 인프라 비용을 약 40% 절감했다고 발표했다. Spot 회수에 대비해 STOPTIMEOUT을 120초로 설정하고 SIGTERM 핸들러로 in-flight HTTP 요청을 graceful drain, 워커는 SQS message visibility timeout을 재설정하는 패턴을 표준화했다. re:Invent 2023 CON401.
Savings Plans는 사용자가 "1년 또는 3년간 시간당 N달러어치 컴퓨트를 쓰겠다"고 약정하는 대가로 할인을 받는 제도다. 두 종류가 있고, Fargate에 적용되는 건 Compute Savings Plans다.
| 종류 | 적용 대상 | 할인율 | 유연성 |
|---|---|---|---|
| EC2 Instance Savings Plans | 특정 family + region의 EC2만 | ~72% | 낮음(family·region 고정) |
| Compute Savings Plans | EC2 + Fargate + Lambda 모두 | ~66% | 매우 높음(family·region·서비스 자유) |
Compute Savings Plans의 핵심은 유연성이다. 1년 약정으로 시간당 $10 컴퓨트를 사면, 그 안에서 ECS Fargate를 쓰든 EC2를 쓰든 Lambda를 쓰든 할인 적용된다. 워크로드를 EC2에서 Fargate로 이전하는 도중에도 약정이 그대로 살아 있어서, 마이그레이션 중 비용 폭증을 막아준다.
[Compute Savings Plans $10/h 약정]
│
├─ EC2 m5.xlarge × 2 $0.38/h → 자동 SP 적용
├─ Fargate Task 5개 $4.20/h → 자동 SP 적용
└─ Lambda 호출 $5.42/h → 자동 SP 적용
합계 약정 한도 안
Spot과 Compute SP는 별개의 할인 메커니즘이라 Fargate Spot에는 SP가 추가 적용되지 않는다(Spot 자체 할인만 적용). 하지만 On-Demand 부분에는 SP가 적용된다. 그래서 위의 Capacity Provider 혼합(base=2 On-Demand + Spot 80%)을 쓰면, On-Demand 2개에는 SP 할인이 적용되고 Spot 8개에는 Spot 할인이 적용되는 이중 할인 패턴이 된다.
Reserved Instance(RI)는 SP보다 더 오래된 제도로 EC2·RDS·ElastiCache 등 별도 제도를 가진다. RI는 인스턴스 타입을 고정하는 대신 capacity reservation도 함께 제공하고, SP는 capacity reservation은 없고 청구 할인만 제공한다. AWS는 2019년 SP를 발표하며 사실상 "RI는 더 이상 권장하지 않음"이라는 신호를 보냈고, 현재 신규 워크로드의 표준은 SP다. SAP 시험에서 "유연성·다중 서비스 할인"이 강조되면 Compute SP, "EC2 인스턴스 고정·최대 할인율"이면 EC2 Instance SP, "스토리지·DB capacity 보장 필요"면 RI가 답이다.
Fargate는 x86_64와 ARM64(Graviton2 기반) 모두를 지원한다. ARM64는 같은 성능에 약 20% 싸다. Task Definition의 runtimePlatform.cpuArchitecture만 ARM64로 바꾸면 적용된다.
{
"family": "myapp",
"runtimePlatform": {
"cpuArchitecture": "ARM64",
"operatingSystemFamily": "LINUX"
},
"cpu": "1024",
"memory": "2048",
...
}전제 조건은 컨테이너 이미지가 multi-architecture 빌드여야 한다는 점이다. docker buildx로 amd64·arm64 둘 다 푸시해두면 Fargate가 자동으로 맞는 이미지를 받는다. 일부 native binary(C/C++)나 머신러닝 라이브러리는 ARM64 지원이 아직 부족할 수 있어서, 마이그레이션 전에 의존성 호환을 확인해야 한다.
docker buildx build \
--platform linux/amd64,linux/arm64 \
-t myrepo/myapp:1 --push .2022년 Snap(Snapchat 모기업)은 백엔드 마이크로서비스 일부를 Graviton2 Fargate로 옮겨 약 22% 비용 절감을 달성했다. 가장 큰 작업은 종속성 라이브러리(특히 JNI 바인딩 가진 Java 라이브러리, native node-gyp 모듈)의 ARM64 빌드 확보였다. AWS re:Invent 2022 CMP301 발표. 핵심 교훈: Graviton 절감의 80%는 인프라 변경, 20%는 종속성 정리 작업이다.
ARM64가 같은 성능에 단가가 낮은 이유는 두 가지다. 첫째, AWS가 직접 설계한 칩이라 Intel·AMD에 라이선스 비용을 안 낸다. 둘째, ARM 아키텍처가 RISC 계열이라 같은 트랜지스터로 더 많은 코어를 넣을 수 있다(Graviton3는 64코어/소켓). 같은 데이터센터 공간·전력에서 더 많은 컴퓨트가 나오는 게 단가 차이의 본질이다. 이 트렌드는 Apple Silicon(M1·M2·M3)과 같은 흐름이고, 향후 클라우드 컴퓨트의 기본값이 ARM으로 바뀌어갈 가능성이 높다.
Fargate Spot(70%) + Compute SP(66%) + Graviton(20%)는 각각 다른 축의 할인이라 조합하면 누적 효과가 매우 크다. 다만 곱연산은 아니고 가법 효과에 가깝다.
시나리오: 백오피스 API 1년 운영, 평균 5 Task × 1 vCPU × 2GB 메모리
| 구성 | 단가 (월) | 비고 |
|---|---|---|
| Baseline: x86 Fargate On-Demand 100% | ~$200 | 기준 |
| + Graviton ARM | ~$160 | -20% |
| + Compute SP 1년 약정 | ~$108 | -32% (SP 할인) |
| + Capacity Provider base=2 + Spot 80% | ~$60 | Spot 부분 추가 절감 |
| 합계 절감 | ~70% |
여기서 흥미로운 점은 Spot과 SP는 상호 보완적이라는 사실이다. Spot은 회수 위험이 있고 SP는 약정 부담이 있는데, 둘을 혼합하면 안정 부분(SP + On-Demand)과 가변 부분(Spot)이 자연스럽게 갈린다.
🎯 시나리오: "한 SaaS가 ECS Fargate로 백오피스 API를 운영하는데, 평균 트래픽은 5 Task로 충분하지만 마케팅 캠페인 때 일시 30 Task까지 폭증한다. 1년 약정 가능, 회수 허용 가능. 어떤 구성이 비용 최적인가?" — 답은 Compute SP 5 Task 약정 + Capacity Provider(base=2 On-Demand + Spot 80%). 평균 5 Task의 baseline을 SP로 묶고, 그 위 트래픽은 Spot으로 처리. base=2로 회수 시 가용성 최소 보장. 약정 한도 안의 자원은 SP 할인, 한도 밖은 Spot 할인. 두 레버가 자연스럽게 갈린다.
Fargate의 콜드 스타트가 30~60초나 걸리는 가장 큰 원인은 이미지 Pull이다. 노드 캐시가 없어서 매번 ECR에서 전체 이미지를 받아 압축 해제한다. 2GB 이미지면 네트워크 + 압축 해제 모두 시간이 든다.
해결책 세 가지가 있다.
1. 이미지 자체를 줄이기. Distroless·Alpine·multi-stage build로 200MB 이하로 만든다. 가장 효과 큼.
2. ECR Pull Through Cache. Docker Hub·quay.io 이미지를 ECR로 캐시. 외부 네트워크 비용·실패 위험을 줄인다.
3. SOCI (Seekable OCI). 이미지를 lazy 로딩한다. 컨테이너가 실제로 읽는 파일만 네트워크로 가져오고, 나머지는 백그라운드에서 받는다. 큰 머신러닝 이미지(8GB+)에서 시작 시간을 50~80% 줄일 수 있다.
[전통적 Pull]
ECR ────[전체 2GB]────► Task 압축해제 30초 ► 실행
[SOCI lazy]
ECR ────[manifest + index]────► Task 즉시 실행
│ │
└─[필요한 파일만 페치]──────┘ 백그라운드
(보통 200~500MB만 실제 사용)
SOCI는 ECR이 별도 인덱스를 미리 만들어두는 방식이라 사용자 측 변경이 거의 없다. Fargate Task Definition에서 자동 적용된다.
SOCI의 lazy loading 발상은 demand paging(OS 가상 메모리)에서 왔다. OS는 프로세스 메모리 전체를 한 번에 로드하지 않고 페이지 폴트가 날 때만 가져온다. 컨테이너 이미지의 파일 시스템도 마찬가지로 실제 읽히는 파일이 전체의 일부일 뿐이라는 관찰에서 출발했다. 학술적으로는 ATC 2016의 "Slacker: Fast Distribution with Lazy Docker Containers" 논문이 같은 발상을 먼저 제안했고, SOCI는 이걸 OCI 표준 위에 구현한 셈이다.
⚠️ 함정: SOCI는 큰 이미지일수록 효과가 크고, 작은 이미지(100MB 이하)에서는 인덱스 오버헤드가 더 크다. "모든 이미지에 SOCI를 켜라"는 보기는 오답이다. 작은 이미지는 그냥 받는 게 빠르다.
같은 워크로드를 세 가지 컴퓨트 옵션 중 어디에 두느냐는 SAP 시험에 나오는 시나리오다. 분기점은 워크로드의 수명, 빈도, 자원 크기 세 축으로 결정된다.
| 워크로드 | Lambda | Fargate | EC2 |
|---|---|---|---|
| 100ms × 1만 회/일 (짧고 빈번) | ⭐ 최적 | 비싸짐 | 가장 비쌈 |
| 5분 × 100회/일 (중간) | 한도 가까움 | ⭐ 최적 | 인스턴스 띄우면 유휴 큼 |
| 24/7 × 4 Task (장시간 일정) | 부적합 | 비쌈 | ⭐ 최적 (RI/SP) |
| GPU 추론 | 미지원 | 제한적 | ⭐ G/P 시리즈 |
| 가변 트래픽 + spiky | 좋음 | ⭐ Capacity Provider | 오버 프로비저닝 |
경험적 분기점:
Lambda는 2020년부터 메모리 10GB · 6 vCPU · 15분 실행이 가능해져 일부 Fargate 워크로드를 대체 가능해졌다. 그래도 백오피스 API처럼 connection pool을 유지해야 하는 패턴은 여전히 Fargate가 유리하다.
2023년 한 로그 분석 회사가 batch 잡 일부를 Fargate에서 Lambda로 옮긴 사례. 처리 시간 평균 3분, 호출 빈도 시간당 200회, 메모리 4GB. Fargate에서는 평균 2개 Task가 항상 떠 있어 유휴 비용이 컸지만, Lambda는 실행 시간만 청구되어 월 비용이 약 60% 줄었다. 다만 Lambda 콜드 스타트(VPC 연결 시 1~2초)를 받아들일 수 있어야 했다.
ECS Service의 Task 수는 Application Auto Scaling으로 조정한다. EC2 ASG와 별개 서비스로, ECS·DynamoDB·Aurora·SageMaker 등 다양한 리소스의 스케일러로 쓰인다.
세 가지 정책:
aws application-autoscaling register-scalable-target \
--service-namespace ecs \
--resource-id service/prod/myapp \
--scalable-dimension ecs:service:DesiredCount \
--min-capacity 2 --max-capacity 50
aws application-autoscaling put-scaling-policy \
--service-namespace ecs \
--resource-id service/prod/myapp \
--scalable-dimension ecs:service:DesiredCount \
--policy-name cpu-target \
--policy-type TargetTrackingScaling \
--target-tracking-scaling-policy-configuration '{
"TargetValue": 60.0,
"PredefinedMetricSpecification":
{"PredefinedMetricType":"ECSServiceAverageCPUUtilization"}
}'Target Tracking은 내부적으로 CloudWatch 알람을 자동 생성해 desired count를 조정한다. 동작 원리는 PID controller에 가깝지만 AWS 측 구현은 단순한 비례 제어다. 빠르게 늘리고 느리게 줄이는 패턴이 기본값이라 트래픽 변동에 안정적이다.
Auto Scaling의 동작은 제어 이론(control theory)의 응용이다. 측정값(CPU%)과 목표값(60%)의 차이(error)를 보고 액추에이터(Task count)를 조정한다. 정확한 PID 제어는 적분·미분 항까지 쓰지만 AWS의 Target Tracking은 단순 P 제어에 가깝다. 단순한 만큼 oscillation(진동) 위험이 있어서, scale-in cooldown을 길게 잡는 게 표준이다. Netflix는 이 한계 때문에 Scryer라는 predictive auto-scaler를 만들어 트래픽 패턴을 ML로 예측한다.
Fargate는 단가표 위 숫자만으로 비싸 보이지만, Fargate Spot(70%) + Compute SP(66%) + Graviton(20%)을 조합하면 같은 워크로드를 70% 가까이 싸게 돌릴 수 있다. 단가 비교에서 가장 중요한 변수는 평균 노드 사용률과 트래픽 가변성이다. 사용률 40% 이상으로 일정 24/7이면 EC2 + SP가 우위고, 그 외엔 Fargate가 운영 부담까지 포함해 우위다.
내일은 서비스 메시·서비스 디스커버리를 본다. ECS Service Connect·AWS Cloud Map·App Mesh의 차이가 무엇이고, mTLS·카나리·서킷 브레이커 같은 메시 기능이 어떻게 구현되는지를 다룬다. Fargate 위에 마이크로서비스 10개를 띄우면 그들 간 통신을 어떻게 안전·관찰 가능하게 만드는가의 이야기다.
선택지를 클릭하면 정답·해설이 펼쳐집니다.
문제 1
한 SaaS가 ECS Fargate로 백오피스 API를 운영한다. 평균 트래픽은 5 Task로 충분하지만 마케팅 캠페인 때 30 Task까지 폭증한다. 1년 약정 가능, 일부 회수 허용. 비용 최적 구성은?
문제 2
Fargate Task Definition에 cpu=512(0.5 vCPU), memory=8192(8GB)를 설정하니 등록 실패. 원인은?
문제 3
Fargate 콜드 스타트가 평균 60초나 걸린다. 이미지 크기는 4GB이고, 머신러닝 추론용이다. 시작 시간을 가장 효과적으로 줄이는 방법은?
문제 4
한 회사가 EC2와 Fargate를 동시에 쓴다. 1년 약정 할인을 받되 EC2와 Fargate에 모두 적용되어야 하고, 마이그레이션 중 워크로드를 EC2에서 Fargate로 이동해도 할인이 유지되어야 한다. 어떤 약정을 쓰는가?
문제 5
머신러닝 추론 워크로드. 평균 100ms 처리, 시간당 5만 회 호출, 메모리 3GB. 가장 비용 효율적인 컴퓨트는?
문제 6
Fargate Spot Task가 SIGTERM을 받았다. 2분 안에 graceful shutdown을 보장하기 위한 표준 패턴은?
문제 7
Fargate Task가 평균 노드 사용률 60%로 24/7 운영된다. 평균 8 Task가 항상 떠 있다. 1년 약정 가능. 비용 면에서 가장 유리한 선택은?