AWS Database Savings Plans: DB 팀이 알아야 할 사항

AWS는 관리형 데이터베이스 서비스에 대해 비용을 최대 35%까지 절감할 수 있는 지출 기반 할인 모델인 Database Savings Plans를 통해 Savings Plans 포트폴리오를 확장했습니다. 이는 Savings Plans 모델이 Compute(컴퓨트) 영역을 넘어 확장된 첫 사례이며, DB 팀이 장기적인 데이터베이스 지출을 약정하는 방식을 변화시킵니다.

Usage.ai는 2026년 1월에 Database Savings Plans에 대한 네이티브 지원을 추가했습니다.

AWS Database Savings Plans란 무엇인가?

(Reserved Instances (RI, 예약 인스턴스)가 요구하는 것처럼) 특정 인스턴스 클래스, 엔진 또는 리전(Region)을 약정하는 대신, 1년 기간 동안 일정한 시간당 지출 금액을 약정합니다. AWS는 수동 작업 없이 매시간 약정된 금액까지 모든 적격 사용량에 대해 자동으로 할인을 적용합니다.

이 모델은 Compute Savings Plans가 작동하는 방식을 반영하지만, 처음으로 데이터베이스 계층에 적용되었습니다. 이는 프로비저닝된(Provisioned) 데이터베이스 사용량과 서버리스(Serverless) 데이터베이스 사용량을 모두 포함합니다.

약정 작동 방식

1년 동안 시간당 달러 금액을 약정합니다.
AWS는 매시간 가장 큰 가치를 제공하는 곳을 우선순위로 하여 적격 사용량에 할인을 적용합니다.
약정 금액을 초과하는 사용량은 표준 온디맨드(On-demand) 요율로 청구됩니다.
단일 플랜으로 한 리전의 RDS 인스턴스와 다른 리전의 Aurora 인스턴스를 모두 커버할 수 있으며, 별도의 RI가 필요하지 않습니다.

결제 옵션

Database Savings Plans는 No Upfront(선불 없음) 방식으로, 1년 기간 동안 월간 요금으로만 청구됩니다. Compute 및 EC2 Instance Savings Plans와는 구조적인 차이점으로, All Upfront(전액 선불) 또는 Partial Upfront(부분 선불) 옵션이 없습니다. AWS는 월간 요금을 미리 결제할 수 있는 별도의 "Advance Pay" 청구 기능을 제공하지만, 이는 Savings Plan 자체의 결제 옵션은 아닙니다.

어떤 AWS 서비스가 포함되나요?

Database Savings Plans는 다음의 관리형 데이터베이스 서비스에 적용됩니다:

Amazon Aurora: Gen 7+ 프로비저닝 인스턴스 (db.r7, db.r8g, db.m7 제품군), Aurora Serverless v2, Aurora DSQL
Amazon RDS: Gen 7+ 프로비저닝 인스턴스 (db.r7, db.r8g, db.m7 제품군)
Amazon DynamoDB: 온디맨드 처리량 (최대 18% 절감); 프로비저닝된 용량 (최대 12% 절감)
Amazon ElastiCache: Valkey 엔진만 해당 (Gen 7+ 프로비저닝 및 Serverless). 표준 Redis 및 Memcached는 여전히 예약 인스턴스 (Reserved Nodes)가 필요합니다.
Amazon DocumentDB: Gen 7+ 프로비저닝 인스턴스 및 DocumentDB Serverless
Amazon Neptune: Gen 7+ 프로비저닝 인스턴스 및 Neptune Serverless
Amazon Neptune Analytics: 2026년 3월 추가 예정
Amazon Keyspaces: 온디맨드 및 프로비저닝된 처리량
Amazon Timestream: InfluxDB 인스턴스 (LiveAnalytics는 포함되지 않음)
Amazon OpenSearch: Serverless 및 Gen 7+ 프로비저닝 인스턴스 (2026년 3월 확장 예정)
AWS DMS: Gen 7+ 복제 인스턴스 및 DMS Serverless

