스팟 인스턴스, 싼 값에는 어떤 대가가 숨어있나?
결론부터 적으면, 스팟은 온디맨드 대비 최대 90% 할인이 가능하지만 그 할인은 "중단될 수 있다는 조건" 위에 서 있다. 실제 중단 빈도는 평균 5% 미만이라 생각보다 안정적이지만, 그 5%를 감당할 설계가 없으면 할인율은 의미가 없다. 판단 기준은 가격표가 아니라 "이 워크로드가 중단을 견디는가"다.
핵심 정리
- 스팟은 온디맨드 대비 최대 90% 할인이지만 AWS 공식 문서는 평균 중단 비율을 5% 미만으로 설명한다.
- 중단은 2분 경고 후 발생하며, 그보다 앞서 오는 Rebalance recommendation을 선제 신호로 쓸 수 있다.
- Spot은 Savings Plans 적용 대상이 아니라서, AWS는 기본 용량은 온디맨드·커밋형, 추가 탄력성은 스팟으로 섞는 하이브리드를 권장한다.
- 실제 사례에서 ITV는 EKS 스팟으로 최대 60% 절감(연 15만 달러), SmartNews는 최대 50% 절감을 보고했지만 둘 다 stateless·fault-tolerant 워크로드 전제였다.
- 진짜 비용은 인스턴스 단가가 아니라 "중단 감지→드레인→재스케줄링"까지 포함한 복구 비용이다.
왜 온디맨드 대신 스팟을 검토하게 됐나?
배치 처리, CI 파이프라인, 비동기 워커처럼 언제 끝나도 되고 언제 다시 시작해도 되는 작업들이 온디맨드 요금을 그대로 내고 있다는 게 눈에 걸렸기 때문이다. 우리 팀도 야간 배치 잡을 온디맨드 c5.xlarge로 돌리다가, 어차피 실패해도 재시도 로직이 있는 구조라는 걸 재확인하고 스팟으로 옮겼다. AWS는 이런 워크로드를 stateless·fault-tolerant로 정의하고, 이 전제가 성립할 때만 최대 90% 할인을 강조한다. 반대로 이 전제가 없는 상태에서 가격만 보고 옮기면, 중단 시 재처리 비용이 할인폭을 다 까먹는 구조가 된다. 그래서 검토의 출발점은 "얼마나 싸지나"가 아니라 "이 작업이 끊겨도 되는가"였다.
스팟 가격은 어떻게 정해지고 왜 계속 바뀌나?
스팟 가격은 입찰이 아니라 AWS가 장기적인 수요·공급 추세에 따라 정하는 단순화된 방식이고, 지역·인스턴스 타입별 최저가가 5분마다 갱신되어 공개된다. 예전 방식(진짜 경매형 입찰)과 헷갈리는 경우가 많은데, 지금은 사용자가 입찰가를 정해서 싸움을 붙이는 구조가 아니라 AWS가 산정한 가격을 그대로 받는 구조다. 그래서 같은 인스턴스 타입이라도 리전과 가용영역(AZ)에 따라 가격 차이가 나고, 이 차이가 시간에 따라 계속 움직인다. 실무에서는 이 가격 변동성 자체보다, 특정 인스턴스 패밀리·AZ에 워크로드가 몰려 있을 때 회수 리스크가 커진다는 점이 더 중요했다. AZ에 용량이 없으면 자동으로 다른 곳으로 재시도되긴 하지만, 애초에 여러 인스턴스 타입·AZ로 분산해두는 편이 안정적이었다.
중단은 실제로 어떤 순서로 일어나나?
중단은 AWS가 용량을 회수해야 할 때 2분 경고 후 종료되는 방식으로 진행되고, 이 신호는 이벤트로 수집해 자동화 대응이 가능하다. AWS 스팟 중단 처리 문서에 나오는 Instance-action: terminate 같은 이벤트를 잡아서, 드레인(진행 중인 요청 마무리) 후 재스케줄링하는 흐름을 미리 짜두는 게 핵심이다. 이 흐름을 EventBridge나 오토스케일링 그룹의 라이프사이클 훅과 연결해두면, 중단이 "장애"가 아니라 "정상 이벤트"로 처리된다. 우리도 처음엔 중단 알림을 사후 로그로만 확인했는데, 이후 사전 훅으로 트래픽을 빼고 넘기는 구조로 바꾸자 서비스 단위 에러율 체감이 확실히 줄었다. 다만 이건 "체감"이지 벤치마크로 수치화한 값은 아니라서, 여기서 임의의 퍼센트를 붙이진 않겠다.
Rebalance recommendation은 중단 경고와 뭐가 다른가?
Rebalance recommendation은 공식 중단 통보보다 먼저 오는 "위험 상승" 신호이고, 아직 확정된 중단이 아니라 선제 교체용 힌트다. 실무에서는 이 신호를 받으면 새 인스턴스를 미리 띄워 트래픽을 옮기고, 기존 인스턴스는 여유 있게 정리하는 식으로 활용했다. 2분 경고만 믿고 대응하면 드레인 시간이 빠듯할 수 있는데, Rebalance recommendation을 같이 구독해두면 대응 여유가 생긴다. 다만 이 신호가 항상 오는 것도, 항상 정확한 것도 아니라서 "안전망 하나 더"로 보는 게 맞지 "확실한 사전 경보"로 과신하진 않는다.
"스팟은 아무 때나 훅 끊긴다"는 말, 맞는 오해인가?
절반만 맞는 말이다. 실제로 끊길 수 있다는 건 사실이지만, AWS 공식 문서 기준 평균 중단 비율은 5% 미만이라 "수시로 끊긴다"는 인상과는 거리가 있다AWS 공식 문서. 오해가 생기는 지점은 이 숫자를 워크로드 특성과 분리해서 받아들이기 때문이다. 특정 인스턴스 패밀리 하나에, 특정 AZ 하나에 몰아넣으면 그 조합의 회수 리스크는 평균치보다 훨씬 커질 수 있다. 반대로 여러 인스턴스 타입과 AZ에 분산하고, 중단 감지·드레인 자동화까지 갖추면 체감 안정성은 크게 달라진다. 즉 "스팟 자체가 불안정하다"기보다 "분산·자동화 없이 쓰면 불안정해진다"가 더 정확한 문장이다.
실제로 어디에 쓰고 어디는 피했나?
적합한 쪽은 컨테이너·EKS 기반의 수평 확장형 워크로드, 배치, CI, 비동기 큐 처리, stateless API 서버였다. ITV는 EKS에서 스팟을 활용해 온디맨드 대비 최대 60% 비용 절감과 연간 EC2 비용 15만 달러 절감을 보고했고, 중단 동작을 더 잘 이해한 뒤로 오히려 프로덕션 신뢰도가 높아졌다고 설명한다. SmartNews도 fault-tolerant·stateless 워크로드를 전제로 최대 50% 비용 절감 방향을 제시한 사례가 있다. 반대로 피한 쪽은 지연에 민감한 상태 저장 워크로드, DB 자체, 복구 비용이 큰 장시간 배치, SLA가 빡빡한 핵심 트래픽 경로였다. 이런 영역은 스팟만 단독으로 두지 않고 온디맨드나 Savings Plans 같은 커밋형 용량을 기본선으로 깔고, 스팟은 추가 탄력성 확보용으로만 섞었다. 스팟이 Savings Plans 적용 대상이 아니라는 점도 이 구분에 영향을 줬는데, 이미 커밋형 할인을 받는 기본 용량과 스팟의 할인 로직이 겹치지 않기 때문에 두 가지를 명확히 나눠서 설계하는 편이 계산도 쉬웠다.
판단 기준을 어떻게 정리했나?
스팟 인스턴스를 검토할 때마다 다시 확인하는 체크리스트는 결국 이 다섯 가지로 좁혀졌다.
- 이 워크로드가 중단돼도 재시도·재스케줄링으로 복구 가능한가
- 인스턴스 패밀리·AZ를 여러 개로 분산했는가, 한 조합에 몰아넣지 않았는가
- 중단 감지→드레인→재스케줄링을 자동화했는가, 사후 로그 확인에만 의존하지 않는가
- 핵심 경로(SLA가 빡빡한 트래픽)는 온디맨드·커밋형을 기본선으로 두고 스팟은 탄력분으로만 섞었는가
- 가격표의 할인율이 아니라 중단 복구까지 포함한 총비용으로 계산했는가
2026년 기준으로도 이 다섯 가지 기준 자체는 크게 달라지지 않았다. 바뀌는 건 인스턴스 타입별 최저가와 각 팀의 자동화 성숙도뿐이고, 결국 스팟을 쓸지 말지는 가격이 아니라 우리 워크로드가 "정상 이벤트로서의 중단"을 감당할 구조인지로 갈린다.