Saving Plans 완전 정복: 기본 개념 이해하기

AWS에서 비용을 줄이고 싶을 때 가장 먼저 떠오르는 건 Reserved Instance입니다. 하지만 인스턴스 타입, 리전, OS, 테넌시까지 조건이 맞아야 한다는 전제는 실제로 실무에서 상당한 제약이 되곤 합니다.

Savings Plans는 그런 구조적 불편함을 크게 덜어낸 ‘유연한 약정 모델’입니다. ‘무엇을 쓸지’가 아니라 ‘얼마어치를 쓸지’를 약속함으로써 다양한 서비스에 자동으로 할인을 적용해주는 방식이죠.

Savings Plans란 무엇인가

RI와의 차이점 요약

Savings Plans는 AWS에서 제공하는 사용량 기반 할인 모델로, 기존 Reserved Instance(RI)보다 훨씬 유연한 구조를 가지고 있습니다. 많은 분들이 RI와 SP를 단순히 같은 ‘정액제 할인 수단’으로 생각하시곤 합니다. 하지만 Savings Plans는 구조적으로 RI와 뚜렷한 차이가 있습니다.

우선, RI는 “특정 인스턴스를 특정 조건으로 계속 쓰겠다”는 약속에 기반합니다. 예를 들어 특정 리전, 특정 인스턴스 타입, 운영체제, 테넌시까지 고정해야만 할인 적용이 됩니다. 반면, SP는 “시간당 일정 금액을 AWS에서 사용하겠다”는 금액 약정 방식입니다.

즉, RI는 ‘무엇을 쓸지’에 대한 약정이고, SP는 ‘얼마어치를 쓸지’에 대한 약정입니다. Savings Plans는 고객이 AWS에 “1시간에 $20어치는 무조건 쓸 예정입니다”처럼 약정하면, 그 금액 한도 내에서 EC2, Lambda, Fargate 등 다양한 컴퓨팅 서비스에 자동으로 할인 요금을 적용해줍니다.

그 외 초과 사용분은 기존 온디맨드 요금이 그대로 적용됩니다.

Savings Plans는 이렇게 할인 적용이 “금액 기준”으로 이뤄지기 때문에, 인스턴스 타입이 바뀌거나, 리전을 이동하거나, 운영체제를 변경하더라도 조건만 맞으면 자동으로 적용되며, RI보다 훨씬 유연하게 운영할 수 있습니다.

Compute SP vs EC2 Instance SP

Savings Plans는 적용 범위에 따라 두 가지로 나뉩니다. 하나는 Compute Savings Plans, 또 하나는 EC2 Instance Savings Plans입니다.

Compute Savings Plans

Compute Savings Plans는 AWS에서 제공하는 가장 유연한 할인 모델로, EC2, Fargate, Lambda와 같은 AWS의 다양한 컴퓨팅 서비스에 할인 혜택을 제공합니다. 리전, 인스턴스 타입, 운영체제, 테넌시 등과 같은 조건에 상관없이 약정 금액만 충족하면 자동으로 할인이 적용되며, 별도의 서비스나 인프라 변경 없이도 자유롭게 사용할 수 있다는 점이 큰 장점입니다

예를 들어 서울 리전에서 EC2를 쓰다가 나중에 미국 리전으로 옮기더라도, 또는 m5 인스턴스를 쓰다가 c6i로 바꾸더라도 할인 적용은 그대로 유지됩니다. 그래서 이 플랜은 서비스 구조가 자주 바뀌거나 EC2 외의 워크로드를 함께 사용하는 조직에서 매우 유용하게 사용됩니다.

다만 Compute SP는 유연성 덕분에 할인률이 RI보다는 조금 낮습니다. 그래도 온디맨드 대비 최대 66% 수준까지 절감이 가능한 매우 강력한 옵션입니다.

EC2 Instance Savings Plans

EC2 Instance Savings Plans는 특정 인스턴스 패밀리(m5, c6i 등)와 특정 리전에만 적용되는 할인 모델로, Compute SP보다 높은 할인률(최대 72%)을 제공합니다. 이 모델은 EC2에만 적용되며, 지정된 패밀리와 리전 내에서 인스턴스 크기, 운영체제, 테넌시(기본, 전용)에는 유연하게 적용됩니다.

따라서, 예를 들어 서울 리전의 c6i 계열 인스턴스에 대해 약정을 걸었다면, 같은 리전 내에서 c6i.large, c6i.xlarge 등 다양한 크기의 인스턴스에서 할인 혜택을 받을 수 있지만, 다른 패밀리나 다른 리전의 인스턴스에는 적용되지 않습니다. 구조가 고정적인 환경에서는 높은 할인률을 통해 비용을 절감할 수 있지만, 인프라가 유동적으로 변경되는 환경에서는 제약이 될 수 있는 모델입니다.

