초보 개발자

AWS RDS와Aurora 비교 본문

AWS

AWS RDS와Aurora 비교

taehyeki 2025. 6. 8. 17:47

AWS RDS와 Aurora 상세 비교 분석

1. RDS와 Aurora의 기본 설명

Amazon RDS 
Amazon RDS는 AWS 클라우드에서 관계형 데이터베이스를 설정, 운영 및 확장할 수 있게해주는 관리형 서비스입니다. 

데이터베이스 관리의 많은 일상적인 작업(프로비저닝,백업, 패치 적용, 복구, 장애 감지, 복구)을 자동화하여 사용자의 운용 관리 작업 부담을 덜어줍니다.

RDS는 MySQL, PostgreSQL, MariaDB, Oracle, Microsoft SQL Server 등 다양한 상용 및 오픈 소스 데이터베이스 엔진을 지원합니다.

Amazon Aurora
Amazon Aurora는 MySQL 및 PostgreSQL과 호환되는 AWS의 클라우드 네이티브 관계형 데이터베이스입니다. 기존 데이터베이스와 달리 스토리지와 컴퓨팅을 분리한 분산 아키텍처를 사용하여 고성능, 고가용성을 제공합니다.

Aurora는 표준 MySQL 대비 최대 5배 , PostgreSQL 대비 최대 3배의 성능을 제공하며, 데이터를 3개의 가용 영역(AZ)에 걸
쳐 6개의 복제본으로 자동 복제하여 뛰어난 내구성을 보장합니다.

 

2. RDS와 Aurora 상세 비교표

비교 항목  Amazon RDS Amazon Aurora
지원 엔진 MySQL, PostgreSQL, MariaDB, Oracle, SQL Server MySQL, PostgreSQL와 호환
스토리지 아키텍처 인스턴스마다 독립 스토리지 컴퓨트/스토리지 분리, 6중 AZ 블록 레벨 복제
스토리지 확장 자동 증가 지원, 최대 64TiB 자동 증가, 최대 128 TiB
Auto Scaling (읽기 복제본) 지원 없음, 수동 생성/삭제 필요 CPU/커넥션 기준 자동 리더 추가/삭제
읽기 복제본 수 최대 5개 최대 15개
복제 지연 수초 ~ 수분 단위 밀리초 단위
리더 엔드포인트  제공 하지 않음( 각 복제본에 개별 연결 ) 제공 ( 자동 로드 밸런싱 )
멀티 AZ 인스턴스, 클러스터 타입 지원  읽기 복제본 생성 필요.
가용성 멀티 AZ시 99.95% 99.99%
성능 표준 성능  MySQL 대비 최대 5배, PostgreSQL 대비 3배 성능
(컴퓨트/스토리지 분리 구조에 의해)
서버리스 지원 없음 Aurora Serverless v2: ACU 기반 컴퓨트 자동 확장 및 Multi-AZ
마스터 유저
Secrets Manager 통합
지원 ( 통합 시 읽기 복제본 작성 불가)  지원

 


3. RDS가 적절한 경우 vs. Aurora가 적절한 경우


RDS가 적절한 경우:


1. 다양한 데이터베이스 엔진 필요
   • Oracle, SQL Server, MariaDB 등 Aurora에서 지원하지 않는 엔진이 필요한 경우
   • 특정 엔진의 고유 기능이나 확장 기능을 사용해야 하는 경우

2. 비용 민감성
   • 소규모 또는 중간 규모의 워크로드에서 비용 최적화가 중요한 경우
   • 데이터베이스 성능보다 비용 효율성이 우선시되는 경우
   • 개발/테스트 환경과 같이 고가용성이 덜 중요한 환경

3. 예측 가능한 워크로드
   • 트래픽 패턴이 일정하고 급격한 확장이 필요하지 않은 경우
   • 수동으로 관리할 수 있는 안정적인 워크로드

4. 기존 애플리케이션 마이그레이션
   • 기존 온프레미스 데이터베이스를 최소한의 변경으로 클라우드로 이전하려는 경우
   • 특정 데이터베이스 버전에 의존하는 레거시 애플리케이션

5. 단순한 아키텍처 요구
   • 복잡한 고가용성 설정이나 글로벌 배포가 필요하지 않은 경우
   • 기본적인 백업 및 복구 기능으로 충분한 경우

Aurora가 적절한 경우:

1. 고성능 요구
   • 높은 처리량과 낮은 지연 시간이 필요한 트랜잭션 워크로드
   • 대규모 데이터셋에 대한 복잡한 쿼리 처리가 필요한 경우

2. 고가용성 및 내구성 중요
   • 99.99% 이상의 가용성이 필요한 미션 크리티컬 애플리케이션
   • 데이터 손실을 최소화해야 하며, 빠른 장애 복구가 필요한 경우

3. 자동 확장 필요
   • 예측할 수 없는 워크로드나 급격한 트래픽 증가에 대응해야 하는 경우
   • 읽기 부하에 따라 자동으로 확장/축소가 필요한 경우

