AWS RDS, 진짜 줄일 수 있는 비용 찾기

Apr 29. 2025

이 글에서는 복잡한 AWS 서비스 설명은 과감히 생략합니다.

대신, “지금 당장 어디서 줄일 수 있는지”,

“우리가 놓치고 있었던 비용 포인트는 무엇인지”

정말 필요한 내용만 바로 짚어드립니다.

최근 AWS 비용을 절감하는 방안이 많이 화두가 되고 있습니다. 그동안 편하게 사용해온 AWS, 이제는 처절하게 비용을 줄이는 방법을 찾아야 합니다. AWS의 비용 구조를 이해하면 생각보다 비용을 절감할 수 있는 포인트가 많이 존재하는 것을 알 수 있습니다. 이번에는 RDS를 비용 절감 차원에서 이해해보는 시간을 가져보겠습니다.

AWS RDS(Relational Database Service)는 클라우드 환경에서 손쉽게 데이터베이스를 구축하고 운영할 수 있는 서비스입니다. 그러나 서버 비용, I/O 비용, 스토리지 비용을 최적화하지 않으면 예상보다 높은 비용이 발생할 수 있습니다. Aurora MySQL과 일반 RDS의 비용 차이를 이해하고, 비용 절감 전략을 통해 최적화를 도모해야 합니다.

비용 절감 방법으로는 예약 인스턴스(RI) 활용, 쿼리 최적화, 캐싱 활용, 데이터 정리 및 압축 등이 있습니다. AWS Cost Explorer와 CloudWatch를 활용하여 정기적으로 모니터링하고 최적화하는 것이 중요합니다. 그러나 실제 사례에서 문제를 발견하고 비용을 줄이기 위해서는 구체적으로 각 항목이 어떻게 비용이 나가는지를 분석할 수 있어야 합니다.

RDS란 무엇인가?

RDS(Relational Database Service)는 AWS에서 제공하는 클라우드형 데이터베이스 서비스로, 사용자가 데이터베이스를 손쉽게 구축하고 운영할 수 있도록 지원합니다. 클라우드 환경에서는 EC2 인스턴스에서 직접 데이터베이스를 운영할 수도 있지만, 대부분의 사용자는 운영의 간편성, 관리의 용이성, 자동 백업 등의 이유로 RDS를 선택합니다.

RDS는 크게 인스턴스(서버), 스토리지, I/O 작업으로 구성되어 있으며, 각각의 요소에서 비용이 발생합니다. 이번 글에서는 RDS 비용 구조를 세부적으로 분석하고, 효과적인 비용 절감 전략을 살펴보겠습니다.

AWS Cost Explorer를 통한 비용 분석

AWS는 비용을 효과적으로 관리할 수 있도록 “Cost Explorer”라는 비용 분석 도구를 제공합니다. AWS와 협력하는 MSP(Managed Service Provider)와 계약이 되어 있다면, 그들이 제공하는 Cost Explorer를 통해 세부적인 비용 분석 및 관리가 가능합니다.

RDS 비용 구조 세부 분석

RDS의 비용은 주로 다음 세 가지로 구성됩니다. 비용 시뮬레이션은 아래 링크에서 확인하실 수 있습니다.

AWS Pricing Calculator

https://calculator.aws/#/createCalculator/AuroraMySQL

1. 서버 비용(인스턴스 비용)

서버를 가동하는 것 자체로 발생하는 비용을 의미합니다. RDS 인스턴스의 사양(CPU, 메모리 등)에 따라 비용이 결정됩니다. 보통 CPU와 메모리가 2배 높아지면, 비용도 2배 높아진다고 보면 됩니다. 그 밖에도 인스턴스의 종류(db.r6i.large, db.t4g.medium 등), 운영 체제(리눅스, 윈도우) 및 배포 옵션(싱글 AZ, 멀티 AZ)에 따라 비용이 크게 달라집니다. 장기적으로 운영할 경우 온디맨드 인스턴스보다 예약 인스턴스(RI, Reserved Instance)를 활용하거나 Savings Plans를 도입하면 약 30~50%의 비용을 절감할 수 있습니다.

이 예를 보면 Aurora MySQL 호환 인스턴스인데 이는 Aurora 클러스터를 구성할 경우입니다. Aurora MySQL은 AWS에 최적화된 스토리지 엔진으로, 스토리지가 100GB 단위로 128TB까지 자동 확장됩니다. AWS에 의하면 IOPS 성능, 데이터 캐싱, 다중 쓰레드 활용이 더 뛰어나다고 합니다. 필자가 속한 스타트업에서도 Aurora MySQL로 많이 구성합니다. 이때 클러스터를 구성할 수 있는데 1개의 Write DB와 복수 개의 Read DB로 구성할 수 있습니다. Read DB는 오토스케일링이 가능해 트래픽이 높아지는 상황에서도 안정적인 운영이 가능합니다.

