AWS EC2 비용 절감을 위한 스팟 인스턴스 및 오토스케일링 활용법

클라우드 인프라를 운영할 때 가장 큰 고민 중 하나는 단연 비용 절감입니다.

특히 24시간 켜두어야 하는 웹 애플리케이션이나 마이크로서비스 환경에서 온디맨드(On-Demand) 인스턴스만 고집하다 보면 예상치 못한 ‘요금 폭탄’을 맞기 십상인데요.

AWS가 제공하는 스팟 인스턴스(Spot Instances)와 Auto Scaling(오토스케일링)을 제대로 조합하면, 안정성을 유지하면서도 서버 비용을 기존 대비 60%에서 최대 90%까지 아끼는 고효율 아키텍처를 설계할 수 있습니다.

실무에 바로 적용해 볼 수 있는 스팟 인스턴스의 작동 원리부터 오토스케일링 연동, 그리고 서비스 중단 없는 아키텍처 설계 노하우까지 한눈에 쉽게 풀어드립니다.

1. 온디맨드의 1/10 가격? 스팟 인스턴스의 동작 원리

스팟 인스턴스는 AWS 데이터센터에서 남아도는 남는 서버 자원(여유 용량)을 경매 형태로 저렴하게 제공하는 제도입니다.

  • 압도적인 할인율: 정가로 이용하는 온디맨드 인스턴스에 비해 최대 90%까지 할인된 파격적인 가격에 사용할 수 있습니다.
  • 갑작스러운 반환(Interruption) 리스크: AWS에 갑자기 정가 사용 고객(온디맨드 사용자)이 몰려서 여유 자원이 부족해지면, AWS는 2분 전에 사전 알림(Warning Notice)을 보낸 뒤 해당 스팟 인스턴스를 강제로 회수해 갑니다.

“2분 뒤에 서버가 꺼질 수 있다면 실무에서 어떻게 쓰라는 거지?”라는 의문이 생길 수밖에 없는데요.

핵심은 서버가 갑자기 꺼져도 전체 서비스에 영향이 없는 구조(Stateless)를 만들고, 오토스케일링 그룹이 알아서 인스턴스를 대체하도록 아키텍처를 잡는 것입니다.

2. 비용과 안정성을 모두 잡는 ‘혼합 인스턴스(Mixed Instances)’ 오토스케일링

스팟 인스턴스만으로 100% 서버를 구성하는 것은 매우 위험합니다. 특정 지역의 스팟 용량이 전멸하면 전체 서비스가 내려갈 위험이 커지기 때문입니다.

따라서 가장 추천하는 방식은 오토스케일링 그룹(Auto Scaling Group) 안에서 온디맨드와 스팟 인스턴스를 섞어서 사용하는 ‘혼합 인스턴스 정책’을 적용하는 것입니다.

① 베이스(Base) 용량은 온디맨드로 지키기

  • 전체 트래픽이 아무리 줄어들어도 유지되어야 하는 최소한의 서버 수량(예: 2~3대)은 온디맨드(또는 절약 플랜/예약 인스턴스)로 고정합니다.
  • 이렇게 하면 스팟 자원이 순간적으로 모두 회수되더라도 서비스가 완전히 먹통이 되는 최악의 상황은 방지할 수 있습니다.

② 확장(Scale-out) 트래픽은 스팟 인스턴스로 대응

  • 낮 시간대나 이벤트로 인해 트래픽이 몰려 추가되는 인스턴스 영역(70~80% 비율)은 모두 스팟 인스턴스로 충원하도록 설정합니다.
  • 이 방식을 통해 평소 기본 서버 비용은 안정되게 유지하고, 트래픽 폭증으로 늘어나는 가변 비용만 60~80% 이상 대폭 깎아낼 수 있습니다.

3. 실무 아키텍처 설계 시 반드시 챙겨야 할 핵심 옵션

오토스케일링 설정에서 몇 가지 핵심 옵션만 켜두어도 스팟 회수 타격을 거의 느끼지 못하게 만들 수 있습니다.

① 인스턴스 유형 다변화 (Instance Diversity)

단 하나의 인스턴스 타입(예: t3.medium)만 고집하면 해당 타입의 스팟 자원이 부족할 때 새로운 서버를 띄우지 못합니다.

c5.large, c5a.large, c6i.large 등 사양이 비슷하거나 약간 다른 최소 3~5개 이상의 인스턴스 패밀리와 크기를 섞어서 등록해 두어야 합니다.

② 최적 할당 전략: price-capacity-optimized

AWS 오토스케일링 그룹의 할당 전략 중 price-capacity-optimized를 선택합니다.

이 옵션은 AWS가 현재 용량이 넉넉해서 중단될 확률이 가장 낮으면서도 가격이 저렴한 스팟 풀(Pool)을 알아서 계산해 우선 할당해 주는 아주 똑똑한 정책입니다.

③ 용량 재조정(Capacity Rebalancing) 기능 활성화

AWS에서 2분 뒤 스팟을 회수하겠다는 ‘재조정 권고’ 신호를 보내면, 기존 서버가 꺼지기 전에 오토스케일링 그룹이 미리 새로운 대체 스팟 인스턴스를 먼저 생성합니다.

새 서버가 준비되고 트래픽이 안전하게 넘어가면 기존 서버를 끄기 때문에 유저가 느끼는 서비스 끊김 현상이 완벽하게 사라집니다.

4. 스팟 인스턴스 도입에 적합한 업무와 피해야 할 업무

모든 시스템에 스팟 인스턴스를 넣을 수 있는 것은 아닙니다. 시스템의 특징에 따라 명확하게 구분해 주는 지혜가 필요합니다.

  • 스팟 인스턴스 추천 업무 (Stateless):
  • 웹/앱 서버 (Nginx, Node.js, Spring Boot 등 앞단 API 서버)
  • 컨테이너 기반 환경 (Amazon EKS, ECS Cluster)
  • 빅데이터 분석 및 배치 작업 (EMR, 파이프라인 프로세싱)
  • CI/CD 테스트 및 빌드 서버
  • 스팟 인스턴스 비추천 업무 (Stateful):
  • 단일 데이터베이스(RDBMS) 서버 (상태가 저장되어 데이터 손실 위험)
  • 세션 메모리가 서버 내부 메모리에 남아있는 형태의 레거시 웹 애플리케이션
  • 장시간 멈춤 없이 연속 실행되어야 하는 중요 배치 작업

단순히 “서버 사양을 줄여서 비용을 아끼자”는 방식은 성능 저하라는 부작용을 낳습니다.

하지만 스팟 인스턴스와 오토스케일링을 조합한 아키텍처를 구성해 두면, 성능과 응답 속도는 100% 최고 스펙으로 유지하면서도 매달 나오는 클라우드 청구서 금액을 놀라울 정도로 가볍게 다이어트할 수 있습니다.

운영 중인 서비스의 특징을 잘 살펴보신 뒤, 위험도가 낮은 개발 환경이나 프론트엔드 API 단부터 차근차근 스팟 인스턴스 혼합 정책을 적용해 보시길 적극 추천해 드립니다.

Leave a Comment