AWS 03-1 관계형 DB를 맡긴다 — RDS·Aurora·Aurora DSQL

서울에서 PostgreSQL 을 운영용 db.r7g.large(2 vCPU·16 GiB) 한 대로 띄우면 RDS(Relational Database Service)는 시간당 $0.2869, Aurora 는 $0.333 입니다. 한 대만 놓고 보면 Aurora 가 16% 비쌉니다. 그런데 운영 DB 는 보통 한 대로 두지 않습니다. 장애가 나면 넘겨받을 대기 서버와, 읽기 요청을 나눠 받을 복제본을 더 둡니다. RDS 는 이 둘을 따로 세워야 해서 세 대가 되지만, Aurora 는 복제본 한 대가 대기 역할까지 겸해서 두 대로 끝납니다. 그래서 같은 구성을 갖추면 Aurora 쪽 월 청구서가 140달러 넘게 가볍습니다(계산은 「같은 사양이면 얼마나 차이 나나」 절). 세 번째 선택지 Aurora DSQL 에는 인스턴스가 없어서 시간당 요금이라는 항목부터 없습니다.

값이 뒤집히는 까닭은 저장소를 다루는 방식이 셋 다 다르기 때문입니다. RDS 는 인스턴스마다 자기 디스크를 붙이고, Aurora 는 여러 인스턴스가 저장소 하나를 나눠 쓰고, DSQL 은 인스턴스도 저장소도 사용자에게 보이지 않게 감춘 채 처리한 일의 양만큼 받습니다. 요금은 전부 2026-09-23 서울 리전(ap-northeast-2) 기준이고, 한 달은 730시간으로 셉니다.

지도

flowchart TD
    START["관계형 DB 가 필요하다"] --> Q1{"엔진이 MySQL·PostgreSQL 인가"}
    Q1 -- "아니다" --> RDS["RDS<br/>Oracle·SQL Server·Db2·MariaDB 포함 6종"]
    Q1 -- "그렇다" --> Q2{"인스턴스 클래스를 직접 고르나"}
    Q2 -- "고른다" --> Q3{"읽기 분산·수십 초 장애 조치가 필요한가"}
    Q3 -- "아직 아니다" --> RDS
    Q3 -- "필요하다" --> AUR["Aurora<br/>인스턴스 여럿이 저장소 하나를 공유"]
    Q2 -- "용량을 맡긴다" --> Q4{"PostgreSQL 이고<br/>트리거·확장·큰 트랜잭션 없이 되나"}
    Q4 -- "된다" --> DSQL["Aurora DSQL<br/>인스턴스 없음, 처리량만큼 과금"]
    Q4 -- "안 된다. 또는 MySQL" --> SV2["Aurora Serverless v2<br/>ACU 로 늘고 0 까지 준다"]

1. RDS — 다중 AZ 가 두 방식이라는 것부터

RDS 는 IBM Db2·MariaDB·SQL Server·MySQL·Oracle·PostgreSQL 여섯 엔진 가운데 하나를 깐 인스턴스를 빌려 주고, 백업·패치·장애 감지와 복구를 맡는 서비스입니다(What is Amazon RDS?). 인스턴스 클래스 이름 읽는 법은 AWS 01-1 서버를 통째로 빌린다 — EC2·Lightsail·Beanstalk·CloudShell 1절과 같고 앞에 db. 만 붙습니다. t 계열은 크레딧이 바닥나도 계속 달리는 unlimited 모드로만 돌고, 24시간 평균이 기준을 넘으면 vCPU 시간당 $0.075 가 더 붙습니다.

콘솔의 「다중 AZ」 밑에는 성격이 다른 두 방식이 있습니다. 다중 AZ 인스턴스 방식은 다른 AZ 에 대기 한 대를 두고 넘겨받을 준비만 시키고, 다중 AZ 클러스터 방식은 AZ 셋에 인스턴스 셋을 두어 대기 둘이 읽기까지 받게 합니다. 둘을 나란히 놓으면 이렇습니다.

(Multi-AZ DB instance deployments · Multi-AZ DB cluster deployments · Failing over a Multi-AZ DB cluster · Amazon RDS FAQs)

