대부분의 사람들은 Compute Savings Plan이 클라우드 컴퓨팅 비용을 절감해 준다는 점을 이해하고 있습니다. 하지만 그 정확한 메커니즘을 이해하는 사람은 훨씬 적습니다. 약정 금액(commitment amount)을 어느 방향으로든 잘못 설정하면 실제로 돈을 낭비하게 되기 때문입니다.

너무 높게 설정하면: 사용하지 않는 약정 시간(committed hours)에 대해 비용을 지불하게 됩니다. 너무 낮게 설정하면: 커버할 수 있었던 사용량에 대한 절감 혜점(savings)을 놓치게 됩니다. 적절한 규모로 설정된 Savings Plan과 잘못 설정된 Savings Plan의 차이는 중규모 플릿(fleet) 기준으로 연간 수만 달러에 달할 수 있습니다.

이 가이드는 AWS와 Azure에서의 실제 예시와 함께, 시간 단위로 정확한 메커니즘을 살펴봅니다.

1단계: 약정 금액(Commitment Amount) 선택

다른 무엇보다 먼저, 시간당 얼마를 약정할지 결정해야 합니다. 이것은 전체 과정에서 가장 중요한 단 하나의 결정입니다. 할인 적용(discount application), 커버리지 계산(coverage calculation), 빌링(billing) 등 나머지 모든 것은 자동으로 이루어집니다.

약정 금액은 달러 수치로 표현됩니다: 시간당 $X. 이는 최소 지출 수준을 나타냅니다. 당신은 클라우드 제공업체에게 다음과 같이 말하는 것입니다:

AWS, Azure, GCP 전반에서 약정 기반 할인 (Commitment-based discounts)이 어떻게 작동하는지 이해하고 싶다면, 여기에서 전체적인 현황을 다루었습니다: 멀티 클라우드 서비스에서 약정 기반 할인(Commitment-Based Discounts)이란 무엇인가?

2단계: 클라우드 제공업체가 할인된 요율을 적용함

활성화된 Savings Plan이 있으면, 클라우드 제공업체는 매시간 귀하의 적격한 컴퓨팅 사용량에 대해 할인된 요율을 적용합니다. 매칭할 단계도, 작성할 규칙도, 태그를 지정할 인스턴스도 없습니다. 할인은 자동으로 적용됩니다.

AWS의 경우, 할인은 EC2 인스턴스 (EC2 instance) 시간, Fargate 컴퓨팅, 그리고 Lambda 실행 시간 요금에 적용됩니다. Azure의 경우, 가상 머신 (Virtual Machine) 컴퓨팅, AKS 노드 풀 VM, Azure Functions Premium, 컨테이너 인스턴스 (Container Instances), 그리고 App Service Premium v3에 적용됩니다.

제공업체는 먼저 가장 높은 할인율 (savings rate)을 가진 사용량에 할인을 적용하는 것으로 시작합니다. 만약 귀하가 m5.xlarge (60% 할인율)와 c5.xlarge (58% 할인율)를 동시에 실행하고 있다면, 약정된 시간당 금액에 도달할 때까지 m5에 Savings Plan 요율이 먼저 적용된 다음 c5에 적용됩니다.

예약 인스턴스 (Reserved Instances, RI)는 Savings Plan보다 먼저 적용됩니다. 특정 인스턴스 유형에 대한 EC2 RI를 보유하고 있다면, 해당 RI 할인이 먼저 적용됩니다. 그 후 Savings Plan이 남은 적격 사용량을 커버합니다. RI는 안정적이고 특정 구성이 고정된 핵심 부분을 처리하며, Savings Plan은 그 외의 모든 것을 처리합니다.

3단계: 약정 금액까지의 사용량은 할인된 요율로 청구됨

할인된 요율은 약정 금액까지 귀하의 적격 사용량에 대해 시간 단위로 적용됩니다.

예시: 귀하가 AWS에서 시간당 $5.00를 약정했습니다. 특정 시간 동안, 귀하는 온디맨드 (on-demand) 요율로 $8.00가 소요되는 컴퓨팅을 실행합니다.

• 귀하의 Savings Plan은 할인된 요율로 첫 $5.00 상당의 컴퓨팅 비용을 충당합니다.
• 60% 절감 시, 해당 $5.00의 온디맨드 (on-demand) 컴퓨팅 비용은 약 $2.00–$2.50가 됩니다.
• 나머지 $3.00의 온디맨드 사용량은 표준 요율로 청구됩니다.
• 해당 시간의 총 청구 금액: $8.00 대신 약 $5.00–$5.50

4단계: 약정 금액을 초과하는 사용량은 온디맨드 요율로 청구됩니다

