ECS Fargate vs EC2: 스펙 조합과 요금 비교
ECS 태스크를 어디서 돌릴지는 Fargate와 EC2 기반 중의 선택입니다. 흔한 통념은 “Fargate는 편한 대신 비싸다"인데, 단가를 실제로 계산해 보면 격차는 통념보다 작고, 비교를 뒤집는 변수는 단가가 아니라 사용률입니다. 결론을 먼저 적으면, 기본값은 Fargate이고, EC2 기반은 GPU·특수 하드웨어·상시 고사용률 대형 플릿처럼 조건이 명확할 때의 선택입니다. ECS와 Fargate의 개념 자체는 AWS 고급 #1에서, 배포 실무는 AWS 실전 #1에서 다뤘습니다. 요금은 us-east-1 기준입니다.
과금 단위가 다릅니다: 태스크 vs 인스턴스 #
Fargate는 태스크에 선언한 vCPU·메모리 크기만큼 초 단위로 과금합니다(vCPU당 시간당 약 $0.04048, GB당 약 $0.004445). 태스크가 내려가면 과금도 끝나고, 호스트라는 개념이 청구서에 없습니다.
EC2 기반은 인스턴스가 떠 있는 시간만큼 과금합니다. 태스크가 하나든 열이든, 인스턴스의 빈 공간이 놀고 있든 요금은 같습니다. 대신 인스턴스 선택권(패밀리 비교 참조)과 호스트 접근권을 얻고, AMI 패치, 용량 관리, 에이전트 운영이라는 일이 따라옵니다.
이 구조 차이가 뒤에 나오는 모든 비교의 바탕입니다. Fargate의 단가에는 “빈 공간이 없다"가 포함되어 있고, EC2의 단가에는 “빈 공간도 산다"가 포함되어 있습니다.
Fargate 스펙 조합: 정해진 격자 안에서 고릅니다 #
Fargate는 임의의 스펙을 받지 않고, vCPU 단계마다 허용되는 메모리 범위가 정해져 있습니다.
| vCPU | 메모리 범위 |
|---|---|
| 0.25 | 0.5·1·2GB |
| 0.5 | 1〜4GB |
| 1 | 2〜8GB |
| 2 | 4〜16GB |
| 4 | 8〜30GB |
| 8 | 16〜60GB |
| 16 | 32〜120GB |
읽는 법은 두 가지입니다. 첫째, vCPU 대 메모리 비율이 1:2에서 1:8 사이로, EC2의 c·m·r 스펙트럼을 태스크 단위로 고르는 셈입니다. 둘째, 상한이 16vCPU·120GB라서 그 이상의 단일 태스크는 EC2 기반으로 갈 수밖에 없습니다. 임시 스토리지는 20GiB가 기본 포함이고 최대 200GiB까지 늘릴 수 있으며, GPU는 지원하지 않습니다. 0.25vCPU 같은 소수점 크기는 EC2에는 없는 선택지라, 작은 사이드카·경량 API를 잘게 쪼개는 데는 Fargate 격자가 오히려 유리합니다.
단가 비교: 프리미엄은 생각보다 작습니다 #
같은 2vCPU·8GB를 놓고 계산합니다.
- Fargate(x86): 2×$0.04048 + 8×$0.004445 = 시간당 약 $0.117
- EC2 m7i.large(x86, 2vCPU·8GiB): 약 $0.101 — Fargate가 약 16% 비쌉니다.
- Fargate(ARM): 2×$0.03238 + 8×$0.003556 = 약 $0.093
- EC2 m8g.large(Graviton, 2vCPU·8GiB): 약 $0.090 — 격차가 약 4%까지 줄어듭니다.
그러니 온디맨드 단가만 보면 “2배 비싸다"는 통념은 성립하지 않습니다. 비교를 실제로 가르는 것은 EC2 쪽 사용률입니다. EC2 기반에서는 태스크들이 인스턴스에 빈틈없이 들어차지 않는 한 빈 공간도 요금에 포함됩니다. 스케일 인 뒤에 반쯤 빈 인스턴스가 남는 빈 패킹 손실, 배포 여유분, 데몬·에이전트 몫까지 감안하면 플릿 사용률 70%는 잘 관리된 편인데, 그 시점에 EC2의 실효 단가는 이미 Fargate를 넘습니다. 거꾸로 사용률을 90% 이상으로 유지할 수 있는 대형 고정 플릿이라면 EC2 기반의 단가 우위가 실제로 남습니다.
EC2 기반이 이기는 조건 #
- GPU·가속기: Fargate는 GPU 태스크를 못 받습니다. 추론·학습 컨테이너는 EC2 기반(g·p 계열) 확정입니다.
- 특수 하드웨어: 로컬 NVMe(i·d 계열), 초대형 메모리, 특정 CPU 세대 고정이 필요한 경우입니다. 단일 태스크가 16vCPU·120GB를 넘는 경우도 여기 속합니다.
- 호스트 접근: 커널 파라미터 조정, 특권 컨테이너, 호스트 네트워크 모드, 노드마다 하나씩 도는 에이전트류가 필요한 경우입니다.
- 상시 고사용률 대형 플릿: 부하가 평평해서 빈 패킹을 90% 이상으로 유지할 수 있고, 리저브드·Savings Plans 약정까지 걸어 둔 경우입니다. 이 조합이면 단가 우위가 관리 비용을 넘어섭니다.
이 목록에 해당하지 않는데 EC2 기반을 쓰고 있다면, 지불하는 것은 단가가 아니라 용량 관리라는 상시 업무입니다.
요금을 내리는 축: ARM, Spot, Savings Plans #
Fargate 안에서도 내릴 축이 세 개 있습니다.
- ARM(Graviton): 단가가 x86보다 약 20% 낮습니다. 컨테이너 이미지의 ARM 빌드(멀티 아치)만 있으면 태스크 정의에서 아키텍처 한 줄 변경입니다.
- Fargate Spot: 중단 허용 워크로드(배치, 큐 소비자)라면 최대 70% 할인입니다. x86과 ARM 모두 지원되고, 2분 전 중단 통지를 처리할 수 있어야 합니다.
- Compute Savings Plans: 시간당 약정 금액을 걸면 Fargate에도 적용됩니다. EC2 기반처럼 인스턴스를 고정하지 않아도 약정 할인을 받을 수 있다는 뜻입니다.
셋은 겹쳐 쓸 수 있습니다. ARM에 Spot까지 겹치면 x86 온디맨드 대비 4분의 1 수준까지 내려가므로, “Fargate는 비싸서 못 쓴다"는 결론을 내리기 전에 이 축들을 먼저 적용해 봅니다. 놀고 있는 태스크·서비스 정리는 상시 점검 목록과 겹치는 작업입니다.
선택 순서 #
- 강제 조건부터 거릅니다: GPU, 호스트 접근, 16vCPU·120GB 초과, 특수 하드웨어 중 하나라도 걸리면 EC2 기반입니다.
- 아니면 Fargate로 시작합니다: 태스크 크기는 컨테이너의 실측 사용량(CloudWatch Container Insights)에 맞춰 격자에서 고르고, 작게 시작해 올립니다.
- 아키텍처는 ARM을 먼저 검토합니다: 멀티 아치 빌드만 갖추면 20%가 그대로 절감됩니다.
- 워크로드 성격에 맞춰 Spot·약정을 겹칩니다: 중단 허용이면 Spot, 기저 부하가 안정적이면 Compute Savings Plans입니다.
- 플릿이 커지면 재계산합니다: 부하가 평평해지고 사용률 90%대 운영이 가능해진 시점에 EC2 기반 전환의 단가 우위가 관리 비용을 넘는지 계산하고, 넘을 때만 옮깁니다.
정리 #
- Fargate는 태스크 크기만큼, EC2 기반은 인스턴스가 떠 있는 시간만큼 과금합니다. 모든 비교는 이 구조 차이에서 출발합니다.
- Fargate 스펙은 0.25〜16vCPU, 최대 120GB 메모리의 격자에서 고릅니다. GPU는 없고, 임시 스토리지는 기본 20GiB입니다.
- 같은 스펙의 온디맨드 단가 격차는 x86 약 16%, ARM 약 4%로 통념보다 작습니다. 비교를 가르는 것은 EC2 플릿의 실제 사용률입니다.
- EC2 기반은 GPU, 특수 하드웨어, 호스트 접근, 상시 고사용률 대형 플릿이라는 명확한 조건에서 선택합니다.
- Fargate 요금은 ARM 20%, Spot 최대 70%, Compute Savings Plans 약정으로 겹쳐 내립니다. 비싸다는 결론은 이 축들을 적용한 뒤에 내립니다.