인스턴스 방식은 두 대 값을 내고 읽기는 한 대만 받습니다. 대기가 쓰는 스토리지 값도 같이 내므로 gp3 는 서울 GB-월 $0.131 이 다중 AZ 에서 $0.262 로 두 배가 됩니다. 주 인스턴스와 대기 사이의 복제 전송은 무료입니다.

RDS 를 써 봤어도 놓치기 쉬운 것이 셋 더 있습니다.

• 읽기 전용 복제본은 손으로 늘리고 줄입니다. 주 인스턴스의 변경을 비동기로 받는 읽기 전용 인스턴스이고, 모든 엔진이 원본 하나에 최대 15개입니다. Oracle 은 복제 지연을 줄이려면 5개 이하를 권합니다. RDS 는 복제본 자동 증감을 지원하지 않습니다(Working with DB instance read replicas · Quotas and constraints for Amazon RDS)
• 엔진 버전 업그레이드는 다중 AZ 여도 멈춥니다. OS 패치는 대기를 먼저 고친 뒤 넘겨 받아서, 계획된 이 전환은 보통 1분 미만입니다. 엔진 업그레이드는 주와 대기를 동시에 고칩니다. SQL Server 는 롤링 업그레이드로 전환 시간만큼만 멈추고, MySQL·PostgreSQL·MariaDB 는 블루/그린 배포로 멈추는 시간을 줄일 수 있습니다(Maintaining a DB instance)
• 특정 시점 복구(PITR, Point-In-Time Recovery)는 원본을 되돌리지 않고 새 인스턴스를 만듭니다. 보존은 0~35일이고, 백업 저장은 리전의 DB 스토리지 합계만큼 무료, 초과분은 서울 GB-월 $0.095 입니다(Restoring a DB instance to a specified time)

늘 켜 둘 DB 라면 약정을 겁니다. 예약 인스턴스는 엔진·클래스 패밀리·리전을 정해 1년이나 3년 약정하고 최대 69% 를 깎습니다. 스토리지·I/O 는 깎아 주지 않습니다(Amazon RDS Reserved Instances). Database Savings Plans 는 1년 동안 시간당 얼마어치를 쓰겠다고 약속하는 방식이고, 엔진·패밀리·리전을 바꿔도 할인이 따라갑니다. 프로비저닝 인스턴스는 최대 20%, Serverless v2·DSQL 같은 서버리스는 최대 35% 이고, 같은 워크로드에 RDS 예약 인스턴스와 겹쳐 받지 못합니다(Introducing Database Savings Plans · Database Savings Plans pricing). EC2 쪽 두 약정의 차이는 AWS 01-1 서버를 통째로 빌린다 — EC2·Lightsail·Beanstalk·CloudShell 1절에 있습니다.

RDS Proxy 는 커넥션 풀을 대신 맡는 관리형 프록시입니다. Lambda 함수처럼 연결을 자주 여는 앱이 DB 연결을 고갈시키지 않게 막고, 장애 조치 동안 앱 쪽 연결을 붙잡아 둡니다(Amazon RDS Proxy).

모아 보면 RDS 는 엔진을 고르는 폭이 넓고 I/O 값이 없는 대신, 읽기 분산과 빠른 전환은 따로 사서 붙여야 합니다.

복제본을 여러 대 두기 시작하고 복제 지연이 신경 쓰이기 시작했다면 Aurora 로 옮길 때입니다.

2. Aurora — 인스턴스 여럿이 저장소 하나를 나눠 쓴다

Aurora 는 MySQL·PostgreSQL 과 호환되는 엔진을 쓰되, 계산을 맡는 인스턴스와 데이터를 담는 클러스터 볼륨을 떼어 놓은 관계형 DB 입니다. RDS 다중 AZ 는 주 인스턴스와 대기가 각자 EBS 디스크를 붙이고 주 인스턴스가 대기에게 복제합니다. Aurora 는 모든 인스턴스가 같은 볼륨 하나를 봅니다.

