Aurora vs RDS: 구조 차이와 갈아타는 기준

인프라 AWS 비용
5 분 소요

RDS 콘솔에서 엔진을 고를 때 첫 갈림길은 MySQL이냐 PostgreSQL이냐가 아니라, 표준 RDS냐 Aurora냐입니다. 둘 다 매니지드이고 같은 프로토콜로 접속하니 겉보기엔 등급 차이 같지만, 실제로는 스토리지 구조가 다른 별개의 제품입니다. 결론을 먼저 적으면, 소형·안정 부하는 표준 RDS가 싸고, 읽기 스케일·가용성·스파이키 부하 요구가 실측으로 보이면 Aurora로 갑니다. 인스턴스 클래스 선택은 RDS 인스턴스 클래스 비교에서 다뤘고, 이 글은 그 앞 단계의 선택입니다. 요금은 us-east-1 기준입니다.

구조가 다릅니다: 디스크가 아니라 스토리지 서비스 #

표준 RDS는 인스턴스에 EBS 볼륨이 붙는 구조입니다. 크기를 미리 정하고, Multi-AZ면 스탠바이에 같은 볼륨이 하나 더 생기고, 리드 레플리카는 각자 자기 스토리지에 복제본을 씁니다.

Aurora는 컴퓨트와 스토리지를 분리했습니다. 데이터는 3개 AZ에 걸쳐 6중으로 복제되는 공유 스토리지 계층에 있고, 인스턴스들은 그 위에 붙습니다. 이 구조에서 차이가 연쇄적으로 나옵니다.

  • 리드 레플리카 최대 15개가 같은 스토리지를 읽으므로, 복제 지연이 밀리초 단위입니다. 표준 RDS의 레플리카는 논리 복제라 지연이 초 단위로 벌어질 수 있습니다.
  • 페일오버가 빠릅니다. 레플리카가 이미 같은 데이터를 보고 있으므로 승격이 대개 30초 안에 끝납니다. 표준 RDS Multi-AZ는 1〜2분쯤 봅니다.
  • 스토리지가 자동으로 늘어납니다. 미리 크기를 정하지 않고 쓴 만큼 과금되며, 상한은 256TiB까지 올라갔습니다. “디스크가 꽉 찼다"는 운영 사고 유형이 하나 사라집니다.
  • 스냅샷 복원 없이 몇 분 만에 쓰기 가능한 복제 클러스터를 만드는 빠른 클로닝, MySQL 호환판의 Backtrack(테이블 복원 없이 시점 되감기) 같은 부가 기능도 이 스토리지 계층에서 나옵니다.

요금 구조: 인스턴스 프리미엄 + 스토리지·I/O #

Aurora 요금은 세 층입니다.

  • 인스턴스: 같은 클래스 기준으로 표준 RDS보다 시간당 요금이 20% 안팎 높습니다.
  • 스토리지: 기본 구성(Aurora Standard)에서 GB·월 약 $0.10. 표준 RDS의 gp3(약 $0.115/GB·월, 스토리지 선택 기준 참조)와 비슷한 수준이지만, 쓴 만큼만 냅니다.
  • I/O: 여기가 변수입니다. Aurora Standard는 I/O 요청 100만 건당 약 $0.20을 따로 받습니다. 캐시가 잘 듣는 워크로드면 무시할 수준이고, 쓰기·스캔이 많으면 인스턴스 요금을 넘어서기도 합니다. 청구서에서 이 항목이 커지는 것이 Aurora 요금이 예측을 벗어나는 대표 경로입니다.

그래서 I/O-Optimized 구성이 있습니다. I/O 과금을 없애는 대신 인스턴스 요금이 약 30% 더 높고 스토리지가 GB·월 약 $0.225로 오릅니다. 기준선은 명확합니다. 전체 Aurora 지출에서 I/O가 25%를 넘으면 I/O-Optimized가 쌉니다. 클러스터 단위로 전환할 수 있으므로, Standard로 시작해 청구서의 I/O 비중을 보고 결정하면 됩니다.

