AWS 스팟 인스턴스 완벽 가이드 2026: EC2 Auto Scaling으로 최대 90% 비용 절감하기

AWS 스팟 인스턴스란 무엇인가?

AWS 스팟 인스턴스(Spot Instance)는 Amazon EC2의 미사용 예비 컴퓨팅 용량을 온디맨드 가격 대비 최대 90% 할인된 가격으로 제공하는 구매 옵션입니다. 쉽게 말하면, AWS 데이터센터 어딘가에 비어 있는 서버를 저렴하게 빌려 쓰는 거라고 생각하면 됩니다. AWS 데이터센터의 유휴 서버 용량을 실시간으로 경매하는 방식으로, 특정 가용 영역과 인스턴스 유형의 스팟 가격은 수요와 공급에 따라 실시간으로 변동됩니다.

단 하나의 조건이 있습니다. AWS가 해당 용량을 회수해야 할 때 2분 전 중단 알림(Interruption Notice)을 보내고 인스턴스를 종료한다는 것입니다. 솔직히 처음 접하면 이 조건이 부담스럽게 느껴질 수 있습니다. 하지만 제대로 처리하기만 하면 기업 입장에서는 컴퓨팅 비용을 대폭 절감하면서도 안정적인 서비스 운영이 충분히 가능합니다.

2026년 기준 Skyscanner, Airbnb, Samsung 등 글로벌 기업들이 스팟 인스턴스를 핵심 인프라 전략으로 채택하고 있습니다. AWS·Azure·GCP 약정 할인 완벽 비교 가이드와 함께 스팟 인스턴스는 클라우드 비용 최적화의 3대 축 중 하나로 자리매김하고 있습니다.

EC2 구매 옵션 비교: 어떤 상황에 무엇을 써야 하나?

AWS EC2는 크게 네 가지 구매 옵션을 제공합니다. 각 옵션의 특성과 적합한 워크로드를 이해하는 것이 비용 최적화의 출발점입니다.

FinOps 실무에서 권장하는 최적 전략은 이 세 가지를 조합하는 3계층(Tiered) 접근법입니다. 베이스라인은 Savings Plans·예약 인스턴스로, 변동 부하는 온디맨드로, 배치·학습 등 내결함성 워크로드는 스팟으로 처리하면 전체 컴퓨팅 비용을 온디맨드 대비 40~60% 절감할 수 있습니다. 처음에는 복잡해 보이지만, 막상 구현해보면 생각보다 어렵지 않습니다.

2026년 핵심 변경 사항: Spot Fleet은 공식 레거시

이 부분은 특히 중요합니다. AWS는 2024년 말 Spot Fleet을 공식 레거시(Legacy) 서비스로 분류했습니다. 기존에 Spot Fleet을 사용 중이라면 2026년 중으로 마이그레이션을 완료해야 하며, 신규 구축은 반드시 EC2 Auto Scaling 그룹을 사용해야 합니다.

EC2 Auto Scaling이 Spot Fleet보다 나은 핵심 이유는 다음과 같습니다:

• Capacity Rebalancing: 2분 중단 알림이 발생하기 전에 선제적으로 대체 인스턴스를 프로비저닝하여 서비스 연속성 확보
• Mixed Instances Policy: 스팟과 온디맨드를 하나의 Auto Scaling 그룹 안에서 비율 기반으로 통합 관리
• Attribute-Based Instance Selection (ABS): 특정 인스턴스 타입 목록 지정 없이 vCPU·메모리 등 속성 기반 선택으로 더 넓은 스팟 풀 활용
• ELB 헬스 체크, CloudWatch 알람 기반 스케일링과 완전 통합되어 운영 복잡도 감소

스팟 인스턴스에 적합한 워크로드 선택

중단을 허용할 수 있는 내결함성(Fault-Tolerant) 워크로드라면 스팟 인스턴스가 적합합니다. 2026년 현재 가장 널리 활용되는 사례들입니다:

• CI/CD 파이프라인: GitHub Actions self-hosted runner, Jenkins 에이전트 — 중단 시 빌드만 재시작하면 되므로 업무에 지장 없음
• 머신러닝 학습: 체크포인트를 주기적으로 S3에 저장하면 중단 후 재개 가능
• 배치 처리: AWS Batch, EMR Spark 작업 — 작업 단위 재시도 로직 내장
• 빅데이터 분석: Athena, EMR, Glue 워크로드
• 웹 서비스 Auto Scaling: 트래픽 급증 시 수평 확장용 스팟 노드 (온디맨드 베이스라인 유지 필수)
• 개발·테스트 환경: 업무 시간 외 자동 종료와 함께 사용하면 최대 80% 이상 절감
• 미디어 트랜스코딩: FFmpeg, AWS MediaConvert 병렬 인코딩 파이프라인

