AWS 비용이 부담되기 시작하면 대부분 인스턴스를 끄거나 사양을 줄이는 방법부터 찾습니다. 그런데 이런 노력을 한참 해봐도 청구서가 기대만큼 줄지 않는 경우가 많습니다. 이유는 간단합니다. 청구서는 '사용량 × 단가'로 결정되는데, 인스턴스를 끄고 줄이는 건 사용량을 낮추는 일이고, RI와 Savings Plans는 단가 자체를 낮추는 수단이기 때문입니다. 사용량만 손대고 단가를 그대로 두면, 청구서는 어느 지점부터는 더 줄지 않습니다.

대부분의 조직은 AWS를 온디맨드(On-Demand) 방식으로 시작합니다. 쓴 만큼 내는 구조라 워크로드 예측이 어려운 초기에는 합리적인 선택입니다. 문제는 서비스가 안정화되고 사용 패턴이 예측 가능해진 뒤에도, 단가를 결정하는 요금 모델은 초기 그대로 온디맨드에 머물러 있는 경우가 많다는 점입니다.

RI(Reserved Instance)와 Savings Plans(SP)는 일정 기간 사용을 약속하는 대신 온디맨드 대비 최대 72~75%까지 할인받는 구조입니다. 월 컴퓨팅 지출이 큰 조직일수록 이 제도의 활용 여부에 따라 연간 비용 차이가 수억 원단위로 벌어집니다. 

'약정'이라는 단어 때문에 도입을 미루는 경우도 많지만, 구조를 이해하면 리스크는 충분히 통제할 수 있습니다.

온디맨드만 쓰는 것은 '정가'만 내는 구조입니다

온디맨드를 택시에 빗대어 보겠습니다. 언제든 잡아탈 수 있고, 내리고 싶을 때 내리면 됩니다. 대신 미터기 요금을 냅니다. 언제 어디로 갈지 모르는 출장 같은 이동이라면 택시가 정답입니다.

그런데 매일 같은 시간에 같은 경로로 출퇴근하면서 매번 택시를 타는 사람은 드뭅니다. 클라우드도 같은 구조입니다. 운영 환경의 웹 서버, 24시간 돌아가는 데이터베이스, 항상 떠 있어야 하는 API 서버처럼 1년 뒤에도 켜져 있을 게 확실한 워크로드에 온디맨드 정가를 계속 내는 것은, 값싼 정기권이 있는 노선을 매일 비싼 택시로 다니는 것과 같습니다.

온디맨드 요금은 매달 쓴 만큼 찍히기 때문에, 낭비가 아니라 정상 사용처럼 보입니다. 인스턴스를 껐다 켜는 스케줄링, 스펙을 줄이는 라이트사이징은 모두 '사용량' 측면의 절감이라 눈에 보이고 실행하기도 쉽습니다. 반면 '단가’ 측면에서 같은 사용량을 더 싸게 사는 방법이 있다는 걸 많이 놓치십니다.

실제 기업들의 AWS 비용 점검을 하다 보면, 사용량 최적화는 어느 정도 되어 있는데, 이 사용량 전체를 여전히 정가로 지불하고 있는 경우를 많이 봅니다. 이때 남은 절감 수단이 약정 할인입니다. 즉, 온디맨드는 유연함의 대가로 정가를 내는 예측 불가능한 워크로드용 방식이고, 약정 할인(RI/SP)은 사용을 약속하는 대가로 할인을 받는 예측 가능한 워크로드용 방식입니다.

RI/SP는 "우리 인프라에서 확실히 계속 쓸 부분이 어디인가"를 요금에 반영하는 것입니다. 사용 패턴은 이미 바뀌었다면, 지불 방식 변경도 고려해 보시는 게 좋습니다.

[참고] 인스턴스 사용량 축은 어떻게 최적화하는지 더 궁금하다면?
👉 AWS 비용이 매달 새는 3가지 구조와 절감 포인트

RI와 Savings Plans, 각각 무엇을 약속하는 걸까요

RI(Reserved Instance)는 '무엇을 쓸지'를 약속합니다. Savings Plans(SP)는 '얼마나 쓸지'를 약속합니다. 같은 할인 제도인데 약속의 대상이 다르죠.

RI는 "서울 리전에서, 이 타입의 인스턴스를, 1년(또는 3년) 동안 쓰겠다"고 구성을 지정해서 예약하는 방식입니다. 예약과 같은 조건(리전, 인스턴스 타입, OS 등)의 인스턴스가 실제로 돌아가고 있으면 그 요금이 자동으로 할인가로 청구되고, 조건이 다른 인스턴스만 돌아가고 있으면 할인은 적용되지 않습니다.

SP는 "시간당 10달러어치 컴퓨팅을 쓰겠다"라고 금액만 약속하는 방식입니다. 어떤 인스턴스를 쓰든 그 금액까지는 할인가가 자동 적용됩니다. 다만 약정한 시간당 금액은 실제 사용량과 무관하게 매시간 청구되고, 사용량이 약정에 못 미치면 그 차액은 그대로 낭비가 됩니다. 할인 범위에 따라 Compute SP와 EC2 Instance SP, 두 가지로 나뉩니다.

