AWS RI 완전 정복: 기본 개념 이해하기
RI의 기본 개념과 핵심 용어
RI(Reserved Instance)는 이름 그대로, AWS에 “특정 인스턴스를 일정 기간 동안 사용하겠다”고 약속함으로써 할인을 받는 방식입니다.
하지만 여기서 말하는 ‘예약’은 인스턴스를 고정적으로 할당받는 것이 아니라, 할인 자격을 구매하는 것에 가깝습니다. 즉, 온디맨드 인스턴스를 그대로 쓰되, 구매한 RI의 조건이 맞으면 RI 할인율이 자동 적용되는 구조입니다. RI는 AWS EC2 서비스에서 쉽게 구매할 수 있습니다. 아래는 예약 인스턴스를 구매하는 화면입니다.
구매 화면에 나오는 선택지에 대해 간단히 살펴보겠습니다.
제품클래스
RI는 제품 클래스에 따라 크게 두 가지 유형으로 나뉩니다. 일반적으로 사용하는 Standard RI와 Convertible RI입니다. 보통 할인률이 더 높은 Standard RI를 많이 사용하고 유연성이 필요할 경우 Convertible RI를 선택할 수 있습니다.
1) Standard RI
고정형 예약 모델입니다. 인스턴스 타입, 크기, 운영체제, 테넌시, 리전을 예약할 때 선택한 조건 그대로 사용해야 하며, 변경이 불가능합니다. 그 대신 Convertible RI보다 높은 할인율(최대 72%)을 제공하기 때문에, 장기적으로 변경 가능성이 적고 워크로드가 일정한 경우 가장 경제적인 선택이 됩니다. 예를 들어, 3년 동안 m6i.large 10대를 계속 사용할 예정이라면 Standard RI를 통해 안정적인 비용 절감을 기대할 수 있습니다.
2) Convertible RI
Convertible RI는 이름 그대로 예약 조건의 변경이 가능한 모델입니다. 인스턴스의 타입, 크기, 운영체제, 테넌시 등을 변경할 수 있어, 워크로드에 따라 필요한 인스턴스를 유연하게 조정할 수 있다는 장점이 있습니다. 다만 이 유연성의 대가로 할인율은 최대 66%로 Standard RI보다 낮습니다. 예를 들어, 1년 후에 m6i.large 대신 ARM 기반 Graviton 인스턴스인 c7g.large로 바꾸고 싶거나, OS를 Linux에서 Windows로 변경해야 할 가능성이 있다면 Convertible RI가 더 적합합니다.
플랫폼
RI(Reserved Instances)의 플랫폼(Platform) 선택은 주로 운영체제(OS)와 소프트웨어 라이선스에 따라 결정되며, 비용 관점에서 중요한 요소입니다.
예를 들어, 플랫폼에는 Linux/UNIX, Windows, Red Hat Enterprise Linux (RHEL), SUSE Linux 등이 포함됩니다.
Linux/UNIX (일반적인 리눅스): 라이선스 비용이 포함되지 않아 가장 저렴한 옵션입니다. EC2 인스턴스 비용만 지불하면 됩니다.
Windows: 마이크로소프트의 라이선스 비용이 포함되어 있으므로, 리눅스보다 비쌉니다. 따라서 동일한 인스턴스 사양에서도 Windows 플랫폼은 추가 비용이 발생하며, 이는 EC2 On-Demand 요금이나 RI 요금에도 반영됩니다.
RHEL, SUSE: 상용 리눅스 배포판을 사용하는 경우, 라이선스 비용이 EC2 요금에 포함되어 있으며, 따라서 비용이 Linux/UNIX보다 높습니다.
즉, RI 플랫폼을 선택할 때는 단순히 EC2 인스턴스의 성능이나 리전만 고려하는 것이 아니라, 운영체제 라이선스 비용까지 함께 고려해야 합니다.
비용 절감 관점에서는 Linux/UNIX 플랫폼이 가장 유리하며, Windows나 RHEL 같은 상용 OS는 추가 라이선스 비용이 포함되므로, 가능한 오픈소스 운영체제 사용을 검토하는 것이 좋습니다. 다만, 특정 애플리케이션이 Windows나 RHEL에서만 동작하는 경우에는 해당 플랫폼을 선택할 수밖에 없으므로, 이러한 선택이 비즈니스 요구사항에 부합하는지와 비용 효과성을 함께 따져봐야 합니다.
용량이 예약된 제공
구매 화면에 표시된 ‘용량이 예약된 제공만 표시’를 활성화하면 가용 영역이라는 선택지가 있습니다. 여기에서는 가용영역을 특정하지 않거나 a, b, c, d 중 특정에서 구매할 수 있습니다. 가용 영역을 특정하지 않는 것은 리전 스코프 레벨에서 구매를 하는 것입니다. 반대로 가용 영역을 특정 하면 AZ(가용영역) 스코프로 구매를 하게 됩니다.
리전 스코프 RI와 AZ 스코프 RI의 차이는 RI의 본질적인 역할, 즉 “할인”과 “용량 예약”의 차이에서 출발합니다. 기본적으로 AZ 스코프가 제한이 있는 반면 할인률이 더 높진 않습니다.
RI(Reserved Instance) 개념 자체는 AWS의 EC2 인스턴스에 대해 일정 기간(1년 또는 3년) 사용을 약속하고, 그 대가로 할인 혜택을 받는 서비스입니다. 이때 대부분의 고객은 RI를 단순히 “할인을 위한 예약”이라고 이해하지만, AZ 스코프 RI의 경우에는 “할인”뿐만 아니라 특정 AZ에서의 리소스 용량 확보라는 추가적인 기능이 제공됩니다.
리전 스코프 RI는 리전 내 어디서든 조건만 맞으면 할인 혜택이 적용됩니다. 특정 AZ에 구애받지 않고 리전 전체에 걸쳐 유연한 리소스 배치를 할 수 있기 때문에, Auto Scaling이나 Spot 대체와 같은 동적 인프라 구성에 적합합니다. 다만, 리전 스코프 RI는 할인만 약속하며, 특정 AZ에서 반드시 인스턴스를 실행할 수 있도록 자리까지 보장해주지는 않습니다. 즉, 99% dkfofh 아주 드물긴 하지만, 특정 AZ에서 리소스가 부족해 인스턴스 생성이 불가능할 수도 있는 리스크를 감수해야 합니다.
반면, AZ 스코프 RI는 특정 AZ에서 반드시 리소스를 제공받을 수 있도록 자리를 예약해줍니다. 할인 혜택은 물론, 해당 AZ에서의 용량 확보까지 보장되기 때문에, 가용성 확보나 특정 AZ에 고정 배치가 필요한 워크로드(예: DB HA 쌍, 고정 IP 설정 등)에 유리합니다. 하지만 특정 AZ에만 적용되므로, 리전 내 다른 AZ로의 유연한 리소스 배치는 어렵다는 제약이 따릅니다.
결과적으로, 대부분의 일반적인 상황에서는 리전 스코프 RI가 더 유연하고 관리가 쉽지만, 특정 AZ에서의 인스턴스 확보가 반드시 필요하다면 AZ 스코프 RI를 선택하는 것이 적합합니다. 즉, 할인만 필요한지, 아니면 할인 + 특정 AZ에서의 자리 예약까지 필요한지를 기준으로 선택하면 됩니다.
단, AWS는 리전 스코프 RI를 구매하더라도 리전 내에서 충분한 용량을 제공하기 위해 최대한 노력하지만, 특정 AZ에서의 리소스 부족 상황은 예외적으로 발생할 수 있다는 점은 반드시 염두에 두어야 합니다.
일반적으로 AZ를 특정해야 할 경우가 아니라면 리전 스코프를 많이 사용합니다.
테넌시
테넌시는 기본으로 선택할 수 있는 Shared Tenancy와 전용으로 사용하는 Dedicated Tenancy로 구분됩니다.
Shared Tenancy (기본 선택)
AWS의 기본 옵션으로, 여러 고객의 인스턴스가 같은 물리 서버에 함께 배치됩니다. 대부분의 EC2 RI는 Shared Tenancy용으로 제공되며, 가장 저렴하고 일반적인 선택입니다. 별도의 물리적 격리가 필요 없고, 보안/컴플라이언스 요구사항이 없는 대부분의 워크로드에 적합합니다. RI 구매 시 별도 테넌시는 디폴트로 기본값인 Shared로 적용됩니다.
Dedicated Tenancy
단일 고객만을 위한 전용 물리 서버에 인스턴스를 배치합니다. 보안, 규제, 또는 특정 감사 요건에 따라 다중 고객과 자원 공유가 불가할 때 사용합니다. RI를 구매할 때 Dedicated Tenancy를 선택할 수 있으나, 할인율은 Shared에 비해 제한적입니다. Dedicated Host 또는 Dedicated Instance 형태로 사용할 수 있으며, 물리적 리소스 전용 배치를 원하면 이 옵션을 선택해야 합니다.
일반적으로 금융이나 정부 등 보안, 규제, 또는 특정 컴플라이언스 상 물리적 격리가 보장될 필요가 없다면 Shared Tenancy를 사용하면 됩니다.
기간
기간은 RI 계약을 몇 년 동안 유지할지 선택하는 항목입니다. AWS에서는 주로 1년과 3년 기간을 제공합니다. 당연히 3년 RI가 1년 RI보다 할인율이 더 높습니다. (보통 1년 RI는 30~40% 절감, 3년 RI는 50~70% 절감 효과) 다만, 3년은 상당히 긴 기간이므로 서비스의 장기적인 사용 계획이 확실해야 합니다.
장기간 안정적으로 운영되는 프로덕션 시스템이라면 3년 RI를 사용하고, 신규 프로젝트나 사용량 예측이 불확실한 경우 1년 RI를 사용하면 됩니다.
결제 옵션
RI 구매 시 결제 방법을 선택해야 하는데, 아래 3가지 중 하나를 고를 수 있습니다.
All Upfront는 예약 인스턴스 전체 비용을 구매 시점에 한 번에 결제하는 방식으로, 가장 큰 할인 혜택을 받을 수 있는 옵션입니다. 예산이 충분하고 장기적으로 운영 계획이 명확한 경우, 최대한의 비용 절감을 위해 All Upfront을 선택하는 것이 유리합니다.
Partial Upfront는 전체 요금 중 일부를 선납하고, 나머지 금액은 매달 나눠서 결제하는 방식입니다. 할인 효과는 All Upfront보다는 다소 낮지만, 선납 부담을 줄이고 매달 일정 금액으로 나눠 지불할 수 있어 할인과 유동성의 균형을 맞출 수 있는 선택지로 많이 활용됩니다.
No Upfront는 선납 비용 없이 매달 일정 금액을 결제하는 방식입니다. 할인 폭은 가장 적지만, 초기 투자 비용 부담이 전혀 없다는 점에서 유리하며, 예산이 빠듯하거나 단기적인 프로젝트 등 불확실성이 큰 경우에 선택할 수 있는 옵션입니다. 다만, 장기적으로는 다른 옵션에 비해 비용 절감 효과가 적을 수 있습니다.
RI 적용 방식
RI(Reserved Instance)를 구매했다고 해서 그 인스턴스에 자동으로 100% 적용된다고 생각하면 오해입니다.
RI는 조건이 정확히 일치하는 온디맨드 인스턴스가 존재할 때만 할인 적용이 이루어집니다. 즉, 아무 EC2 인스턴스에나 적용되는 것이 아니라, RI와 EC2 간의 매칭 조건이 맞아야 합니다.
EC2 인스턴스에 RI가 적용되는 우선순위
AWS는 RI를 EC2 인스턴스에 자동으로 매핑할 때 다음과 같은 우선순위 기준을 따릅니다.
시간 순: 먼저 실행된 인스턴스에 먼저 할당
정확한 매칭 우선: 인스턴스 타입/OS/리전/테넌시가 RI 조건과 완전히 일치할 경우 우선 적용
할당 가능한 RI부터 적용: 동일한 조건이 여러 개일 경우, 아직 커버되지 않은 RI가 먼저 매칭
즉, RI가 있다고 해서 아무 인스턴스나 자동 할인되는 것은 아니며, 온디맨드 인스턴스와의 “1:1 매칭” 원칙이 우선입니다.
할인 적용을 위한 주요 조건
RI는 구매 시 다음 세 가지 속성 조건이 명확하게 설정됩니다. 이 조건이 온디맨드 인스턴스와 일치해야 할인 적용이 됩니다.
1) 인스턴스 패밀리 (Instance Family)
m5.xlarge로 구매한 RI는 c6i.large에는 적용되지 않습니다.
그러나 m5.large나 m5.2xlarge 처럼 크기가 다를 경우는 매칭이 됩니다. 리전 스코프 RI + Linux + 공유 테넌시일 경우에만 “가변 사이즈 적용”이 가능합니다. (예: m5.large 2개로 m5.xlarge 1개 적용 가능).
2) 운영체제 (OS / Platform)
Amazon Linux, Ubuntu, RHEL, Windows 등 OS가 반드시 일치해야 합니다.
Windows RI는 Windows 인스턴스에만 적용되며, 라이선스 포함 여부도 맞아야 합니다.
3) 테넌시 (Tenancy)
Default (공용 호스트)
Dedicated (전용 호스트)
RI는 구매 시 선택한 테넌시 조건과 인스턴스가 동일해야만 적용됩니다.
리전, AZ 스코프도 선택한 경우 조건으로 포함되며, Convertible RI는 교환 후의 조건이 적용 기준이 됩니다.
예시로 보는 적용 여부
실무 팁
리전 스코프 RI + Linux + Default 테넌시 조합은 가장 유연하고 범용적입니다.
가변 사이즈 적용(Instance Size Flexibility)은 이 조합일 때만 활성화되며, 다양한 사이즈의 인스턴스에 자동 적용될 수 있어 실무에서 가장 추천되는 옵션입니다.
마무리
이 글에서 다룬 핵심은 아래와 같습니다.
RI는 고정된 리소스에만 적용되고, 조건이 일치해야 할인됩니다.
구조가 자주 바뀐다면 Convertible RI가, 고정 인프라에는 Standard RI가 유리합니다.
약정 기간과 결제 방식의 조합에 따라 할인폭이 크게 달라집니다.
커버리지를 기준으로 점진적이고 분산된 구매가 가장 안전합니다.
중고 RI 거래소인 RI Marketplace도 전략적으로 활용할 수 있습니다.
AWS는 구매 구조를 니즈에 따라 복잡하게 설계했지만, 우리는 전략으로 단순하게 대응할 수 있습니다.
FinOps 커뮤니티에 함께 하실래요?
저는 최근 48%, $36000의 AWS 비용절감을 달성했습니다.
클라우드 비용을 효율화하고 싶은 분들, 비슷한 고민을 나누고 싶다면 제가 운영 중인 AWS-FINOPS-KR Slack 커뮤니티에 참여하세요. 실제 절감 사례, 질문, 전략 공유를 나누실 수 있습니다.
