온디맨드(On-demand)로 실행되는 모든 RDS 데이터베이스는 대부분의 프로덕션 데이터베이스가 필요로 하지 않는 유연성에 대해 프리미엄 비용을 지불하고 있습니다. 예약 인스턴스(Reserved Instances, RI)는 일정 기간 사용하겠다는 약속을 대가로 가격 할인을 제공함으로써 이러한 프리미엄을 제거합니다. 특정 데이터베이스 유형을 1년 또는 3년 동안 실행하기로 동의하면 AWS는 그에 대해 33-69% 더 적은 비용을 청구합니다.

RDS RI를 최대한 활용하려면 콘솔에서 "RI 구매(Purchase RI)"를 클릭하는 것 이상의 노력이 필요합니다. 최대 절감액을 끌어내는 팀은 크기 유연성(Size flexibility) 메커니즘을 이해하고, 과도하게 큰 인스턴스를 예약하는 것을 피하며, 어떤 엔진이 유연성을 제공하고 어떤 엔진이 그렇지 않은지 파악하고, 사용률을 모니터링하여 사용량이 적은 예약 건을 조기에 발견합니다.

RDS 예약 인스턴스(Reserved Instance)의 실제 정의

RDS RI는 물리적 서버나 특정 데이터베이스 인스턴스가 아닙니다. 이는 실행 중인 데이터베이스의 속성이 예약 사항과 일치할 때 AWS가 자동으로 적용하는 비용 할인입니다.

구매 시 다음 사항을 지정합니다: 엔진(MySQL, PostgreSQL, MariaDB, Oracle, SQL Server, Aurora), 인스턴스 패밀리(Instance family), 배포 유형(Single-AZ 또는 Multi-AZ), 리전(Region), 기간(1년 또는 3년), 그리고 결제 옵션(선불 없음(No Upfront), 부분 선불(Partial Upfront), 전액 선불(All Upfront)). 그러면 AWS는 태깅, 할당, 구성 변경 없이 계정 내에서 일치하는 실행 중인 모든 데이터베이스에 예약 요율을 적용합니다.

핵심 메커니즘: RI는 리소스가 아니라 비용 청구 항목(Billing artifact)입니다. 데이터베이스에는 아무런 변화도 일어나지 않습니다. 만약 데이터베이스를 삭제하더라도 RI는 기간이 만료될 때까지 계속 비용을 청구합니다. 이것이 올바른 RI를 구매하는 것이 중요한 이유입니다. 아무것과도 일치하지 않는 사용되지 않는 RI는 순전한 낭비입니다.

RDS RI는 실제로 얼마나 절감할 수 있는가?

절감액은 엔진 및 인스턴스 패밀리에 따라 1년 선불 없음(No Upfront) 기준 약 33%에서 3년 전액 선불(All Upfront) 기준 최대 69%까지 다양합니다. US East 지역의 Graviton4 기반 검증된 MySQL 요율을 사용하면 다음과 같습니다 (Vantage.sh, 2026년 5월, AWS API 출처):

• db.r8g.large Single-AZ: 시간당 온디맨드(on-demand) $0.239 → 예약(reserved) $0.160. 연간 $692 절감.
• db.r8g.xlarge Single-AZ: 시간당 온디맨드(on-demand) $0.478 → 예약(reserved) $0.320. 연간 $1,384 절감.
• db.r8g.xlarge Multi-AZ: 시간당 온디맨드(on-demand) $0.956 → 예약(reserved) $0.640. 연간 $2,768 절감.

1년 약정 선결제 없음(No Upfront) 조건의 db.r8g.xlarge Single-AZ 인스턴스 10대 규모의 플릿(fleet)을 사용할 경우: 연간 $13,840를 절감할 수 있습니다. 요율은 변동될 수 있으므로 aws.amazon.com/rds/mysql/pricing에서 현재 요율을 확인하십시오.

가장 큰 절대적 절감액은 가장 크고 안정적인 인스턴스를 먼저 예약함으로써 얻을 수 있습니다. 절감 비율(percentage savings)이 아닌 월간 온디맨드(on-demand) 비용을 기준으로 우선순위를 정하십시오.

엔진별 전체 가격 상세 내역은 RDS 예약 인스턴스(Reserved Instances) 가격 가이드에서 모든 엔진과 결제 옵션을 자세히 다루고 있습니다.

RDS에 전환 가능 예약 인스턴스(Convertible Reserved Instances)가 있나요?