반면 스팟이 적합하지 않은 경우도 분명히 있습니다. 실시간 결제 처리, 단일 인스턴스 기반 데이터베이스, 세션 상태를 로컬 디스크에 저장하는 모노리식 애플리케이션 등은 중단 시 서비스 장애로 직결됩니다. 이런 워크로드는 솔직히 온디맨드나 예약 인스턴스를 쓰는 게 맞습니다.

EC2 Auto Scaling으로 스팟 + 온디맨드 혼합 운영하기

혼합 인스턴스 정책(Mixed Instances Policy) 설정

EC2 Auto Scaling 그룹에서 혼합 인스턴스 정책을 사용하면 온디맨드 베이스라인을 안정적으로 유지하면서 추가 용량을 저렴한 스팟으로 채울 수 있습니다. 다음은 AWS CLI JSON 형식의 Auto Scaling 그룹 생성 예시입니다 (서울 리전 기준으로 구성했습니다):

{
  "AutoScalingGroupName": "my-mixed-asg",
  "MinSize": 2,
  "MaxSize": 20,
  "DesiredCapacity": 6,
  "MixedInstancesPolicy": {
    "LaunchTemplate": {
      "LaunchTemplateSpecification": {
        "LaunchTemplateName": "my-launch-template",
        "Version": "$Latest"
      },
      "Overrides": [
        { "InstanceType": "m7g.large" },
        { "InstanceType": "m6g.large" },
        { "InstanceType": "m7i.large" },
        { "InstanceType": "m6i.large" },
        { "InstanceType": "c7g.xlarge" },
        { "InstanceType": "c6g.xlarge" }
      ]
    },
    "InstancesDistribution": {
      "OnDemandBaseCapacity": 2,
      "OnDemandPercentageAboveBaseCapacity": 20,
      "SpotAllocationStrategy": "price-capacity-optimized"
    }
  }
}

위 설정의 핵심 포인트:

• OnDemandBaseCapacity: 2 — 항상 최소 2개의 온디맨드 인스턴스를 유지하여 안정성 확보
• OnDemandPercentageAboveBaseCapacity: 20 — 베이스라인 초과 용량의 20%는 온디맨드, 나머지 80%는 스팟으로 채움
• 6개 인스턴스 타입 지정: 다양한 스팟 풀에서 용량을 확보하여 중단 위험 분산

Attribute-Based Instance Selection으로 더 넓은 스팟 풀 활용

특정 인스턴스 타입 목록 대신 속성 기반 선택(ABS)을 사용하면 자동으로 수십 개의 호환 인스턴스 타입에서 스팟 용량을 확보합니다. 스팟 풀 다양화를 자동화하여 중단 빈도를 낮추는 데 가장 효과적인 방법입니다 — 개인적으로도 이 방식을 가장 추천합니다:

"Overrides": [
  {
    "InstanceRequirements": {
      "VCpuCount": { "Min": 4, "Max": 8 },
      "MemoryMiB": { "Min": 8192, "Max": 32768 },
      "CpuManufacturers": ["amazon-web-services", "intel", "amd"],
      "InstanceGenerations": ["current"]
    }
  }
]

price-capacity-optimized: 2026년 권장 할당 전략

스팟 인스턴스에는 여러 할당 전략이 있지만, 2026년 AWS 공식 권고 전략은 price-capacity-optimized입니다. 이 전략은 가격과 용량 가용성을 동시에 고려하여 중단 가능성이 가장 낮으면서도 저렴한 스팟 풀을 자동으로 선택합니다.

실제 사례를 보면 전략 선택이 얼마나 중요한지 실감할 수 있습니다. Skyscanner는 lowest-price에서 capacity-optimized로 전환한 후 스팟 중단 횟수가 월 200~300회에서 10~15회로 95% 이상 감소했습니다. Mobileye도 중단 비율이 75% 감소했고요. 전략 하나 바꾸는 것만으로 이런 차이가 나다니 꽤 놀랍습니다.

스팟 인스턴스 중단 처리 실전 가이드

스팟 인스턴스를 안정적으로 운영하려면 중단을 사전에 감지하고 자동으로 처리하는 메커니즘이 필수입니다. 2026년 기준 세 가지 주요 방법을 소개합니다.

방법 1: EC2 메타데이터 API 폴링 (IMDSv2)