유지되는 인프라가 명확하고, 구조가 자주 바뀌지 않는 경우에는 오히려 EC2 Instance SP가 더 나은 선택이 될 수 있습니다.

아래는 Compute SP vs EC2 Instance SP의 핵심 비교 내용입니다.

적용 대상 및 유연성 차이

Compute Savings Plans는 EC2, Lambda, Fargate를 포함한 다양한 컴퓨팅 서비스에 적용되며, 인스턴스 타입, 운영체제, 리전, 테넌시의 제한이 없습니다. 즉, 어떤 리전에서 어떤 인스턴스 타입을 사용하든, 어떤 OS를 선택하든 관계없이 약정한 시간당 금액 내에서 자동으로 할인이 적용됩니다.

반면, EC2 Instance Savings Plans는 EC2 서비스에만 적용되며, 특정 인스턴스 패밀리(예: m5, c6i)와 리전을 지정해야 합니다. 다만 지정된 조건 내에서는 인스턴스 크기, OS, 테넌시는 자유롭게 변경이 가능합니다.

할인률 및 제한 조건 차이

Compute Savings Plans는 유연성을 제공하는 대신 할인률이 최대 66% 수준으로 상대적으로 낮습니다.

EC2 Instance Savings Plans는 적용 범위가 제한적인 대신, 최대 72%까지 높은 할인률을 제공합니다.

사용 사례별 선택 전략

Compute SP는 리전, 인스턴스 타입, 서비스(EC2/Fargate/Lambda) 변경이 잦은 환경이나, 클라우드 인프라를 처음 도입하는 조직, 또는 마이크로서비스/서버리스 등 다양한 워크로드가 혼합된 환경에 적합합니다.

EC2 Instance SP는 특정 리전과 인스턴스 패밀리가 고정되어 있으며, 장기적으로 변동이 적은 워크로드(예: 안정적인 웹서버, 고정된 데이터베이스)에서 더욱 효과적입니다.

EC2 → Lambda/Fargate 워크로드 변화 시의 적용 여부

Compute SP는 EC2, Lambda, Fargate 간 워크로드 이동에도 그대로 적용됩니다. 즉, EC2에서 Lambda로, 또는 EC2에서 Fargate로 아키텍처를 변경하더라도 약정 금액 내에서 자동으로 할인이 유지됩니다.

반면 EC2 Instance SP는 EC2 서비스에만 한정되므로, Lambda나 Fargate로 전환할 경우 할인 혜택을 받을 수 없습니다.

정리하면,

Savings Plans는 RI처럼 세부 조건(인스턴스 타입, 리전, OS 등)을 일일이 고정하지 않아도 되기 때문에, 인프라 구조가 바뀌더라도 지속적으로 할인 혜택을 유지할 수 있는 모델입니다. Compute SP는 유연성을 최우선으로, EC2 Instance SP는 조금 더 제한적이지만 높은 할인률을 원하는 경우에 적합합니다.

할인 대상과 적용 우선순위

Savings Plans를 구매하셨다고 해서, 모든 AWS 리소스에 무조건 적용되는 것은 아닙니다. 할인 혜택은 적용 가능한 서비스에 대해, 일정한 우선순위에 따라 자동으로 부여됩니다.

Savings Plans는 어디에 적용되나요?

Savings Plans는 컴퓨팅 기반 서비스에만 적용됩니다. 대표적으로 아래 세 가지 서비스가 포함됩니다.

1) Amazon EC2 (Elastic Compute Cloud)

대부분의 워크로드에서 가장 널리 사용되는 가상 서버 서비스입니다.

Savings Plans는 EC2의 온디맨드 인스턴스 요금에 대해 자동으로 할인율을 적용합니다.

2) AWS Fargate

컨테이너 기반 워크로드를 실행할 수 있는 서버리스 컴퓨팅 플랫폼입니다.

Fargate를 사용하면 EC2 인스턴스를 따로 구성하지 않아도 되며, Savings Plans는 이 Fargate 사용 시간에도 동일하게 할인 혜택을 제공합니다.

3) AWS Lambda

이벤트 기반으로 코드를 실행하는 서버리스 서비스입니다.

함수 실행 시간과 메모리 사용량에 따라 과금되는 구조인데, 이 비용 역시 Savings Plans의 커버 대상입니다.