예시는 아시아 태평양(서울) 리전에서 8 vCPU, 64GB Memory인 db.r6g.2xlarge에 대한 월 비용 계산입니다. 비용은 시간당으로 계산되며 한달 평균 730시간(30.4일) 기준으로 월 $1022가 발생합니다. Aurora MySQL의 경우 시간당 $1.4, 일반 RDS MySQL은 시간당 $1.14로, 클러스터를 구성할 경우 약 20% 더 비싼 편입니다.

즉, db.r6g.2xlarge 스펙에 해당하는 하나의 인스턴스를 띄우고 운영하게 되면 월 서버 비용만 $1022가 지출됩니다. 윈도우용 SQL로 RDS에 서버를 띄우게 되면, 시간당 비용은 $3.2로 라이선스 비용이 포함되어 지출이 약 2.3배 높아지는 것을 알 수 있습니다.

Q. Aurora 클러스터로 구성하면 추가 비용이 발생할까?

A. Aurora 클러스터를 생성하면 클러스터 관리 자체에 대한 추가 비용은 발생하지 않습니다. 다만, 읽기 전용 복제본을 생성하면 그 숫자만큼 인스턴스 비용이 추가됩니다.

2. I/O 비용(Storage IO 비용)

I/O 비용은 RDS가 데이터를 읽고 쓸 때 발생하는 비용입니다. 데이터베이스에 요청되는 쿼리 빈도나 복잡성에 따라 비용이 증가합니다. 비용은 요청 수(I/O)를 기준으로 측정되는데 아래와 같은 기준으로 발생됩니다.

$0.20 per 1 million requests

과금 대상 I/O 작업은 아래와 같습니다.

읽기(select) 요청

쓰기(insert/update/delete) 요청

Read/Undo 로그

Binary 로그

백업 및 스냅샷 생성 시 I/O 작업

인덱스 작성 또는 최적화 작업

하지만 대부분의 비용은 읽기 및 쓰기에서 발생하게 됩니다. 실무에서 예상 가능한 IOPS 예시는 다음과 같습니다.

IOPS에 관련된 추이는 AWS 클라우드와치에서 Read IOPS, Write IOPS, Storage IOPS의 그래프를 통해 확인할 수 있습니다. 또한 Performance schema에 로깅을 허용했을 경우 SQL로도 아래 쿼리로 직접 모니터링이 가능합니다.

SELECT table_name, index_name, COUNT_READ / 1024 / 1024 AS Read_MB, COUNT_WRITE / 1024 / 1024 AS Write_MB FROM performance_schema.table_io_waits_summary_by_index_usage ORDER BY Read_MB DESC, Write_MB DESC;

비효율적인 쿼리 또는 대량의 데이터 변경 작업(INSERT, UPDATE, DELETE 등)은 많은 I/O 작업을 발생시켜 비용 증가로 이어질 수 있습니다. 읽기의 경우 버퍼에 저장된 데이터를 불러올 경우 비용이 발생하지 않습니다. 메모리에서 데이터를 바로 읽기 때문입니다. 따라서 버퍼 히트율이 높다면 읽기에서 어느정도 비용 최적화가 가능합니다.

이를 응용하면 Aurora 클러스터를 이용할 경우 Write db 하나만 있는 것보다 스펙을 한단계 낮춰서 Write db 1개와 Read db 1개를 운영하는 것이 비용 효율적일 수도 있습니다. 인스턴스의 버퍼는 개별적으로 관리되는데 Write db의 경우 버퍼 캐시를 활용하더라도 결국 디스크에 써야 하므로 비용이 발생하게 됩니다. 그러나 Write db의 페이지를 제외하고 Read db 페이지만 효율적으로 캐싱이 된다면 쿼리 히트율을 높일 수 있습니다. 즉 읽기 IOPS 비용이 줄어들 수 있습니다. 가령 r6i.2xlarge로 Write db를 구성하는 것보다 r6i.xlarge로 Write db, Read db를 각각 1개씩 구성하는 것이 비용 효율적일 수 있습니다.

더불어 I/O 비용을 절감하기 위해서는 다음 전략을 고려해야 합니다.

쿼리 최적화(Full table scan 방지, 효율적 인덱스 설계)

캐싱 시스템 활용(ElastiCache 등)

3. 데이터 저장 비용(Storage 비용)

RDS가 사용하는 스토리지 공간에 따라 발생하는 비용입니다. GB-Month 단위로 계산되는데 1GB 당 $0.1을 사용합니다. 예를 들어 500GB의 스토리지를 사용하고 있다면 월 비용이 $50 발생하게 됩니다. Aurora MySQL의 경우 스토리지 공간은 자동으로 확장되므로, 데이터나 로그가 많이 기록될 경우 비용이 급작스럽게 자동으로 증가할 수 있습니다.

스토리지 사용량은 Redo 로그, Undo 로그, Bin 로그 등이 포함될 수 있습니다. 하지만 사용하는 모든 스키마와 인덱스 크기의 합계와 거의 비슷하다고 볼 수 있습니다. 따라서 기본적으로 비용을 관리하기 위해서는 데이터 라이프사이클 관리(필요 없는 오래된 데이터 주기적 삭제)가 필요합니다. 불필요한 데이터 및 로그를 정리하는 것입니다. 데이터베이스의 사이즈는 아래 쿼리로 스키마별로 확인할 수 있습니다.