인스턴스 내부에서 메타데이터 엔드포인트를 주기적으로 폴링하여 중단 알림을 감지하는 방법입니다. IMDSv2를 사용하는 최신 방식으로 작성합니다:

#!/bin/bash
# 5초마다 중단 알림 확인 (IMDSv2 방식)
while true; do
  TOKEN=$(curl -s -X PUT "http://169.254.169.254/latest/api/token" \
    -H "X-aws-ec2-metadata-token-ttl-seconds: 21600")

  INTERRUPTION=$(curl -s -H "X-aws-ec2-metadata-token: $TOKEN" \
    "http://169.254.169.254/latest/meta-data/spot/interruption-action" \
    --write-out "%{http_code}" -o /dev/null)

  if [ "$INTERRUPTION" = "200" ]; then
    echo "중단 알림 수신! 상태 저장 후 종료 처리 시작..."
    # 1. 작업 상태를 S3에 체크포인트 저장
    aws s3 cp /var/app/checkpoint.json s3://my-bucket/checkpoints/

    # 2. Auto Scaling 그룹에서 이 인스턴스 분리
    INSTANCE_ID=$(curl -s -H "X-aws-ec2-metadata-token: $TOKEN" \
      "http://169.254.169.254/latest/meta-data/instance-id")
    aws autoscaling detach-instances \
      --instance-ids "$INSTANCE_ID" \
      --auto-scaling-group-name my-asg \
      --should-decrement-desired-capacity
    break
  fi
  sleep 5
done

방법 2: Amazon EventBridge로 중앙 집중식 처리 (권장)

메타데이터 폴링보다 훨씬 권장되는 방식입니다. AWS가 EC2 Spot Instance Interruption Warning 이벤트를 자동으로 EventBridge에 발행하므로, Lambda 함수로 중앙 집중식 처리가 가능합니다. 아래는 Terraform으로 인프라를 구성하는 예시입니다:

# EventBridge 규칙 (Terraform)
resource "aws_cloudwatch_event_rule" "spot_interruption" {
  name        = "spot-interruption-handler"
  description = "EC2 스팟 인스턴스 중단 알림 처리"
  event_pattern = jsonencode({
    source      = ["aws.ec2"],
    detail-type = ["EC2 Spot Instance Interruption Warning"]
  })
}

resource "aws_cloudwatch_event_target" "lambda" {
  rule      = aws_cloudwatch_event_rule.spot_interruption.name
  target_id = "SpotInterruptionLambda"
  arn       = aws_lambda_function.spot_handler.arn
}

# Lambda 핸들러 (Python 3.12)
import boto3

def handler(event, context):
    instance_id = event["detail"]["instance-id"]
    asg = boto3.client("autoscaling")

    # ShouldDecrementDesiredCapacity=False → 대체 인스턴스 자동 시작
    asg.terminate_instance_in_auto_scaling_group(
        InstanceId=instance_id,
        ShouldDecrementDesiredCapacity=False
    )
    print(f"스팟 중단 처리 완료: {instance_id}")

이 구조는 모든 계정·리전의 스팟 중단 이벤트를 하나의 Lambda로 집중 처리할 수 있어 운영 복잡도를 크게 낮춥니다. Slack 알림이나 JIRA 티켓 생성 같은 추가 로직도 쉽게 연결할 수 있어서, 팀 전체 가시성을 높이는 데도 효과적입니다.

방법 3: EKS에서 AWS Node Termination Handler 사용

Kubernetes(EKS)에서 스팟 인스턴스를 사용한다면 반드시 AWS Node Termination Handler(NTH)를 설치해야 합니다. 쿠버네티스 비용 최적화 완벽 가이드 2026에서도 강조하듯, NTH는 스팟 중단 알림을 감지하면 해당 노드를 즉시 cordon 처리하고 Pod를 graceful하게 다른 노드로 이동시킵니다:

# Helm으로 AWS Node Termination Handler 설치
helm repo add eks https://aws.github.io/eks-charts
helm repo update

helm install aws-node-termination-handler eks/aws-node-termination-handler \
  --namespace kube-system \
  --set nodeSelector."kubernetes\.io/os"=linux \
  --set enableSpotInterruptionDraining=true \
  --set enableRebalanceMonitoring=true \
  --set enableRebalanceDraining=true \
  --set emitKubernetesEvents=true

Graviton 스팟 인스턴스: 추가 20~25% 절감으로 최대 절약 실현