Serverless v2: 스파이키 부하의 답 #

Aurora에는 인스턴스 클래스 대신 용량 단위(ACU)로 초 단위 과금하는 Serverless v2가 있습니다. ACU당 시간당 약 $0.12(I/O-Optimized는 약 $0.156)이고, 부하에 따라 몇 초 만에 증감합니다. 최소 용량을 0으로 두면 유휴 시 자동 일시정지되어 컴퓨트 요금이 0이 됩니다. 야간에 비는 사내 도구, 개발·검증 환경, 트래픽 예측이 안 되는 신규 서비스가 대상입니다.

계산은 필요합니다. 상시 부하라면 같은 용량의 프로비저닝 인스턴스보다 ACU 단가가 비싸므로, 기저 부하가 안정된 서비스는 프로비저닝 + 필요 시 레플리카 쪽이 쌉니다. Serverless v2는 “부하가 출렁이거나 0으로 떨어지는 시간이 길다"는 조건에서만 절감 수단입니다.

표준 RDS가 여전히 정답인 조건 #

  • 소형·안정 부하: db.t4g.micro(월 $12쯤)로 충분한 서비스에 Aurora 프리미엄을 얹을 이유가 없습니다. 개발·검증 환경도 마찬가지입니다(0 ACU Serverless v2가 경쟁 상대이긴 합니다).
  • 엔진이 다른 경우: Aurora는 MySQL·PostgreSQL 호환만 있습니다. MariaDB, Oracle, SQL Server는 표준 RDS 확정입니다.
  • 버전·확장 요구가 구체적인 경우: Aurora는 호환이지 동일 엔진이 아니라서, 커뮤니티판의 특정 마이너 버전이나 일부 확장·스토리지 엔진(MyISAM 등)이 필요하면 표준 RDS로 갑니다.
  • 요금 예측 가능성: I/O 과금 없는 고정 구성이 우선이면 표준 RDS + gp3가 단순합니다.

반대로 읽기 레플리카를 늘려 가는 중이거나, 페일오버 시간이 SLA에 걸리거나, 스토리지 증설 작업이 반복되거나, I/O 병목 실측(버퍼 풀 판정 참조)이 클래스 증설로 안 잡히면 Aurora 전환을 검토할 시점입니다.

전환 실무: 리드 레플리카 승격이 정석입니다 #

표준 RDS MySQL·PostgreSQL에서 Aurora로는 Aurora 리드 레플리카를 만들어 복제가 따라잡은 뒤 승격하는 경로가 정석입니다. 스냅샷 복원보다 중단이 짧고, 전환 전에 Aurora 쪽 성능을 실제 부하 복제로 검증할 수 있습니다. 승격 전에 애플리케이션의 접속 문자열을 클러스터 엔드포인트(쓰기)와 리더 엔드포인트(읽기)로 나눠 두면 이후 레플리카 확장이 코드 변경 없이 됩니다. 연결·마이그레이션 일반 실무는 AWS 실전 #2에서 다뤘습니다.

정리 #

  • Aurora는 등급이 아니라 구조가 다른 제품입니다. 3AZ 6중 복제 공유 스토리지에서 15개 레플리카, 30초 페일오버, 256TiB 자동 확장이 나옵니다.
  • 요금은 인스턴스 프리미엄(20% 안팎)에 스토리지·I/O가 얹히는 3층 구조입니다. I/O가 지출의 25%를 넘으면 I/O-Optimized로 전환합니다.
  • Serverless v2는 ACU 초 단위 과금에 0 ACU 일시정지가 됩니다. 스파이키하거나 유휴가 긴 부하에서만 절감 수단입니다.
  • 소형·안정 부하, MySQL·PG 외 엔진, 특정 버전·확장 요구, 요금 예측 우선이면 표준 RDS가 정답입니다.
  • 전환은 Aurora 리드 레플리카 승격이 정석이고, 그 전에 클러스터·리더 엔드포인트 분리를 해 둡니다.
X