AWS Spot Instance 적용하기

Aug 12. 2025

가장 보편적으로 사용되는 On-Demand 인스턴스는 즉각적인 사용성을 제공하지만, 예측 가능한 워크로드나 대규모 운영 환경에서는 불필요하게 높은 비용을 지불하게 만드는 주범이 되기도 합니다.

본 글에서는 On-Demand 인스턴스만으로는 해결하기 어려운 비용 최적화의 한계를 해결해줄 수 있도록 실제 AWS Management Console에서 Spot 인스턴스를 직접 실행하는 방법부터 인스턴스 중단 감지 및 알림 설정, Auto Scaling Group을 통한 온디맨드-스팟 혼합 전략, 그리고 EKS/ECS와 같은 컨테이너 환경에서의 Spot 활용 방안까지 실질적인 구현 가이드라인을 제공합니다.

Spot Instance의 핵심 특성인 '중단 가능성'을 이해하고, 어떤 워크로드에 가장 적합하며 어떻게 안정적으로 활용할 수 있는지 실질적인 방안을 알아보겠습니다.

EC2 Spot 인스턴스 직접 실행하기

Step 1. AWS Management Console 접속

AWS 콘솔(https://console.aws.amazon.com)에 로그인한 후, 상단 검색창에서 EC2를 검색해 진입합니다.

Step 2. 인스턴스 시작

메뉴에서 “인스턴스” → “인스턴스 시작(Launch Instance)” 버튼을 클릭합니다.

Step 3. AMI 및 인스턴스 유형 선택

Amazon Linux 2, Ubuntu 등 원하는 AMI를 선택합니다. (예: t3.medium, m6g.large 등)

Step 4. 구매 옵션에서 Spot 인스턴스 선택

고급 세부 정보 > “구매 옵션(Purchase Option)” 항목에서 “Spot 인스턴스 요청(Request Spot Instances)” 체크박스를 활성화합니다.

Step 5. 중단 동작 선택

“인스턴스 종료 행동(Interruption behavior)”에서 Stop 또는 Terminate 중 선택합니다. Stop은 상태를 보존하고 중단하고 Terminate는 인스턴스를 즉시 삭제합니다.

Step 6. 추가 설정

스토리지, 네트워크, 보안 그룹 등의 일반 인스턴스 설정을 동일하게 구성합니다. 필요 시 user-data를 통해 자동 실행 스크립트 삽입 가능합니다.

Step 7. 인스턴스 시작

마지막 단계에서 “인스턴스 시작(Launch Instance)” 클릭하여 실행합니다. 콘솔에 Spot 인스턴스로 표시되며, Spot Request ID를 통해 상태 추적이 가능합니다.

인스턴스 중단 감지 및 알림 설정 방법

Spot 인스턴스는 AWS가 예고 없이 회수할 수 있으므로, 중단(Interruption) 시점을 감지하고 적절한 조치를 취할 수 있도록 설정하는 것이 중요합니다. AWS는 Spot 인스턴스 중단 2분 전에 알림을 제공하며, 이를 기반으로 자동화된 알림 또는 작업을 구성할 수 있습니다.

Spot 인스턴스 중단 감지 방법

AWS는 중단 예정이 있을 경우, 인스턴스의 메타데이터 URI에서 다음 값을 통해 예고를 제공합니다.

<http://169.254.169.254/latest/meta-data/spot/instance-action>
## 반환 JSON 예시
{
"action": "terminate",
"time": "2025-06-11T10:00:00Z"
}

이 URI에 접근했을 때 HTTP 200 OK가 반환되면, 해당 인스턴스는 2분 이내 중단 예정입니다. cron이나 systemd timer로 30초마다 실행하게 구성하면 실시간 감지 및 대응이 가능합니다.

Amazon EventBridge + SNS 알림 구성

콘솔 설정으로 자동화된 알림을 받고 싶다면 다음 절차로 구성합니다

Step 1. EventBridge 룰 생성

서비스 이름: EC2 Spot Instance

이벤트 유형: EC2 Spot Instance Interruption Warning

패턴 설정 예시 (JSON):

{
"source": ["aws.ec2"],
"detail-type": ["EC2 Spot Instance Interruption Warning"]
}

Step 2. SNS 주제 생성

새로운 SNS 주제(Topic)를 만들고 이메일 구독 추가

EventBridge 룰의 타겟으로 SNS를 연결

Step 3. 알림 수신 테스트

테스트 이벤트를 수동으로 발생시켜 이메일 수신 여부 확인

Auto Scaling Group에서 Spot 혼합 전략

온디맨드 + 스팟 혼합 구성

온디맨드 + 스팟 혼합 구성(Mixed Instance Policy)은 AWS Auto Scaling Group(ASG)에서 비용 절감과 가용성 확보를 동시에 추구할 수 있는 전략입니다. 이 구성은 일정 비율의 온디맨드 인스턴스와 스팟 인스턴스를 혼합하여, 스팟의 경제성과 온디맨드의 안정성을 균형 있게 활용하는 방식입니다.

Mixed Instance Policy

Mixed Instance Policy는 ASG의 인스턴스 풀에 서로 다른 인스턴스 유형과 구매 옵션(온디맨드, 스팟)을 혼합할 수 있는 정책입니다.

주요 특징

여러 인스턴스 타입 지정 가능 (예: m6g.large, c6g.large 등)

스팟/온디맨드 비율 조정 가능 (예: 70% 스팟, 30% 온디맨드)

스팟 인스턴스 부족 시 온디맨드로 대체 가능

EC2 인스턴스 재고 상황에 따라 자동 할당

콘솔에서 설정하는 방법

Step 1. Auto Scaling Group 생성 시작

EC2 콘솔 → Auto Scaling Groups → “Create Auto Scaling group”

Step 2. Launch Template 구성

Launch Template에서 AMI, 키페어, 보안 그룹, 사용자 데이터 등 정의

Step 3. “Purchase options and instance types” 단계

Launch template overrides 섹션에서 다양한 인스턴스 타입 추가 (ex. t3.large, m5.large, c6g.large 등)

Allocation strategy 설정. lowest-price (가장 저렴한 스팟부터 우선), capacity-optimized (중단 위험이 낮은 인스턴스 우선)

Step 4. On-Demand base / percentage 설정

On-Demand base capacity: 최소 온디맨드 개수 지정 (예: 2)

On-Demand percentage above base: 그 외 용량 중 온디맨드 비율 (예: 30%)

아래는 총 10개 인스턴스를 원할 경우 예시입니다.

최소 2개는 온디맨드

나머지 8개 중 30%인 약 2.4개 ≈ 2~3개는 온디맨드

총 4~5개는 온디맨드, 나머지는 스팟

용량 기준 vs 비용 기준 스케일링

AWS Auto Scaling에서는 인스턴스를 스케일링할 때 두 가지 주요 전략을 선택할 수 있습니다: 용량 기준(capacity-based) 스케일링과 비용 기준(cost-optimized) 스케일링입니다. 두 방식은 어떤 인스턴스를 먼저 선택할지, 어떤 풀을 우선순위에 둘지에 따라 비용과 안정성 측면에서 서로 다른 장단점을 가집니다.

용량 기준(Capacity-Optimized) 스케일링

스팟 인스턴스의 중단 가능성이 가장 낮은 풀을 우선 선택합니다. 용량 기준의 의미는 AWS 입장에서 충분한 인스턴스 풀을 가지고 있다는 것입니다. 즉 가용 가능한 풀 중 가장 여유가 있는 풀(= 용량이 가장 많은 풀)을 선택하여 인스턴스를 배치합니다.

안정성 확보가 중요할 때 선택할 수 있습니다. 비용이 약간 더 들 수 있으나, 중단 리스크를 줄이는 데 효과적입니다.

비용 기준(Lowest-Price) 스케일링

현재 가장 저렴한 스팟 인스턴스 풀에서 먼저 할당합니다. 비용 절감을 극대화할 수 있습니다. 중단되어도 괜찮은 비동기 작업이나 일시적인 테스트 환경 등에서 활용할 수 있습니다. 중단 리스크가 더 크지만, 비용을 최소화할 수 있습니다.

실패 없이 유지 가능한 최소 용량 설정 전략

Spot 인스턴스를 Auto Scaling Group(ASG)에서 활용할 때, 중단 위험을 고려해 On-Demand 인스턴스를 포함한 최소 용량을 안정적으로 유지하는 전략이 중요합니다. 아래는 실무에서 적용할 수 있는 구체적 접근 방법입니다.

On-Demand Base Capacity 설정

ASG 설정에서 “On-Demand Base Capacity” 항목은 전체 최소 용량 중 무조건 온디맨드로 유지해야 하는 인스턴스 수를 의미합니다. 최소 용량이 4인데 Base Capacity를 2로 설정하면, 항상 2개는 온디맨드 인스턴스로 유지되고, 나머지 2개만 Spot으로 충당됩니다. 이렇게 하면 Spot 인스턴스가 중단되더라도 서비스 중단 없이 최소한의 용량을 유지할 수 있습니다.

Capacity-Optimized 우선 적용

중단 가능성이 낮은 Spot 풀을 우선 선택하는 Capacity-Optimized 전략을 통해 예기치 않은 인스턴스 종료를 줄일 수 있습니다. 특히 애플리케이션이 상태 기반(Stateful)이 아니거나, 워커 기반일 경우 유리합니다.

Min/Max/Desired 설정 간 균형 유지

MinCapacity는 서비스의 최저 안정성을 의미하며, 이는 반드시 On-Demand로 보장하는 수준과 연결되어야 합니다. 서버가 반드시 3개 이상 떠 있어야 한다면, BaseCapacity = 3 또는 MinCapacity = 3으로 설정합니다. DesiredCapacity는 평균 트래픽에 따라 유동적으로 Spot을 활용해 탄력적 비용 절감을 가능케 합니다.

Lifecycle Hook + 중단 알림 처리

Spot 중단 시 감지 이벤트(EC2 Spot Instance interruption notice)를 CloudWatch로 감지하고 SNS로 알림을 받습니다. 중단되기 전 2분의 예고 시간 안에 세션을 종료시키고 작업 재배치 등을 처리해 graceful shutdown을 할 수 있습니다.

ASG에 Multiple Instance Types 구성

동일한 용량 그룹 내에서 다양한 인스턴스 타입(c6g, m6g, r6g 등)을 혼합하면, 특정 타입의 Spot 풀이 부족하더라도 대체 타입에서 자동으로 선택이 가능합니다. 중단률이 분산되므로 안정성이 증가할 수 있습니다.

EKS, ECS에서 Spot 활용하기

K8s 노드 그룹에서 Spot 노드 구성

Amazon EKS에서는 Spot 인스턴스를 워커 노드로 구성해 클러스터 운영 비용을 크게 절감할 수 있습니다. 특히, 비핵심 워크로드나 중단에 민감하지 않은 작업을 Spot 노드에서 실행하면 높은 비용 효율을 달성할 수 있습니다.

Spot 노드를 구성하는 기본 흐름은 다음과 같습니다.

Step 1. EKS 클러스터 생성 또는 기존 클러스터 선택

AWS Management Console에서 EKS 클러스터를 생성하거나 기존 클러스터를 선택합니다.

Step 2. EKS용 Node Group 생성

EC2 Managed Node Group 또는 Karpenter, EC2 Auto Scaling Group 기반으로 선택 가능합니다. 간단하게 구성하려면 EC2 Managed Node Group으로 하고 고도화된 제어가 필요하다면 Karpenter를 권장합니다.

Step 3. Spot 인스턴스 기반 노드 그룹 구성

Node Group 생성 시 Capacity type을 Spot으로 선택합니다. 인스턴스 유형은 여러 타입을 혼합 지정합니다. (예: m6g.large, c6a.large 등) Capacity-Optimized 전략을 사용하는 것이 안정성에 유리합니다.

Step 4. Node Taint 적용 (선택)

Spot 노드에 taint를 설정하여, 중요하지 않은 워크로드만 할당되도록 설정할 수 있습니다.

kubectl taint nodes <노드명> spotInstance=true:NoSchedule

Step 5. Node Selector 또는 Affinity 설정

워크로드의 deployment 또는 pod spec에 다음과 같은 형태로 Spot 노드에서만 실행되도록 설정합니다.

nodeSelector:
lifecycle: spot

Step 6. 중단 알림 처리

AWS는 Spot 인스턴스가 중단되기 2분 전에 알림을 전송합니다. DaemonSet 또는 KEDA 등으로 감지하여 graceful shutdown 처리가 가능합니다.

Spot Interruption Handler 및 graceful termination 설정

Spot 인스턴스는 언제든지 AWS에 의해 2분 예고 후 중단될 수 있기 때문에, 중단에 대비한 자동 처리 메커니즘을 구성하는 것이 중요합니다. 이를 통해 작업 손실을 줄이고, 클러스터의 서비스 연속성을 유지할 수 있습니다.

Interruption Handler 구성 방식

A. DaemonSet으로 구성 (EKS 기준)

클러스터 내 모든 노드에 감시 에이전트를 배포합니다.

대표 오픈소스

AWS Labs의 kube-spot-termination-notice-handler

동작 방식

메타데이터 API를 주기적으로 체크

중단 감지 시 해당 노드를 cordon → drain 처리

Pod를 다른 노드로 이관하여 Graceful Termination 유도

apiVersion: apps/v1
kind: DaemonSet
...
containers:
- name: spot-interrupt-handler
image: amazon/aws-node-termination-handler
env:
- name: ENABLE_SPOT_INTERRUPTION_DRAINING
value: "true"

B. AWS Auto Scaling Lifecycle Hook (ECS 또는 ASG)

Auto Scaling Group 기반으로 Spot 인스턴스를 사용하는 경우, 중단 시 알림을 SNS/SQS로 전달하여 Lambda 또는 EventBridge로 후속 작업을 처리합니다.

Graceful Termination 설계 포인트

Shutdown Hook 또는 PreStop 설정으로 서비스 내 종료 준비 시간을 확보합니다.

lifecycle:
preStop:
exec:
command: ["/bin/sh", "-c", "sleep 10"]

Connection draining을 활성화하여 LB 연결을 즉시 끊지 않도록 유지합니다. 그리고 Stateless한 워크로드를 우선 배치하여 중단의 영향을 최소화합니다.

Fargate Spot의 활용 가능성과 한계

AWS Fargate Spot은 컨테이너 워크로드를 서버리스 방식으로 운영하면서도, 최대 70%까지 비용 절감이 가능한 옵션입니다. 일반 Fargate와 동일한 실행 환경에서 동작하지만, Spot 인스턴스 기반으로 운영되어 언제든지 중단될 수 있다는 점에서 차이가 있습니다.

활용 가능성

비용 최적화 Fargate Spot은 온디맨드 대비 훨씬 저렴하게 과금되므로, 대규모 컨테이너 작업에 있어 비용 절감 효과가 큽니다. 특히, 비정기적이거나 비동기적인 작업, ML 학습/배치 작업, 대량의 일시적 트래픽 대응에 적합합니다.

서버리스 + Spot 조합 EC2 Spot은 인스턴스를 직접 구성해야 하지만, Fargate Spot은 인프라 관리 없이 컨테이너 단위로 Spot 혜택을 받을 수 있어 운영 편의성이 매우 높습니다.

ECS Task 단위 구성 가능 ECS에서 Task Definition에 capacityProviderStrategy를 설정하면, FARGATE_SPOT을 우선 사용하고, 필요 시 FARGATE로 백업하는 전략을 구성할 수 있습니다.

[
{ "capacityProvider": "FARGATE_SPOT", "weight": 1 },
{ "capacityProvider": "FARGATE", "weight": 0, "base": 1 }
]

제한

예고 없이 중단 가능 EC2 Spot과 달리 Fargate Spot은 2분 중단 알림이 제공되지 않으며, 예고 없이 종료됩니다. 따라서 세션 기반, 실시간 트래픽 처리 서비스에는 부적합합니다.

가용성 제약 Spot 용량이 부족하면 Task가 아예 실행되지 않거나, 실행 도중 중단될 수 있어 항상 실행이 보장되어야 하는 워크로드에는 사용을 피해야 합니다.

EKS에서는 아직 미지원 (2025년 6월 기준) Fargate Spot은 현재 ECS에서만 지원되며, EKS Fargate에서는 사용할 수 없습니다. 따라서 Kubernetes 기반 클러스터에서는 EC2 기반 Spot 노드 그룹을 이용해야 합니다.

실수 없이 Spot을 잘 쓰는 팁

다양한 AZ/인스턴스 타입을 함께 구성해 안정성 확보

Spot 인스턴스는 AWS의 유휴 자원을 활용하는 구조이기 때문에, 수급이 불안정하거나 특정 인스턴스 타입이 갑자기 회수되는 경우가 발생할 수 있습니다. 이를 방지하기 위해서는 다음과 같은 전략이 필요합니다.

멀티 AZ 구성

동일 리전에 여러 가용 영역(AZ)을 포함시키면, 한 AZ에서 Spot 용량이 부족할 경우 다른 AZ에서 인스턴스를 확보할 수 있는 기회가 생깁니다.

Auto Scaling Group 또는 EC2 Fleet에서 Availability Zones를 2개 이상 지정하여 장애 상황에 대한 회복성을 높일 수 있습니다.

다양한 인스턴스 타입 조합

하나의 인스턴스 타입만 선택하면 해당 타입의 Spot 수요가 몰릴 경우 쉽게 중단되므로, m6g.large, c6g.large, t4g.medium 등 다양한 타입을 혼합 구성하면 수급 리스크가 분산됩니다.

EC2 Auto Scaling Group의 Mixed Instance Policy 또는 EC2 Fleet에서 InstanceTypeOverrides를 설정해 다양한 유형을 지정할 수 있습니다.

Capacity-Optimized 전략 사용

AWS는 중단 가능성이 낮은 풀이 무엇인지 지속적으로 추적하고 있으며, Capacity-Optimized 전략은 이러한 풀이 우선 선택되도록 인스턴스를 배치합니다.

이는 단순 비용 기반보다 안정성을 우선시하는 경우 매우 효과적입니다.

중단 감지 시 graceful shutdown 자동화

EC2 인스턴스 내에서 감지 스크립트를 주기적으로 실행하거나, AWS Lambda와 CloudWatch Event를 함께 사용하여 처리할 수 있습니다.

while true; do
if curl -s <http://169.254.169.254/latest/meta-data/spot/instance-action>; then
echo "중단 감지됨 - 종료 준비 시작"
# 애플리케이션 종료/세션 저장/메시지 큐 작업 마무리 등
/opt/app/cleanup.sh
break
fi
sleep 5
done