AWS Graviton(ARM 기반) 인스턴스는 동급 Intel/AMD 인스턴스 대비 온디맨드 기준 약 20~25% 저렴합니다. 여기에 스팟 할인(최대 90%)을 더하면 x86 온디맨드 대비 최대 92%까지 절감이 가능합니다. 개인적으로 이 조합이 2026년 기준 가장 강력한 비용 절감 전략이라고 생각합니다. Graviton과 스팟을 함께 사용하는 것이 2026년 현재 최강의 조합입니다.

2026년 기준 추천 Graviton 스팟 인스턴스 조합:

• m7g.large ~ 2xlarge: 범용 웹 서버, API 서버, 마이크로서비스
• c7g.large ~ 4xlarge: CPU 집약적 컴파일, 미디어 처리, 암호화 연산
• r7g.large ~ 4xlarge: 메모리 집약적 캐싱(Redis), 인메모리 데이터베이스
• g5g.xlarge ~ 4xlarge: ML 추론 워크로드 (T4G GPU + Graviton2 조합)

Graviton 호환성 체크: Java 11+, Python 3.7+, Node.js 14+, Go 1.14+, .NET 6+, Rust는 코드 변경 없이 Graviton에서 동작합니다. Docker 이미지는 linux/arm64 플랫폼 빌드가 필요하지만, BuildKit으로 멀티 아키텍처 빌드를 구성하면 x86과 ARM 모두에 동일하게 배포할 수 있습니다:

# Docker 멀티 아키텍처 이미지 빌드 (amd64 + arm64)
docker buildx build \
  --platform linux/amd64,linux/arm64 \
  -t 123456789.dkr.ecr.ap-northeast-2.amazonaws.com/myapp:latest \
  --push .

실제 비용 절감 시나리오 계산

백 마디 말보다 숫자가 직관적입니다. 실제 워크로드를 기준으로 스팟 인스턴스 도입 전후 비용을 비교합니다. 아래 요금은 서울 리전(ap-northeast-2) 2026년 5월 기준 참고값입니다.

시나리오 1: CI/CD 빌드 팜

8개 m6i.xlarge 인스턴스를 24시간 온디맨드로 운영하던 팀이 혼합 스팟 전략으로 전환하는 경우:

시나리오 2: ML 학습 클러스터

p3.2xlarge 4개로 주당 40시간 학습을 진행하는 경우:

• 온디맨드: $3.06/h × 4개 × 40h = $489.6/주
• 스팟(평균 ~$0.65/h): $0.65 × 4 × 40h = $104/주
• 주간 절감액: $385.6 (79% 절감)
• 1시간 단위 체크포인트 저장 시 중단으로 인한 재시작 오버헤드는 최대 1시간에 불과

시나리오 3: Graviton 스팟 조합 (최대 절감)

m6i.xlarge(x86 온디맨드 $0.200/h) 대비 m7g.large(Graviton 스팟 ~$0.018/h) 전환 시:

• m6i.xlarge 온디맨드 대비 91% 절감
• 동일 워크로드 기준 Graviton은 vCPU·메모리 효율이 높아 실질 성능 비용도 개선

스팟 인스턴스 도입 실무 체크리스트

마지막으로, 성공적인 스팟 인스턴스 도입을 위한 2026년 실무 체크리스트입니다. 이 중 하나라도 빠지면 운영 중 예상치 못한 문제가 발생할 수 있으니 꼼꼼히 확인하세요:

1. ✅ 워크로드 내결함성 확인: 인스턴스 중단 시 작업이 자동 재시작되는가?
2. ✅ 상태 외부화: 로컬 디스크 대신 S3, DynamoDB, EFS 등 외부 저장소에 상태 저장
3. ✅ 체크포인트 구현: ML 학습·장시간 배치 작업의 진행 상태를 정기적으로 저장
4. ✅ 5개 이상의 인스턴스 타입 지정: 스팟 풀 다양화로 중단 위험 분산
5. ✅ price-capacity-optimized 전략 사용: AWS 2026년 공식 권고 전략
6. ✅ Capacity Rebalancing 활성화: 중단 전 선제적으로 대체 인스턴스 기동
7. ✅ 중단 처리 자동화: EventBridge + Lambda 또는 AWS Node Termination Handler 설치
8. ✅ 온디맨드 베이스라인 유지: 전체 용량의 20~30%는 온디맨드로 안정성 확보
9. ✅ Spot Fleet 마이그레이션: 기존 Spot Fleet 사용 중이면 EC2 Auto Scaling 그룹으로 전환
10. ✅ AWS Spot Instance Advisor 활용: 인스턴스 타입별 중단 빈도와 절감율을 사전 확인 후 선택