Amazon EC2(이하 EC2)가 “Interruptible Capacity Reservations”(중단 가능 용량 예약)을 새롭게 배포했습니다.
이 기능을 잘 활용하면, 기존에 예약해 둔 용량이 한가할 때 조직 내부의 다른 워크로드가 이를 임시로 사용하고, 원소유자가 필요할 때 즉시 회수(reclaim)할 수 있어, 자원 낭비를 줄이고 효율을 높일 수 있습니다. 아래는 Interruptible Capacity Reservations를 실제로 설정하고 운영하기 위한 단계별 가이드입니다.
기존 예약의 한계 vs 공유/활용의 장점
기존의 On‑Demand Capacity Reservations(ODCR)은 특정 가용영역(AZ)에 필요한 인스턴스 수를 예약해 두어, 갑작스러운 수요 증가나 AZ 부하에도 안정적으로 인스턴스를 확보할 수 있게 해줍니다.
하지만 문제는, 예약된 용량이 사용되지 않아 유휴 상태로 남는 경우가 많다는 점입니다. 이 경우, 비용이 낭비되고 조직 전체의 자원 활용률이 낮아질 수 있습니다.
Interruptible Capacity Reservations는 이런 유휴 상태의 용량을 "임시 공유 가능한 용량"으로 전환할 수 있게 해 줍니다.
예약 소유자는 여전히 용량을 보유한 채로, 유휴 용량을 다른 팀이나 워크로드에 제공하고, 필요 시 언제든지 즉시 reclaim → 원래대로 돌려받을 수 있습니다.
사용자는 스팟 인스턴스와 유사하게, 유연하고 일시적인 워크로드(배치 작업, 데이터 분석, ML 학습 등)에 저비용으로 활용 가능합니다.
이로써 조직 전체의 Reserved Capacity 활용률을 높이고, 자원 낭비를 줄이며, 비용 효율을 개선할 수 있습니다.
Interruptible Capacity Reservations 설정 절차
다음은 Interruptible Capacity Reservations를 실제로 설정하고 사용하는 절차입니다.
1. 기존 ODCR 확보
먼저, 유휴 상태일 수 있는 ODCR이 있어야 합니다. 기존에 On-Demand Capacity Reservation으로 용량을 확보해 둔 경우 해당 예약이 출발점이 됩니다.
2. ODCR을 Interruptible로 전환
AWS 관리 콘솔 또는 API를 통해 기존 ODCR을 Interruptible로 전환합니다. 이 설정을 하면 다른 워크로드가 해당 용량을 소비할 수 있게 됩니다.
3. 워크로드에 적용 — Launch Template / Auto Scaling
공유된 interruptible capacity를 사용하려면, 인스턴스를 시작할 때 launch template 또는 Auto Scaling 그룹(ASG)에 “interruptible capacity reservation ID”를 지정해야 합니다. 또한 market type을 interruptible-capacity-reservation으로 지정해야 합니다.
Auto Scaling을 사용하는 경우, 다음과 같은 제한사항에 유의해야 합니다:
- Mixed Instances Group은 interruptible 예약과 함께 사용할 수 없습니다.
- Auto Scaling 그룹 설정 시 capacity-reservations-only 옵션만 지원되며, capacity-reservations-first 옵션은 사용할 수 없습니다.
즉, 워크로드 설계 시 반드시 “중단 가능”하고 “유연한” 작업이어야 하며 — 체크포인트, graceful shutdown, 재시작 허용 등이 가능한 패턴이어야 합니다.
4. 중단 알림 처리
공유된 interruptible capacity가 reclaim 될 경우, EC2는 인스턴스에 대해 약 2분 전(interruption notice) 를 보냅니다.
따라서, 애플리케이션 또는 워크로드에선 이 알림을 감지하여 체크포인트 저장, graceful shutdown, 작업 재시도 등의 로직을 미리 구현해 두는 것이 좋습니다.
운영 시 고려사항 & 주의점
Interruptible Capacity Reservations을 운영할 때 다음과 같은 점을 반드시 고려해야 합니다.
- 모든 워크로드에 적합한 것은 아님: 중단 가능성을 허용할 수 없는 상태(예: 실시간 서비스, 지속 연결 서비스 등)에는 부적절합니다. 반드시 “중단 시 복구 가능한 워크로드”여야 합니다.
- Mixed Instances Group 비지원: 다양한 인스턴스 타입 혼합이나 유연한 인스턴스 타입 변경 정책이 필요하면 사용에 한계가 있을 수 있습니다.
- 용량 reclaim 시 2분 알림 외에는 자동 대응되지 않음: 자동종료 이후 자동 재기동은 기본적으로 지원되지 않기 때문에, 추가 자동화 작업 (예: EventBridge + Lambda + ASG 재기동) 등이 필요합니다.
- 비용: 예약 소유자는 예약된 모든 용량(사용 유휴 포함)에 대해 비용을 지불합니다. 소비자는 실제 사용한 인스턴스 시간에 대해서만 요금이 청구됩니다.
- 리전 및 AZ 지원 여부 확인: interruptible 예약 기능은 모든 리전에서 지원되는 것은 아니며, 리전별 지원 여부를 사전에 확인해야 합니다.

실제 활용 예시
아래와 같은 방식으로 Interruptible Capacity Reservations를 활용하는 것을 추천드립니다.
- Reserved Pool 계정: 조직 내 공용 계정 또는 팀이 ODCR로 일정량의 용량을 예약해 두고, 평소에는 idle 상태로 둡니다.
- 워크로드 계정/팀: 배치 작업, 데이터 분석, ML 훈련 등 중단 허용 가능한 워크로드가 생길 때, Reserved Pool의 interruptible capacity를 사용하도록 요청합니다.
요약
Interruptible Capacity Reservations는, 예약된 용량이 유휴 상태로 남아 있을 때 발생하는 자원 낭비를 줄이고, 조직 전체의 자원 효율성을 크게 향상시킬 수 있는 기능이라고 생각합니다.
비용 효율 + 자원 활용 효율 + 유연성이 중요한 스타트업이나 대규모 조직이라면, Interruptible Capacity Reservations를 도입을 고려해보시는 걸 추천드립니다.
'AWS' 카테고리의 다른 글
| [AWS] CloudWatch Agent 설치 방법 - In-Console Agent Management 활용법 (0) | 2025.12.01 |
|---|---|
| [AWS] S3 Recycle Bin 구성 가이드 (0) | 2025.11.30 |
| [AWS] Service Quotas 자동 할당량 관리 설정 방법 (0) | 2025.11.30 |
| [AWS] S3에서 ABAC(속성 기반 권한 제어) 설정 가이드 (0) | 2025.11.29 |
| [AWS] Amazon CloudWatch 로그 그룹 삭제 방지(Deletion Protection) 기능 추가 (0) | 2025.11.29 |