🔥 Spot, On-Demand, Reserved: 세 가지 가격 모델

한 달 t3.medium 한 대를 서울 리전에 띄워 두고 처음 받아 본 청구서에서 EC2 한 줄을 봤다. 시간당 단가에 720시간을 정확히 곱한 금액이 거기 있었다. 켜 둔 시간만큼 정확히 빠지는, 가장 정직한 가격. 그날 처음으로 "그러면 이 한 줄을 깎는 다른 모델은 어떻게 생겼지?"를 진지하게 살펴봤다.

가격 페이지에서 마주친 답은 네 종류다. On-Demand, Spot, Savings Plans, Reserved Instances. 할인되는 방식과 그 대가로 받아들이는 부담이 모두 다르다. "관리형이 감추는 비용"이라는 표현을 CloudWatch 편부터 반복해 왔는데, EC2 가격 모델이 그 표현에 가장 잘 들어맞는다. 시간당 단가가 깎이는 대신 내가 운영해야 할 손잡이가 한 두 개씩 늘어난다.

On-Demand가 가격 모델의 출발점인 이유

On-Demand는 약정 없이 시간(또는 초) 단위로 켠 만큼만 비용을 부과한다. AWS 공식 EC2 On-Demand 가격 페이지에서 m6i.large는 us-east-1 기준 시간당 $0.096이다. 24/7로 한 달 켜 두면 $0.096 × 24 × 30 = $69.12. 서울 리전(ap-northeast-2)은 us-east-1 대비 단가가 다르므로, 정확한 서울 단가는 가격 페이지의 region 선택을 ap-northeast-2로 두고 직접 확인한다(아래 worked example의 $0.124/hr는 인용 시점에 확인한 가정값이다).

이 가격이 나머지 세 모델의 기준선이다. Spot이 "최대 90% 할인"이라고 말할 때의 100%, Savings Plans가 "최대 72%"라고 말할 때의 100%, Reserved Instance가 "최대 72%"라고 말할 때의 100%는 셋 다 On-Demand 시간 단가가 분모다. 그래서 어떤 절감을 이야기하든 On-Demand가 얼마인지부터 확실히 잡고 들어간다.

또 하나, On-Demand는 깎이는 대가로 무엇도 약속하지 않는 유일한 모델이다. 갑자기 인스턴스를 두 배로 늘려도 같은 시간당 단가가 그대로 적용되고, 한 시간 만에 전부 끄면 그 한 시간만 청구한다. 탄력 자체가 가치인 단계, 즉 부하의 형태가 아직 안 잡혔거나 6개월 안에 기술 스택을 바꿀 가능성이 큰 단계에서 이 기준선을 그대로 유지하는 것이 가끔 가장 합리적이다.

Spot은 어떻게 90%까지 깎이는가: spare capacity와 2분 통보의 거래

AWS의 Spot Instance 페이지는 시간당 가격을 On-Demand 대비 최대 90%까지 낮춰 준다고 적어 둔다. 실제 절감폭은 리전·인스턴스 타입·시간대에 따라 다르다. 90%는 상한선일 뿐 보장이 아니고, 어떤 풀에서는 단가가 On-Demand에 가깝게 올라가는 시점도 등장한다.

이 깊은 할인이 어디서 오느냐. AWS가 한 리전·한 가용영역의 한 인스턴스 타입에 평소 사용량보다 많은 capacity를 미리 깔아 둔다. 그 남는 capacity를 Spot이라는 이름으로 다시 시장에 내보낸다. 누군가가 같은 capacity를 On-Demand 가격에 사겠다고 하면, AWS는 Spot을 회수해서 그 요청에 줘야 한다. 그래서 Spot 인스턴스에는 언제든 회수가 가능하다는 한 가지 약속이 같이 따라온다.

회수가 결정되면 EC2가 2분 전 interruption notice를 인스턴스 메타데이터(/latest/meta-data/spot/instance-action)와 EventBridge로 함께 보낸다. 2분이 지나면 AWS가 stop 또는 terminate 동작을 시작한다. Hibernation 동작이 걸린 경우에는 interruption notice 자체의 적용이 다르므로, 일반 stop/terminate와 같은 2분 여유를 가정하지 않는 게 안전하다. 이 2분은 짧지만, 잘 설계된 워크로드는 그 안에 진행 중인 작업을 체크포인트하고, ECS/Kubernetes 같은 오케스트레이터가 워크로드를 다른 인스턴스로 이관한다.