Savings Plan은 약정한 금액까지의 사용량만 충당합니다. 특정 시간 동안 해당 임계값을 초과하는 모든 사용량은 Savings Plan이 전혀 없는 것처럼 일반 온디맨드 (on-demand) 요율로 청구됩니다.

이는 페널티가 아니라 의도된 설계입니다. 귀하의 Savings Plan은 기본 지출 수준을 약정한 것입니다. 해당 기본 수준을 초과하는 추가 사용량은 귀하가 약정하지 않은 유연한 온디맨드 용량입니다.

만약 사용량이 정기적으로 약정 금액을 상당한 차이로 초과한다면, 이는 약정 금액이 너무 적게 설정된 Savings Plan입니다. Savings Plan은 새로운 구매를 기존 구매 위에 쌓는 방식이므로, 언제든지 두 번째 약정을 추가할 수 있습니다. 기존의 약정 금액을 상향 수정할 수는 없습니다.

5단계: 미사용 약정 금액은 관계없이 청구됩니다

이 단계는 대부분의 사람들이 과소평가하는 부분입니다. 만약 시간당 $5.00를 약정했는데 특정 시간의 실제 컴퓨팅 사용량이 $2.00뿐이라면, 귀하는 여전히 $5.00를 지불해야 합니다. 사용하지 않은 $3.00의 약정 금액은 청구되며 이월되지 않습니다.

이월(rollover)은 없습니다. 각 시간은 독립적입니다. 화요일 피크 시간대에 저축해둔 미사용 약정 금액이 월요일 새벽 3시의 이례적으로 한산한 시간대에 혜택을 주지는 않습니다.

이것이 바로 약정 규모를 보수적으로 산정하는 것이 중요한 이유입니다. 사용량이 적은 시간대에 과도하게 약정하는 금액이 커질수록, 그 금액만큼의 손실을 아무런 수익 없이 지불하게 됩니다. 만약 시간당 $1.00를 초과하여 약정하고 한 달 동안 720시간을 운영한다면, 바쁜 시간대에 Savings Plan 할인이 올바르게 적용되고 있더라도 매달 $720의 순수한 낭비가 발생합니다.

6단계: 할인은 매시간 자동으로 갱신됩니다

Savings Plan은 구매 후 별도로 활성화, 갱신 또는 관리할 필요가 없습니다. 약정 기간 동안 매시간 클라우드 제공업체는 사용자의 적격 컴퓨팅 사용량(eligible compute usage)을 확인하고, 약정 금액까지 할인된 요율을 적용하며, 나머지 금액은 온디맨드(on-demand) 요율로 청구합니다.

인스턴스 유형을 변경하거나, 새로운 리전(region)에서 실행하거나, 워크로드를 마이그레이션(migrate)하더라도 아무것도 업데이트할 필요가 없습니다. 할인이 자동으로 따라오는데, 이것이 바로 Savings Plan이 예약 인스턴스(Reserved Instances, RI)보다 갖는 핵심적인 장점입니다.

주의가 필요한 한 가지 시나리오: 기존의 Savings Plan 위에 새로운 Savings Plan을 추가로 쌓는 경우, 모든 활성 플랜의 결합된 약정 금액이 총 시간당 약정 금액이 됩니다. 의도치 않은 과잉 약정을 피하기 위해 이를 지속적으로 추적하십시오.

AWS와 Azure의 Savings Plan 할인 적용 방식 차이점

핵심 메커니즘은 거의 동일합니다. 하지만 두 가지 중요한 차이점이 있습니다.

• AWS: 예약 인스턴스(RI) 우선 적용, 그 다음 Savings Plan 적용

AWS는 엄격한 순서에 따라 할인을 적용합니다: RI를 먼저 적용하고, 그 다음 Savings Plan을 적용합니다. 실질적인 이점은 RI와 Savings Plan이 진정으로 서로를 보완한다는 점입니다. 플릿(fleet)의 안정적이고 구성이 확정된 핵심 부분에는 RI를 구매하십시오. 유연성이 필요한 나머지 부분에는 Savings Plan을 사용하십시오. 이 결합된 전략은 전체 컴퓨팅 환경(compute footprint)에서 거의 최대치에 가까운 절감 효과를 포착합니다.

Azure: 예약(Reservations) 우선 적용, 1년 플랜보다 3년 플랜 우선 적용

Azure도 Savings Plan보다 예약(Reservations)을 우선 적용하는 동일한 원칙을 따릅니다. 하지만 Azure에는 두 번째 규칙이 추가됩니다. 만약 3년 약정과 1년 약정의 Savings Plan이 동시에 활성화되어 있다면, 3년 약정(더 높은 할인율)이 먼저 적용됩니다. 이는 가치가 낮은 약정이 소진되기 전에 가장 가치 있는 약정으로부터의 혜택을 극대화하기 위함입니다.

