17.2 AWS Aurora PostgreSQL

Aurora PostgreSQL은 AWS가 PostgreSQL 호환으로 만든 클라우드 네이티브 DB. wire 프로토콜·SQL은 표준 PostgreSQL 그대로지만, 스토리지 엔진과 복제 메커니즘을 AWS가 자체 구현. RDS보다 확장성·HA·복제 성능이 강하고, 비용은 더 높습니다.

구조

    flowchart TD
  W["writer instance"]
  R1["reader instance 1"]
  R2["reader instance 2"]
  R3["reader instance N"]
  S["Aurora 분산 스토리지<br/>(6 카피 across 3 AZ)"]

  W <--> S
  R1 <--> S
  R2 <--> S
  R3 <--> S

  classDef pg fill:#ede9fe,stroke:#6d28d9,color:#3b0764
  classDef rd fill:#d1fae5,stroke:#047857,color:#064e3b
  classDef st fill:#fed7aa,stroke:#c2410c,color:#7c2d12
  class W pg
  class R1,R2,R3 rd
  class S st
  

핵심 차이 RDS와:

• 분산 스토리지: 6 카피 across 3 AZ — durability 11 9s
• writer + readers가 같은 스토리지 공유 (streaming 복제 X)
• 자동 storage 확장 — 10GB ~ 128TB
• 빠른 failover: 1 writer 사고 시 reader 중 promote (수십 초)
• read replica 추가가 빠름: 새 스토리지 카피 안 만들어도 됨

RDS vs Aurora

클러스터 구성

Aurora Cluster
├── writer endpoint  (DNS — 항상 writer)
├── reader endpoint  (DNS — readers 라운드로빈)
└── instance endpoints (개별 instance DNS)

writer endpoint는 자동 failover 시 자동 전환. application은 그대로 사용합니다.

Aurora Serverless v2

ACU (Aurora Capacity Unit) = 메모리·CPU·네트워크의 묶음
0.5 ACU ~ 128 ACU 범위에서 자동 스케일

scale-up·scale-down이 초 단위. 코드 변경 없습니다.

Aurora I/O Optimized

인스턴스 + 스토리지 비용 ↑
I/O 비용 0 (무제한)

write 부하 큰 워크로드(WAL 폭증)에 고정 비용으로 안전합니다. 임계: 월 I/O 비용이 인스턴스 비용의 25%+ 면 검토합니다.

Aurora의 강점

1. 빠른 read replica 추가

스토리지 공유이므로 스토리지 복제 없이 instance만 추가:

aws rds create-db-instance \
  --db-instance-identifier mycluster-reader-1 \
  --db-cluster-identifier mycluster \
  --engine aurora-postgresql \
  --db-instance-class db.r6g.large

분 단위 추가.

2. global database

primary region (write) → 다른 region (read replica)

cross-region 복제가 초 단위 lag. DR 용도.

3. clone

aws rds restore-db-cluster-to-point-in-time \
  --source-db-cluster-identifier prod-cluster \
  --db-cluster-identifier prod-clone \
  --restore-to-time '2026-05-23T09:50:00Z'

PITR을 staging clone으로 즉시 — 운영 데이터에 영향 없이 실험 가능합니다.

4. Babelfish (Aurora 전용)

MS SQL Server T-SQL 호환 layer. PostgreSQL과 같이 동작합니다.

Aurora의 한계

모니터링

운영 사례

1. read 부하 폭증

client → reader endpoint
        → 5 reader instance

reader 추가가 빠르므로 주말 batch 같은 변동 부하에 강함.

2. multi-region DR

us-east-1 (primary)
└── ap-northeast-2 (DR — read replica)

DR 사고 시 ap-northeast-2를 promote.

3. 분석 분리

logical replication 또는 logical decoding으로 Redshift·Snowflake에 ETL.

비용 모델

Aurora를 선택할까

RDS Proxy

Aurora·RDS 앞에 두는 매니지드 connection pooler — pgBouncer 대체.

client → RDS Proxy → Aurora/RDS

매니지드 풀러 — Aurora 운영에서 자주 함께.

정리

• Aurora PostgreSQL = AWS 자체 분산 스토리지 위의 PG 호환 DB
• writer + reader 같은 스토리지 공유, failover ~30초
• read replica·storage 자동 확장·multi-region · clone이 강점
• 100% PG 호환 아님, 비용 RDS의 ~1.5배
• 큰 read 부하·HA 엄격·multi-region이면 Aurora, 그 외엔 RDS로 충분
• RDS Proxy로 connection pooling 매니지드

다음 절(17.3)에서는 Microsoft의 매니지드 — Azure Database for PostgreSQL Flexible Server를 봅니다.