아니요, 그리고 이것은 EC2 RI 관리를 해온 팀들이 가장 흔하게 혼동하는 부분 중 하나입니다.

EC2는 표준(Standard) 및 전환 가능(Convertible) RI를 제공합니다. 반면 RDS는 표준(Standard) RI만 제공합니다. 전환 가능한 RDS 예약 인스턴스는 존재하지 않습니다. RDS가 제공하는 것은 크기 유연성(size flexibility)이며, 이는 완전히 다른 메커니즘입니다. 계약 기간 중간에 구성을 변경할 수 있는 유연성이 필요하다면, 1년 약정을 사용하거나 AWS 데이터베이스 절약 플랜(AWS Database Savings Plan)을 검토하십시오.

크기 유연성(Size Flexibility): 어떤 엔진이 지원하며 어떻게 작동하나요?

크기 유연성(size flexibility)을 사용하면 정규화 단위(normalization units)를 통해 동일한 패밀리 내의 여러 데이터베이스 크기를 단일 RI로 커버할 수 있습니다:

db.micro = 0.5 | db.small = 1 | db.medium = 2 | db.large = 4 | db.xlarge = 8 | db.2xlarge = 16 | db.4xlarge = 32

db.r8g.xlarge RI (8 단위)는 자동으로 2개의 db.r8g.large (각 4 단위) 또는 4개의 db.r8g.medium (각 2 단위), 또는 합계가 8 단위가 되는 모든 조합을 커버합니다. 또한 db.r8g.2xlarge의 50%를 커버하며, 나머지 50%는 온디맨드(on-demand) 요율로 청구됩니다.

크기 유연성을 지원하는 엔진: MySQL, MariaDB, PostgreSQL, Aurora, Oracle BYOL.

크기 유연성(size flexibility)을 지원하지 않는 엔진: Microsoft SQL Server (LI 또는 BYOL), Oracle License Included. 이 엔진들은 정확한 크기의 예약(exact-size reservations)이 필요합니다. 예를 들어, db.r8g.xlarge SQL Server RI는 오직 db.r8g.xlarge SQL Server만 커버하며 그 외의 것은 커버하지 않습니다.

이러한 차이점은 SQL Server 및 Oracle LI 팀에게 매우 중요합니다. 크기를 변경할 때마다 새로운 RI를 구매해야 합니다. 반면 MySQL, PostgreSQL, MariaDB의 경우, 크기 유연성 덕분에 인스턴스 크기를 줄이거나 분할한 후에도 커버리지 연속성을 유지할 수 있습니다.

6단계 구매 프로세스

1단계: 예약하기 전에 적정 크기(Right-Size)로 조정하기

과도하게 큰(oversized) 데이터베이스를 예약하면 1~3년 동안 낭비가 고착화됩니다. 사용률이 40%인 인스턴스에서 33% 할인을 받는 것은, 적정 크기로 80% 사용률을 보이는 인스턴스에서 동일한 할인을 받는 것보다 절감액이 적습니다.

RI를 구매하기 전에 30일간의 CloudWatch 분석을 실행하십시오. 다음 네 가지 지표가 중요합니다:

• CPUUtilization (CPU 사용률): P90이 40% 미만이면 컴퓨팅 자원이 과다 할당(over-provisioned)된 상태입니다.
• FreeableMemory (사용 가능한 메모리): 전체 RAM의 25% 이상이 지속적으로 여유가 있다면 메모리 자원이 과다 할당된 상태입니다.
• DatabaseConnections (데이터베이스 연결): 변경하려는 더 작은 크기의 max_connections 상한선과 비교하여 확인하십시오.
• BufferCacheHitRatio (버퍼 캐시 히트율): 99% 이상이면 워킹 셋(working set)이 현재 버퍼 풀에 적합하므로, RAM 크기를 줄여도 안전할 수 있습니다.

먼저 적정 크기로 조정해야 하는 경제적 이유는 다음과 같습니다: db.r8g.xlarge RI는 연간 $1,384를 절감합니다. db.r8g.large RI는 연간 $692를 절감할 뿐만 아니라, 기본 컴퓨팅 비용 자체가 연간 $692 더 저렴합니다. 예약 전에 크기를 적정하게 조정하면 해당 과다 할당된 인스턴스에 대한 실질적인 절감액이 두 배가 됩니다.

2단계: 구매 전 연장 지원(Extended Support) 상태 확인하기

