07. Cost & Scaling — Lambda vs Fargate vs EC2 vs MediaConvert, GPU, spot

이 문서가 답하는 질문: 어떤 컴퓨트로 어떤 단계를 돌릴까? GPU는 언제 쓰고 spot은 언제 쓰나?

한 줄 답

컴퓨트 선택은 “단계의 시간 분포 × 동시성 패턴 × 1초당 비용” 의 3축으로 결정된다. Lambda는 짧고 간헐적, Fargate는 중간 길이 + 격리, EC2 spot은 긴 작업 + 비용 우선, MediaConvert/Elastic Transcoder는 transcode 외주. GPU 인코딩은 H.264/H.265는 비용 효율, AV1은 아직 CPU가 더 쌀 수 있다 — 항상 비용 단가 측정 후 결정.

Why — 왜 한 가지 컴퓨트로 안 되는가

미디어 파이프라인의 단계는 시간/메모리/CPU 프로파일이 극단적으로 다르다.

→ 모든 단계를 한 컴퓨트로 처리하려 하면 어느 한쪽이 비효율.

• 모두 Lambda → transcode 시간 부족 + 메모리 한도
• 모두 EC2 → probe/DB write에서 idle 비용 폭주

How — 컴퓨트 선택의 3축

1) 컴퓨트 옵션 비교표

2) “Lambda를 쓸까 vs Fargate를 쓸까”의 결정 트리

Lambda를 고를 때:

• 단계가 15분 안에 끝남
• 메모리 ≤ 10GB
• 동시성이 변동 큼 (event-driven)
• 외부 binary는 Layer로 packaging 가능

Fargate를 고를 때:

• 15분 초과 가능성
• 메모리 > 10GB
• 컨테이너 그대로 lift-and-shift
• spike가 없고 baseline 동시성 있음

EC2 spot을 고를 때:

• 시간당 처리량이 명확하고 인터럽트 견딜 수 있음
• 비용이 critical
• 자체 스케줄러 운영 가능

MediaConvert를 고를 때:

• 다양한 코덱/포맷 출력 필요
• minute 단가 OK (영상당 $0.005-0.05 수준)
• 자체 인코딩 운영 부담 회피

3) 미디어 파이프라인의 표준 조합

→ Lambda × 3 + MediaConvert × 1. 가장 흔한 형태.

장점:

• Lambda: 가벼운 단계는 invocation 단위 비용 → 비용 효율
• MediaConvert: 무거운 transcode는 매니지드로 외주 → 인프라 운영 부담 0

대안 (자체 transcode):

• Lambda transcode (15분 이내): cold start + Layer 빌드 가능
• Fargate transcode: 컨테이너로 ffmpeg 운영
• EC2 spot transcode: 비용 최저이지만 운영 부담 최고

What — 비용 구조의 디테일

1) 진짜 비용은 컴퓨트가 아니다

AWS 청구서를 까보면 미디어 파이프라인의 컴퓨트 비용은 30-40%다. 나머지는:

→ 컴퓨트만 최적화하면 30-40%만 손댄 것. 저장 + 전송 + 매니지드가 더 큰 항목.

2) Lambda 비용 모델

비용 = (메모리 GB × 실행 시간 초 × $0.0000166667) + (요청 수 × $0.20/1M)

메모리는 곧 vCPU — Lambda는 메모리 GB에 비례해 vCPU/네트워크 대역폭 자동 조정.

역설: 메모리를 늘리면 시간당 비용↑이지만, 처리 시간이 더 줄어들면 총 비용이 감소 가능.

256MB × 30초 = 7.68 GB-s × $0.0000166 = $0.000128
1024MB × 8초 = 8.19 GB-s × $0.0000166 = $0.000136 (조금 더 비싸지만 빨라짐)
3008MB × 3초 = 9.02 GB-s × $0.0000166 = $0.000150 (더 비쌈)

→ CPU-bound 작업은 1769MB 근처가 sweet spot. 메모리 의존 작업은 필요한 만큼만.

