효과적 절감률 (ESR): 커버리지(Coverage)와 사용률(Utilization)을 대체한 클라우드 절감 지표

RI(Reserved Instance) 커버리지는 85%인데 AWS 비용은 여전히 계속 상승하고 있습니까? ESR은 왜 커버리지 지표가 당신을 속이는지, 실제로 진실을 말해주는 수치를 어떻게 계산하는지, 그리고 그 수치를 얻은 후 무엇을 해야 하는지를 설명합니다.

효과적 절감률 (ESR)이란 무엇인가?

효과적 절감률 (Effective Savings Rate, ESR)은 클라우드 할인 도구의 실제 ROI(투자 대비 수익)를 측정하는 FinOps KPI (Key Performance Indicator)입니다. 2019년 ProsperOps의 공동 창립자인 Erik Carlin에 의해 도입되었으며, 현재는 Rate Optimization (요율 최적화) 역량 하의 FinOps Foundation 표준이며, AWS는 이를 Cost and Usage Dashboard (비용 및 사용 대시보드)의 Summary Billing (요약 빌링) 탭에 기본적으로 내장했습니다.

ESR이 도입되기 전, FinOps 팀은 두 가지 대리 지표(proxy metrics)를 추적했습니다:

커버리지 (Coverage): 리소스의 몇 퍼센트에 할인이 적용되었는가? 이것이 실제로 돈을 아껴주고 있는지에 대해서는 아무것도 말해주지 않습니다.
사용률 (Utilization): 구매한 약정(commitment)의 몇 퍼센트가 소비되고 있는가? 이것이 적절한 양이나 유형을 구매했는지에 대해서는 아무것도 말해주지 않습니다.

ESR은 진짜 질문에 답합니다: 커버리지, 사용률, 그리고 할인율을 동시에 고려했을 때, 전체 적격 클라우드 지출(eligible cloud spend)에 대해 당신이 받고 있는 순 할인율(net percentage discount)은 얼마인가?

공식

두 가지 동등한 형태가 있습니다:

형태 1 (나눗셈):

ESR = 1 – (실제 지출 / 온디맨드 환산 지출)

형태 2 (절감액):

ESR = 생성된 클라우드 절감액 / 온디맨드 환산 지출

각 용어의 의미:

온디맨드 환산 (On-Demand Equivalent, ODE) 지출: 할인이 전혀 없는 상태에서 정확히 동일한 워크로드를 전체 온디맨드 가격으로 실행했을 때의 이론적 비용입니다. 분모에 해당하며, 실제 리소스 사용량이 변할 때만 변경됩니다.
할인을 포함한 실제 지출 (Actual Spend Including Discounts): 상각된(amortized) 선불 RI 비용을 포함하여 모든 할인 도구가 적용된 후 실제로 지불한 금액입니다.
생성된 클라우드 절감액 (Cloud Savings Generated): ODE에서 실제 지출을 뺀 값입니다.

100만 달러의 ODE와 70만 달러의 실제 지출 = 30만 달러의 절감액 = 30% ESR입니다.

ESR은 곱셈적(multiplicative)입니다. 커버리지 (Coverage), 사용률 (Utilization), 또는 할인율 (Discount rate)을 개선하면 모두 ESR이 변동하지만, 이들은 서로 상호작용합니다. 90%의 커버리지, 70%의 사용률, 30%의 할인율을 가진 경우보다 70%의 커버리지, 95%의 사용률, 40%의 할인율을 가진 경우가 더 높은 성과를 낼 수 있습니다. ESR은 이 세 가지 요소의 순결과(net outcome)를 포착합니다.

AWS CUR에서 ESR을 계산하는 방법

AWS Cost and Usage Report (CUR)가 가장 적합한 데이터 소스입니다. 기본 대시보드는 근사치를 제공하지만, CUR은 정확한 수치를 제공합니다.

전제 조건:

리소스 수준의 세분화(granularity)로 CUR이 활성화되어 있어야 함
보고서에 상각 비용 (Amortized costs)이 포함되어 있어야 함
약정 적용 대상 서비스로 필터링되어 있어야 함: EC2, Fargate, Lambda, RDS, ElastiCache, Redshift, OpenSearch

1단계: 대상 서비스의 lineItem/NetAmortizedCost 합계 → 실제 지출 (Actual Spend)

2단계: 동일한 line item의 pricing/publicOnDemandCost 합계 → ODE 지출 (ODE Spend)