대상 데이터베이스 중 MySQL 5.7 또는 PostgreSQL 11을 실행 중인 것이 있다면 중단하십시오. 이 버전들은 2026년 3월 1일부터 연장 지원(Extended Support) 3년 차에 접어듭니다 ($0.200/vCPU-hr 추가 요금 발생). 연장 지원 요금은 예약 인스턴스(RI)로 할인이 적용되지 않습니다.

db.r8g.xlarge MySQL 5.7 (4 vCPUs)의 경우: 연장 지원(Extended Support) 비용 = 4 × $0.200 × 730 = $584/월입니다. 예약 인스턴스(RI)를 통해 월 $115를 절약할 수 있습니다. 즉, 불필요하게 $584를 지불하면서 $115를 아끼고 있는 셈입니다. 먼저 MySQL 8.0 또는 8.4로 업그레이드하십시오. 엔진 업그레이드는 RI보다 5배 더 큰 절감 효과를 제공합니다.

3단계: 구매 전 배포 유형(Deployment Type) 감사

단일 가용 영역(Single-AZ) 및 다중 가용 영역(Multi-AZ) RI는 별도로 구매해야 하며, 각자의 유형에 맞는 인스턴스만 커버합니다. Multi-AZ 인스턴스에 Single-AZ RI를 적용하면 아무런 절감 효과가 없습니다.

먼저 인스턴스 환경을 감사하십시오:

aws rds describe-db-instances \
--query 'DBInstances[*\].[DBInstanceIdentifier,MultiAZ,DBInstanceClass]' \
--output table

이 과정에서 추가로 확인할 사항: 운영 환경이 아닌 데이터베이스가 잘못된 Multi-AZ로 실행되고 있는지 확인하십시오. 개발(Dev) 및 스테이징(Staging) 환경은 고가용성(HA)이 거의 필요하지 않습니다. 예약(Reservation)을 하기 전에 이들을 Single-AZ로 전환하면, RI 할인 외에도 Multi-AZ 프리미엄 비용을 추가로 절감할 수 있습니다.

Multi-AZ가 실제로 비용을 지불할 가치가 있는 시점에 대한 더 자세한 분석: RDS Multi-AZ vs Single-AZ: the cost of high availability.

4단계: 최대 유연성을 위해 가장 작은 정규화 단위(Normalization Unit)로 구매

크기 유연성(Size Flexibility)이 있는 엔진의 경우, 향후 필요할 수 있는 가장 작은 인스턴스 크기로 구매하면 동일한 총 약정 금액 내에서 가장 유연한 커버리지를 확보할 수 있습니다.

예시: r8g 커버리지를 위해 8개의 정규화 단위가 필요한 경우.

• 옵션 A: 1x db.r8g.xlarge RI
• 옵션 B: 2x db.r8g.large RIs

두 옵션의 총 비용은 동일합니다. 하지만 나중에 xlarge 하나를 large로 크기 조정(Right-sizing)할 경우, 옵션 B는 낭비 없이 두 개의 large 인스턴스를 계속 커버할 수 있습니다. 반면 옵션 A는 남는 단위가 발생하며 일부는 온디맨드(On-demand)로 과금됩니다.

주의사항: 이는 크기 유연성이 있는 엔진(MySQL, PostgreSQL, MariaDB, Aurora, Oracle BYOL)에만 적용됩니다. SQL Server 및 Oracle LI의 경우, 현재 실행 중인 크기와 정확히 일치하게 구매하십시오.

5단계: 상황에 맞는 결제 옵션 선택

• No Upfront (선불금 없음): 오늘 지불할 자본금이 0원입니다. 약 30-33%의 절감 효과가 있습니다. 1년 계약만 가능합니다. 처음으로 RI (Reserved Instance)를 구매하거나 워크로드(Workload)에 대한 확신이 낮은 경우에 가장 적합합니다.

• Partial Upfront (부분 선불): 적당한 금액의 일시불 결제와 함께 월간 요금이 감소합니다. 약 35-50%의 절감 효과가 있습니다. 1년 또는 3년 계약이 가능합니다. 대부분의 프로덕션 데이터베이스에 가장 적합합니다.

• All Upfront (전액 선불): 전체 계약 기간 비용을 구매 시점에 모두 지불합니다. 약 45-69%의 절감 효과가 있습니다. 가장 안정적이고 가장 오래 실행되는 프로덕션 데이터베이스에 가장 적합합니다.

