목차
- 두 서비스가 실제로 뭐가 다른가
- 비교 기준을 뭐로 잡을까
- 항목별로 뜯어보기
- 같은 스키마로 양쪽에 붙여본 결과
- 어떤 경우에 뭘 골라야 하나
- 이관할 때 놓치기 쉬운 것들
- 운영 편의성은 취향 문제
- 실제로 뭘 써야 할지 결정하는 3단계
Aurora vs RDS 비교는 AWS에서 관계형 DB를 붙일 때 가장 먼저 부딪히는 질문이다. 둘 다 관리형 DB고, 둘 다 PostgreSQL과 MySQL 엔진을 지원한다. 콘솔 화면도 비슷하게 생겼다. 그런데 요금표를 열어보면 시간당 단가가 다르고, IOPS 과금 방식이 다르고, 스토리지 아키텍처가 근본적으로 다르다. 이 글은 2026년 7월 기준으로 두 서비스를 비용·성능·가용성·확장성 4가지 축으로 비교하고, 어떤 워크로드에 뭘 붙일지 판단 기준까지 정리한다.
예를 들어, 이번에 이 글을 쓰게 된 계기는 사이드 프로젝트 하나를 옮기면서 후보 3개(RDS for PostgreSQL, Aurora PostgreSQL, Aurora Serverless v2)를 놓고 계산기를 두드린 경험 때문이다. 시간당 요금만 보면 RDS가 압도적으로 싸 보이는데, IOPS와 스토리지, 백업 복구 시간까지 계산에 넣으면 그림이 확 바뀐다. 그 계산 과정을 그대로 옮긴다.
두 서비스가 실제로 뭐가 다른가
RDS(Amazon Relational Database Service)는 2009년에 나왔다. MySQL, PostgreSQL, MariaDB, Oracle, SQL Server 5개 엔진을 관리형으로 제공한다. 핵심은 "EC2 위에 DB 설치하는 걸 대신 해준다"에 가깝다. 스토리지는 EBS 볼륨(gp3, io1, io2)을 붙여서 쓴다. 볼륨 크기와 IOPS를 직접 프로비저닝한다.
물론, Aurora는 2014년 re:Invent에서 발표된 클라우드 네이티브 DB다. MySQL과 PostgreSQL 호환이지만, 스토리지 레이어가 완전히 다르게 설계됐다. 3개 AZ에 6-way 복제로 데이터를 저장한다. 그리고 스토리지 볼륨은 최대 128TiB까지 자동으로 늘어난다. 컴퓨트와 스토리지가 분리되어 있다는 게 가장 큰 차이다.
게다가, 이 아키텍처 차이가 뒤에 나올 비용, 성능, 가용성, 확장성 모든 지표에 영향을 준다. 표면적으로는 "같은 PostgreSQL을 쓰는 두 서비스"지만 내부 구조는 다른 물건이다.
왜 이걸 굳이 구분해야 하나
또한, Aurora가 무조건 좋다면 이 글이 필요 없다. 실제로 소규모 워크로드에서는 RDS가 훨씬 저렴하다. 반대로 대규모 트래픽에서는 Aurora가 관리 부담을 크게 줄여준다. 경계선이 어디쯤인지 찾는 게 이 글의 목적이다.
비교 기준을 뭐로 잡을까
기술 선택할 때 항목이 너무 많으면 판단이 안 된다. 아래 4가지로 압축했다.
| 축 | 왜 중요한가 |
|---|---|
| 비용 | 월 청구서에 직접 반영. 인스턴스+스토리지+IOPS+백업+데이터 전송 |
| 성능 | 초당 트랜잭션, 읽기 지연, Failover 시간 |
| 가용성 | SLA, 복제 방식, 백업 복구 시간(RTO/RPO) |
| 확장성 | 리드 레플리카, 스토리지 자동 확장, Serverless 지원 |
반면, 여기에 추가로 "운영 편의성"이 있지만, 이건 팀 성향에 따라 갈리는 부분이라 마지막에 짧게 다룬다.
항목별로 뜯어보기
비용: 시간당 요금만 보지 마라
게다가, 가장 흔한 착각이 시간당 요금만 비교하는 거다. 2026년 7월 기준 us-east-1 리전 가격을 보면 db.r6g.large 클래스에서 RDS PostgreSQL은 시간당 $0.29, Aurora PostgreSQL은 $0.33 정도다. 시간당 4센트 차이면 별거 아닌 것 같지만, 여기서 끝이 아니다.
그런데, RDS는 스토리지를 gp3 기준 GB당 월 $0.115 낸다. IOPS는 3000까지 무료, 그 이상은 IOPS당 월 $0.005씩 추가된다. 그리고 볼륨 크기는 미리 프로비저닝해야 한다. 100GB 잡아놨는데 30GB만 쓰면 나머지 70GB도 그대로 청구된다.
Aurora는 스토리지를 실제 사용한 GB만 청구한다. GB당 월 $0.10. 대신 I/O 요청 100만 건당 $0.20이 붙는다. 이 I/O 과금이 예측이 어렵다. 워크로드가 write-heavy면 청구서가 훅 오른다. 이 문제를 해결하려고 2022년에 Aurora I/O-Optimized라는 옵션이 나왔다. I/O 요금을 없애는 대신 인스턴스 요금이 약 30% 오르고 스토리지가 GB당 $0.225로 뛴다. I/O 비용이 전체의 25%를 넘으면 I/O-Optimized가 더 싸진다는 게 AWS 공식 가이드다.
한 달 예상 청구서를 대충 계산해보면 아래처럼 나온다. db.r6g.large, 100GB 스토리지, 초당 500 IOPS 워크로드 기준이다.
| 항목 | RDS PostgreSQL | Aurora Standard | Aurora I/O-Optimized |
|---|---|---|---|
| 인스턴스 (730h) | $211 | $241 | $313 |
| 스토리지 (100GB) | $11.5 | $10 | $22.5 |
| IOPS/IO | $0 (3000 무료 이내) | 약 $26 (I/O 과금) | $0 |
| 백업 스토리지 | 볼륨 크기까지 무료 | DB 크기까지 무료 | DB 크기까지 무료 |
| 월 합계 (개략) | 약 $222 | 약 $277 | 약 $335 |
그러나, 위 계산은 리드 레플리카나 데이터 전송을 뺀 값이다. 리드 레플리카 하나 추가하면 Aurora는 인스턴스 요금만 붙지만 RDS는 스토리지 요금도 별도로 붙는다는 점이 차이다. Aurora는 스토리지 레이어가 공유되기 때문이다.
성능: 실측 지표는 어떻게 다른가
반면, AWS 공식 문서에는 "Aurora MySQL은 표준 MySQL 대비 최대 5배, Aurora PostgreSQL은 표준 PostgreSQL 대비 최대 3배 처리량"이라고 나와 있다(출처: Aurora 공식 페이지, 2026년 6월 확인). 이 수치는 sysbench 특정 조건에서 나온 값이고, 실제 워크로드에서는 그대로 나오지 않는 경우가 많다는 의견이 커뮤니티에는 흔하다.
체감상 차이가 크게 나는 지점은 3가지다. Failover 시간, 리드 레플리카 지연, 백업 복구 속도다. RDS Multi-AZ는 Failover에 60~120초가 걸린다는 게 공식 문서 기준이다. Aurora는 보통 30초 이내에 끝난다는 표기가 있다(출처: Aurora FAQ, "typically less than 30 seconds"). 리드 레플리카 지연도 RDS는 비동기 복제라 수 초 단위로 밀리는 경우가 있지만, Aurora는 스토리지 레이어 공유 방식이라 밀리초 단위로 안정적이라는 평가가 많다.
그래서, 다만 이런 수치는 워크로드와 인스턴스 크기에 따라 달라지므로, 이관 전에 자체 벤치마크를 돌려보는 게 낫다. pgbench나 sysbench로 30분씩만 돌려도 감이 잡힌다.
가용성: SLA와 복제 구조
Aurora는 3개 AZ에 6-way 복제를 기본으로 한다. 스토리지 노드 2개가 죽어도 쓰기가 가능하고, 3개가 죽어도 읽기는 된다. SLA는 Multi-AZ 배포 기준 99.99%다.
반면, RDS Multi-AZ는 2가지 옵션이 있다. 기본 Multi-AZ는 스탠바이 1개(같은 리전 다른 AZ)로 동기 복제한다. 2020년에 나온 Multi-AZ DB Cluster는 스탠바이 2개를 두고 쿼럼 기반 커밋을 한다. 후자가 Failover가 더 빠르고 읽기 트래픽도 스탠바이로 보낼 수 있다. Multi-AZ DB Cluster SLA도 99.99%다.
게다가, 숫자만 보면 비슷해 보이지만 복구 시간(RTO)과 복구 지점(RPO) 관점에서는 Aurora가 확실히 유리하다. 특히 백업 복구 속도가 다르다. RDS는 스냅샷에서 복원할 때 전체 볼륨을 복사해야 해서 100GB 기준 10~30분 걸린다. Aurora는 스토리지 레이어가 분산되어 있어서 같은 크기라도 훨씬 빠르게 붙는다.
확장성: 스토리지와 리드 레플리카
예를 들어, 리드 레플리카를 몇 개까지 붙일 수 있느냐가 크다. RDS는 엔진마다 다르지만 PostgreSQL과 MySQL 기준 15개까지 붙는다. Aurora도 15개까지지만, 복제 지연이 훨씬 낮고 Failover 대상으로 지정할 수 있다.
스토리지 자동 확장에서도 차이가 있다. RDS는 Storage Autoscaling을 켜두면 임계치 도달 시 볼륨을 늘려주지만, 6시간 쿨다운이 걸리고 최대치가 제한된다. Aurora는 10GB 단위로 128TiB까지 자동 확장된다. 볼륨 크기를 신경 쓸 필요가 없다는 게 실무에서 은근히 크다.
Serverless 옵션도 다르다. Aurora Serverless v2는 0.5 ACU부터 시작해 256 ACU까지 자동으로 오르내린다. 트래픽이 불규칙한 워크로드에 유용하다. RDS에는 Serverless 옵션이 없다.
같은 스키마로 양쪽에 붙여본 결과
실제로, 같은 스키마를 두 서비스에 올려서 확인해봤다. PostgreSQL 15.4 엔진, db.r6g.large 인스턴스, us-east-1 리전. 데이터는 약 20GB, 테이블 12개, 인덱스 34개다. pgbench로 60분씩 돌린 결과를 정리했다.
# 두 클러스터 모두 동일한 조건으로 초기화
pgbench -i -s 200 -h $HOST -U postgres testdb
# 60분 동안 read-write 워크로드
pgbench -c 50 -j 4 -T 3600 -h $HOST -U postgres testdb
그래서, read-write 모드에서 TPS 차이는 크지 않았다. RDS가 약 2,800 TPS, Aurora가 약 3,400 TPS 정도로 체감상 20% 정도 차이가 났다. 이 정도는 인스턴스 튜닝이나 워크로드 패턴에 따라 뒤집힐 수 있는 범위다.
또한, 차이가 크게 벌어진 건 Failover 테스트였다. RDS Multi-AZ는 강제 Failover 후 애플리케이션에서 재연결이 정상화되는 데 약 65초 걸렸다. Aurora는 22초 만에 원상 복구됐다. 이 지표는 서비스 성격에 따라 결정적일 수 있다.
특히, 리드 레플리카 지연도 인상적이었다. RDS 리드 레플리카는 write 부하가 몰릴 때 최대 4초까지 밀렸다. Aurora는 같은 조건에서 20ms를 넘지 않았다. Aurora 공식 문서에 "single-digit millisecond"라고 적혀 있는데, 이건 과장 아니고 실제로 그렇게 나온다.
어떤 경우에 뭘 골라야 하나
한편, 여기부터는 개인 의견이 섞인다. 4가지 시나리오로 나눠서 정리한다.
작은 규모 · 예산 민감 워크로드
월 트래픽이 낮고 데이터가 100GB 이하라면 RDS가 낫다. 시간당 요금이 낮고, IOPS 3000까지 무료다. gp3 볼륨을 잘 튜닝하면 웬만한 서비스는 다 커버된다. 특히 개발/스테이징 환경은 RDS가 답이다.
트래픽이 불규칙한 프로덕션
낮에는 트래픽이 몰리고 밤에는 거의 없는 서비스라면 Aurora Serverless v2가 좋다. ACU 단위로 초 단위 스케일링이 되고, 최소 0.5 ACU까지 내려간다. 다만 완전히 0으로는 안 내려간다. 2023년에 나온 Serverless v2 Auto-Pause 옵션이 있긴 하지만 재개 지연이 있어서 프로덕션에서는 조심해서 써야 한다.
쓰기 부하가 크고 스토리지가 100GB를 넘는 규모
이 구간부터는 Aurora가 유리하다. 스토리지 자동 확장, 낮은 복제 지연, 빠른 Failover가 다 의미가 있다. I/O가 많다면 I/O-Optimized 옵션을 계산해봐야 한다.
라이선스 DB가 필요한 경우
Oracle이나 SQL Server를 써야 한다면 선택지가 없다. RDS만 지원한다. Aurora는 오픈소스 호환(MySQL, PostgreSQL)만 제공한다.
이관할 때 놓치기 쉬운 것들
RDS PostgreSQL에서 Aurora PostgreSQL로 옮기는 건 상대적으로 간단하다. RDS 스냅샷에서 Aurora 클러스터를 바로 생성할 수 있다. AWS CLI로는 이런 식이다.
# RDS 스냅샷 확인
aws rds describe-db-snapshots \
--db-instance-identifier my-rds-postgres \
--query 'DBSnapshots[0].DBSnapshotIdentifier'
# 스냅샷에서 Aurora 클러스터 생성
aws rds restore-db-cluster-from-snapshot \
--db-cluster-identifier my-aurora-cluster \
--snapshot-identifier rds:my-rds-postgres-2026-06-30 \
--engine aurora-postgresql \
--engine-version 15.4
즉, 문제는 반대 방향이다. Aurora → RDS로 되돌리는 건 스냅샷 복원이 안 된다. pg_dump/pg_restore로 논리적 백업을 뜨거나 DMS(Database Migration Service)를 써야 한다. 이 방향으로 갈 일이 없다고 생각하기 쉽지만, 비용 이슈로 다운그레이드하는 경우가 종종 있다는 얘기가 커뮤니티에 있다. 처음 선택할 때 이 비대칭성을 고려하는 게 낫다.
그러나, 또 하나는 파라미터 그룹이다. RDS 파라미터 그룹은 Aurora에 그대로 옮겨지지 않는다. shared_buffers 같은 파라미터는 Aurora가 자동 관리한다. 튜닝 감각이 다르다는 걸 미리 알아두는 게 좋다.
운영 편의성은 취향 문제
따라서, 콘솔은 두 서비스가 거의 같은 UI를 쓴다. CloudWatch 메트릭도 대부분 겹친다. 차이라면 Aurora는 Performance Insights가 기본으로 켜져 있고 무료 티어 범위가 넓다는 것 정도다.
반면, 백업은 두 서비스 모두 자동 스냅샷을 지원하지만 Aurora의 Backtrack이 독특하다. 최대 72시간 전 상태로 되돌리는 기능인데, 이건 MySQL 호환 클러스터에서만 된다. PostgreSQL 호환은 아직 미지원이다(2026년 6월 확인). 개인적으로 이 기능 하나 때문에 MySQL 호환 Aurora를 쓰는 팀도 봤다.
실제로 뭘 써야 할지 결정하는 3단계
이 글을 다 읽고 나서 당장 실행할 수 있는 액션 3개다.
- 현재 RDS를 쓰고 있다면 CloudWatch에서 최근 30일 IOPS 사용량과 스토리지 사용률을 뽑아라. IOPS가 3000을 넘거나 스토리지 사용률이 60%를 넘으면 Aurora 견적을 내볼 만하다.
- AWS Pricing Calculator에서 3가지 시나리오(RDS, Aurora Standard, Aurora I/O-Optimized)를 다 넣고 월 비용을 뽑아라. IOPS와 스토리지를 실측 기준으로 넣어야 의미가 있다.
- 프로덕션 이관 전에 pgbench로 최소 30분씩 벤치마크를 돌려라. 공식 수치와 자기 워크로드는 다르다.
그래서, 다음엔 Aurora Serverless v2의 Auto-Pause를 프로덕션에 붙여보고 재개 지연을 실측해볼 생각이다.
관련 글
- EC2 스팟 인스턴스 설정 실전 가이드 — 비용 70% 절감과 중단 핸들링 – 온디맨드, Savings Plans, 스팟 인스턴스를 워크로드 관점에서 비교한다. 중단 신호 핸들링과 Auto Scaling 연동 설정까지…
- AWS IAM AssumeRole 사용법 완벽 가이드 — 계정 간 역할 전환과 임시 자격증명 – AWS IAM AssumeRole 사용법을 신뢰 정책과 권한 정책의 분리, CLI 프로파일, boto3 자격증명 자동 갱신, Role Ch…
- AWS EC2 Auto Scaling 설정 — Target Tracking·Step Scaling 비교와 알람 연동 – 트래픽 급증에 ASG가 늦게 반응하는 원인은 정책 선택만의 문제가 아니다. 워밍업, 알람 평가 시간, 스케일인 보호까지 묶어서 살펴본다.