이전 세대 인스턴스 제품군 (db.m5, db.r5, db.r6g 등)은 대상이 아니며 여전히 예약 인스턴스 (Reserved Instances)가 필요합니다.

이 두 가지 약정 유형이 모든 관련 요소에서 어떻게 비교되는지 이해하고 싶다면, 여기에서 전체 의사결정 프레임워크를 다루었습니다 AWS Savings Plans vs Reserved Instance

Database Savings Plans가 예약 인스턴스 (Reserved Instances)와 다른 점

예약 인스턴스 (Reserved Instances)는 구매 시 정확한 인스턴스 클래스 (instance class), 데이터베이스 엔진 (database engine), 배포 유형 (deployment type), 그리고 AWS 리전 (AWS Region)을 지정해야 합니다. 할인이 적용되려면 이 네 가지 요소가 실행 중인 워크로드와 모두 일치해야 합니다. 이 중 하나라도 변경하면 예약 인스턴스 (RI)는 더 이상 적용되지 않습니다.

현대적인 데이터베이스 환경은 정기적으로 크기를 조정하거나, 인스턴스 세대를 업그레이드하거나, 엔진을 마이그레이션하거나, 단일 가용 영역 (Single-AZ)에서 다중 가용 영역 (Multi-AZ)으로 전환합니다. 각각은 일상적인 결정이지만, 각 결정은 예약 인스턴스 (RI)를 사용 불가능한 상태로 만들고 예상치 못한 비용 노출을 초래할 수 있습니다.

Database Savings Plans는 할인 혜택을 구성 (configuration)으로부터 분리합니다. 약정된 지출은 변경될 수 있는 특정 설정이 아니라 실제 사용량을 따릅니다.

몇 가지 주요 구조적 차이점은 다음과 같습니다:

유연성 (Flexibility): RI (Reserved Instances)는 구성 변경 시 깨지지만, Savings Plans는 일상적인 변경 사항 속에서도 지출액을 따라갑니다.
최대 할인율 (Max discount): RI는 3년 선납 (All Upfront) 시 최대 40% 이상을 제공하며, Database Savings Plans는 최대 35% (Serverless) 또는 최대 20% (Provisioned Gen 7+)를 제공합니다.
기간 (Term): RI는 1년 또는 3년을 지원하지만, Database Savings Plans는 1년만 지원합니다.
과금 순서 (Billing order): RI는 매 과금 시간마다 가장 먼저 적용되며, Savings Plans는 남은 적격 사용량에 대해 두 번째로 적용됩니다.
커버리지 자동화 (Coverage automation): RI는 구성과 정확히 일치해야 하지만, Savings Plans는 적격 지출 전반에 걸쳐 자동으로 적용됩니다.

DynamoDB의 경우, 동일한 워크로드에 대해 Database Savings Plans와 DynamoDB 예약 용량 (Reserved Capacity)을 결합하여 사용할 수 없다는 점에 유의해야 합니다.

재무적 영향은 무엇인가요?

배포 모델별 할인 범위:

Serverless (Aurora Serverless v2, Aurora DSQL, ElastiCache Serverless for Valkey, DocumentDB Serverless, Neptune Serverless, OpenSearch Serverless): 최대 35%
Provisioned Gen 7+ 인스턴스 (Aurora, RDS, ElastiCache Valkey, DocumentDB, Neptune, DMS, Timestream InfluxDB): 최대 20%
DynamoDB / Keyspaces 온디맨드 처리량 (On-demand throughput): 최대 18%
DynamoDB / Keyspaces 프로비저닝된 처리량 (Provisioned throughput): 최대 12%

표면적인 할인율을 넘어, 더 강력한 재무적 논거는 고립된 RI 비용 (Stranded RI cost)을 줄이는 것입니다. 인스턴스 크기가 조정되거나 업그레이드되어 RI가 고립되면, 새로운 구성에 대한 온디맨드 요금을 지불하면서 동시에 기존 RI에 대한 비용도 계속 지불하게 됩니다. 변경이 빈번한 대규모 데이터베이스 환경의 경우, 고립된 RI로 인한 낭비를 방지함으로써 얻는 이득이 두 약정 모델 간의 작은 할인율 차이와 같거나 더 클 수 있습니다.