즉, Compute Savings Plans를 도입하시면 EC2, Fargate, Lambda에서 발생하는 컴퓨팅 비용에 대해 자동으로 가장 먼저 할인 요율이 적용됩니다.

적용 우선순위는 어떻게 되나요?

Savings Plans가 적용되는 순서는 다음과 같습니다.

AWS는 내부적으로 다음과 같은 방식으로 할인 적용을 계산합니다.

같은 시간대에 실행 중인 리소스 중에서

Savings Plans 약정 금액이 커버 가능한 범위 내에서

높은 할인율이 적용되는 리소스부터 순차적으로 할인 적용

즉, 할인은 무조건 순서대로 “사용한 만큼” 깎아주는 것이 아니라, “가장 높은 할인 효과를 낼 수 있는 리소스”부터 우선 적용됩니다. 예를 들어, 같은 시간에 EC2와 Lambda가 동시에 동작 중이라면, Compute SP는 EC2에 먼저 할인을 적용한 후, 남은 금액이 있을 경우 Lambda에 적용하는 식으로 계산됩니다.

이렇게 우선순위를 적용하는 이유는 고객이 약정한 시간당 금액을 최대한 효율적으로 소진시키고, 할인 효과를 극대화하기 위함입니다.

동일한 약정 금액으로 커버 가능한 범위는 어느 정도일까요?

Savings Plans는 “시간당 약정 금액” 기준으로 할인 혜택이 정해집니다.

예를 들어 시간당 $10을 약정했다면, 해당 시점의 총 EC2/Fargate/Lambda 사용량 중 $10 어치까지는

할인된 요금이 적용되며, 초과분에 대해서만 온디맨드 요금이 붙게 됩니다.

즉, 커버 범위는 다음의 조합에 따라 달라집니다.

구매한 Savings Plans의 약정 금액 (예: $5/hr, $20/hr 등)

실제로 동시에 발생하는 컴퓨팅 리소스 사용량

해당 리소스에 적용 가능한 할인률

예를 들어 m5.large EC2 인스턴스 여러 대가 항상 떠 있는 환경이라면, 그 인스턴스들의 시간당 온디맨드 비용이 약 $0.12씩 발생하므로, Savings Plans 약정 $5/hr만으로도 상당히 많은 인스턴스를 커버할 수 있습니다.

반면, 워크로드에 따라 사용량이 유동적인 Lambda나 Auto Scaling이 자주 일어나는 Fargate 환경이라면, 남는 시간도 있고, 모자라는 시간도 있을 수 있습니다. 따라서 Savings Plans는 가능하면 평균 사용량 기준으로 보수적으로 시작하고, 이후 점진적으로 확대하는 전략이 좋습니다.

SP 약정 방식과 전략

“시간당 USD 약정”의 구조

Savings Plans는 기본적으로 “시간당 몇 달러($)를 쓰겠다”는 약정을 의미합니다. 이 방식은 기존의 Reserved Instance처럼 “인스턴스 수량”을 기준으로 할인하는 방식과 다르며, 시간 단위로 전체 컴퓨팅 지출을 총액 기준으로 묶는 방식입니다.

즉, 어떤 서비스를 얼마나 쓰든, 사용 금액이 시간당 약정 범위를 넘지 않으면 항상 할인을 받을 수 있다는 뜻입니다.

실무에서 유용한 포인트

시간 단위 약정이므로, 하루 중 트래픽이 몰리는 구간만 커버할 수는 없습니다. 항상 1시간 단위의 최소 사용량을 기준으로 약정해야 합니다.

약정은 기본적으로 1년 또는 3년 기간으로 진행되며, No Upfront / Partial Upfront / All Upfront 결제 방식에 따라 할인률이 달라지게 됩니다.

Compute SP의 유연성: 리전, OS, 인스턴스까지 자유롭게

Savings Plans 중에서도 Compute Savings Plans는 RI나 EC2 Instance SP에 비해 압도적인 유연성을 자랑합니다.

1) 리전 유연성

기존 RI는 구매 시 특정 리전을 고정해야 했습니다. 서울(ap-northeast-2)에서 구매한 RI는 오레곤(us-west-2)에서는 사용할 수 없었습니다. 하지만 Compute SP는 리전을 이동해도 그대로 적용됩니다.

즉, 글로벌한 환경에서 인프라를 운영하시거나, 향후 마이그레이션이나 리전 간 이전이 예상되는 경우 Compute SP는 매우 유리한 선택이 됩니다.

2) 운영체제와 테넌시 무관

Windows, RHEL, Ubuntu 등 어떤 OS를 쓰든, Default 테넌시든 Dedicated든 상관없이 Compute SP는 그대로 적용됩니다.