arm64 (Graviton2) — x86 대비 20% 저렴 + 19% 빠름. Lambda Layer 빌드만 arm64로 맞추면 됨.

3) MediaConvert 비용 모델

$ per minute of output × 출력 수

(가격은 region/시점에 따라 다름 — 항상 공식 가격 확인)

핵심:

• 출력 minute(input 아님) 기준 — ABR ladder 4단(360p+540p+720p+1080p)이면 minute × 4
• Reserved transcoding slot 옵션 — 상시 처리량이면 30-50% 할인
• Job Template으로 출력 옵션 미리 정의 — 호출마다 옵션 작성 부담 없음

4) S3 비용 — 미디어의 가장 큰 함정

Lifecycle policy가 핵심:

• Hot 산출물 (HLS, sprite) → S3 Standard
• Cold 원본 (raw upload) → IA 또는 Glacier IR (30-90일 후)
• 영구 보관 → Deep Archive

예: 1TB 미디어를 30일만 hot 유지 + 1년 cold:

• 모두 Standard: $0.023 × 1000GB × 12 = **$276/년**
• Lifecycle 적용: $0.023 × 1000 × 1 +$0.004 × 1000 × 11 = $67/년 (76% 절감)

놓치기 쉬운 비용:

• 버전 관리 — 켜지면 모든 PUT이 새 버전, 삭제 안 됨. 미디어 파이프라인은 보통 끔.
• MultiPart upload 미완료 — abort 안 한 부분이 영구 저장. Lifecycle로 7일 후 자동 abort.
• EventBridge / S3 Event 비용 — 자체는 싸지만 throttle 시 retry로 폭주 가능.

5) 데이터 전송 비용 — 가장 안 보이는 함정

가장 흔한 사고:

• VPC Lambda → 외부 API 호출 시 NAT 통과 → GB당 $0.045
• Cross-region replication 안 끄고 두면 영원히 비용 누적
• CloudFront 미사용 → S3 → 사용자 직접 egress가 비싸게 됨

6) GPU 인코딩 — 언제 의미 있는가

GPU instance (g4/g5/p3)는 NVENC/NVDEC로 H.264/H.265 가속.

비용 분석 예 (1080p 1시간 영상):

• CPU encode (c5.4xlarge): 30분 × $0.68/h =$0.34
• GPU encode (g4dn.xlarge): 5분 × $0.526/h =$0.044
• MediaConvert: 60분 × $0.015 =$0.90 (Basic HD)

→ 자체 운영하면 GPU가 압도적 저렴, 그러나 GPU instance 운영 부담 + spot 회수 위험. → MediaConvert는 운영 부담 0의 대가로 단가 ↑ — 트레이드오프.

7) Spot Instance — 비용 vs 안정성

EC2 spot은 on-demand의 60-90% 할인. 단점은 2분 경고 후 회수 가능.

미디어 파이프라인 spot 활용 패턴:

• chunk 단위 transcode — 1분 segment 단위로 처리, 회수 시 다른 worker가 이어서
• 체크포인트 — DynamoDB에 진행 상황 저장
• Fargate Spot — 컨테이너 spot, 더 단순

한계: spot은 capacity가 부족할 때 회수가 잦아짐. mission-critical에는 mixed (on-demand + spot) 권장.

What-if — 잘못 쓰면 어떻게 깨지는가

1) “Lambda 메모리 무지성 max”

10GB 메모리는 256MB의 40배 비용. 작업이 메모리 의존이 아니면 1769MB(1 vCPU)가 sweet spot. → Lambda Power Tuning 도구로 측정.

2) “MC ClientRequestToken 없이 retry”

같은 영상 두 번 transcode → minute 비용 2배. 자세히는 04.

3) “S3 lifecycle policy 안 둠”

미사용 raw 영상이 Standard에 영원히 → 매월 $$$ 누적. → 모든 버킷에 lifecycle policy 의무화.

4) “VPC Lambda + NAT Gateway 무지성”