Azure는 또한 매시간을 완전히 독립적으로 처리합니다. 만약 사용자가 $100의 대상 컴퓨팅(eligible compute)을 사용하고 약정 금액이 $80라면, Azure는 $80를 Savings Plan 요율로 책정하고 나머지 $20는 종량제(pay-as-you-go) 요율로 책정합니다. 만약 한 시간 동안 $60만 사용하고 $80를 약정했다면, 이 금액이 이월(roll over)되지 않는 한 $20만큼의 혜택을 잃게 됩니다.

약정 기간을 고민하고 있다면, 1년 약정과 3년 약정 사이의 트레이드오프(tradeoffs)는 단순히 할인율 차이보다 더 깊은 내용을 담고 있습니다. 1년 약정과 3년 AWS 약정 사이의 선택 방법

약정 규모를 올바르게 산정하는 방법

Savings Plan이 순이익(net savings)을 창출할지 아니면 순낭비(net waste)를 초래할지를 결정하는 단 하나의 숫자는 바로 약정 금액(commitment amount)입니다.

최근 30~60일간의 시간당 컴퓨팅 지출 데이터를 추출하세요. AWS Cost Explorer에서는 EC2/Lambda/Fargate로 필터링하고 시간 단위(hourly granularity)로 내보내기(export) 하십시오. Azure Cost Management에서는 VM 컴퓨팅 지출을 일 단위(daily granularity)로 내보낸 뒤, 이를 24로 나누어 시간 단위의 대리 값(proxy)으로 사용하십시오.

시간당 지출액의 P70을 찾으십시오. 모든 시간당 값을 낮은 순에서 높은 순으로 정렬한 뒤, 70번째 백분위수(70th percentile)에 해당하는 값을 찾습니다. 초기 약정 금액을 이 숫자 또는 이보다 약간 낮은 수준으로 설정하십시오.

AWS나 Azure의 권장 사항을 그대로 사용하지 마십시오. 두 플랫폼 모두 Savings Plan 권장 사항을 제공합니다. 하지만 이들은 과도한 약정(over-commitment)을 피하는 것이 아니라, 커버리지(coverage)를 최적화하도록 설계되어 있습니다. 플랫폼의 권장 사항은 종종 여러분이 계산한 P70보다 더 높은 약정 금액을 제안할 것입니다. 여러분 자신의 계산을 믿으십시오.

보수적으로 시작한 다음, 단계적으로 늘려가십시오. 첫 구매 시에는 P65–P70 수준으로 약정하십시오. 30일 후에 사용률 (utilization)을 검토하십시오. 사용률이 지속적으로 95%를 상회한다면, 그 위에 두 번째 약정을 추가하십시오. Savings Plans는 중첩(stack)이 가능하므로, 첫 번째 약정을 수정하거나 취소하지 않고도 추가 약정을 층층이 쌓을 수 있습니다.

Usage.ai의 역할

위의 모든 단계는 현재 여러분의 팀이 수동으로 수행해야 하는 작업들입니다. 데이터를 추출하고, P70을 계산하고, 권장 사항을 검증하고, 구매를 제출하고, 사용률을 모니터링하고, 사용량이 감소할 때 대응하며, 만료 전에 갱신하는 과정 말입니다. 각 단계 자체는 복잡하지 않지만, 이들이 모이면 클라우드당 매달 8~16시간의 FinOps 작업 시간이 소요됩니다.

Usage.ai는 이 전체 프로세스를 자동화합니다. 이 플랫폼은 24시간 데이터 갱신 주기(Cost Explorer의 72시간 주기와 대조됨)를 통해 시간당 컴퓨팅 지출을 분석하고, 정확한 약정 수준을 계산하며, 승인된 매개변수 내에서 자동으로 구매를 진행합니다. 만약 워크로드 감소로 인해 약정 사용률이 낮아지면, Usage.ai는 크레딧(credits)이 아닌 실제 현금으로 캐시백(cashback)을 제공합니다.

수수료 모델은 실현된 절감액(realized savings)의 일정 비율로만 책정됩니다. Usage.ai가 절감액을 만들어내지 못한다면, 여러분은 비용을 지불하지 않습니다.

여러분의 팀은 현재 Savings Plan 규모 산정(sizing)을 어떻게 처리하고 계십니까? 수동 P70 계산, AWS/Azure의 기본 권장 사항, 혹은 다른 방법을 사용 중이신가요? 다른 분들은 효과적인 절충안을 찾았는지 궁금합니다.

전체 기술 분석 내용을 여기서 계속 읽어보세요 → How Compute Savings Plans Work (Step-by-Step)