flowchart TD
    APP["애플리케이션"] --> CEP["클러스터 엔드포인트<br/>늘 쓰기 인스턴스를 가리킴"]
    APP --> REP["리더 엔드포인트<br/>읽기 복제본에 나눠 보냄"]
    CEP --> W["쓰기 인스턴스<br/>AZ-a"]
    REP --> R1["읽기 복제본<br/>AZ-b"]
    W -- "쓰기: 사본 6개에 복제" --> VOL
    R1 -- "읽기" --> VOL
    subgraph VOL["클러스터 볼륨 — AZ 셋에 사본 6개"]
        SA["AZ-a<br/>사본 2개"]
        SB["AZ-b<br/>사본 2개"]
        SC["AZ-c<br/>사본 2개"]
    end

볼 곳은 화살표의 방향입니다. 복제는 인스턴스 사이가 아니라 쓰기 인스턴스와 볼륨 사이에서 일어납니다. 볼륨은 10 GiB 조각마다 AZ 셋에 여섯 벌을 두고(AZ 마다 두 벌), 사본 둘을 잃어도 쓰기가, 셋을 잃어도 읽기가 멈추지 않게 설계돼 있습니다. 인스턴스를 몇 대 두든 복제는 똑같이 일어나고, 요금은 사본 한 개 값만 받습니다(Availability and Durability · Amazon Aurora under the hood: quorums and correlated failure · Amazon Aurora pricing). 볼륨을 나눠 쓰는 이 구조 때문에 복제본·저장소·장애 전환이 RDS 와 다르게 움직입니다.

(Replication with Amazon Aurora · Quotas and constraints for Amazon Aurora · High availability for Amazon Aurora)

마지막 줄이 함정입니다. Aurora 인스턴스 한 대는 다중 AZ 가 아닙니다. 데이터는 AZ 셋에 있어도 계산은 한 AZ 에 있어서, AZ 가 통째로 내려가면 다른 AZ 에 인스턴스를 손으로 만들어야 합니다. 복제본이 대기를 겸하는 대가도 있습니다. 장애 전환 동안에는 복제본이 쓰기를 넘겨받느라 그 복제본이 받던 읽기가 잠깐 끊깁니다.

I/O 과금 두 방식

I/O 는 DB 가 저장소에 읽고 쓰는 요청 한 건 한 건입니다. Aurora 는 여기에 값을 매기는 방법이 둘이고, 클러스터마다 하나를 고릅니다. Aurora Standard 는 저장소를 싸게 받고 I/O 를 건수대로 받습니다. Aurora I/O-Optimized 는 I/O 값을 없애는 대신 인스턴스와 저장소 단가를 올립니다.

(Amazon Aurora storage)

따로 붙는 비용은 넷입니다. 백업 저장은 클러스터 크기만큼 무료이고 초과분은 GB-월 $0.023 입니다. AZ 사이의 클러스터 복제 전송은 무료, 다른 AZ 의 EC2 와 주고받는 트래픽은 리전 내 전송 요금을 냅니다. t 계열 CPU 크레딧은 vCPU 시간당 $0.09 입니다. 그리고 AWS 는 Aurora 의 T 클래스를 개발·테스트용으로만 권합니다(DB instance class types). 그래서 끝의 비용 비교는 db.r7g.large 로 셉니다.

Global Database 와 Serverless v2

읽기를 다른 리전까지 넓히려면 Global Database 를 씁니다. 한 리전의 주 클러스터를 최대 10개 다른 리전의 읽기 전용 클러스터로 복제하는 기능이고, 지연은 보통 1초 미만입니다(Using Amazon Aurora Global Database).

인스턴스 클래스를 고르는 일 자체를 맡기고 싶다면 Aurora Serverless v2 입니다. 인스턴스 클래스 대신 용량 범위를 정해 두면 부하에 따라 늘고 주는 Aurora 인스턴스입니다. 단위 ACU(Aurora Capacity Unit)는 메모리 약 2 GiB 에 그만큼의 CPU·네트워크를 묶은 양이고, 범위는 0~256 ACU, 서울 요금은 ACU-시간 $0.20(I/O-Optimized 면 $0.26)입니다. 최소를 0 으로 두면 사용자 연결 없이 정한 시간(5분~1일)이 지난 뒤 자동 일시 중지되어 인스턴스 값이 0 이 되고, 저장소 값만 남습니다. 다시 연결하면 보통 약 15초, 24시간 넘게 멈춰 있었으면 30초 이상 걸려 깨어납니다.

