Spot 인스턴스 실전: 최대 90% 할인의 조건과 중단 대응 설계
EC2 비용을 내리는 축은 셋입니다. 약정으로 내리는 RI·Savings Plans, 아키텍처로 내리는 Graviton, 그리고 이 글의 주제인 Spot입니다. 결론을 먼저 적으면, Spot은 중단을 수용할 수 있는 워크로드에 한해 온디맨드 대비 최대 90%(실무 체감 40〜70%) 할인을 약정 없이 주는 계약이고, 판단 기준은 가격이 아니라 “2분 통지 후 사라져도 되는가"입니다. 이 질문에 예라고 답할 수 있는 워크로드에서 Spot을 안 쓰는 것은 손해이고, 아니라고 답해야 하는 워크로드에 쓰는 것은 장애 예약입니다. 요금은 us-east-1 기준입니다.
한눈에 보는 비교 #
| 구분 | 온디맨드 | Spot |
|---|---|---|
| 할인 | 없음 (기준) | 최대 90%, 풀별 변동 |
| 약정 | 없음 | 없음 |
| 중단 | 없음 | 2분 통지 후 회수 가능 |
| 용량 보장 | 높음 | 없음 (풀 상황에 따라 미충족 가능) |
| SLA·안정성 요구 워크로드 | 적합 | 부적합 |
| 배치·CI·스테이트리스 확장분 | 가능 (비쌈) | 최적 |
| 조합 | RI·SP의 대상 | RI·SP와 별개, 초과분 담당 |
계약의 실체: 남는 용량을 싸게, 대신 돌려줄 수 있게 #
Spot은 AWS의 남는 EC2 용량을 시장 가격으로 쓰는 방식입니다. 가격은 인스턴스 타입 × AZ 단위의 풀마다 수급에 따라 완만하게 움직이고, 대체로 온디맨드의 10〜30% 수준에서 형성됩니다. 대가는 두 가지입니다. AWS가 용량을 되찾아야 할 때 2분 통지 후 인스턴스가 회수되고, 애초에 풀에 용량이 없으면 요청 자체가 채워지지 않을 수 있습니다.
중단은 예외 상황이 아니라 계약의 일부입니다. 통지는 인스턴스 메타데이터(IMDS)와 EventBridge로 옵니다. 그보다 앞서 리밸런스 권고(rebalance recommendation)라는 조기 신호가 먼저 오는 경우가 많아, 이 신호에 새 인스턴스를 미리 띄우고 작업을 옮기는 여유를 벌 수 있습니다. 즉 Spot 운영의 실력은 싼 풀을 고르는 것이 아니라 2분 안에 정리하고 나가는 절차를 자동화해 두는 것입니다.
어디에 쓰는가: 중단 내성이 기준입니다 #
잘 맞는 워크로드는 상태를 밖에 두고 재시도가 자연스러운 것들입니다. CI 빌드·테스트 러너, 배치·데이터 처리(체크포인트 전제), 컨테이너 오케스트레이터 위의 스테이트리스 서비스 확장분, 렌더링·시뮬레이션, 개발 환경입니다. K8s나 ECS 위에서는 중단이 “노드 하나 빠짐"으로 흡수되므로 특히 잘 맞습니다.
피해야 할 워크로드는 상태가 안에 있거나 중단 비용이 큰 것들입니다. 데이터베이스, 단일 인스턴스 서비스, 긴 작업인데 체크포인트가 없는 처리, 그리고 라이선스가 인스턴스에 묶인 상용 소프트웨어입니다. “프로덕션이라 안 된다"가 아니라 “중단 내성이 없어서 안 된다"가 정확한 기준입니다. 중단 내성을 갖춘 프로덕션 서비스의 확장분은 Spot의 정당한 자리입니다.
실무 표준 구성은 혼합입니다. 바닥 용량은 온디맨드 + 약정으로 잠그고, 트래픽 변동에 따라 늘어나는 부분을 Spot으로 채웁니다. Auto Scaling 그룹의 혼합 인스턴스 정책이 이 구성을 기본 지원하고, 온디맨드 비율을 백분율로 지정할 수 있습니다.
중단 빈도를 줄이는 설계: 다양화와 할당 전략 #
중단 빈도는 운에 맡기는 것이 아니라 설계로 낮춥니다.
- 인스턴스 다양화: 풀(타입 × AZ)마다 용량 사정이 다르므로, 쓸 수 있는 타입을 넓게 열어 둘수록 깊은 풀에서 실행될 확률이 올라갑니다. “m7i.large만"이 아니라 m·c·r 여러 세대와 크기를 후보로 넣는 것이 기본입니다. 타입 선택의 기준은 인스턴스 패밀리 비교를 따르되 폭을 넓힙니다.
- 할당 전략은 price-capacity-optimized: 현재 권장 기본값입니다. 가장 싼 풀이 아니라 용량이 깊으면서 싼 풀을 고르므로, lowest-price 전략 대비 중단이 눈에 띄게 줄어듭니다. 최저가만 좇는 전략은 얕은 풀에 몰려 중단으로 되갚는 구성입니다.
- 컨테이너면 Fargate Spot도 선택지: Fargate 태스크에도 Spot이 있어 온디맨드 대비 약 70% 할인을 받습니다. 다만 EC2 Spot처럼 타입 다양화로 중단 확률을 조절하는 수단은 없으므로, 짧은 배치 태스크나 중단 허용 서비스에 씁니다.
가격 면에서 하나 더 적으면, Spot 할인과 RI·SP는 겹치지 않습니다. 약정은 온디맨드 요금에 걸리는 할인이고 Spot은 별도 시장이므로, 약정 커버리지를 바닥 사용량에 맞추고 Spot 사용분은 약정 계산에서 제외하는 것이 커버리지 설계의 기본입니다.
판단 순서 #
- 중단 시나리오를 먼저 씁니다: 이 워크로드의 인스턴스가 2분 통지 후 사라지면 무슨 일이 나는지 적어 봅니다. 답이 “재시도되고 끝"이면 Spot 후보, “데이터 유실·장애"면 제외입니다.
- 상태를 밖으로 뺍니다: 작업 큐, 체크포인트, 외부 스토리지로 상태를 분리하면 Spot 가능 영역이 넓어집니다. Spot 도입이 아키텍처를 건강하게 만드는 순서이기도 합니다.
- 다양화 폭과 할당 전략을 설정합니다: 타입 후보를 넓히고 price-capacity-optimized를 지정합니다. 중단 통지·리밸런스 권고 핸들러(드레이닝 자동화)까지가 한 세트입니다.
- 바닥과 변동분을 나눕니다: 바닥은 온디맨드 + 약정, 변동분은 Spot이라는 혼합 정책을 Auto Scaling에 넣습니다.
- 중단률을 관측하고 조정합니다: 중단이 잦은 풀은 후보에서 빼고, Spot 충족률이 낮으면 온디맨드 폴백이 동작하는지 확인합니다. Spot은 설정하고 끝이 아니라 관측하며 운영하는 대상입니다.
정리 #
- Spot은 약정 없이 최대 90% 할인을 주는 대신 2분 통지 후 회수될 수 있는 계약입니다. 판단 기준은 가격이 아니라 중단 내성입니다.
- CI, 배치, 스테이트리스 확장분이 최적이고, DB와 체크포인트 없는 긴 작업은 제외입니다. 프로덕션 여부가 아니라 상태의 위치가 기준입니다.
- 중단 빈도는 설계로 낮춥니다. 타입 다양화 + price-capacity-optimized 할당 + 통지 핸들러 자동화가 3종 세트입니다.
- 표준 구성은 혼합입니다. 바닥은 온디맨드 + RI·SP로 잠그고 변동분을 Spot으로 채우며, 약정 커버리지 계산에서 Spot 사용분은 제외합니다.
- 컨테이너는 Fargate Spot(약 70% 할인)도 선택지입니다. 이로써 약정, Graviton, Spot의 비용 3축이 완성됩니다.