4. 글로벌 배포
   • 여러 리전에 걸쳐 낮은 지연 시간으로 데이터에 액세스해야 하는 경우
   • 재해 복구를 위한 글로벌 백업 전략이 필요한 경우

5. 서버리스 운영 모델
   • 간헐적인 워크로드나 예측할 수 없는 트래픽 패턴

6. 고급 기능 활용
   • 백트래킹, 병렬 쿼리, 데이터 API 등의 기능이 필요한 경우
   • 기계 학습 통합이나 Zero-ETL 기능이 필요한 경우
   • 고급 모니터링 및 성능 최적화 도구가 필요한 경우

 


## 4. 다각도 비교 분석

 


### 아키텍처 및 설계 측면

RDS:
• 전통적인 단일 인스턴스 또는 다중 AZ 아키텍처 사용
• 각 인스턴스는 자체 EBS 볼륨에 데이터 저장
• 다중 AZ 배포 시 동기식 복제를 통해 대기 인스턴스 유지
• 읽기 복제본은 비동기식 복제를 통해 데이터 수신

Aurora:
• 스토리지와 컴퓨팅이 분리된 분산 아키텍처
• 데이터는 3개의 AZ에 걸쳐 6개의 복제본으로 자동 복제
• 모든 인스턴스가 동일한 분산 스토리지 볼륨 공유

Aurora의 분산 아키텍처는 스토리지 노드 장애에 더 강한 내성을 제공하며, 데이터베
이스 인스턴스와 스토리지를 분리함으로써 더 빠른 장애 복구와 확장성을 제공합니다.

### 확장성 측면

RDS:
• 수직적 확장: 인스턴스 유형 변경 (다운타임 발생 가능)
• 수평적 확장: 읽기 전용 복제본 수동 추가 (최대 5개)
• 복제본 오토스케일링 불가: 수동으로 스케일 인/아웃 필요
• 리더 엔드포인트 없음: 복제본 간 로드 밸런싱을 위해 별도의 NLB 필요
• 스토리지 확장: 수동으로 확장 필요, 프로비저닝된 IOPS 조정 필요

Aurora:
• 수직적 확장: 인스턴스 유형 변경 (최소한의 다운타임)
• 수평적 확장: 최대 15개의 Aurora 복제본 지원
• Aurora Auto Scaling: CPU 사용률 또는 연결 수에 따라 자동으로 복제본 추가/제거
• 리더 엔드포인트 제공: 모든 복제본에 대한 자동 로드 밸런싱
• 스토리지 자동 확장: 10GB 단위로 최대 128TB까지 자동 확장
• Aurora Serverless: 사용량에 따라 자동으로 용량 조정 (ACU 단위)

Aurora는 특히 읽기 워크로드 확장에 있어 더 유연하고 자동화된 접근 방식을 제공합
니다. Aurora Auto Scaling은 트래픽 패턴에 따라 자동으로 복제본을 추가하거나 제거
할 수 있으며, 리더 엔드포인트를 통해 복제본 간 로드 밸런싱을 자동으로 처리합니다
.

### 가용성 및 내구성 측면

RDS:
• 다중 AZ 배포: 99.95% 가용성 제공
• 장애 복구 시간: 일반적으로 60-120초
• 데이터 복제: 동기식 복제를 통해 대기 인스턴스에 복제 (다중 AZ 배포 시)
• 백업: 일일 자동 백업 및 수동 스냅샷
• 백업 보존: 최대 35일
• 특정 시점 복구: 백업 보존 기간 내에서 가능

Aurora:
• 기본 가용성: 99.99% 이상
• 장애 복구 시간: 일반적으로 30초 미만 (약 10초)
• 데이터 복제: 3개 AZ에 걸쳐 6개 복제본으로 자동 복제
• 백업: 연속 백업 및 자동 스냅샷
• 백업 보존: 최대 35일
• 백트래킹: 최대 72시간 내에서 특정 시점으로 빠르게 되돌리기 가능 (스냅샷 복원
없이)
• 글로벌 데이터베이스: 재해 복구를 위한 여러 리전에 걸친 복제 지원

Aurora는 더 강력한 데이터 복제 모델과 빠른 장애 복구 메커니즘을 제공합니다. 특히
백트래킹 기능은 데이터베이스를 특정 시점으로 빠르게 되돌릴 수 있어, 실수로 인한
데이터 손실을 쉽게 복구할 수 있습니다.

### 성능 측면

RDS:
• 표준 데이터베이스 엔진 성능
• I/O 성능: 프로비저닝된 IOPS에 의존
• 복제 지연: 일반적으로 수초~수분 (네트워크 상태 및 부하에 따라 다름)
• 쿼리 최적화: 기본 엔진 수준의 최적화만 가능
• 연결 관리: 표준 연결 풀링 메커니즘