평균 회수율은 어떨까. AWS Spot Instance Advisor는 직전 30일 데이터를 기준으로 인스턴스 타입·리전별 frequency of interruption을 < 5% / 5–10% / 10–15% / 15–20% / >20%의 다섯 단계로 표시한다. 전체 평균은 5% 미만으로 잡혀 있고, 일반 패밀리들이 자주 < 5% 칸에 분포한다(단 시점·리전 의존). 단, 이 숫자는 과거의 30일이지 내일의 보장이 아니다. capacity 부족이 한 번 터지면 그 칸이 며칠 사이에 바뀐다.

Spot 요청 시점에 어느 capacity 풀에서 인스턴스를 가져올지 결정하는 손잡이를 allocation strategy라고 부른다. 다섯 가지로, lowest-price, capacity-optimized(2019-08 도입), capacity-optimized-prioritized, diversified, price-capacity-optimized(2022-11 도입). 마지막 price-capacity-optimized가 가격과 회수 가능성을 동시에 보고 풀을 고른다. AWS가 2026년 현재 기본 권장으로 표기하고 있고, 새 fleet을 짤 때 이유 없이 lowest-price를 고르면 가격은 살짝 더 싸지만 회수율이 높아져 결과적으로 손해가 자주 난다.

여기서 "관리형이 감추는 비용"이 한 번 더 등장한다. Spot 시간당 단가는 분명 싸다. 그런데 그 단가를 누리려면 내가 운영해야 할 별도 인프라가 자란다. 인스턴스 타입을 충분히 다양화하고(여러 타입과 가용영역을 섞고), capacity rebalancing을 켜고, 2분 안에 작업을 옮길 lifecycle hook을 짜고, 회수가 빈번한 시간대를 모니터링한다. 이 운영 비용, 즉 사람 시간과 운영 복잡도가 m6i.large 한 대를 90% 깎는 대목에서는 잘 드러나지 않는다. 한 달에 m6i.large 100대를 24/7 운용하는 규모에서는 그 운영 비용이 절감액 안쪽으로 들어와 명백한 흑자가 되지만, 5대를 운용하는 소규모에서는 종종 적자다.

옛날에 있던 Spot Block, 1~6시간을 회수 없이 보장해 주던 옵션은 2021-07-01부로 신규 가입을 종료했고 기존 고객도 2022-12-31까지만 지원했다. 지금은 사용할 수 없는 옵션이라 아직도 일부 글에 남아 있는 "Spot Block 6시간 보장"은 더는 답이 아니다.

Spot이 맞는 곳은 명확하다. 작업이 stateless이거나, 체크포인트로 한 번에 분 단위 진척을 잃어도 괜찮은 batch·CI/CD·렌더 파이프라인·머신러닝 학습. 반대로 금지해야 할 곳도 명확하다. 데이터베이스 같은 stateful 워크로드, 사용자가 5초 latency를 즉시 인지하는 OLTP, 또는 회수가 났을 때 사람이 24시간 retry를 받지 못하는 시스템. 이 두 칸을 헷갈리면 절감액이 다음 주 장애 보고서로 돌아온다.

Savings Plans는 어떻게 다른가: 시간당 약정이라는 새 차원

Savings Plans는 AWS가 2019년 11월 re:Invent에서 EC2·Fargate를 묶어 발표했고, Lambda 적용은 2020년 2월에 합류했다. Reserved Instance 모델보다 한 단계 유연한 약정을 도입한 것이 핵심이고, 약정의 단위가 인스턴스 타입이 아니라 시간당 달러($/hr)다.

작동 방식을 한 줄로 풀면 이렇다. 내가 "1년 동안 매시간 $10어치 EC2/Fargate/Lambda를 쓰겠다"고 약정한다. 그러면 그 시간당 $10까지의 사용분에는 SP 할인 단가를 적용한다. 시간당 $12를 쓴 시간은 $10어치를 SP 가격으로, 나머지 $2어치를 On-Demand 가격으로 청구한다. 시간당 $7만 쓴 시간이 있어도 $10을 그대로 청구한다(약속한 commitment). 그래서 SP는 "정말로 매시간 그만큼은 안 줄어들 것"이라고 확신하는 baseline에만 거는 게 안전하다.

종류는 네 가지다(2025년에 AWS가 Database Savings Plans를 추가했다). Compute Savings Plans는 EC2·Fargate·Lambda를 한 묶음으로 보고 인스턴스 패밀리·크기·OS·테넌시·리전을 자유롭게 바꿔도 할인이 따라간다. 최대 할인은 On-Demand 대비 up to 66%. EC2 Instance Savings Plans는 한 리전 안에서 한 패밀리(예: ap-northeast-2의 M6i 묶음)에만 적용되는 대신 더 깊게 up to 72%까지 할인 폭이 있다. 같은 패밀리 안에서는 size·OS·테넌시는 자유로이 바꿀 수 있지만, 리전이나 패밀리를 벗어나면 그 시간당 commitment를 AWS가 SP가 아니라 On-Demand 단가로 청구한다. 세 번째는 Machine Learning Savings Plans, 곧 SageMaker용으로 up to 64% 할인 폭이 있다.

