6편 · 약 22분

클라우드 DB 비용 최적화: 인스턴스·스토리지·I/O 비용 관리

왜 클라우드 DB 비용은 예측하기 어려운가

클라우드 매니지드 DB는 사용한 만큼 청구되지만, 그 "사용"의 구성이 복잡하다. 인스턴스 요금만 보다가 스토리지 자동 확장, 예상 밖의 I/O 요금, 백업 스토리지, 데이터 전송 비용에 놀라는 경우가 많다. 비용 최적화는 이 각각의 구성 요소를 이해하는 것에서 시작한다.

비용 구성 요소 분해

인스턴스 비용

vCPU + 메모리
On-Demand / RI / SP

↓

RDS: 인스턴스 시간당
Aurora: ACU-시간 또는
인스턴스 시간당

스토리지 비용

GB-월 기준
gp2 / gp3 / io1 / io2

↓

gp3: 3,000 IOPS
기본 포함
추가 IOPS 별도 과금

I/O 비용

읽기·쓰기 요청 수
(Aurora Standard만)

↓

Aurora: $0.20/100만
I/O 요청
RDS: 스토리지 유형으로 제어

백업 스토리지

자동 백업 보존 기간
+ 수동 스냅샷

↓

DB 스토리지 크기
이내: 무료
초과분: GB-월 과금

데이터 전송

리전 간 / 인터넷
아웃바운드

↓

동일 리전 AZ 간:
대체로 무료
Cross-Region: GB당 과금

클라우드 DB 비용 구성 요소

RDS와 Aurora의 청구 방식 차이를 간과하면 Aurora가 예상보다 비싸지는 함정에 빠진다. Aurora Standard는 스토리지 비용이 낮지만 I/O 요청 건수에 따라 비용이 변동된다. 쓰기가 많은 OLTP 워크로드에서 I/O 비용이 전체 Aurora 청구의 25~40%를 차지하는 사례가 자주 보고된다.

인스턴스 비용 최적화

Reserved Instance vs Savings Plan

구분	Reserved Instance (RI)	Database Savings Plan
약정 대상	특정 인스턴스 패밀리, 리전, 엔진 고정	시간당 지출액 약정
유연성	낮음 (변경 시 마켓플레이스 매각 필요)	높음 (인스턴스 패밀리 간 자동 적용)
최대 절감	약 63% (3년 All Upfront)	약 35%
권장	안정적 프로덕션 DB	인스턴스 패밀리 변동 가능성 있을 때

라다링(laddering) 전략: 3년 RI를 한 번에 구매하지 말고, 1년 RI를 서로 다른 만료 시점으로 나눠서 구매한다. 예를 들어 r8g.xlarge 3대가 필요하면 1대씩 1개월 간격으로 RI를 구매하면 매년 갱신 시점이 분산된다. 워크로드가 축소되면 일부만 갱신하고 나머지를 스팟으로 대체할 수 있다.

인스턴스 사이즈 최적화 (Rightsizing)

AWS Compute Optimizer는 RDS/Aurora에 대해 메모리 용량 감소 없이 CPU 과잉 프로비저닝을 탐지하고 대안 인스턴스 유형을 추천한다. 다음 지표로 판단한다.

과잉 프로비저닝 신호:
- CPU 사용률 평균 < 20% (수일 이상 지속)
- FreeableMemory > 총 메모리의 50% 이상 지속
- DatabaseConnections < max_connections의 30%

공격적 최적화 금지 기준:
- 버퍼풀 히트율 < 99%: 메모리 부족 신호 → 다운사이징 금지
- IOPS가 스토리지 한계에 근접 중인 경우
- 예정된 트래픽 성수기 전

실사례: db.r8g.xlarge(4 vCPU, 32 GB) → db.r8g.large(2 vCPU, 16 GB) 전환으로 인스턴스 비용 약 50% 절감이 가능하지만, 버퍼풀 크기 감소가 쿼리 성능에 미치는 영향을 먼저 스테이징에서 검증해야 한다.

Aurora Serverless v2

트래픽 변동이 심하고 피크가 짧은 경우 Aurora Serverless v2를 고려한다. 0.5 ACU 단위로 자동 스케일링되며, 피크 외 시간대에 비용이 크게 줄어든다.