실무 지침: 어떤 데이터베이스든 첫 RI 구매 시에는 1년 계약의 No Upfront 옵션으로 시작하십시오. 12개월 후에 사용률(Utilization)을 검토하십시오. 만약 RI가 완전히 사용되었고 데이터베이스가 동일한 구성으로 계속 실행 중이라면, 더 높은 할인율을 위해 Partial Upfront 또는 All Upfront로 갱신하십시오.

6단계: 매월 사용률을 모니터링하고 저사용 발생 시 조기에 조치하십시오

실행 중인 데이터베이스를 커버하는 RI는 비용 절감을 생성합니다. 하지만 매칭되는 데이터베이스가 삭제되었거나 크기가 조정된 RI는 낭비를 생성합니다. 매월 모니터링을 통해 이를 조기에 발견할 수 있습니다.

AWS Cost Explorer에서: Reservations > Utilization Report로 이동하여 Amazon RDS를 필터링하십시오. 잘 관리된 플릿(Fleet)이라면 전반적으로 90% 이상의 사용률을 보여야 합니다. 사용률이 80% 미만인 RI는 즉시 조사가 필요합니다.

CLI 명령어:
aws ce get-reservation-utilization
--time-period Start=[start],End=[end]
--granularity MONTHLY
--filter '{"Dimensions":{"Key":"SERVICE","Values":["Amazon Relational Database Service"]}}'

사용률이 낮은 RI를 발견했을 때: 해당 계정의 다른 곳에 매칭되는 인스턴스가 있는지 확인하십시오. 없다면, RI 만료 시까지 해당 RI를 소비할 수 있도록 동일한 속성을 가진 새 데이터베이스를 실행하는 것을 고려하십시오. Standard RI (RDS에서 제공하는 모든 RI)의 경우, RI가 만료될 때까지 다른 구성으로 교환할 수 없습니다.

올바른 작업 순서

대부분의 팀은 RI (Reserved Instances) 구매를 먼저 최적화한 다음, 나중에 비용이 많이 드는 근본적인 문제들을 해결합니다. 올바른 순서는 다음과 같습니다:

• 먼저 확장 지원 (Extended Support) 비용을 제거하세요. MySQL 5.7 또는 PostgreSQL 11이 확장 지원 3년 차에 해당하나요? 예약하기 전에 업그레이드하세요.
• 비운영 환경의 다중 AZ (Multi-AZ)를 단일 AZ (Single-AZ)로 전환하세요. 개발(Dev) 및 스테이징(Staging) 환경에는 고가용성 (HA)이 필요하지 않습니다. RI를 구매하기 전에 10개의 인스턴스를 전환하는 것만으로도 연간 $14,016를 절약할 수 있습니다.
• 30일간의 CloudWatch 데이터를 사용하여 적정 규모 산정 (Right-sizing)을 수행하세요. 약정(Commitment)을 하기 전에 과다 프로비저닝된 인스턴스의 규모를 줄이세요.
• 여전히 r7g 또는 그 이전 세대를 사용 중이라면 최신 Graviton 세대(r8g, m8g)로 마이그레이션하세요.
• 정돈되고 적정 규모로 조정된 플릿 (Fleet)에 대해 RI를 구매하세요. 지출이 가장 큰 인스턴스부터 1년 약정, 선결제 없음 (No Upfront) 방식으로 시작하세요.
• 매월 사용률을 모니터링하세요. 예약된 자원이 기간 만료 전에 사용량이 적은 것을 파악하세요.

Usage.ai Flex Reserved Instances는 확장 지원 (Extended Support) 노출을 드러내고, 비운영 환경의 다중 AZ (Multi-AZ)를 식별하며, 예약을 권장하기 전에 사용률을 평가하고, 승인된 매개변수 내에서 최적의 RI를 구매함으로써 이 전체 순서를 자동으로 실행합니다.

권장 사항은 Cost Explorer의 72시간 주기와 달리 24시간마다 갱신됩니다. 만약 예약된 인스턴스의 사용률이 낮아지면, Usage.ai는 실제 현금으로 캐시백을 제공합니다.

여러분의 RDS 플릿에서 RI 지출 낭비의 가장 큰 원인은 무엇이었나요? 사용률이 낮은 예약, 잘못된 배포 유형, 아니면 적정 규모 산정 전의 예약인가요?

전체 아키텍처 및 최적화 세부 분석 내용을 여기서 확인하세요 → How to Save on RDS Reserved Instances: A Quick Guide