Compute Savings Plans vs. 예약 인스턴스(RI) 비교
두 방식 모두 1년 또는 3년 약정을 통해 최대 66~72%의 할인을 제공하지만, 적용 범위와 유연성에서 큰 차이가 납니다.
항목 | Compute Savings Plans (CSP) | 예약 인스턴스 (RI) |
적용 대상 | EC2, Lambda, Fargate | EC2 (일부 RDS 등) |
인스턴스 패밀리 변경 | 무제한 가능 (C5 → M6g 등) | 제한적 (전환형 RI만 가능) |
리전(Region) 변경 | 무제한 가능 (서울 → 도쿄 등) | 불가능 (특정 리전 고정) |
OS 변경 | 무제한 가능 (Linux → Windows 등) | 조건부 가능 |
관리 편의성 | 매우 높음 (자동 적용) | 낮음 (수동 매칭 및 관리 필요) |
우리 서비스 패턴에는 무엇이 유리할까?
1. 이런 경우 'Compute Savings Plans'가 압도적으로 유리합니다
마이크로서비스(MSA) 환경: EC2뿐만 아니라 Fargate나 Lambda를 활발히 사용하는 경우.
기술 스택의 변화가 빠른 팀: 내년에 인스턴스 타입을 인텔(x86)에서 그라비톤(ARM)으로 바꿀 계획이 있는 경우.
글로벌 확장 계획: 서비스 거점을 서울에서 미국이나 유럽으로 유동적으로 옮겨야 하는 경우.
귀차니즘(?)이 있는 경우: 어떤 리소스를 얼마나 샀는지 일일이 관리하고 매칭하기 싫을 때 (AWS가 알아서 가장 저렴한 조합으로 자동 적용해 줍니다).
2. 이런 경우 '예약 인스턴스(RI)'를 고려해볼 법합니다
극도의 안정성: 특정 리전의 특정 AZ(가용 영역)에 용량 예약(Capacity Reservation)이 반드시 필요한 경우. (단, 요즘은 On-Demand Capacity Reservation으로 대체 가능합니다.)
전용 호스트(Dedicated Hosts)를 사용해야 하는 특수 보안 규정이 있는 경우.
RDS 전용 약정: Savings Plans는 아직 RDS를 지원하지 않으므로, 데이터베이스 비용 절감은 여전히 DB RI를 써야 합니다.
Tip
2026년에 새로 EC2 RI를 산다는 건, 스마트폰 시대에 삐삐를 사는 것과 비슷합니다.
특별한 이유가 없다면 Compute Savings Plans를 선택하세요. 서비스가 커지면서 인스턴스 타입을 업그레이드하거나(M5 → M7), 서버리스(Fargate)로 전환할 때 RI는 애물단지가 되기 십상이지만 SP는 묵묵히 제 역할을 다합니다.
한 가지 팁: 약정 금액을 정할 때 현재 사용량의 100%를 다 걸지 마세요. 베이스라인(최저 사용량)의 70~80% 정도만 약정하고, 나머지는 상황에 따라 조절하는 것이 가장 경제적입니다.
댓글
댓글 0개
이 문서에는 댓글을 달 수 없습니다.