AWS 01-3 요청이 올 때만 돈다 — Lambda·Batch
AWS 의 Lambda 는 아무도 부르지 않으면 한 푼도 받지 않습니다. 서버를 켜 둘 필요도 없습니다. 그런데 서울 리전에서 요청당 100 ms 걸리는 API 를 Lambda 에 올리고 앞에 API Gateway 를 세우면, 평균 초당 5건이 안 되는 요청으로도 한 달 요금이 작은 EC2 한 대를 넘어섭니다.
공짜로 시작하던 것이 어디서 역전되는지 이 편에서 직접 계산합니다. 그 전에 Lambda 가 무엇을 파는지 보고, 끝에서는 Lambda 가 못 하는 긴 일을 맡는 Batch 를 봅니다. 요금과 한도는 전부 2026-09-23 서울(ap-northeast-2) 기준입니다.
지도
flowchart TD
START["코드를 돌려야 하는데 늘 켜 둘 이유는 없다"] --> Q1{"한 번 실행이 15분 안에 끝나나"}
Q1 -- "끝난다" --> Q2{"요청이 한 달 내내 고르게 많은가"}
Q2 -- "아니다. 몰렸다 끊기거나 적다" --> L["Lambda<br/>부를 때만 실행"]
Q2 -- "그렇다" --> S["EC2·컨테이너<br/>켜 둔 서버가 더 싸다"]
Q1 -- "안 끝난다" --> Q3{"대부분 기다리는 시간인가"}
Q3 -- "그렇다. 승인·외부 응답을 기다린다" --> D["Lambda durable functions<br/>체크포인트로 최대 1년"]
Q3 -- "아니다. 계속 계산한다" --> B["Batch<br/>큐에 넣으면 서버를 띄워 돌린다"]
갈림길은 한 번 실행 시간(15분)과 한 달 동안의 요청 분포 두 가지입니다. 앞의 것은 한도라서 넘을 수 없고, 뒤의 것은 돈이라서 계산으로 정합니다. 그림의 durable functions 는 Lambda 의 확장 기능으로, 진행 결과를 체크포인트(나중에 이어 갈 수 있게 저장해 둔 진행 지점)로 남겨 15분을 넘는 실행을 잇습니다. 3절에서 봅니다.
1. Lambda — 부를 때만 켜지는 함수
Lambda 에 코드를 함수(function)로 올려 두면, 이벤트가 올 때 AWS 가 실행 환경을 띄워 그 함수를 돌리고 요청 수와 실행 시간만큼 받습니다.
실행 환경(execution environment)은 함수 하나가 도는 격리된 작은 컴퓨터로, Firecracker 라는 경량 가상 머신(마이크로VM) 위에 뜹니다. 한 실행 환경은 한 번에 요청 하나만 처리하고, 끝나면 얼려 두었다가 다음 요청에 다시 씁니다. 그러다 몇 시간 안에 AWS 가 거둬 갑니다. 서버를 빌리는 것이 아니라 실행 한 번을 빌리는 셈이고, 이렇게 서버를 직접 다루지 않는 방식을 서버리스라고 부릅니다.
무엇이 함수를 깨우나
함수를 부르는 쪽을 트리거(trigger)라고 합니다. HTTP 요청으로 부르는 입구는 둘입니다. API Gateway 는 API 앞에 세우는 관문 서비스로 인증·요청 제한·도메인 연결을 맡습니다. 함수 URL 은 함수 하나에 붙는 전용 HTTPS 주소입니다. 주소 자체에는 요금이 없지만, 인증은 IAM(AWS 의 권한 체계)이나 무인증 둘뿐입니다(Select a method to invoke your Lambda function using an HTTP request). 이 둘의 차이는 2절의 계산에서 돈으로 드러납니다. 이벤트로 부르는 쪽에는 S3 업로드와 EventBridge 가 있습니다. EventBridge 는 AWS 서비스와 애플리케이션에서 나온 이벤트를 규칙에 맞춰 다른 서비스로 보내는 서비스로, 정해진 시각에 함수를 부르는 일정 기능도 있습니다. 트리거마다 함수를 부르는 방식은 세 갈래로 나뉩니다.
| 호출 방식 | 대표 트리거 | 동작 |
|---|---|---|
| 동기 | API Gateway, 함수 URL | HTTP 요청을 받아 함수를 부르고 응답을 기다린다 |
| 비동기 | S3 파일 업로드, EventBridge 규칙 | 이벤트를 넘기고 응답을 안 기다린다 |
| 이벤트 소스 매핑 | SQS(Simple Queue Service) | Lambda 가 큐를 읽어 메시지 묶음을 함수에 넘긴다 |
요금 — 요청 수와 GB-초
Lambda 는 요청 한 건마다 붙는 요청 요금과 실행 시간에 매기는 실행 요금을 받습니다. 실행 요금의 단위 GB-초(GB-second)는 함수에 준 메모리(GB)에 실행 시간(초)을 곱한 값입니다. 메모리 512 MB 인 함수가 100 ms 돌면 0.5 × 0.1 = 0.05 GB-초이고, 시간은 1 ms 단위로 올림합니다. 실행 단가는 아키텍처에 따라 갈립니다. Arm 은 AWS 가 설계한 Arm 프로세서 Graviton 을 쓰는 아키텍처(arm64)이고, x86 은 인텔·AMD 계열(x86_64)입니다.
Lambda · 서울 · 2026-09-23
요청 100만 건당 $0.20
실행 x86 GB-초당 $0.0000166667
실행 Arm GB-초당 $0.0000133334
월 무료 한도 요청 100만 건 + 40만 GB-초
- 무료 한도는 x86 과 Arm 에 똑같이 적용되고 매달 다시 채워집니다
- 실행 환경을 새로 띄울 때 도는 초기화 코드의 시간도 실행 요금에 들어갑니다(AWS Lambda standardizes billing for INIT Phase)
요청 요금은 같고 실행 단가만 Arm 이 20% 쌉니다. 순수 자바·파이썬 코드는 아키텍처 설정 하나로 옮겨 가지만, 네이티브 라이브러리를 쓰면 Arm 용 빌드가 있는지부터 봐야 합니다.
한도
아래 표에서 설계를 자주 묶는 것은 실행 시간과 동시성(concurrency)입니다. 동시성은 같은 순간에 처리 중인 요청 수, 곧 떠 있는 실행 환경 수입니다. 계산식은 초당 평균 요청 수 × 평균 실행 시간(초) 이라서, 초당 100건이 0.5초씩 걸리면 동시성 50입니다.
| 항목 | 값 |
|---|---|
| 한 번 실행 최대 | 900초(15분) |
| 메모리 | 128 MB ~ 10,240 MB. CPU 는 메모리에 비례하고 1,769 MB 에서 vCPU 1개 상당 |
/tmp 임시 디스크 |
512 MB ~ 10,240 MB. 512 MB 까지는 추가 요금 없음 |
| 계정 동시성 | 리전당 기본 1,000. 새 계정은 더 낮게 시작해 사용량에 따라 자동으로 오른다 |
| 요청·응답 크기 | 동기 6 MB씩, 비동기 1 MB |
계정 동시성이 바닥나면 넘치는 요청은 스로틀링(throttling), 즉 거절당합니다(Lambda quotas · Understanding Lambda function scaling).
15분 한도에는 예외가 하나 있습니다. Lambda Managed Instances(함수를 내 계정의 EC2 인스턴스 위에서 돌리는 방식, 이 절 끝에서 다시 봅니다)는 비동기 호출과 이벤트 소스 매핑 호출(Amazon MQ·DocumentDB 제외)을 90분까지 돌립니다.
콜드 스타트와 대책
요청이 왔는데 쉬고 있는 실행 환경이 없으면, Lambda 는 코드를 받아 실행 환경을 새로 띄우고 핸들러(요청마다 불리는 함수 본체) 밖의 초기화 코드부터 돌립니다. 이 준비 시간이 콜드 스타트(cold start)입니다. 얼려 둔 실행 환경을 다시 쓰는 경우는 웜 스타트(warm start)라고 합니다.
콜드 스타트는 보통 호출의 1% 미만이고, 길이는 100 ms 미만부터 1초 넘게까지 갈립니다(Understanding the Lambda execution environment lifecycle). 의존 모듈이나 프레임워크를 올리는 초기화는 몇 초 걸리기도 합니다. 드물어도 사용자 앞에 선 API 라면 그 몇 초가 곧 응답 지연입니다. 이 지연을 없애는 길은 둘입니다. 초기화를 미리 해 둔 실행 환경을 기다리게 하거나, 초기화를 끝낸 결과를 저장해 두고 꺼내 쓰는 것입니다.
앞의 길이 프로비저닝된 동시성(provisioned concurrency)입니다. 정한 개수만큼 실행 환경을 미리 초기화해 늘 대기시킵니다. 요청은 준비가 끝난 환경이 받으므로 콜드 스타트가 없어지고, 대신 대기시킨 시간만큼 요금이 따로 나갑니다. 뒤의 길이 SnapStart 입니다. 함수의 버전(version), 곧 코드와 설정을 발행한 순간에 고정한 사본을 발행할 때 초기화를 한 번 하고, 끝난 상태를 스냅샷으로 떠 둡니다. 새 실행 환경은 처음부터 초기화하는 대신 이 스냅샷에서 되살아납니다. 두 기능 모두 이렇게 발행한 버전에 켭니다. 둘을 나란히 놓으면 이렇습니다.
| 프로비저닝된 동시성 | SnapStart | |
|---|---|---|
| 하는 일 | 정한 개수만큼 실행 환경을 미리 초기화해 늘 대기시킨다 | 버전을 발행할 때 초기화를 끝낸 메모리·디스크 상태를 스냅샷으로 떠 두고, 새 실행 환경을 거기서 되살린다 |
| 효과 | 두 자릿수 ms 안에 응답 | 몇 초 걸리던 시작을 최적일 때 1초 미만까지. 자주 불리는 함수일수록 효과가 크다 |
| 지원 | x86·Arm 모두 | 자바 11 이상, 파이썬 3.12 이상, .NET 8 이상 |
| 요금 | 켜 둔 시간 동안 따로 받는다. 무료 한도 적용 안 됨 | 자바는 추가 요금 없음. 파이썬·.NET 은 스냅샷 보관료 + 복원료 |
둘은 한 함수 버전에 같이 켤 수 없습니다. SnapStart 는 발행하지 않고 편집 중인 판($LATEST)에는 못 쓰고, EFS(Elastic File System, 공유 파일 시스템) 연결이나 512 MB 넘는 /tmp 와도 같이 못 씁니다. 자바로 Lambda 를 쓴다면 SnapStart 부터 켜 봅니다. 공짜이고 코드를 거의 안 고칩니다. 다만 초기화 때 만든 난수 시드나 고유 ID 가 스냅샷에 박혀 여러 실행 환경이 같은 값을 나눠 갖게 되므로, 그런 값은 핸들러 안에서 만들어야 합니다(Improving startup performance with Lambda SnapStart).
프로비저닝된 동시성은 대기만으로도 돈이 나갑니다. 서울에서 512 MB 짜리 하나를 한 달(2,628,000초) 켜 두면 x86 은 0.5 GB × 2,628,000 × $0.0000051254 = 약 $6.73, Arm 은 GB-초당 $0.0000041003 으로 약 $5.39 입니다. 처리한 요청에는 요청 요금과, 보통보다 싼 실행 요금(GB-초당 x86 $0.0000119592 · Arm $0.0000095674)이 따로 붙습니다. 30개를 켜 두면 x86 기준 대기에만 월 약 $202 로, t4g.small(월 $15.18) 열세 대 값입니다. 「켜 두지 않는다」는 Lambda 의 장점을 돈 주고 되사는 셈입니다.
그래서 Lambda 는 언제 맞나
부르지 않으면 돈이 안 나가는 대신, 한 번 실행 15분 한도와 콜드 스타트를 안고 가야 합니다.
| 이럴 때 맞다 | 이럴 때 안 맞다 | 대신 치르는 것 |
|---|---|---|
| 요청이 몰렸다 끊기는 API, 밤에는 거의 0 인 서비스 | 요청이 한 달 내내 고르게 많은 API(→ 2절의 교차점) | 요청이 많으면 켜 둔 서버보다 비싸진다 |
| S3 업로드·큐 메시지마다 도는 짧은 후처리, 정해진 시각의 짧은 작업 | 15분을 넘는 일 | 한 번 15분, 동기 요청 6 MB 한도가 설계를 묶는다 |
| 서버·OS 패치·스케일링을 맡기고 싶을 때 | 웹소켓처럼 연결을 오래 붙잡는 일, 실행 사이에 메모리 상태를 들고 있어야 하는 일 | 콜드 스타트와 계정 동시성을 늘 의식해야 한다 |
요청량이 2절의 교차점을 넘어 한 달 내내 머물면 켜 둔 서버로 갑니다(EC2 는 EC2 편 01-1, 컨테이너는 컨테이너 편 01-2). 중간 길로 Lambda Managed Instances 가 있습니다. EC2 인스턴스 값에 온디맨드 가격의 15% 인 관리 수수료와 요청 100만 건당 $0.20 을 더해 받고, 한 실행 환경이 요청 여럿을 동시에 받습니다(Lambda Managed Instances). 한 번 실행이 15분을 넘으면 3절의 durable functions 나 4절의 Batch 로 갑니다.
2. 초당 몇 건부터 EC2 한 대가 더 싼가
요청 하나를 받아 DB 를 한 번 읽고 JSON 을 돌려주는 흔한 API 를 두 방식으로 돌려 봅니다. Lambda 쪽은 요청당 100 ms·512 MB·Arm 함수이고, 입구는 함수 URL·API Gateway HTTP API·REST API 셋을 따로 셉니다. EC2 쪽은 EC2 편(01-1)에서 본 t4g.small(Graviton, vCPU 2 · 2 GiB) 한 대가 직접 요청을 받습니다. 양쪽 다 밖으로 나가는 전송량과 로그 요금은 뺐습니다.
두 쪽이 같은 양의 일을 감당하는지부터 봅니다. 512 MB 함수가 받는 CPU 는 vCPU 약 0.29개입니다(1,769 MB 에서 1개인 비례). 요청마다 100 ms 내내 CPU 를 다 써도 초당 10건이면 vCPU 0.29개어치입니다. t4g.small 은 CPU 크레딧(평소 기준 성능을 넘어 잠깐 치고 올라갈 때 쓰는, 시간 따라 쌓이는 여유분) 없이도 vCPU 2개 × 20% = 0.4개를 계속 낼 수 있으므로, 초당 10건 안팎은 한 대로 감당합니다. 대부분 DB 응답을 기다리는 API 라면 여유가 더 큽니다.
API Gateway 는 요청 수로 받고, 종류에 따라 값이 세 배 가까이 차이 납니다. 기능을 줄이고 값을 낮춘 HTTP API 는 100만 건당 $1.23(월 첫 3억 건), 기능이 더 많은 REST API 는 $3.50(월 첫 3억 3,300만 건)입니다. 기능 차이는 04-2편에서 봅니다.
양쪽 한 달 값을 셈합니다. EC2 쪽 단가는 EC2 편과 같습니다.
EC2 쪽 · 서울 · 한 달(730시간)
t4g.small $0.0208 × 730 = $15.18
EBS gp3 8 GB $0.0912 × 8 = $0.73
공인 IPv4 $0.005 × 730 = $3.65
합계 = $19.56
Lambda 쪽 · 초당 N 건 · 서울 · 한 달(2,628,000초)
요청 수 R = N × 2,628,000
GB-초 G = R × 0.05
Lambda (R − 100만) × $0.0000002
+ (G − 40만) × $0.0000133334
+ HTTP API R × $0.00000123
+ REST API R × $0.0000035
- Lambda 무료 한도는 매달 다시 채워지므로 계산에 넣었습니다(0 아래로는 안 내려갑니다). API Gateway 의 무료 한도는 넣지 않았습니다
| 초당 요청 | 월 요청 수 | Lambda 만(함수 URL) | + HTTP API | + REST API | EC2 한 대 |
|---|---|---|---|---|---|
| 1 | 263만 | $0.33 | $3.56 | $9.52 | $19.56 |
| 2 | 526만 | $0.85 | $7.32 | $19.25 | $19.56 |
| 5 | 1,314만 | $5.85 | $22.02 | $51.84 | $19.56 |
| 10 | 2,628만 | $17.24 | $49.57 | $109.22 | $19.56 |
| 20 | 5,256만 | $40.02 | $104.67 | $223.98 | $19.56 |
EC2 한 대($19.56)와 같아지는 교차점을 식으로 풀면, 요청이 한 달 내내 고르게 들어올 때 함수 URL 초당 약 11건, HTTP API 약 4.6건, REST API 약 2.0건입니다(REST API 는 초당 2건에서 $19.25 로 아직 Lambda 가 쌉니다). 표를 보면 교차점을 끌어내리는 주범은 Lambda 가 아니라 API Gateway 입니다. 초당 10건에서 Lambda 값은 $17 인데 HTTP API 가 $32 를 더 얹습니다.
몰렸다 끊기는 부하에서는 계산이 달라진다
위 표는 요청이 고르게 들어온다고 친 값입니다. 낮 12시간은 초당 30건, 밤 12시간은 0 인 API 를 대 보면 평균은 초당 15건으로 함수 URL 교차점(11건)을 넘지만, 결론은 반대로 나옵니다. EC2 는 평균이 아니라 가장 붐빌 때에 맞춰 대수를 정해야 하기 때문입니다. 한 대가 초당 약 10건이면 30건에는 세 대와 그 앞의 로드 밸런서(ALB, EC2 편 기준 시간당 $0.0225)가 필요합니다.
낮 12시간 초당 30건 · 밤 0건 · 서울 · 한 달
월 요청 수 30 × 365시간 × 3,600 = 3,942만 건
Lambda + 함수 URL = 약 $28.63
Lambda + HTTP API $28.63 + $48.49 = 약 $77.12
EC2 세 대 한 달 내내 3 × $19.56 = $58.69
+ ALB $0.0225 × 730 = $16.43
합계 = 약 $75.12 (+ 처리량 요금)
밤에 한 대로 줄이면 평균 두 대 = 약 $55.55
몰렸다 끊기는 부하에서는 Lambda + 함수 URL 이 밤에 줄인 EC2 보다도 절반 값입니다. HTTP API 를 붙이면 EC2 세 대와 비슷해집니다. 한 달 평균이 교차점을 넘어도 가장 붐빌 때와 평균의 차이가 크면 Lambda 가 이길 수 있고, 요청이 고르게 들어오면 교차점이 그대로 답입니다.
3. Lambda durable functions — 15분을 넘겨 기다리는 함수
주문 → 결제 → 사람의 승인을 사흘 기다림 → 배송 요청 같은 흐름은 계산은 몇 초인데 기다림이 깁니다. 15분 한도 안에서는 못 기다리고, 서버를 사흘 켜 두자니 아깝습니다.
durable functions 는 이런 흐름을 위한 Lambda 기능이고, 서울 리전에서 쓸 수 있습니다. 함수 안에 단계(step)와 대기(wait)를 선언해 두면 단계 하나가 끝날 때마다 결과를 체크포인트로 남기고, 최대 1년 동안 이어서 실행합니다. 대기에 들어가면 함수를 끝내고, 그동안 실행 요금이 붙지 않습니다(프로비저닝된 동시성을 켜지 않은 보통 함수 기준). 기다리는 대상은 정해 둔 시간일 수도 있고 콜백(callback)일 수도 있습니다. 콜백은 승인 시스템 같은 바깥 쪽이 「끝났다」는 API 를 불러 멈춘 실행을 깨우는 방식입니다.
깨어나면 Lambda 는 함수를 처음부터 다시 부르고, 이미 끝난 단계는 코드를 다시 돌리지 않고 저장된 결과를 꺼내 씁니다. 이 과정을 재실행(replay)이라고 합니다. 단계 밖의 코드는 재실행 때마다 다시 돌기 때문에, 난수나 현재 시각처럼 돌 때마다 값이 바뀌는 코드는 단계 안에 넣어야 합니다. 한 번 호출은 여전히 함수 제한 시간(최대 15분)을 지키고, 1년은 호출 여럿을 이은 전체 실행의 상한입니다(Basic concepts).
공식 SDK(Software Development Kit)는 Node.js·파이썬·자바·C#/.NET 에 있습니다. 실행 하나에 단계·대기는 3,000개, 저장하는 데이터는 누적 100 MB 까지이고 둘 다 못 늘립니다. 끝난 실행의 기록은 1~90일(기본 14일) 보관합니다.
durable functions 추가 요금 · 서울 · 2026-09-23
단계·대기·콜백 같은 연산 100만 건당 $9.80
저장한 데이터 GB 당 $0.30
보관 중인 데이터 GB-월 당 $0.19
+ 기존 Lambda 요청·실행 요금
사흘 승인 흐름을 한 달에 주문 1만 건 돌린다고 쳐 봅니다. 주문 하나에 연산 5개(시작 1 · 단계 3 · 콜백 대기 1), 연산마다 10 KB 를 저장한다고 잡은 값입니다.
주문 1만 건 · 사흘 승인 · 서울 · 한 달
연산 5 × 1만 = 5만 건 × $9.80/100만 = $0.49
저장 50 KB × 1만 = 0.5 GB × $0.30 = $0.15
보관 0.5 GB × (3일 + 14일) ÷ 30 × $0.19 = $0.05
Lambda 호출 2만 번, 실행은 무료 한도 안 = $0
합계 ≈ $0.70
사흘을 기다리는 주문 1만 건이 월 1달러가 안 됩니다. 기다림에 돈이 안 나가기 때문입니다.
같은 문제를 푸는 AWS 서비스로 Step Functions 가 있습니다. Step Functions 는 흐름을 코드 밖의 상태 기계 정의로 그리고 여러 서비스를 엮는 쪽이고, durable functions 는 흐름을 함수 코드 안에 평소 쓰는 언어로 적는 쪽입니다. Step Functions 는 07-2편(이벤트로 잇고 흐름을 짠다)에서 봅니다. durable functions 는 기다림이 싼 대신 재실행을 견디는 코드와 못 늘리는 한도 둘을 요구합니다.
| 이럴 때 맞다 | 이럴 때 안 맞다 | 대신 치르는 것 |
|---|---|---|
| 사람 승인·외부 콜백을 며칠씩 기다리는 업무 흐름 | 쉬지 않고 계산만 몇 시간 하는 일(→ Batch) | 재실행을 전제로 코드를 짜야 한다 |
| 단계가 있고 중간 실패 뒤 이어서 해야 하는 처리 | 단계가 3,000개를 넘거나 저장할 데이터가 100 MB 를 넘는 일 | 두 한도를 못 늘린다 |
| AI 에이전트처럼 모델 응답을 기다리며 여러 번 오가는 흐름 | 흐름을 코드 밖에서 그림으로 관리하고 싶을 때(→ Step Functions) | 연산·저장·보관 요금이 따로 붙는다 |
흐름이 여러 서비스를 넘나들고 운영자가 진행 상태를 그림으로 봐야 하면 Step Functions 를, 기다림이 아니라 계산이 길면 Batch 를 봅니다.
4. Batch — 큐에 넣으면 서버를 띄워 돌린다
밤마다 영상 2,000개를 인코딩해야 한다고 해 봅니다. 하나에 20분씩 걸려 Lambda 15분에 안 들어갑니다. EC2 수십 대를 손으로 띄우고 일감을 나누고 끝나면 끄는 일을 맡는 것이 Batch 입니다. 컨테이너로 싼 일괄 작업을 큐에 넣으면, EC2·Fargate(서버 없이 컨테이너만 돌려 주는 AWS 컴퓨팅)·스팟 가운데 정해 둔 컴퓨팅을 필요한 만큼 띄워 돌리고 다 끝나면 줄입니다. Batch 자체 요금은 없고, 띄운 EC2·Fargate 와 거기 딸린 디스크·전송량 값을 냅니다(AWS Batch Pricing). 이 일은 구성 요소 넷으로 정의합니다.
| 구성 요소 | 하는 일 | 영상 예에서 |
|---|---|---|
| 작업(job) | 제출하는 일의 단위. 컨테이너 하나로 돈다 | 「영상 인코딩」 한 건 |
| 작업 정의(job definition) | 작업의 설계도. 컨테이너 이미지·vCPU·메모리·IAM 역할·환경 변수 | 인코더 이미지, vCPU 4 · 8 GiB |
| 작업 큐(job queue) | 제출된 작업이 컴퓨팅을 기다리는 줄. 우선순위를 줄 수 있다 | 급한 큐 · 싼 시간에 도는 큐 |
| 컴퓨팅 환경(compute environment) | 작업을 돌릴 컴퓨팅 묶음. 종류와 최소·최대 vCPU 를 정한다 | 스팟 EC2, 최대 512 vCPU |
영상마다 작업을 2,000번 제출할 필요는 없습니다. 배열 작업(array job)으로 한 번 제출하면 Batch 가 크기만큼 자식 작업을 만들고, 자식마다 번호(0~1,999)를 환경 변수 AWS_BATCH_JOB_ARRAY_INDEX 로 넘겨 어느 영상을 맡을지 알려 줍니다. 배열 크기는 최대 10,000입니다. 노드 여러 대가 한 작업을 같이 도는 다중 노드 병렬 작업(multi-node parallel job)도 있어서, GPU 여러 대로 모델 하나를 학습시키는 일에 씁니다.
영상 예의 결말을 셈해 봅니다. 작업 하나가 c7g.xlarge(Graviton, vCPU 4 · 8 GiB, 서울 온디맨드 시간당 $0.1632) 한 대를 쓴다고 칩니다.
영상 2,000개 × 20분 · 최대 512 vCPU · 서울
동시에 도는 작업 512 ÷ 4 = 128개
걸리는 시간 2,000 ÷ 128 = 16회차 × 20분 ≈ 5시간 20분
인스턴스 시간 2,000 × 1/3시간 ≈ 667시간
온디맨드 667 × $0.1632 ≈ $109
스팟 할인폭은 때마다 다르고 최대 90% → 최저 약 $11
+ EBS·전송량
하룻밤 5시간 남짓에 끝나고, 온디맨드면 약 $109, 스팟이면 그보다 크게 내려갑니다. 스팟(Spot)은 AWS 의 남는 EC2 를 싸게 쓰는 대신 2분 예고 뒤 회수당할 수 있는 방식이라, 끊겨도 다시 하면 되는 일괄 작업과 잘 맞습니다. Batch 는 작업이 스스로 실패하면 재시도하도록 설정할 수 있습니다. 다만 제한 시간을 넘겨 끊긴 작업은 재시도하지 않습니다. 작업에는 기본 제한 시간이 없어서, 무한 반복에 빠진 작업을 막으려면 제한 시간(최소 60초)을 걸어 둡니다(Job timeouts).
컴퓨팅 종류는 이렇게 고릅니다(When to use Fargate).
| Fargate | EC2(온디맨드·스팟) | |
|---|---|---|
| 시작 속도 | 약 30초 | 인스턴스를 새로 띄우면 몇 분 |
| 맞는 일 | 작업 크기가 제각각인 데이터 변환·리포트 생성처럼 AWS 가 권하는 대부분의 작업 | vCPU 32개·메모리 244 GiB 를 넘는 작업, GPU 작업, 직접 만든 AMI 가 필요한 작업, 동시 작업이 아주 많을 때 |
| 실행 시간 | 14일을 넘기면 도중에 끊길 수 있다 | 제한 없음 |
긴 계산을 싸게 병렬로 돌리는 대신, 시작이 느리고 미리 갖춰 둘 것이 많습니다.
| 이럴 때 맞다 | 이럴 때 안 맞다 | 대신 치르는 것 |
|---|---|---|
| 15분 넘게 계산하는 일괄 작업(인코딩·시뮬레이션·대량 변환) | 사용자가 응답을 기다리는 요청 | EC2 를 새로 띄우면 시작까지 몇 분 걸린다 |
| 같은 일을 수천 건 병렬로 | 몇 초짜리 이벤트 처리(→ Lambda 가 싸고 빠르다) | 작업을 컨테이너 이미지로 싸고 구성 요소 넷을 설정해야 한다 |
| GPU 가 필요한 일, 스팟으로 값을 깎고 싶은 일 | 늘 같은 양이 도는 상시 작업 | 최소 vCPU 를 0 으로 두지 않으면 쉬는 동안에도 값이 나간다 |
작업이 몇 분 안에 끝나고 건수가 때마다 다르면 Lambda 가 더 단순합니다. 늘 같은 양이 도는 상시 작업이면 ECS(Elastic Container Service) 서비스로 켜 두는 쪽이 낫습니다(컨테이너 편 01-2).
이럴 땐 무엇
| 상황 | 서비스 | 이유 |
|---|---|---|
| 낮에만 몰리고 밤에는 0 인 API | Lambda + 함수 URL 또는 HTTP API | 가장 붐빌 때에 맞춘 EC2 여러 대보다 싸다 |
| 요청이 한 달 내내 고르고 교차점(함수 URL 11건 · HTTP API 4.6건 · REST API 2.0건)을 넘는다 | EC2 또는 컨테이너 | 켜 둔 서버 한 대가 더 싸다 |
| 웹훅처럼 단순한 HTTP 입구 하나 | Lambda + 함수 URL | API Gateway 요금이 안 붙는다 |
| 자바 API 의 콜드 스타트가 거슬린다 | Lambda + SnapStart | 자바는 추가 요금 없음 |
| 콜드 스타트를 아예 없애야 한다 | Lambda + 프로비저닝된 동시성 | 미리 초기화, 대신 켜 둔 시간만큼 요금 |
| 사람 승인을 며칠 기다리는 업무 흐름 | Lambda durable functions | 기다리는 동안 실행 요금 0원 |
| 영상 수천 개를 밤새 인코딩 | Batch + 스팟 EC2 | 배열 작업, 스팟 할인 |
| GPU 로 모델을 학습시키는 일괄 작업 | Batch + EC2 GPU 인스턴스 | Batch 는 GPU 작업에 EC2 를 권한다 |
자주 붙는 서비스는 API Gateway · S3 · SQS · EventBridge(트리거), IAM(실행 역할), CloudWatch(로그·지표), ECR(컨테이너 이미지 보관), Step Functions(흐름 정의)입니다. 여러 서비스를 엮어 끝까지 따라가는 설명은 조합 편(이 시리즈 20번대)에서 합니다.
한 장 요약
Lambda 는 요청 100만 건당 $0.20 + GB-초(서울 Arm $0.0000133334)를 받고, 매달 100만 건·40만 GB-초가 무료입니다. 한 번 실행은 15분까지이고, 자바라면 콜드 스타트 대책인 SnapStart 가 공짜입니다. 요청이 고르게 들어오면 함수 URL 초당 약 11건, HTTP API 약 4.6건, REST API 약 2.0건부터 EC2 한 대가 싸지만, 몰렸다 끊기는 부하에서는 Lambda 가 이길 수 있습니다. 며칠 기다리는 흐름은 durable functions, 15분 넘게 계산하는 일은 Batch 가 맡습니다.
관련 항목
요청이 올 때만 도는 같은 갈래
AWS Lambda · Lambda durable functions · AWS Batch · Lambda Managed Instances
Lambda 를 깨우는 트리거
API Gateway · Lambda 함수 URL · Amazon S3 · Amazon SQS · Amazon EventBridge · 이벤트 소스 매핑
Lambda 요금과 한도를 이루는 단위
GB-초 · AWS 프리 티어 · Graviton · Arm · x86 · 동시성 · 예약된 동시성 · 스로틀링 · Service Quotas
콜드 스타트를 다루는 장치
콜드 스타트 · 실행 환경 · 프로비저닝된 동시성 · SnapStart · Lambda 버전 · Firecracker
durable functions 를 이루는 개념
체크포인트 · 재실행 · 콜백 · 내구성 실행 · AWS Step Functions
Batch 를 이루는 구성 요소와 컴퓨팅
작업 정의 · 작업 큐 · 컴퓨팅 환경 · 배열 작업 · 다중 노드 병렬 작업 · EC2 · Fargate · 스팟 인스턴스 · GPU · AMI
같은 일을 켜 둔 서버로 하는 수단
t4g.small · CPU 크레딧 · Application Load Balancer · ECS · EKS
이 서비스들이 올라앉는 바탕
서버리스 · 마이크로VM · 컨테이너 · Docker · 이벤트 기반 아키텍처