서론: AWS 약정 모델의 중요성 — “할인”의 덫을 피하는 생존 전략
클라우드의 유연성은 매력적이지만, 온디맨드(On-Demand) 가격으로 운영하면 예산은 순식간에 증발합니다. 예약 인스턴스(Reserved Instances, RI) 와 절약형 플랜(Savings Plans, SP) 은 최대 75% 할인이라는 강력한 무기를 제공하지만, 잘못된 약정은 “할인”이 아니라 “비용 손해” 로 변질됩니다.
약정 모델 = “미래 비용에 대한 보험”
| 온디맨드 | RI / SP |
|---|---|
| 즉시 사용, 즉시 과금 | 장기 약정 → 대폭 할인 |
| 예측 불가능 | 예측 가능 + 안정적 예산 |
| 월 ₩10M | 월 ₩3M ~ ₩4M |
“할인율이 높다고 무조건 좋은 게 아니다.” 1년 약정 후 3개월 만에 서비스 종료 → 남은 9개월은 “죽은 돈” SP를 RI처럼 잘못 이해 → 적용 안 되는 리소스에 과다 지출
비용 손해의 3대 함정 (실제 청구서 사례)
| 함정 | 사례 | 손실 규모 |
|---|---|---|
| 과도한 RI 구매 | 3년 All-Upfront RI 50대 → 실제 사용 15대 | ₩180M 손실 |
| SP 적용 범위 오해 | Compute SP → Lambda 비용 미적용 | ₩42M 누락 |
| 리전/인스턴스 타입 불일치 | us-east-1 RI → ap-northeast-2 사용 | 0% 할인 적용 |
본 글의 목표: “할인 극대화 + 손해 제로” 전략
- RI vs SP 근본 차이
- RI: 인스턴스 타입·리전·OS 고정 → 최대 75%
- SP: 컴퓨팅 사용량 기반 → 유연성 ↑, 최대 72%
- 실제 절감 시뮬레이션
- 월 100 vCPU 사용 기준, 1년 vs 3년, EC2 vs ECS vs Lambda
- 5가지 치명적 구매 실수 + 방지 팁
- “All-Upfront = 무조건 이득” 오해
- “Convertible RI = 자유로운 변경” 착각
- “SP는 무조건 낫다” 편견
- 자동화된 약정 관리 로드맵
- Cost Explorer + AWS Compute Optimizer
- RI/SP Coverage Report 자동화 (ChatGPT + Lambda)
핵심 메시지
약정 모델은 “돈을 아끼는 도구”가 아니라, “잘못 쓰면 돈을 묶는 족쇄”입니다. 할인율 1%를 쫓다 100만 원을 날리지 마라.
본 글은 단순 비교를 넘어, “내 서비스에 딱 맞는 약정 전략” 을 실제 청구서 데이터 기반으로 설계하는 실전 가이드를 제공합니다.
오늘의 약정 결정이, 3년 후의 재무 보고서를 결정합니다. 할인의 문턱에서, 현명한 선택을 시작하라.
Reserved Instance (RI)와 Savings Plans (SP) 비교 분석
RI와 SP는 모두 1년 또는 3년 약정 모델을 기반으로 하며, 약정 기간이 길수록, 그리고 선결제 비율이 높을수록 할인율이 증가합니다. 하지만 그 적용 범위와 유연성에서 큰 차이를 보입니다.
1. 근본적인 차이점 및 유연성 비교
| 구분 | Reserved Instance (RI) | Savings Plans (SP) |
| 적용 범위 | 특정 인스턴스 속성에 고정 (리전, 인스턴스 유형, 테넌시) | 지출 금액 ($/시간)에 고정 (컴퓨팅 지출 약정) |
| 유연성 (EC2) | 제한적 (패밀리 내 인스턴스 크기 변경 가능) | 높음 (인스턴스 패밀리, 리전, OS에 관계없이 적용) |
| 적용 가능 서비스 | EC2, RDS, ElastiCache, Redshift, DynamoDB | EC2, Fargate, Lambda (Compute Savings Plans) |
| 관리 복잡성 | 높음 (개별 리소스 매칭 필요) | 낮음 (자동으로 최적의 워크로드에 적용) |
| 주요 장점 | 특정 서비스에 대한 최대 할인율 확보 | 최고의 유연성 및 운영 편의성 제공 |
핵심 차이: RI는 ‘특정 인스턴스’의 사용 약정인 반면, SP는 ‘시간당 컴퓨팅 비용 지출’ 자체에 대한 약정입니다. 이 차이가 유연성과 관리 편의성을 결정합니다.
2. 실제 절감 효과와 효율성
- RI의 효율: RI는 가장 높은 할인율(최대 72% 이상)을 제공할 수 있지만, 해당 RI가 지정된 속성(예: 리전, 인스턴스 패밀리)에 정확하게 매칭되어야만 할인이 적용됩니다. 사용률이 100%에 근접할 때 가장 효율적입니다.
- SP의 효율: SP의 할인율은 RI보다 약간 낮을 수 있지만 (최대 66% 이상), EC2, Fargate, Lambda 등 서비스와 리전을 넘나들며 자동으로 적용됩니다. 인스턴스 타입을 변경하거나 워크로드를 서버리스로 전환해도 할인이 유지되므로, 총체적인 클라우드 지출 관점에서 가장 효과적입니다.
3. 잘못 구매 시 손해보는 케이스 비교 분석
두 모델 모두 약정 기간이 지나기 전에 서비스를 중단하거나 변경할 경우 손해가 발생할 수 있습니다.
가. Reserved Instance (RI) 구매 오류 사례
- 인스턴스 속성 변경:
m5.largeRI를 구매했는데, 서비스 요구사항이 변경되어c5.large인스턴스 패밀리로 마이그레이션한 경우입니다. 두 패밀리는 호환되지 않으므로, 기존m5.largeRI는 더 이상 사용되지 않아 미사용 상태로 비용이 발생하고, 새로 시작한c5.large인스턴스는 온디맨드 비용이 청구되어 이중으로 비용을 지불하게 됩니다.- 예방법: EC2 인스턴스의 경우 ‘Standard’ 대신 ‘Convertible RI’를 선택하여 인스턴스 패밀리 변경 시에도 RI를 교환할 수 있도록 유연성을 확보해야 합니다.
- 용량 예약 RI의 미사용: 용량 예약(Capacity Reservation) 옵션을 포함한 RI를 구매했으나, 해당 용량을 제대로 활용하지 못한 경우입니다. 용량 예약 RI는 예약된 용량에 대해 비용을 부과하므로, 실제 인스턴스를 시작하지 않아도 예약된 용량에 대한 요금을 지불해야 합니다.
나. Savings Plans (SP) 구매 오류 사례
- 과도한 약정: 현재 시간당 컴퓨팅 지출이 10달러인데, 장기적인 성장만을 고려하여 시간당 20달러를 약정하는 SP를 구매한 경우입니다. 서비스 성장 속도가 예상보다 느리거나 오히려 감소하면, 약정한 20달러 중 10달러는 할인 없이 온디맨드로 사용되지만, 나머지 10달러는 실제로 사용되지 않아도 약정된 비용을 매시간 지불해야 합니다.
- 예방법: SP 약정 금액은 최소 지출 규모(Base Load)에만 맞추고, 변동성이 큰 부분은 온디맨드나 Auto Scaling에 맡겨야 합니다. 약정 금액은 최근 3~6개월 동안의 가장 낮은 시간당 지출을 기준으로 설정하는 것이 안전합니다.
- 유연성 과신: SP를 구매했지만, EC2 인스턴스를 갑자기 삭제하고 온프레미스로 완전히 돌아가는 경우입니다. SP는 유연성이 높지만, 약정된 지출 자체를 취소할 수 없습니다. 남은 약정 기간 동안 AWS 컴퓨팅 자원을 사용하지 않아도 약정된 시간당 금액은 계속 청구됩니다.
결론: 비용 절감을 위한 현실적인 접근법
RI와 SP 모두 강력한 비용 절감 도구이지만, 클라우드 아키텍처의 미래 변화를 정확히 예측하는 것은 불가능합니다. 따라서 다음과 같은 현실적인 접근법을 권장합니다.
- SP를 기본 전략으로 채택: 워크로드 변경 가능성, 서비스 종류의 다양성 등을 고려할 때, Savings Plans (특히 Compute SP)가 가장 높은 유연성과 낮은 관리 복잡성을 제공하므로, 최소 지출 규모에 대한 약정은 SP로 시작하는 것이 가장 안전합니다.
- RI는 특정 서비스에 한정: RDS, Redshift와 같이 인스턴스 유형 변경 없이 장기간 안정적으로 운영될 것이 확실한 서비스에 대해서만 가장 높은 할인율을 제공하는 RI를 선택해야 합니다.
- 점진적 약정 증가: 처음부터 3년 전체 선결제를 하기보다, 1년 약정 또는 부분 선결제로 시작하여 서비스의 안정화와 성장에 따라 약정 규모를 점진적으로 늘려가는 전략이 리스크를 최소화하고 비용 효율을 높이는 현명한 방법입니다.
Disclaimer: 본 블로그의 정보는 개인의 단순 참고 및 기록용으로 작성된 것이며, 개인적인 조사와 생각을 담은 내용이기에 오류가 있거나 편향된 내용이 있을 수 있습니다.