적용 우선순위에도 한 가지 함정이 있다. 시간당 사용분에 SP를 적용할 때 AWS는 더 좁은 범위의 약정을 먼저 소진한다. EC2 Instance SP가 먼저 자기 패밀리·리전 안 사용분에 들어가고, 남은 사용분에 Compute SP가 적용된 뒤, 그래도 남으면 On-Demand 단가가 따라온다. 이 순서가 두 SP를 동시에 들고 있을 때 약정 오버랩을 막아 준다.

worked example 한 번 잡아 본다. 서울에서 m6i.large 5대를 24/7로 1년 운용한다고 가정한다. 시간당 5 × $0.124 ≈ $0.62, 한 달 약 $447, 1년 약 $5,360 어치 On-Demand가 bottom line이다. 여기에 EC2 Instance SP 1년 No Upfront(약 25~30% 할인을 흔히 본다)를 걸면 1년 약 $3,750~4,000 수준으로 줄어든다. 같은 조건에 Compute SP 1년 No Upfront(약 20~25% 할인)를 걸면 1년 약 $4,000~4,300. EC2 Instance SP가 더 깊지만, 1년 안에 패밀리를 m6i에서 c7g(Graviton)로 바꿀 가능성이 보이면 Compute SP가 손해가 적다. 1년 안에 패밀리·리전을 바꿀 가능성이 SP 종류의 결정 변수다.

Reserved Instance는 SP와 무엇이 다른가: capacity까지 함께 잠그는 모델

Reserved Instance는 SP보다 더 오래된 모델이고, 약정 단위가 시간당 달러가 아니라 인스턴스 타입의 시간이다. 1년 또는 3년 동안 m6i.large 1대 분량의 capacity를 쓰겠다고 약속한다. Reserved Instance 가격 페이지에서 보면 두 갈래로 나뉜다.

Standard RI는 약정 후 인스턴스 패밀리·OS·테넌시·리전을 바꿀 수 없는 대신 가장 깊은 할인 폭이 있다(up to 72%, 3년 All Upfront 기준). Convertible RI는 약정 후에도 패밀리·OS·테넌시를 바꿀 수 있는 대신 할인 폭은 얕은 편이다(공식 가격 페이지 기준 up to 66%, 3년 All Upfront 기준). 셋의 결제 옵션은 All Upfront / Partial Upfront / No Upfront이고, 선결제할수록 할인 폭이 커진다.

여기에 또 한 갈래가 더 있다. RI를 Regional 범위로 잡으면 한 리전 안 어느 가용영역에서도 할인이 따라가지만 capacity 보장은 없다. Zonal 범위로 잡으면 한 가용영역에 capacity를 잠가 두는 대신 그 가용영역을 벗어나면 할인이 안 따라간다. capacity가 부족해 launch가 실패하는 상황을 피하려면 zonal RI가 답이지만, 그만큼 운영 자유도는 좁다.

여기서 On-Demand Capacity Reservation이라는, 2018-10에 AWS가 출시한 별도 기능이 등장한다. ODCR은 약정 없이 한 가용영역에 capacity를 잠그는 도구다. 잠가 둔 capacity는 시간당 On-Demand 가격으로 청구하고, 약정이 없으니 언제든 cancel할 수 있다. ODCR 위에 SP나 Regional RI 할인은 적용 가능하다. 대신 Zonal RI는 자체적으로 capacity 보장 기능을 가지므로 ODCR과 별도 도구로 본다. capacity 보장과 할인을 분리하고 싶으면 ODCR + Compute SP 조합이 자연스럽다.

관리형이 감추는 비용: 약정한 capacity를 못 쓰는 상황

가격 모델 네 개 중 세 개가 시간당 단가를 깎는 대가로 약정을 받는다. 약정한 capacity를 약정 기간 동안 다 쓰면 깎인 단가만큼 정확히 절감 효과가 있다. 약속한 만큼을 못 쓰면 어떻게 될까. SP는 시간당 commitment에 미치지 못해도 그 commitment를 그대로 청구한다. RI는 인스턴스를 켜지 않아도 약정 시간만큼 청구하고, Standard RI라면 RI Marketplace에서 일부 되팔 수 있지만(Convertible RI는 판매 불가), 기본은 침전 비용이다.

내가 작년에 굴리던 한 팀에서는 c5.xlarge 10대를 1년 Standard RI로 잡아 두었는데, 6개월 만에 워크로드가 Lambda + Fargate로 옮겨 갔다. 남은 6개월의 RI는 사용량 0으로 그대로 비용을 부과받았고, Marketplace에서 절반쯤 회수했다. 결과적으로 같은 6개월을 On-Demand로 굴렸으면 더 쌌을 케이스다. 그날 이후 1년 안에 스택이 바뀔 가능성이 보이면 약정을 안 거는 쪽으로 룰을 잡았다.