SELECT table_schema AS "Database", ROUND(SUM(data_length + index_length) / 1024 / 1024, 2) AS "Size (MB)" FROM information_schema.tables WHERE table_schema NOT IN ('information_schema', 'performance_schema', 'mysql', 'sys') GROUP BY table_schema;

추가적으로 발생 가능한 비용

위의 주요 비용 외에도 다음과 같은 추가 비용이 발생할 수 있습니다.

1. 백업 비용

기본적으로 자동 백업은 데이터베이스 크기만큼 무료로 제공됩니다. 하지만 이를 초과하거나 수동으로 생성한 스냅샷은 추가적인 백업 비용이 발생할 수 있습니다. 초과 용량에 대해서는 월에 GB 당 $0.021이 부과됩니다. 예를 들어 현재 4TB의 데이터베이스가 있는데 백업 보존 기간을 7일로 설정할 경우는 계산이 어떻게 될까요? 7 x 4 = 28TB에서 데이터베이스 크기만큼인 4TB를 제외한 24TB에 대해 백업 비용이 부과될 것이라고 추측하실 수 있습니다. 하지만 AWS의 백업 매커니즘은 다행히 비용 효율적입니다.

백업은 백업을 하는데 사용된 데이터의 비용이라고 보시면 됩니다. 그리고 Aurora는 증분백업 방식으로 동작합니다. 따라서 백업 보존 기간이 7일인 것은 큰 문제가 없습니다. 첫 번째 백업은 전체 데이터를 백업하지만 이후 백업은 변경된 데이터만 저장합니다. 즉 4TB씩 중복 저장하는 것이 아닌 변경된 부분만 추가로 저장합니다. 4TB라고 하더라도 하루 변경량이 100GB라고 하면 초과 용량은 4TB + 600GB = 4.6TB - 4TB = 600GB입니다. 따라서 600 x $0.021 = $12.6 만큼만 월 비용으로 나가게 됩니다. 따라서 7일로 백업 보존 기간을 설정하는 것이 비용을 크게 증가시키지는 않습니다.

2. 추가 지원 비용(Extended Support)

AWS의 기본 지원 외 추가 기술 지원이나 컨설팅 서비스를 사용하는 경우 발생하는 비용입니다. 2024년 12월부터 MySQL 5.7을 유지하고 계시다면 이것과 관련된 비용이 나가고 있을 가능성이 큽니다. 2024년 10월부터 AWS는 MySQL 5.7 지원을 중단했고 12월부터 MySQL 5.7을 사용하실 수는 있지만 Support 비용을 추가로 과금하고 있습니다. 이 금액이 생각보다 꽤 높습니다. vCPU 개수만큼 과금을 하는데 r6i.2xlarge의 경우 8CPU를 씁니다. 이 때 과금되는 비용은 인스턴스 1개당 무려 $714입니다. 서버비용이 31일 기준 $1041임을 감안하면 약 68%를 서버비용으로 추가 과금된다고 보시면 됩니다. 최대한 빠르게 MySQL 8.0 버전으로 업그레이드를 하시는 것이 좋습니다.

8 x 24 x 31 = 5952hours

$0.12 per hour

5952 x $0.12 = $714.24

3. S3 Export 비용

RDS의 데이터를 S3로 내보낼 때 발생하는 비용입니다. AWS는 RDS의 데이터를 스키마 단위, 테이블 단위로 분류하여 S3로 보내는 서비스를 제공합니다. 비용은 $0.01 per GB입니다.

4. 데이터 전송 비용(Data Transfer 비용)

다른 리전이나 인터넷으로 데이터를 전송하는 경우 비용이 발생합니다. 동일 리전 내의 VPC 내부 데이터 전송은 무료이므로, 이를 적극 활용해 비용을 절감하실 수 있습니다. 다른 리전으로 전송할 경우 $0.02 per GB가 발생합니다. 대부분 EC2와 RDS의 통신으로 많이 활용하고 계시고 같은 리전에 두시는 경우가 많으므로 Data Transfer 비용은 발생하지 않는 경우가 대부분입니다. 나중에 말씀드리겠지만 EC2의 데이터 통신은 같은 리전이라고 하더라도 다른 가용영역에서 통신할 경우 추가 비용이 발생하고 그 비용을 간과해서는 안 될 경우가 있습니다. 다만 EC2 - RDS 간 통신에서는 내부 통신 비용이 크게 발생하지 않으므로 크게 걱정하지 않으셔도 됩니다. 만약 RDS의 Data Transfer 비용이 크게 발생하고 계시다면 주의하고 살펴보셔야 합니다.

5. 스냅샷 비용

스냅샷을 장기 보관하시거나 다른 리전으로 복제하시는 경우 추가 비용이 발생합니다. 스냅샷의 주기적인 정리와 보관 정책 설정을 통해 비용을 최적화하실 수 있습니다. 수동으로 만들어두신 스냅샷이 많을 경우 이것들이 모이면 꽤 많은 비용을 초래하게 되므로 적정 시점에 관리해주실 필요가 있습니다.