주의: I/O 비용은 Serverless v2에도 동일하게 적용된다. I/O-Optimized 모드는 Serverless v2와 함께 사용할 때 오히려 비용이 증가하는 경우가 있으므로 I/O 비율을 먼저 확인한다.

스토리지 비용 최적화

gp2 → gp3 전환

RDS의 기본 스토리지 유형이 gp2에서 gp3로 바뀐 지 오래지만, 레거시 인스턴스들이 여전히 gp2를 사용하는 경우가 많다.

항목	gp2	gp3
기본 IOPS	볼륨 크기에 비례 (3 IOPS/GB)	고정 3,000 IOPS (크기 무관)
추가 IOPS	볼륨 크기 증가로만 확보	독립 프로비저닝 가능
GB당 단가	$0.115/GB-월	$0.115/GB-월 (동일)
실질 절감	—	소규모 볼륨에서 IOPS 오버프로비저닝 방지

gp2에서 1TB 볼륨이면 3,000 IOPS가 자동 제공되지만, 100 GB 볼륨이면 300 IOPS밖에 얻지 못한다. 작은 볼륨에서 IOPS를 확보하기 위해 불필요하게 스토리지를 늘리고 있다면 gp3 전환 후 IOPS를 독립 프로비저닝하면 비용을 20~40% 절감할 수 있다.

전환 시 주의: gp3 전환은 다운타임 없이 온라인으로 가능하다. 단, 볼륨 크기가 크면 전환 완료까지 수 시간이 걸릴 수 있으며, 전환 중에는 추가 볼륨 변경이 불가하다.

스토리지 자동 확장

모든 RDS 인스턴스에 Storage Autoscaling을 활성화한다. 여유 스토리지가 전체의 10% 미만이고 5분 이상 지속되면 자동으로 용량을 확장한다. 운영자가 스토리지 부족으로 인한 서비스 장애를 막는 가장 단순한 방법이다.

Storage Autoscaling 설정:
- Maximum storage threshold: 예상 최대 사용량의 150~200%로 설정
- 자동 확장은 매번 10% 또는 10 GB 중 큰 값 이상 증가
- 한 번 확장된 스토리지는 줄일 수 없음 (스냅샷 복원으로만 축소 가능)

Aurora I/O 비용: Standard vs I/O-Optimized

Aurora Standard는 스토리지 비용이 저렴한 대신 I/O 요청 건당 요금이 발생한다. I/O-Optimized는 스토리지와 인스턴스 비용이 각각 약 22%, 30% 높지만 I/O 요청 비용이 없다.

Aurora Standard vs I/O-Optimized 손익분기점

I/O 비율 확인 방법

AWS Cost Explorer에서:
1. Service: Amazon Relational Database Service 선택
2. Usage type: RDS:StorageIOUsage 항목 필터
3. 해당 비용 ÷ 전체 Aurora 청구액으로 비율 계산

AWS CLI:
aws cloudwatch get-metric-statistics \
  --namespace AWS/RDS \
  --metric-name VolumeReadIOPs \
  --dimensions Name=DBClusterIdentifier,Value=<cluster-id> \
  --statistics Sum \
  --period 86400

I/O 비율이 25%를 꾸준히 넘고 있다면 I/O-Optimized 전환을 검토한다. 전환은 클러스터 수정으로 다운타임 없이 적용 가능하다.

백업 스토리지 비용 관리

백업 스토리지 요금은 자동 백업 보존 기간과 수동 스냅샷 크기에 비례한다.

항목	비고
자동 백업 무료 구간	DB 스토리지 크기 이내 (Aurora 기준)
초과분 단가	$0.021/GB-월 (us-east-1 기준)
보존 기간 기본값	1일 (최대 35일 설정 가능)
수동 스냅샷	삭제할 때까지 영구 보존 → 비용 누적 주의

실무 절감 포인트:

개발/스테이징 DB의 자동 백업 보존 기간을 1~3일로 단축.
사용하지 않는 수동 스냅샷 주기적 정리. AWS Backup의 수명 주기 정책 활용.
장기 보존이 필요한 스냅샷은 S3 Glacier로 아카이브 (Amazon RDS Snapshot export to S3 → Glacier 이동).

연결 풀러로 인스턴스 사이즈 줄이기