대표적으로 이런 클러스터는 멈추지 않습니다. 사용자 연결이 열려 있거나, RDS Proxy 를 붙였거나, 프로비저닝 인스턴스가 섞여 있거나, 논리 복제(변경 내역을 다른 DB 로 흘려보내는 PostgreSQL 논리 복제·MySQL binlog 복제)를 켰거나, Global Database 의 주 클러스터인 경우입니다(How Aurora serverless works · Scaling to Zero ACUs). 평일 하루 8시간만 4 ACU 로 쓰고 나머지는 멈춘다면 4 × $0.20 × 8 × 22 = 월 $140.80 입니다.

정리하면 Aurora 는 복제본이 대기를 겸하고 전환이 빠른 대신, I/O 가 청구서에 실리고 작은 운영 DB 는 비싸집니다.

청구서에서 I/O 줄이 전체의 25% 를 넘으면 I/O-Optimized 로 바꾸면 됩니다. 쓰기를 여러 대로 나눠야 하거나 두 리전에서 동시에 써야 하면 DSQL 로 갑니다.

3. Aurora DSQL — 인스턴스가 없는 PostgreSQL 호환 DB

Aurora DSQL 은 AWS 가 서버리스 분산 SQL 데이터베이스로 내놓은 서비스이고, PostgreSQL 16 과 호환됩니다. 인스턴스를 고르지 않고 클러스터 엔드포인트에 PostgreSQL 드라이버로 붙습니다. 2024-12-03 프리뷰, 2025-05-27 정식 출시, 서울은 2025-07-03 부터입니다(Release notes for Aurora DSQL).

인스턴스가 없는 대신 계산·커밋·저장 구성 요소를 따로 배치해 단일 리더가 없고, 읽기와 쓰기가 각각 늘어납니다(Aurora DSQL FAQs). 구성 요소마다 AZ 셋에 나뉘어 돌고, 설계상 가용성은 단일 리전 99.99%, 다중 리전 99.999% 입니다. 다중 리전 클러스터는 두 리전 엔드포인트가 모두 읽기와 쓰기를 받고 강한 일관성을 지킵니다. 짝은 같은 대륙 묶음 안에서만 지어서, 서울은 뭄바이·오사카·싱가포르·도쿄와 묶입니다(What is Amazon Aurora DSQL?).

잠그지 않고, 커밋 때 판정한다

PostgreSQL 은 같은 행을 두 트랜잭션이 고치려 하면 뒤에 온 쪽을 잠금으로 기다리게 합니다. DSQL 은 둘 다 끝까지 진행시키고 커밋하는 순간 겹쳤는지를 봅니다. 이것이 낙관적 동시성 제어(OCC, Optimistic Concurrency Control)입니다. 판정 기준은 「내가 시작한 뒤 남이 같은 행을 먼저 커밋했나」 하나이고, 먼저 커밋한 쪽이 이깁니다. 늦은 쪽은 이 오류를 받습니다.

ERROR: change conflicts with another
  transaction (OC000) (SQLSTATE 40001)

• 40001 — PostgreSQL 의 직렬화 실패(serialization failure) 코드
• OC000 — 같은 행을 둘이 고친 데이터 충돌. 스키마가 바뀌어 난 충돌은 OC001

잠금이 없으니 데드락도, 느린 트랜잭션이 남을 붙잡는 일도 없습니다. 대가는 재시도가 앱의 몫이라는 점입니다. AWS 는 트랜잭션을 여러 번 돌려도 결과가 같게(멱등하게) 짜고 40001 을 받으면 다시 돌리라고 권하며, 기본 키를 UUID 처럼 흩어진 값으로 잡아 한 키에 쓰기가 몰리지 않게 하라고 덧붙입니다(Concurrency control in Aurora DSQL).

한도와 달라지는 것

잠금 대신 커밋 판정을 쓰는 것만 다른 게 아닙니다. 「PostgreSQL 호환」은 드라이버·ORM·SQL 문법이 통한다는 뜻이지 전부 된다는 뜻이 아니고, 2026-09-23 기준으로 막히거나 달라지는 것은 이렇습니다.

(Migrating from PostgreSQL to Aurora DSQL · Supported SQL for Aurora DSQL · Cluster quotas and database limits · Working with foreign key constraints)