Spot 쪽의 숨은 비용은 다른 형태다. 시간당 단가가 90% 깎이는 대목에 운영 손잡이가 늘어난다. 인스턴스 타입 다양화, 가용영역 분산, capacity rebalancing, lifecycle hook, EventBridge 이벤트 처리. 5대를 굴리는 소규모에서는 이 운영 손잡이를 짜는 사람 시간이 절감액보다 더 비싸다. 100대 규모에서는 그 손잡이가 절감액 안쪽으로 잘 들어간다. 규모가 결정 변수다.

언제 쓰지 말아야 하는가

라우팅 테이블: 패킷이 어디로 가는지부터 매 섹션에서 한 번씩 되묻고 있는 질문, 즉 "언제 이 도구를 쓰지 말아야 하는가"를 가격 모델 위에서 한 번 더 본다.

Spot을 쓰지 말아야 할 곳. 데이터베이스 primary, 사용자가 5초 latency를 즉시 인지하는 OLTP, 회수가 났을 때 사람이 24시간 retry를 받지 못하는 시스템, 그리고 인프라 손잡이를 짤 사람 시간이 절감액보다 비싼 작은 규모(인스턴스 5대 미만 정도). Spot 90% 자랑이 차고 넘치지만, 이 네 경우에서 90%를 노리면 다음 분기에 장애 보고서가 돌아온다.

SP/RI를 쓰지 말아야 할 곳. 1년 안에 인스턴스 패밀리·리전·아키텍처가 바뀔 가능성이 보이는 단계(ARM·Graviton 검토 중, 멀티클라우드 검토 중, 회사 reorg 가능). 거기에 더해 부하의 baseline이 아직 안 잡힌 첫 6개월의 스타트업 단계. baseline을 모르고 1년 commit을 걸면 사용량이 commitment보다 적은 시간이 쌓여 깎인 단가가 무의미하다.

On-Demand만 쓰지 말아야 할 곳. 24/7로 켜 두는 baseline이 6개월 이상 명확한 곳. 그런 곳에서 SP/RI를 안 끼면 매시간 25~70%를 그냥 버리는 셈이다. 새 시스템에 EC2를 띄울 때 처음 3개월은 On-Demand로 사용량을 측정하고, 4개월차에 baseline 시간당 commitment를 SP로 거는 룰이 운영팀에 부담이 가장 적다.

가격 모델 한 번 더: 결정 변수는 시간당 baseline과 바꿀 가능성

결정 변수는 두 줄이다. 첫째, 24/7로 안정적으로 굴어가는 시간당 baseline이 얼마인가. 그 baseline 위에 SP를 거는 게 자연스럽다. 둘째, 1년 안에 그 baseline의 패밀리·리전·아키텍처를 바꿀 가능성이 얼마나 되는가. 바꿀 가능성이 크면 Compute SP, 작으면 EC2 Instance SP 또는 Standard RI. 그 위에 fault-tolerant 영역만 Spot으로 올리고, On-Demand는 세 모델로 못 가두는 변동 영역과 새 워크로드의 첫 3개월 측정 기간 정도를 담는다.

이어서 Auto Scaling Group을 본다. 가격 모델 위에서 결정한 baseline+탄력 영역이 거기서 처음으로 수요에 따라 자동으로 늘고 주는 손잡이를 만난다. ASG의 mixed instances policy가 SP/RI/On-Demand/Spot을 하나의 그룹으로 묶는 단계에서, 여기서 잡은 두 결정 변수가 다시 등장한다.

참고 자료

• Amazon EC2 On-Demand Pricing: On-Demand 시간당 가격 페이지, 리전별 단가 확인
• Amazon EC2 Spot Instances: Spot 모델 개요와 최대 90% 할인 표기
• Spot Instance interruption notices (AWS docs): 2분 통보 메커니즘 공식 문서
• Spot Instance Advisor: 인스턴스 타입·리전별 frequency of interruption
• allocation strategies (AWS docs): Spot Fleet/EC2 Fleet 네 가지 전략
• Savings Plans 개요: Compute / EC2 Instance / SageMaker 묶음
• Compute and EC2 Instance Savings Plans: 두 SP 비교, 최대 할인 폭 공식 표기
• Reserved Instances 가격: Standard / Convertible 결제 옵션과 할인 폭
• On-Demand Capacity Reservation 출시: 2018-10 출시 What's New
• Amazon EC2 Spot Blocks deprecation: 2021-07-01 신규 가입 종료, 2022-12-31 지원 종료