VPC Lambda가 외부 API 호출 시 NAT 통과 — GB당 $0.045. → VPC endpoint 활용 (S3, DynamoDB는 무료 endpoint), VPC 안 진짜 필요한 람다만 넣기.

5) “Spot으로 critical path 운영”

업로드 → 재생까지의 critical path를 spot으로 짜면 회수 시점에 처리 멈춤. → critical은 on-demand, retry/batch 작업만 spot.

6) “GPU instance idle”

GPU instance는 시간당 $0.5-3.0+ — idle하면 비용 폭주. → on-demand + auto-scale (작업 갯수에 따라) 또는 Fargate (작업당 과금).

7) “관측 비용 모니터링 안 함”

CloudWatch Logs ingestion은 GB당 $0.50, 보관 GB당$0.03/월. 람다가 verbose log를 빨아대면 한 달 $$$. → 로그 retention 짧게 (7-30일), debug 로그는 dev에만, sample rate 적용.

Insight — 흥미로운 이야기

“AWS Lambda의 가격 모델은 100ms 단위에서 1ms 단위로 (2020)”

처음 Lambda는 100ms 단위 과금이었다 — 30ms 작업도 100ms 청구. 2020년부터 1ms 단위로 바뀌면서 짧은 작업의 비용이 떨어졌다. 이 변화 이후 “DB write 한 줄을 위한 Lambda”가 경제적으로 합리적이 됐다 (자세히는 funnel Lambda 패턴, 05).

“MediaConvert는 자체 만든 Elemental의 후예”

AWS는 2015년 Elemental Technologies를 인수했다 — 방송사 인코더 회사. MediaConvert/MediaLive/MediaPackage 모두 Elemental 출신. 그래서 MC는 다른 AWS 서비스보다 영상 산업의 use case에 깊다 (HDR, IMSC1 자막, SCTE-35 cue 등). 단점: 인터페이스가 방송 산업 용어로 가득해서 일반 개발자는 진입장벽 있음 (Job Template 필수).

“Graviton (arm64)이 미디어에 의미 있는 이유”

Graviton2/3는 x86 대비 20-40% 저렴 + 19-25% 빠름. 게다가 ffmpeg/sharp 같은 미디어 binary가 arm64에 잘 컴파일된다. 의의: 미디어 파이프라인은 arm64 first가 거의 표준. Layer 빌드만 arm64 조심하면 즉시 비용 20%↓.

“Cloudflare R2의 등장이 S3 egress 가격을 깼다”

2022년 Cloudflare R2 — egress 무료. AWS S3가 GB당 $0.085 받는 구간을 R2가 0원으로 도전. AWS는 응답으로 일부 region 무료 이체 늘렸다. 미디어처럼 egress가 큰 워크로드는 multi-cloud 검토 가치 있음. CDN+origin storage가 다른 벤더면 cross-cloud egress 비용 주의.

“Spot Instance는 AWS의 잉여 캐파를 파는 것”

AWS는 capacity planning에서 buffer를 둔다. 그 buffer를 spot으로 판매. 그래서 같은 instance type이라도 region/AZ별로 spot 가격이 시간에 따라 다르게 변동. 잘 운영하면 60-90% 할인이지만 회수 빈도도 시점/지역마다 다름. 운영 팁: spot fleet (여러 instance type 동시 입찰)으로 한 type 회수돼도 다른 type으로 자동 이동.

요약 + Mermaid

요점 — 컴퓨트 선택은 시간/동시성/단가의 3축. 표준 조합은 Lambda × 가벼운 단계 + MediaConvert × transcode. 진짜 비용은 컴퓨트가 30-40%이고 저장/전송이 더 클 수 있다 — S3 lifecycle, NAT Gateway, CloudWatch가 숨은 함정. arm64로 즉시 20% 절감, MC ClientRequestToken으로 중복 방지, GPU/spot은 운영 부담 트레이드오프. 이 챕터의 모든 결정(01-07)이 합쳐져 한 운영 사례를 만든다.