외래 키와 시퀀스는 정식 출시 뒤에 들어왔습니다. 「DSQL 은 외래 키가 안 된다」는 글은 날짜부터 확인합니다. 가장 오래 남을 한도는 트랜잭션당 3,000행·5분입니다. 수만 행을 한 트랜잭션으로 고치는 배치나 마이그레이션은 잘게 나눠 다시 짜야 합니다.

요금 — DPU 와 저장소

DPU(Distributed Processing Unit)는 DSQL 이 SQL 을 처리하며 한 일의 양입니다. 계산(CPU 시간)·읽기(읽은 바이트)·쓰기(쓴 바이트)를 합치고, 다중 리전이면 다른 리전에 복제한 쓰기만큼, 변경 데이터 스트림(CDC)을 켜면 흘려보낸 바이트만큼이 더 붙습니다. 요청이 없으면 DPU 는 0 입니다(How billing works in Aurora DSQL · Aurora DSQL pricing). 서울 단가는 DPU 와 저장소 둘로 나뉩니다.

한 번에 쓰는 DPU 는 크지 않습니다. 약 100바이트 행 5개를 돌려주는 단건 조회가 실행 3 ms 일 때 0.00675 DPU, 행 하나를 넣는 삽입이 실행 8 ms 일 때 0.06175 DPU 입니다. 읽기 트랜잭션은 최소 2,048바이트, 쓰기는 최소 1,024바이트로 치므로 작은 쿼리를 따로따로 날리면 최소치가 쌓입니다.

모아 보면 DSQL 은 운영할 것이 거의 없고 쉬는 동안 계산 값이 0 인 대신, PostgreSQL 기능 일부와 큰 트랜잭션을 내주고 재시도를 앱이 떠안습니다.

트랜잭션 한도에 자주 걸리거나 없는 기능을 앱에서 우회하는 코드가 늘어나면 Aurora PostgreSQL 로 돌아갈 때입니다.

같은 사양이면 얼마나 차이 나나

조건을 하나로 맞춥니다. 서울, PostgreSQL, db.r7g.large(2 vCPU·16 GiB), 데이터 100 GB, 한 달 730시간. 나가는 전송량은 넷 모두 같은 표준 요금이라 뺐고, 백업은 무료 한도 안이라고 봅니다. 단가는 RDS 단일 AZ $0.2869·다중 AZ 두 대 합계 $0.5738, Aurora Standard $0.333·I/O-Optimized $0.433, 저장소는 앞 표의 값입니다. 견줄 구성은 RDS 다중 AZ(A), 거기에 읽기 전용 복제본 한 대를 더한 A', Aurora 의 두 과금 방식(B·C) 넷입니다.

• B 와 C 가 같아지는 I/O: (659.18 − 498.18) ÷ 0.24 ≈ 월 6억 7천만 건. 그 위로는 C 가 쌉니다
• B 와 A' 가 같아지는 I/O 는 월 7억 1천만 건이지만, 그 전에 C 로 바꾸면 C($659.18)가 A'($667.61)보다 쌉니다
• 월 1억 건은 평균 초당 약 38건입니다. 실제 값은 Aurora 의 I/O 지표로 확인합니다

A 와 B 는 하는 일이 다릅니다. A 의 대기는 읽기를 못 받고, B 의 복제본은 대기와 읽기 분산을 겸합니다. B 와 같은 일을 RDS 로 시키면 A' 가 되고, 한 대가 더 많은데도 장애 전환은 1~2분으로 B(흔히 30초 미만)보다 느립니다. 대신 B 는 장애 전환 동안 읽기 분산이 잠깐 사라집니다.

그러면 지금 RDS 다중 AZ 를 쓰고 있다면 Aurora 로 옮겨야 할까요.

• 다중 AZ 만 쓰고 복제본이 없다면 그대로 둡니다. A 가 B 보다 I/O 를 빼고도 $53 쌉니다
• 읽기 전용 복제본까지 쓴다면 Aurora 가 쌉니다. 이 조건에서 A'($667.61)보다 B 는 I/O 월 1억 건에서 $145 싸고, I/O 가 늘면 C 로 바꿔 어느 경우에도 A' 아래에 머뭅니다
• 옮기는 방법은 RDS for MySQL·PostgreSQL 인스턴스에서 Aurora 읽기 복제본을 만드는 방식이 이전용으로 안내돼 있습니다(Replication with Amazon Aurora)