3단계: ESR = 1 – (Net Amortized Cost / Public On-Demand Cost)
/* CUR Athena 테이블을 대상으로 실행하세요 */

SELECT
bill_billing_period_start_date AS billing_period,
SUM(line_item_net_amortized_cost) AS actual_spend,
SUM(pricing_public_on_demand_cost) AS ode_spend,
ROUND(
(1 – SUM(line_item_net_amortized_cost) /
NULLIF(SUM(pricing_public_on_demand_cost), 0))

100, 2
) AS esr_percent
FROM your_cur_table
WHERE
line_item_product_code IN (
'AmazonEC2', 'AmazonRDS', 'AmazonElastiCache',
'AmazonRedshift', 'AWSLambda'
)
AND pricing_public_on_demand_cost > 0
GROUP BY 1
ORDER BY 1 DESC;

피해야 할 일반적인 오류:

순 상각 비용 (Net Amortized Cost) 대신 혼합 비용 (Blended Cost) 사용: 이는 조직 전체의 혼합 평균 요율을 사용하므로 실제 약정 할인 (Commitment Discounts)을 반영하지 못합니다.
데이터 전송 (Data Transfer), 지원 (Support), 또는 마켓플레이스 (Marketplace) 요금을 포함: 이들은 약정 적용이 가능한 온디맨드 (On-demand) 등가 항목이 없으므로 ESR을 낮추게 됩니다.
선불 RI (Reserved Instance) 비용 누락: lineItem/NetAmortizedCost는 상각 (Amortization)을 자동으로 처리하지만, 혼합 비용 (Unblended Cost)은 처리하지 않습니다.
단일 일자 결제 타이밍을 기준으로 계산: 일일 ESR이 급격하게 변동할 수 있으므로, 항상 전체 달력 월 (Calendar Month)을 기준으로 사용해야 합니다.

Azure 및 GCP를 위한 ESR

공식은 세 가지 클라우드 모두 동일합니다. 데이터 소스만 다릅니다.

Azure:

실제 지출 (Actual Spend): 사용 세부 정보 내보내기 (Usage detail export)의 CostInBillingCurrency
ODE 지출 (ODE Spend): 동일한 내보내기 데이터의 PayGPrice × Quantity
약정 유형 (Commitment types): Azure Reservations, Azure Savings Plans
네이티브 ESR 보기: Cost Management Rate Optimization 보기 (portal.azure.com에서 확인 필요)

GCP:

실제 지출 (Actual Spend): Cloud Billing BigQuery 내보내기의 cost 필드
ODE 지출 (ODE Spend): 동일한 내보내기 데이터의 on_demand_cost
약정 유형 (Commitment types): 약정 사용 할인 (Committed Use Discounts, CUDs)
네이티브 ESR 보기: 2025년 1분기 기준 없음, BigQuery에서 직접 계산해야 함

Azure와 GCP의 필드 이름은 주기적으로 변경됩니다. 계산 파이프라인을 구축하기 전에 공식 문서를 통해 반드시 확인하십시오.

업계 벤치마크: 실제 '좋은 상태'란 무엇인가

ProsperOps는 최적화 도구를 도입하기 전의 잠재 고객 계정에서 추출한 수백 개 조직의 연간 15억 달러 이상의 AWS 컴퓨팅 지출을 분석한 2024년 벤치마킹 보고서를 발표했습니다.

0% 중앙값 (Median) ESR: 모든 조직의 절반은 컴퓨팅에서 아무런 절감도 하지 못하고 있습니다.
23% 75 백분위수 (75th percentile): 활발하게 활동하는 FinOps 팀의 평균 이상 수치입니다.
46% 98 백분위수 (98th percentile): 세계 최고 수준입니다. 정교한 자동화가 필요합니다.
-9% 관측된 최솟값: 과도한 약정 (Overcommitment)으로 인해 온디맨드보다 비용이 더 많이 발생하는 경우입니다.

0% 중앙값이 가장 중요한 수치입니다. 연간 컴퓨팅 지출이 50만 달러인 경우, ESR을 0%에서 25%로 올리면 아키텍처를 변경하거나 라이트사이징 (Rightsizing)을 하지 않고도 연간 12만 5천 달러를 절감할 수 있습니다.

ESR 개선의 달러 영향: 연간 절감액 = 연간 컴퓨팅 ODE 지출액 × ESR 개선분. 연간 1,000만 달러 지출 시 5%포인트 개선 = 연간 50만 달러 절감.

높은 커버리지(Coverage)가 높은 ESR을 의미하지 않는 이유