많은 서비스에서 DB 인스턴스를 크게 유지하는 이유 중 하나가 "연결 수가 많아서"다. 연결 수가 인스턴스 메모리에 비례하기 때문이다. 하지만 연결 풀러를 도입하면 실제 DB 연결 수를 10분의 1 이하로 줄일 수 있어 인스턴스 다운사이징이 가능해진다.

연결 풀러 도입 전:
애플리케이션 서버 10대 × 스레드 200개 = 최대 2,000 DB 연결
→ 2,000 연결 유지를 위해 db.r8g.4xlarge(128 GB) 필요

연결 풀러 도입 후:
PgBouncer(PostgreSQL) 또는 ProxySQL(MySQL) 경유
→ 실제 DB 연결: 100개
→ db.r8g.xlarge(32 GB)로 다운사이징 가능
→ 인스턴스 비용 약 75% 절감

AWS RDS Proxy는 매니지드 연결 풀러다. PgBouncer나 ProxySQL을 별도 운영하기 어려운 환경에서 유용하지만, 프록시 자체 비용($0.015/vCPU-시간)이 추가되므로 절감 효과를 계산한 뒤 도입 여부를 결정한다.

비용 가시성 도구

도구	용도
AWS Cost Explorer	서비스·사용 유형별 비용 분석, 예측
AWS Trusted Advisor	사용률 낮은 인스턴스 탐지, RI 구매 추천
AWS Compute Optimizer	인스턴스 사이즈·스토리지 유형 변경 추천
CloudWatch + 비용 알림	월간 예산 임계값 초과 시 알림
Savings Plans 분석 도구	현재 On-Demand 지출 기반 최적 약정 규모 추천

비용 최적화 우선순위 체크리스트

즉시 적용 가능 (다운타임 없음):
[ ] gp2 스토리지를 gp3로 전환 (RDS)
[ ] Storage Autoscaling 활성화 (모든 인스턴스)
[ ] 미사용 수동 스냅샷 정리
[ ] 개발/스테이징 DB 백업 보존 기간 단축
[ ] Aurora I/O 비율 확인 → 25% 초과 시 I/O-Optimized 전환 검토

단기 계획 필요 (1~4주):
[ ] Compute Optimizer 추천 기반 인스턴스 사이즈 검토
[ ] 연결 풀러 도입 검토 (PgBouncer / ProxySQL / RDS Proxy)
[ ] Reserved Instance 구매 계획 수립 (안정 워크로드 기준)
[ ] 리전 간 Read Replica 필요성 재검토

분기 리뷰:
[ ] RI 만료 일정 확인 및 갱신 결정
[ ] 신규 인스턴스 패밀리(r8g, m8g 등) 가격 비교
[ ] 스냅샷 S3 아카이브 정책 수립
[ ] 실제 비용 vs 예산 차이 원인 분석

클라우드별 비용 절감 핵심 포인트 요약

클라우드	핵심 절감 포인트
AWS RDS/Aurora	gp3 전환, RI 구매, Aurora I/O-Optimized 임계값 관리
Google Cloud SQL	Committed Use Discounts(1년 25%, 3년 52%), 연결 관리로 인스턴스 축소
Azure Flexible Server	Reserved Instance(1년 33%, 3년 51%), HA 옵션 선택(Zone vs Same-Zone)
공통	인스턴스 Rightsizing, 스토리지 Autoscaling, 불필요 스냅샷 정리

References

https://aws.amazon.com/rds/aurora/pricing/
https://cloudfix.com/blog/aurora-io-optimized-vs-standard/
https://aws.amazon.com/blogs/database/how-to-optimize-amazon-rds-and-amazon-aurora-database-costs-performance-with-aws-compute-optimizer/
https://sedai.io/blog/understanding-amazon-rds-costs-pricing
https://www.usage.ai/blogs/aws/reserved-instances/rds/storage-cost/
https://lushbinary.com/blog/how-to-optimize-aws-rds-costs-2026/
https://www.usage.ai/blogs/gcp/cloud-sql/pricing/
https://sedai.io/blog/setup-storage-autoscaling-amazon-rds
https://www.mydbops.com/blog/hidden-costs-scaling-rds-over-provisioning
https://virtual-dba.com/blog/2026-database-architects-guide-to-cloud-optimization/