DSQL 은 인스턴스가 없고 I/O 건수를 DPU 로 바꿔 셀 수도 없어서 위 표에 못 넣습니다. 아래는 앞의 조회·삽입 DPU 로 센 참고 수치입니다(백업 제외).

D. Aurora DSQL 단일 리전 · 데이터 100 GB
 저장소 $0.40 × (100 − 1 무료) = $39.60

 월 조회 1,000만 · 삽입 100만
   129,250 DPU − 무료 100,000
   = 29,250 DPU → $0.29
   합계 ≈ $39.89

 트래픽 10배 (조회 1억 · 삽입 1,000만)
   1,292,500 − 100,000
   = 1,192,500 DPU → $11.93
   합계 ≈ $51.53

• 조인·범위 스캔이 많으면 읽은 바이트만큼 DPU 가 커집니다
• 데이터가 1 TB 가 되면 저장소만 월 약 $400 으로, Aurora Standard 저장소($120)와 차이가 벌어집니다

셈을 모으면, 인스턴스를 고르는 방식 중에서는 다중 AZ 만 필요하면 RDS(A), 복제본까지 필요하면 Aurora(B, I/O 가 월 6억 7천만 건을 넘으면 C)가 쌉니다. DSQL 은 트래픽이 작을수록 계산 값이 0 에 가까워지지만, 데이터가 커질수록 GB 당 $0.40 이 청구서의 대부분이 됩니다.

자주 붙는 서비스

EC2·Lambda(DB 에 붙는 앱) · VPC·보안 그룹(DB 를 사설망에 둔다) · Secrets Manager(DB 암호 보관·교체) · CloudWatch(지표·알람) · AWS Backup(백업 일괄 관리) · DMS(다른 DB 에서 옮겨 오기)

이럴 땐 무엇

한 장 요약

RDS 는 엔진을 그대로 주고, Aurora 는 저장 계층을 바꾸고, DSQL 은 트랜잭션 모델까지 바꿉니다. 오른쪽으로 갈수록 관리할 것이 줄고 PostgreSQL 에서 기대던 기능이 빠집니다. RDS 다중 AZ 인스턴스 방식은 대기가 읽기를 못 받고, Aurora 는 I/O 가 전체의 25% 를 넘으면 I/O-Optimized 로 바꿉니다. DSQL 은 트랜잭션당 3,000행·5분이 한도이고 40001 을 받으면 앱이 다시 돌립니다. 서울 db.r7g.large 기준으로 복제본까지 쓰면 Aurora 가, 다중 AZ 만 쓰면 RDS 가 쌉니다.

관련 항목

관리형 관계형 DB 의 같은 갈래

RDS · Aurora · Aurora DSQL · Aurora Serverless v2 · RDS Custom

이 서비스들이 돌리는 엔진

PostgreSQL · MySQL · MariaDB · Oracle Database · SQL Server · Db2

가용성을 떠받치는 장치

다중 AZ 배포 · 읽기 전용 복제본 · 장애 조치 · 가용 영역 · 동기 복제 · 반동기 복제 · 복제 · Aurora Global Database

데이터를 되살리는 장치

자동 백업 · 특정 시점 복구 · DB 스냅샷 · 유지 관리 창 · 블루/그린 배포

저장소와 I/O 를 이루는 부품

EBS · gp3 · IOPS · 클러스터 볼륨 · Aurora I/O-Optimized · 스토리지 자동 확장

DSQL 이 트랜잭션을 다루는 방식

낙관적 동시성 제어 · 비관적 동시성 제어 · 직렬화 실패 · 격리 수준 · 스냅샷 격리 · MVCC · 데드락 · 외래 키 · 트리거

이 DB 들을 사는 요금 방식

온디맨드 인스턴스 · 예약 인스턴스 · Database Savings Plans · Savings Plans · ACU · DPU · CPU 크레딧

앱과 DB 사이에 끼는 것

RDS Proxy · 커넥션 풀 · DNS · Secrets Manager · Lambda

관계형이 아닌 이웃

DynamoDB · ElastiCache · DocumentDB · 샤딩