이는 클라우드 비용 최적화(Cloud Cost Optimization)에서 가장 흔한 오해입니다. 팀들은 RI 커버리지 85%를 달성하고 분기별 검토(Quarterly Review)에서 이를 보고하지만, 정작 청구 금액은 여전히 상승한 것을 발견하곤 합니다.

월간 ODE 지출액이 모두 100만 달러인 두 환경을 비교해 보겠습니다:

환경 A: 커버리지 75%, 사용률(Utilization) 100%, 할인율 30% → 22.5만 달러 절감 → 22.5% ESR
환경 B: 커버리지 100%, 사용률 55%, 할인율 30% → 16.5만 달러 절감 → 16.5% ESR

환경 B가 더 높은 커버리지를 가집니다. 하지만 환경 A가 더 높은 ESR을 가집니다. 그 차이는 사용률(Utilization)에 있습니다. 환경 B는 100% 커버리지를 구매했지만 그중 55%만 소비했습니다. 남겨진(Stranded) 45%에 대해서도 비용이 청구되어 순 절감액을 감소시킵니다.

커버리지는 프로세스 지표(Process Metric)입니다. ESR은 결과 지표(Outcome Metric)입니다.

ESR이 낮은 6가지 이유

약정(Commitment)이 전혀 없음: AWS 조직의 53%가 Savings Plans나 Reserved Instances를 전혀 사용하지 않습니다. 이 경우 정의상 ESR은 0%입니다.
고비용 리소스에 대한 낮은 커버리지: 가장 크고 비싼 리소스들은 온디맨드(On-demand)로 실행되는 반면, 약정은 더 작은 워크로드에만 적용되는 경우입니다.
과도한 약정 및 낮은 사용률: 사용률이 70~80% 미만이면 남겨진 약정 시간(Stranded commitment hours)이 ESR을 마이너스 방향으로 끌어내립니다.
잘못된 인스턴스 패밀리(Instance Family) 또는 리전(Region): 표준 RI는 인스턴스 패밀리별로 지정됩니다. 워크로드가 m6i로 마이그레이션되었는데 m5 RI를 구매했다면, 커버리지는 0이지만 비용은 전액 청구됩니다.
최적화되지 않은 약정 유형: 3년 부분 선납(3-year Partial Upfront)을 선택했을 때 20%포인트 이상의 더 높은 할인율을 얻을 수 있음에도 1년 선납 없음(1-year No Upfront)을 선택하는 경우입니다. 커버리지는 존재하지만, 절감액은 발생하지 않습니다.
오래된 권장 사항: AWS Cost Explorer는 72시간 이상마다 갱신됩니다. 그 갱신 주기 내에서 발생하는 사용량 변화는 다음 갱신 전까지 권장 엔진(Recommendation Engine)에서 보이지 않는 커버리지 공백을 만듭니다.

ESR 개선 방법

커버리지 (Coverage)가 60% 미만인 경우: CUR (Cost and Usage Report)을 가격/공용 온디맨드 비용 (publicOnDemandCost) 기준으로 내림차순 정렬하십시오. 상위 20%의 리소스가 일반적으로 전체 ODE (On-Demand Expenditure)의 60~70%를 차지합니다. Compute Savings Plans부터 시작하십시오. 이는 리전, 패밀리(Family), 운영체제(OS)에 관계없이 EC2, Fargate, Lambda에 적용되며, 최대 가용 할인율의 66%를 제공하면서도 최대의 유연성을 가집니다.

사용률 (Utilization)이 80% 미만인 경우: 약정(Commitment)을 갱신하지 않고 만료시키거나, 전환형 RI (Convertible RIs)를 실제로 실행 중인 인스턴스 유형으로 교환하거나, AWS RI Marketplace에서 표준 RI (Standard RIs)를 판매하십시오. Savings Plans의 경우 교환이 불가능하므로, 만료될 때까지 낭비를 감수하거나 캐시백 플랫폼을 통해 가치를 회수해야 합니다.

할인율 (Discount Rate)이 25% 미만인 경우: AWS EC2 Compute Savings Plans는 1년 약정 선납 없음 (No Upfront) 기준 약 40%의 절감액을 제공하며, 3년 약정 전액 선납 (All Upfront) 기준 최대 66%를 제공합니다. 안정적인 워크로드의 경우, 1년 약정 선납 없음에서 3년 약정 일부 선납 (Partial Upfront)으로 전환하면 효과 절감률 (ESR)을 직접적으로 15~25%포인트 높일 수 있습니다.