네 가지 옵션의 조건과 할인율을 표로 정리했습니다. (할인율은 3년 약정에 선결제를 적용했을 때의 최대치이며, 1년 약정을 선택하거나 선결제 비중을 낮추면 낮아지고 인스턴스 타입·리전에 따라서도 달라집니다.)

바꿀 수 있는 범위가 넓어질수록, 약정 조건이 가벼워질수록 할인율이 낮아지는 사실 하나를 잘 기억해 주세요. 여기에 약정 기간과 결제 방식까지 조합하면 경우의 수가 상당히 많아지기 때문에, 실제 설계는 사용 패턴 데이터를 놓고 정하게 됩니다.

2026년에는 여기에 큰 변화가 하나 생겼습니다. re:Invent 2025에서 발표된 Database Savings Plans입니다. 그동안 SP는 컴퓨팅 영역 중심이었고 데이터베이스는 RI로만 약정할 수 있었는데, 이제 RDS · Aurora · DynamoDB · ElastiCache 등 10개 데이터베이스 서비스가 SP 방식으로 묶입니다. 다만 1년 약정만 가능하고, 최신 세대(Gen 7 이상) 인스턴스만 대상이며, 최대 할인율도 35% 수준으로 RDS Standard RI(최대 69%)보다 낮습니다. 기존 DB RI를 대체하는 게 아니라, DB 구성이 자주 바뀌는 조직을 위한 유연성 옵션이 하나 추가된 것으로 이해하면 됩니다.

RI와 SP 중 뭘 골라야 하는가는, 워크로드마다 답이 달라집니다.

[참고] 약정 설계와 운영을 실제로 어떻게 진행하는지 사례로 보고 싶다면?
👉 AWS 구축부터 운영지원까지! MSP 서비스

약정을 걸기 전에 점검할 2가지

실무에서 가장 자주 나오는 질문은 RI와 SP 중 무엇을 선택할지입니다. 2026년 현재 실무의 답은 양자택일이 아니라 레이어링입니다. 확실한 바닥 사용량(baseline usage)은 Compute SP로 넓게 덮고, 구성이 절대 바뀌지 않는 고정 워크로드는 할인율 높은 RI로 덮고, 변동분만 온디맨드로 남깁니다. AWS가 할인 적용 순서를 자동으로 최적화하기 때문에, 여러 약정을 겹쳐도 충돌하지 않습니다.

최근 60~90일의 '최소 사용량 바닥선'을 확인하셨나요? 

약정 금액은 평균 사용량이 아니라 최소 바닥선 기준으로 잡아야 합니다. 시간대별 사용량 그래프에서 가장 낮은 구간, 새벽에도 항상 돌아가는 수준이 안전한 약정 기준입니다. 실무에서는 이 바닥선의 70~80% 수준부터 약정을 시작하고, 활용률을 확인하며 단계적으로 늘리는 방식이 권장됩니다. 과다 약정은 미사용분이 그대로 낭비로 남습니다.

약정 취소·변경 조건을 확인하셨나요? 

2026년 기준 SP 반환 정책은 생각보다 엄격합니다. 시간당 약정 100달러 이상의 SP는 반환이 불가능하고, 그 미만도 같은 달 내 7일 이내, 연 10회까지만 반환할 수 있습니다. 규모가 큰 약정일수록 사실상 되돌릴 수 없다는 뜻이므로, 처음부터 크게 걸기보다 작게 나눠 거는 편이 안전합니다.

이 두 가지만 점검해도 "약정이 부담스러워 온디맨드 정가를 계속 내는 상태"와 "리스크를 통제하면서 할인을 받는 상태"의 차이가 생깁니다. 인프라는 하나도 바꾸지 않고, 지불 방식만 바꿔서 같은 사용량을 더 낮은 비용으로 운영하는 셈입니다.

마무리 전에, 우리 환경을 한번 점검해 보시기 바랍니다.

• 1년 뒤에도 확실히 켜져 있을 워크로드가 지금 온디맨드 정가로 돌아가고 있지 않나요?
• 최근 60~90일의 시간대별 최소 사용량 바닥선을 확인해 본 적 있나요?
• 이미 구매한 RI/SP가 있다면, 활용률과 커버리지를 정기적으로 보고 있나요?
• 데이터베이스 영역은 RI와 Database Savings Plans 중 어느 쪽이 유리한지 검토해 봤나요?

이 질문에 바로 답하기 어렵다면, 약정을 걸기 전에 사용 패턴 분석부터 시작하는 것이 순서입니다. 약정은 데이터에 기반한 의사결정입니다.

파이브클라우드는 워크로드 사용 패턴 진단부터 RI/SP 약정 포트폴리오 설계, 구매 이후의 활용률·커버리지 모니터링과 갱신 전략 수립까지, 약정 기반 비용 최적화의 전 과정을 함께합니다.