Aurora:
• MySQL 대비 최대 5배, PostgreSQL 대비 최대 3배 향상된 성능
• I/O 최적화: 로그 기반 아키텍처로 I/O 작업 최소화
• 복제 지연: 밀리초 단위 (10-20ms)
• 병렬 쿼리: 대규모 데이터셋에 대한 쿼리 병렬 처리 지원
• 쿼리 캐싱: 향상된 쿼리 캐싱 메커니즘
• 연결 관리: RDS Proxy를 통한 효율적인 연결 관리
• 쿼리 실행 계획 관리: Aurora PostgreSQL의 Query Plan Management

Aurora의 성능 향상은 주로 스토리지 계층의 재설계와 데이터베이스 엔진 최적화에서
비롯됩니다. 특히 로그 기반 아키텍처는 I/O 작업을 최소화하고, 병렬 쿼리 기능은 대
규모 데이터셋에 대한 분석 쿼리 성능을 크게 향상시킵니다.

### 관리 및 운영 측면

RDS:
• 시크릿 매니저 통합: 제한적 (수동 구성 필요)
• 모니터링: 기본 CloudWatch 지표
• 이벤트 알림: 기본 SNS 통합
• 파라미터 그룹: 인스턴스 수준 파라미터 관리
• 유지 관리 기간: 수동 설정 필요
• 버전 업그레이드: 수동 또는 자동 마이너 버전 업그레이드
• 블루/그린 배포: 지원 (RDS Blue/Green Deployments)

Aurora:
• 시크릿 매니저 통합: 기본 지원 (자동 교체 포함)
• 모니터링: 향상된 모니터링 + Performance Insights
• 이벤트 알림: 세분화된 이벤트 알림 시스템
• 클러스터 파라미터 그룹: 클러스터 및 인스턴스 수준 파라미터 관리
• 유지 관리 기간: 더 유연한 관리 옵션
• 버전 업그레이드: 제로 다운타임 패치 및 업그레이드 지원
• 블루/그린 배포: 더 빠른 전환 시간

Aurora는 더 많은 운영 작업을 자동화하고, 더 상세한 모니터링 및 관리 도구를 제공
합니다. 특히 Performance Insights는 데이터베이스 성능 문제를 식별하고 해결하는
데 도움이 되는 강력한 도구입니다.

### 통합 및 확장 기능 측면

RDS:
• AWS 서비스 통합: 기본적인 통합 (IAM, CloudWatch, SNS 등)
• 데이터 API: 지원하지 않음
• 기계 학습 통합: 제한적
• ETL 통합: 수동 구성 필요
• 이벤트 기반 트리거: 제한적

Aurora:
• AWS 서비스 통합: 광범위한 통합 (Lambda, SageMaker, Comprehend 등)
• 데이터 API: HTTP 엔드포인트를 통한 SQL 쿼리 실행 지원
• Aurora Machine Learning: SageMaker 및 Comprehend와의 통합
• Zero-ETL 통합: Amazon Redshift와의 실시간 데이터 통합
• 이벤트 기반 트리거: 향상된 이벤트 처리 기능

Aurora는 다른 AWS 서비스와의 더 깊은 통합을 제공하며, 특히 서버리스 아키텍처와
기계 학습 워크로드에 대한 지원이 뛰어납니다. 데이터 API는 서버리스 함수에서 데이
터베이스에 쉽게 접근할 수 있게 해주며, Aurora Machine Learning은 SQL 쿼리 내에서
직접 기계 학습 모델을 호출할 수 있게 합니다.

### 비용 측면

RDS:
• 인스턴스 비용: 표준 RDS 인스턴스 요금
• 스토리지 비용: 프로비저닝된 스토리지에 대한 비용 (사용량과 관계없이)
• 백업 비용: 자동 백업은 프로비저닝된 스토리지의 100%까지 무료, 이후 추가 비용
• I/O 비용: 프로비저닝된 IOPS에 따른 비용
• 다중 AZ 비용: 대기 인스턴스에 대한 추가 비용

Aurora:
• 인스턴스 비용: RDS보다 약 20% 높은 인스턴스 비용
• 스토리지 비용: 실제 사용한 스토리지에 대해서만 비용 지불
• I/O 비용: 요청 기반 요금 (별도의 IOPS 프로비저닝 불필요)
• 백업 비용: 클러스터 볼륨 크기의 100%까지 무료, 이후 추가 비용
• Aurora Serverless: 실제 사용한 ACU에 대해서만 비용 지불

Aurora는 초기 인스턴스 비용이 더 높지만, 분산 아키텍처와 자동화된 관리 기능으로
인해 총소유비용(TCO)이 낮아질 수 있습니다. 특히 Aurora Serverless는 간헐적 워크
로드에 비용 효율적이며, 스토리지 비용도 실제 사용량에 기반하므로 더 효율적입니다
.

'AWS' 카테고리의 다른 글

「AWS」EC2에 접속하는 4가지 방법  (0) 2024.09.22
[CDK] Unable to resolve AWS account to use.  (0) 2024.01.13
AWS KMS 암복호화 과정  (0) 2024.01.07
AWS Snapshot storage  (0) 2023.08.07
AWS RDS 관련 질문  (0) 2023.06.22