권장 사항 (Recommendations) 갱신이 느린 경우: 동적인 워크로드의 경우, AWS Cost Explorer의 72시간 이상의 지연은 측정 가능하며 반복적으로 발생하는 ESR 저해 요인입니다. 데이터 루프 (Data loop)가 빨라질수록 사용량이 실제로 변하는 시점에 더 가깝게 커버리지 조정을 수행할 수 있습니다.

추적 주기: ESR은 일 단위가 아닌 월 단위로 측정되는 후행 지표 (Lagging indicator)입니다. 세 가지 수준에서 추적하십시오: 전체 ESR, 서비스 그룹별 ESR (RDS와 EC2/Fargate 분리), 그리고 멀티 계정 조직 내 계정별 ESR입니다. 10개 계정의 평균이 28%라면, 9개 계정의 평균이 32%이더라도 -5%인 한 계정이 전체 평균을 깎아내리고 있을 수 있습니다.

300개 이상의 기업 고객인 Usage.ai 사용자들은 이 격차를 해소했습니다. Motive는 연간 클라우드 지출을 520만 달러 절감했습니다. EVGo (NASDAQ: EVGO)는 연간 230만 달러를 절약했습니다. Secureframe은 48만 달러를 절약하여 이를 제품 성장에 직접 재투자했습니다.

ESR이 측정할 수 없는 것

약정 리스크 (Commitment risk): ESR은 절감 성과를 보여줄 뿐, 사용량이 감소할 때 해당 절감액이 보호되는지 여부는 보여주지 않습니다. 벤치마크 데이터에서 나타난 -9%의 최솟값은 공격적으로 약정(Commitment)을 체결한 후 사용량이 감소한 실제 기업들로부터 나온 결과입니다. ESR은 발생한 일을 기록했을 뿐, 이를 방지할 수는 없었습니다.

캐시백 (Cashback) 대 크레딧 (Credits): 일부 플랫폼은 사용되지 않은 약정분에 대해 어디서든 사용할 수 있는 실제 현금 형태의 캐시백으로 보상하는 반면, 다른 플랫폼은 동일한 클라우드에서의 향후 지출에만 사용할 수 있는 벤더 종속적(Vendor-locked)인 크레딧으로 보상합니다. ESR은 이 둘을 동일하게 취급합니다.

탈퇴 비용 노출 (Exit cost exposure): ESR은 도구가 실행되는 동안의 지속적인 절감률을 측정합니다. 중단 시 발생하는 재무적 의무는 측정하지 않습니다. 일부 플랫폼은 고객이 약정 기간이 만료되기 전에 탈퇴할 경우, 실현되지 않은 미래 절감액에 대해 수수료 의무를 발생시키는 계약 조건을 포함합니다. 이는 ESR에서는 완전히 보이지 않습니다.

ESR 이후의 단계: 보장된 약정률 (ICR)

Usage.ai에서 소개한 보장된 약정률 (Insured Commitment Rate, ICR)은 분자에 사용되지 않은 약정에서 회수된 캐시백을 추가함으로써 ESR을 확장합니다:

ICR = (클라우드 절감액 + 회수된 캐시백) / ODE 지출

캐시백은 가산되는 요소이므로 ICR은 항상 ESR보다 크거나 같습니다 (ICR ≥ ESR). 모든 약정이 완전히 사용될 때 ICR은 ESR과 같습니다. 사용량이 감소하고 캐시백이 적용되면, ICR은 회수된 값만큼 정확히 ESR을 초과하게 됩니다.

ESR은 음수가 될 수 있습니다. 하지만 ICR은 결코 음수가 될 수 없습니다. 사용되지 않은 모든 약정은 손실로 흡수되는 대신 실제 현금 캐시백으로 상쇄되기 때문입니다.

계산 예시를 포함한 전체 비교는 ESR vs ICR: 음수가 되지 않는 절감 지표 (ESR vs ICR: The Savings Metric That Does Not Go Negative)에서 확인하십시오.

ESR부터 시작하십시오. 여러분의 수치를 파악하십시오. 그런 다음, 여러분이 구축한 절감액이 서류상에 보이는 것만큼 내구성이 있는지 질문해 보십시오.

여러분의 현재 ESR은 얼마이며, 6가지 근본 원인 중 어떤 것을 가장 자주 겪으셨나요?

전체 운영 세부 분석 내용을 여기서 확인하세요 → 효과적 절감률 (ESR): 클라우드 절감 ROI를 계산하고 개선하기 위한 완벽한 FinOps 가이드