이 덕분에 인스턴스 구조가 자주 바뀌거나, 다양한 OS/테넌시 조합을 사용하는 서비스에서도 별도 설정 없이 자동으로 할인 혜택을 받을 수 있습니다.

3) 인스턴스 타입도 자유롭게

RI나 EC2 SP는 특정 패밀리(m5, c6i 등)에만 할인 적용이 가능했지만, Compute SP는 어떤 인스턴스든 온디맨드 요금이 있는 EC2라면 대부분 커버됩니다. m5.large에서 c7g.medium으로 바꾸더라도 t4g에서 r6i로 확장하더라도 Compute SP는 금액 기준이기 때문에 자동으로 적용됩니다.

전략적으로 어떻게 접근해야 할까요?

Compute SP는 구조가 유동적인 스타트업, 리팩토링 중인 조직, 또는 여러 리전을 함께 사용하는 글로벌 팀에 매우 적합합니다. 반면 구조가 안정적이고, 특정 인스턴스를 3년 이상 고정으로 쓸 수 있다면 Compute SP보다 EC2 Instance SP나 Standard RI가 더 높은 할인 효과를 줄 수 있습니다.

SP 구매 시 고려사항

Savings Plans를 도입하실 때도 RI처럼 단순히 할인률만 보지 마시고, 조직의 예산 운영 방식과 미래 워크로드 계획을 함께 고려하시는 것이 중요합니다.

예산 책정 방식: 약정 금액은 어떻게 정해야 할까요?

다음과 같은 방식으로 예산을 책정하시는 것을 권장드립니다.

최근 3~6개월간의 평균 사용량 분석

AWS Cost Explorer에서 시간당 평균 사용 금액을 추출합니다.

특히 낮/밤, 평일/주말의 사용량 변화를 확인하는 것이 좋습니다.

최대가 아닌, ‘최소 확실 사용량’ 기준으로 약정

평균값보다는 ‘최소값’을 기준으로 약정을 설정하시는 것이 안전합니다.

예를 들어, 시간당 평균 사용이 $15이고, 최소 사용이 $11이라면 $11 수준으로 먼저 약정하고, 추후 상황을 보며 점진적으로 확대하시는 것이 좋습니다.

월 단위 예산과 연간 선결제 계획과 연계

AWS는 No Upfront, Partial Upfront, All Upfront 중 선택할 수 있기 때문에 조직의 연간 예산 집행 계획에 맞춰 결제 구조를 조정하실 수 있습니다.

예산이 넉넉하지 않은 초기에는 No Upfront부터 시작하는 것도 전략입니다.

SP 사용 중단이 필요한 경우의 전략

Savings Plans는 약정 기반 서비스이기 때문에, 도중에 사용을 멈추더라도 약정 금액은 계속 청구됩니다. 따라서 중간에 워크로드가 줄어들거나, 예상보다 서비스 사용량이 감소할 수 있는 경우에는 다음과 같은 대응 전략을 미리 준비해두시는 것이 좋습니다.

1) 워크로드 축소 시점 예측 + 약정 분산 구매 전략

Savings Plans는 한 번에 많이 사는 것보다 3개월에 걸쳐 분산 구매하는 방식이 더 유연합니다.

이렇게 하면 중간에 워크로드가 줄어들어도 남은 약정 비율을 조정하거나, 추가 구매를 멈추는 방식으로 대응할 수 있습니다.

2) SP 적용 대상을 유연하게 분산해두기

Compute SP는 EC2뿐 아니라 Lambda, Fargate에도 적용됩니다. 워크로드가 축소되더라도, 예를 들어 QA 환경, 자동화 백엔드, 크론 작업 등을 EC2 대신 Fargate나 Lambda로 전환하면서 SP 약정을 효율적으로 소진할 수 있습니다.

결론

AWS에서 요금을 줄이기 위한 전략은 어렵지 않습니다. 중요한 건 “내가 확실히 쓸 자원”을 파악하고, 그만큼만 약정을 걸어두는 것입니다.

Savings Plans는 그 실행의 장벽을 크게 낮춰줍니다. 리전도, OS도, 인스턴스도 고정할 필요 없이 내가 쓰는 서비스 전체를 한 금액으로 묶을 수 있습니다.

지금 바로 Cost Explorer로 지난 3개월 사용량을 확인해보세요. 그 중 최소값에 맞춰 Compute SP를 시작해보는 것 그것이 가장 빠르고 안전한 첫 번째 비용 절감 전략이 될 수 있습니다.