RI vs Savings Plans: AWS 약정 할인 선택 기준
이 시리즈에서 EC2, RDS, 컨테이너, 스토리지를 고르는 기준을 다룰 때마다 마지막에 같은 문장이 나왔습니다. “장기 실행이 확정이면 약정 할인을 검토합니다"입니다. 이번 글이 그 약정을 고르는 기준입니다. 결론을 먼저 적으면, EC2 중심의 신규 약정은 Savings Plans가 기본값이고, RI(예약 인스턴스)가 여전히 필요한 자리는 RDS 같은 EC2 밖의 서비스와 용량 예약입니다. 할인율이 같다면 유연한 쪽을 고르는 것이 원칙입니다. 요금과 할인율은 us-east-1, 온디맨드 대비 기준입니다.
한눈에 보는 비교 #
| 구분 | Standard RI | Convertible RI | EC2 Instance SP | Compute SP |
|---|---|---|---|---|
| 최대 할인율 (3년 선결제) | 약 72% | 약 66% | 약 72% | 약 66% |
| 적용 범위 | 인스턴스 패밀리·리전 | 교환으로 변경 가능 | 패밀리·리전 고정 | EC2 전체 + Fargate + Lambda |
| 패밀리 변경 | 불가 | 교환 절차로 가능 | 불가 | 자동 적용 |
| 사이즈·OS 변경 | 조건부 (리전·Linux 등) | 교환 절차로 가능 | 자동 적용 | 자동 적용 |
| 재판매 | Marketplace 가능 | 불가 | 불가 | 불가 |
구조 차이: 속성을 사는가, 금액을 사는가 #
RI는 인스턴스 속성을 사는 약정입니다. “m5.xlarge, us-east-1, Linux를 1년"처럼 속성 조합을 지정하고, 실행 중인 인스턴스가 그 속성과 일치하면 할인이 적용됩니다. 속성이 어긋나면 할인은 놀고 온디맨드 요금이 나갑니다. 리전 단위 Linux RI는 같은 패밀리 안에서 사이즈가 달라도 유연하게 적용되지만, 패밀리를 넘는 변경은 Standard RI로는 불가능하고 Convertible RI의 교환 절차를 거쳐야 합니다.
Savings Plans는 시간당 금액을 사는 약정입니다. “시간당 $10을 1년” 식으로 약정하면, 그 금액까지의 사용량에 할인 단가가 적용되고 초과분만 온디맨드로 나갑니다. 무엇에 적용할지는 AWS가 할인 효과가 큰 순서로 자동 배정합니다. 인스턴스를 m5에서 c7g로 바꾸든, EC2를 줄이고 Fargate를 늘리든(Compute SP 기준) 약정은 계속 소화됩니다. EC2 인스턴스 패밀리를 바꿔 가며 최적화하는 팀이라면 이 차이가 결정적입니다.
관리 부담도 구조에서 갈립니다. RI는 “어떤 속성을 몇 개 샀고 지금 몇 개가 매칭되는지"를 추적해야 하지만, SP는 시간당 약정액과 실사용의 커버리지만 보면 됩니다.
할인율: 최대치가 아니라 같은 조건끼리 비교합니다 #
숫자만 보면 Standard RI와 EC2 Instance SP가 최대 약 72%로 같고, Convertible RI와 Compute SP가 약 66%로 같습니다. 여기서 나오는 실무 결론은 단순합니다.
- EC2 Instance SP vs Standard RI: 할인율이 사실상 같은데 SP 쪽이 사이즈·OS 자동 적용으로 더 유연합니다. 용량 예약과 재판매(뒤에서 다룹니다)가 필요 없다면 SP가 우선입니다.
- Compute SP vs Convertible RI: 역시 할인율이 비슷한데, Convertible RI의 교환은 수동 절차이고 Compute SP의 적용은 자동입니다. 신규라면 Compute SP입니다.
- 최대치는 3년 전액 선결제 기준입니다. 1년 선결제 없음이면 할인율은 낮아지지만(Compute SP 기준 대략 20〜30%대) 부담도 작습니다. 선결제 여부는 할인율보다 현금 흐름 문제이므로 재무 쪽과 정하는 항목입니다.
RI가 남는 자리: SP가 커버하지 못하는 곳 #
SP의 적용 범위는 EC2, Fargate, Lambda입니다(SageMaker는 별도의 SageMaker Savings Plans). 뒤집으면 그 밖의 서비스는 여전히 RI(예약) 체계라는 뜻입니다.
- RDS 예약 인스턴스: RDS 인스턴스 클래스와 Aurora에서 다룬 데이터베이스는 SP 대상이 아닙니다. 안정적으로 도는 프로덕션 DB는 RDS RI가 유일한 약정 수단이고, 절감 폭도 큽니다.
- ElastiCache, OpenSearch, Redshift, DynamoDB: 각각 예약 노드·예약 용량 체계를 따로 갖고 있습니다. 이름은 달라도 구조는 RI와 같습니다.
- 용량 예약: SP와 리전 단위 RI는 요금 할인일 뿐 용량을 보장하지 않습니다. 특정 AZ에서 인스턴스를 반드시 띄워야 하는 요구는 존 단위 RI 또는 온디맨드 용량 예약(ODCR)으로 풀어야 하며, ODCR은 Compute SP와 조합할 수 있습니다.
- 재판매: 약정을 중도에 처분할 수 있는 것은 Standard RI(Marketplace)뿐입니다. SP는 취소·양도가 불가능합니다.
약정 규모: 청구서의 안정 하한선까지만 #
약정의 유일한 리스크는 과약정입니다. SP는 사용량이 약정액에 못 미쳐도 시간당 약정액이 전부 청구되므로, 안 쓴 약정은 그대로 손실입니다. 규모 산정은 다음 순서가 안전합니다.
- 베이스라인을 잽니다: Cost Explorer의 최근 몇 달 사용량에서 야간·주말에도 유지되는 상시 사용분을 찾습니다. 이것이 약정 가능한 하한선입니다.
- 하한선의 일부만 먼저 약정합니다: Cost Explorer의 SP 추천이 계산해 주는 권장액에서 시작하되, 첫 약정은 1년·선결제 없음으로 보수적으로 잡는 편이 안전합니다.
- 레이어링으로 쌓습니다: 약정은 여러 장을 겹칠 수 있습니다. 분기마다 커버리지와 사용률 지표를 보고 부족분만큼 추가 구매하는 방식이, 한 번에 크게 약정하는 것보다 리스크가 작습니다.
- 줄어들 예정인 사용량은 넣지 않습니다: 마이그레이션 예정 워크로드, Lambda vs Fargate에서 다룬 이동 계획이 있는 서비스는 약정 계산에서 뺍니다. 약정 전에 상시 점검 목록으로 낭비부터 지우는 것도 같은 이유입니다. 낭비를 약정하면 할인된 가격으로 낭비할 뿐입니다.
선택 순서 #
- 서비스 범위부터 확인합니다: EC2·Fargate·Lambda면 SP, RDS를 비롯한 데이터베이스·분석 계열이면 해당 서비스의 RI(예약)입니다.
- 패밀리 확신도로 SP 종류를 고릅니다: 패밀리·리전이 몇 년간 고정이라고 확신하면 EC2 Instance SP(최대 72%), 바뀔 수 있으면 Compute SP(최대 66%)입니다. 확신이 없을 때 6%p를 아끼려고 고정 약정을 잡는 것이 전형적인 후회 패턴입니다.
- 용량 보장 요구를 확인합니다: 특정 AZ 용량이 필수면 존 단위 RI 또는 ODCR을 별도로 계획합니다.
- 규모는 안정 하한선 이하로 잡습니다: 상시 사용분만 약정하고, 변동분은 온디맨드로 남깁니다.
- 분기마다 재검토합니다: 커버리지·사용률 지표를 보고 레이어를 추가합니다. 약정은 한 번의 결정이 아니라 반복 운영입니다.
정리 #
- EC2 중심의 신규 약정은 Savings Plans가 기본값입니다. 같은 할인율이면 자동 적용되는 쪽이 이깁니다.
- 패밀리까지 확신하면 EC2 Instance SP(최대 72%), 아니면 Compute SP(최대 66%)입니다. 6%p 차이는 유연성의 가격입니다.
- RDS, ElastiCache, OpenSearch, Redshift는 SP 대상이 아니라 각자의 예약 체계를 씁니다. 프로덕션 DB 약정은 여전히 RI의 영역입니다.
- SP와 리전 RI는 요금 할인일 뿐입니다. 용량 보장은 존 단위 RI나 ODCR로 따로 풉니다.
- 약정 규모는 청구서의 안정 하한선까지만, 여러 장으로 나눠 레이어링합니다. 안 쓴 약정은 손실이고, 낭비를 약정하면 할인된 낭비일 뿐입니다.