RI와 SP, 실무자가 말하는 도입 체크리스트
RI와 SP는 어떻게 구조적으로 비용을 줄이는가
RI(Reserved Instance)와 SP(Savings Plans)를 도입하면 온디맨드 대비 최대 70% 가까이 요금을 줄일 수 있다는 이야기를 들어본 적 있을 겁니다. 어떤 구조로 ‘최대 70% 비용 절감’이 될까요?
이번 글에서는 이 구조적 할인 원리를 약정 기간, 결제 방식, 적용 범위라는 3가지 관점에서 정리해보겠습니다.
할인률의 구성: 약정 기간, 인스턴스 유형, 선결제 여부
RI와 SP의 할인률은 기본적으로 세 가지 요소에 따라 결정됩니다.
1) 약정 기간
기본적으로 1년 약정보다 3년 약정이 더 큰 할인을 제공합니다.
AWS 입장에서 3년 동안 사용을 보장받을 수 있어, 더 큰 할인폭이 가능해집니다.
2) 결제 방식
No Upfront (무선결제): 할인률 가장 낮음
Partial Upfront (일부 선결제): 중간 수준
All Upfront (전액 선결제): 할인률 가장 높음
3) 인스턴스 유형
인스턴스 종류에 따라 기본 단가가 다르므로, 절감률도 상대적으로 차이가 납니다.
CPU, 메모리, 스토리지 비중이 높은 인스턴스일수록 절대 할인금액이 당연히 큽니다.
동일한 인스턴스를 3년 All Upfront RI로 사용하면, 1/3 가격 이하로 운영할 수 있습니다. Compute SP는 동일 할인률을 유지하되 인스턴스 변경이 자유롭다는 점이 장점입니다.
이 계산은 AWS Pricing Calculator를 통해 누구나 시뮬레이션해볼 수 있으며, 서비스별 약정 할인 시나리오도 시각적으로 비교 가능합니다.
온디맨드 대비 최대 70% 절감되는 경우
AWS가 온디맨드 가격을 기본값으로 설정하는 이유는 유연성 때문입니다. 하지만 그 유연성에는 예측 불가능한 인프라 운영 부담이 포함되어 있습니다. RI와 SP는 고객이 사용량과 기간을 고정시켜 주기 때문에, AWS 입장에서는 인프라 활용률을 극대화할 수 있고, 이로 인해 사용자에게 30~72% 수준의 절감 효과를 제공할 수 있습니다.
이 절감폭은 다음과 같은 조건 조합일 때 가장 높습니다
3년 약정 + 전액 선결제
EC2 전용 RI 또는 EC2 Instance Savings Plans
항상 고정적인 워크로드가 존재할 때 사용
적용 가능한 리소스와 적용 불가능한 리소스
할인 적용은 지원 대상 리소스와 조건 일치 여부에 따라 달라집니다.
적용 가능한 리소스
RI: EC2, RDS, ElastiCache, Redshift, OpenSearch 등 일부 서비스
Savings Plans Compute SP: EC2 + Fargate + Lambda 모두 포함 (범용성 최고) EC2 Instance SP: 특정 인스턴스군에만 적용
적용 불가능한 항목
EBS 스토리지 요금
NAT Gateway 사용료
Data Transfer 비용
S3, DynamoDB 등 일부 서버리스/매니지드 서비스
즉, RI/SP로 전체 AWS 요금을 완전히 커버할 수는 없으며, ‘컴퓨팅 리소스’에 집중된 할인 구조임을 이해하는 것이 중요합니다.
RI·SP 도입 전에 반드시 체크할 사항
RI와 SP는 분명 강력한 비용 절감 수단이지만, 모든 상황에 무조건 적용하면 오히려 손해가 될 수도 있습니다. ‘앞으로 이 리소스를 이만큼 계속 쓸 것이다’라는 전제 하에 할인 혜택이 적용되므로, 도입 전에 반드시 몇 가지 체크리스트를 통해 검증하는 과정이 필요합니다.
1) 지속적으로 사용되는 워크로드인가?
가장 먼저 확인해야 할 것은, 이 워크로드가 앞으로도 계속 필요할 것인가?입니다.
24시간 운영되는 웹서버
상시 가용성이 요구되는 API 서버
트래픽이 일정한 배치 시스템
하루 수천~수만 건 호출되는 Lambda 함수
이처럼 ‘사용량이 안정적이고 예측 가능한 서비스’는 RI 또는 SP 적용이 매우 효과적입니다.
반면 아래와 같은 경우에는 정액제 적용이 위험할 수 있습니다.
이벤트성 트래픽 대응용 Auto Scaling 그룹
단기 PoC, 마이그레이션 임시 인프라
기능 종료 가능성이 있는 신규 서비스
트래픽 변화가 큰 QA, 테스트 환경
RI/SP는 ‘짧게 쓰고 끝날 리소스’에 적용하면 바로 손해입니다.
2) 리전 이동, 인스턴스 변경 가능성은 없는가?
RI와 SP는 적용 조건이 다르기 때문에, 향후 리소스 변경 계획이 있다면 신중히 판단해야 합니다.
Standard RI는 리전, OS, 인스턴스 패밀리 변경이 불가능합니다.
Convertible RI는 일부 변경 가능하지만, 복잡한 교환 조건과 비율이 있습니다.
Compute SP는 상대적으로 유연하지만, 약정 시간당 금액을 유지해야 합니다.
예를 들어
EC2를 ap-northeast-2(서울)에서 us-west-2(오레곤)으로 이전 예정이라면? → RI 적용 불가
m5.large를 쓰고 있지만, c6i.large로 바꿀 예정이라면? → Standard RI는 적용 불가
향후 변경 가능성이 조금이라도 있다면, Compute SP 또는 Convertible RI처럼 유연한 방식을 선택하는 것이 안전합니다.
3) Cost Explorer와 Compute Optimizer로 기초 진단하기
AWS의 비용 최적화를 위해 RI(Reserved Instances)와 SP(Savings Plans)를 도입하기 전, 조직의 리소스 사용 패턴을 면밀히 분석하는 것이 중요합니다. 이를 위해 AWS는 두 가지 핵심 도구를 제공합니다: AWS Cost Explorer와 AWS Compute Optimizer입니다.
AWS Cost Explorer: 과거 사용량 분석과 비용 가시화
AWS Cost Explorer는 AWS 리소스의 비용 및 사용량을 시각화하고 분석할 수 있는 도구입니다. 이를 통해 다음과 같은 기능을 활용할 수 있습니다:
시각화 및 분석: 최근 13개월의 비용 및 사용량 데이터를 그래프와 표로 시각화하여 트렌드를 파악할 수 있습니다.
필터링 및 그룹화: 서비스, 계정, 리전, 태그 등 다양한 기준으로 데이터를 필터링하고 그룹화하여 세부적인 분석이 가능합니다.
예측 기능: 과거 데이터를 기반으로 향후 12개월의 비용 및 사용량을 예측하여 예산 계획에 활용할 수 있습니다.
리포트 생성 및 저장: 사용자 정의 리포트를 생성하고 저장하여 정기적인 비용 모니터링에 활용할 수 있습니다.
Cost Explorer를 통해 특정 리소스나 서비스의 사용 패턴을 분석하면, 어떤 리소스에 RI나 SP를 적용하는 것이 효과적인지 판단하는 데 도움이 됩니다.
AWS Compute Optimizer: 리소스 최적화 추천
AWS Compute Optimizer는 머신 러닝을 활용하여 리소스의 사용량 데이터를 분석하고 최적화된 리소스 구성을 추천하는 도구입니다. 주요 기능은 다음과 같습니다:
리소스 분석: EC2 인스턴스, Auto Scaling 그룹, EBS 볼륨, Lambda 함수 등의 리소스에 대해 CPU, 메모리, 네트워크 등의 사용량을 분석합니다.
최적화 추천: 분석 결과를 바탕으로 리소스가 과도하게 프로비저닝되었는지, 부족한지, 또는 최적화되어 있는지를 판단하고, 이에 따른 리소스 유형 변경을 추천합니다.
비용 절감 기회 식별: 과도하게 프로비저닝된 리소스를 식별하여 비용 절감 기회를 제공합니다.
시각적 데이터 제공: 리소스의 사용량 데이터를 그래프로 제공하여, 추천 사항의 근거를 명확히 이해할 수 있습니다.
Compute Optimizer를 활용하면 현재 리소스 구성이 적절한지 평가하고, 필요에 따라 리소스 유형을 조정하여 비용 효율성을 높일 수 있습니다.
도구 활용을 위한 준비 사항
이러한 도구들을 효과적으로 활용하기 위해서는 다음과 같은 준비가 필요합니다:
Cost Explorer 활성화: AWS Management Console에서 Cost Explorer를 활성화하여 비용 및 사용량 데이터를 수집하고 분석할 수 있습니다.
Compute Optimizer 옵트인: Compute Optimizer를 사용하려면 먼저 옵트인해야 하며, 최소 30시간 이상의 CloudWatch 메트릭 데이터가 필요합니다.
CloudWatch Agent 설치: 메모리 사용량 등의 세부 메트릭을 수집하려면 CloudWatch Agent를 설치해야 합니다.
태그 관리: 리소스에 적절한 태그를 부여하여 비용 분석 시 정확한 필터링과 그룹화가 가능하도록 합니다.
결론
할인을 받는 건 어렵지 않습니다. 하지만 잘못 받으면, 되돌릴 수 없습니다. RI와 SP는 ‘사면 무조건 이득’인 정액제가 아닙니다. 정확히는 “예측 가능한 사용량에만 적용할 수 있는 계약 기반 할인 제도”입니다.
그렇기 때문에,
이 리소스를 앞으로도 1~3년 이상 안정적으로 쓸 자신이 있는가?
서비스 구조나 인프라 스펙이 변경될 가능성은 없는가?
이미 과도하게 프로비저닝된 인스턴스는 아닌가?
이 세 가지 질문에 ‘그렇다’고 답할 수 있어야, 비로소 RI나 SP를 효과적으로 사용할 수 있습니다. RI, SP 전략은 ‘확신 있는 영역’에만 적용해야 합니다.
FinOps 커뮤니티에 함께 하실래요?
저는 최근 48%, $36000의 AWS 비용절감을 달성했습니다.
클라우드 비용을 효율화하고 싶은 분들, 비슷한 고민을 나누고 싶다면 제가 운영 중인 AWS-FINOPS-KR Slack 커뮤니티에 참여하세요. 실제 절감 사례, 질문, 전략 공유를 나누실 수 있습니다.