현재 RI를 사용 중이라면 무엇이 바뀌나요?

기존 RI는 별도의 조치 없이도 남은 기간 동안 중단 없이 정상적으로 계속 작동합니다.

결정적인 시점은 갱신(renewal) 때 찾아옵니다. 팀은 데이터베이스의 크기 조정(resize), 용량 모드(capacity modes) 변경, 또는 배포 모델(deployment models)의 전환이 얼마나 자주 발생하는지 평가해야 합니다. 만약 이러한 변화가 빈번하다면, 지출 기반 약정(spend-based commitment)의 유연성이 RI와 비교했을 때 발생하는 약간의 할인 차이보다 더 큰 가치를 제공할 가능성이 높습니다.

Usage.ai가 RI 및 Savings Plan 최적화를 자동화하는 방식에 대한 전체 상세 내용은 How Usage.ai Works: RIs, SPs & Zero-Risk Savings를 참조하십시오.

시작하기: 실무적인 순서

현재 데이터베이스 인벤토리 감사(Audit): AWS 서비스 유형, 인스턴스 패밀리 및 세대(generation), 엔진, 배포 모델, 리전(Region), 그리고 현재 커버리지(coverage) 상태에 따라 모든 관리형 데이터베이스 서비스를 카탈로그화합니다.
대상 워크로드 식별: RDS 및 Aurora는 Gen 7 이상이 필요합니다. ElastiCache는 Valkey가 필요합니다. DynamoDB, Neptune, DocumentDB, Keyspaces, Timestream 및 DMS는 폭넓게 적용 가능합니다. 대상이 아닌 워크로드는 RI 또는 온디맨드(on-demand) 상태를 유지합니다.
소비 패턴 분석: 안정성을 이해하고 합리적인 약정 수준을 설정하기 위해 최소 90일 동안의 시간당 지출 데이터를 검토합니다. Usage.ai는 귀하의 AWS 비용 및 사용 보고서(Cost and Usage Report) 데이터를 사용하여 이 과정을 자동화합니다.
약정 옵션 모델링: 다양한 약정 수준에서 예상 커버리지 비율, 예상 절감액 및 재무적 리스크를 평가합니다. 수동 스프레드시트 모델링은 소규모 환경에서는 작동하지만, 규모가 커지면 빠르게 한계에 부딪힙니다.
구매 및 모니터링: AWS 콘솔 또는 API를 통해 구매합니다. 커버리지 수준을 정기적으로 모니터링하십시오. Usage.ai는 이를 지속적으로 추적하며, 공백이 비용 문제로 이어지기 전에 조정 권장 사항을 제시합니다.

예약 인스턴스(Reserved Instances)는 향후 1~3년 동안 어떤 엔진을 사용하여, 어느 리전에서, 정확히 무엇을 실행할지를 예측해야 했습니다. 데이터베이스 Savings Plans는 이를 더 간단한 질문으로 대체합니다: "얼마나 지출할 예정인가요?"

대부분의 DB 팀은 그 질문에 자신 있게 답할 수 있습니다. 그리고 이제 지출 기반 약정 (spend-based commitments)이 전체 관리형 데이터베이스 스택을 커버함에 따라, 인스턴스별 약정을 추적하는 운영 오버헤드 (operational overhead)가 크게 줄어듭니다.

여러분의 팀은 현재 데이터베이스 약정 전략을 어떻게 다루고 계신가요? 예약 인스턴스 (RI)를 고수하고 계신가요, Savings Plans로 전환하고 계신가요, 아니면 혼합하여 사용하고 계신가요? 다른 분들은 이러한 전환에 대해 어떻게 생각하고 계시는지 듣고 싶습니다.

전체 심층 분석 내용을 여기서 확인하세요 → AWS Database Savings Plans Explained for DB Teams