Multi-Region Architecture Deep Dive

두 리전에서 하나의 서비스처럼 동작하는 아키텍처 설계

Block 1: Multi-Region Foundation | 30분

오늘 세션 구성

총 150min 세션

1

Multi-Region Foundation 30분

2

Data Sync & Replication 30분

3

Traffic Routing & Edge 30분

4

DR & Failover Automation 30분

5

Observability & Operations 30분

질문은 각 Block 종료 시에 받겠습니다.

멀티리전, 목적부터 정한다

리전 규모 장애 격리가용성

Multi-AZ는 AZ 장애를 막고, 멀티리전은 리전 전체에 영향을 주는 드문 이벤트를 막습니다

사용자 근접 지연성능

CDN이 못 줄이는 동적 API 읽기를 사용자와 가까운 리전에서 처리

데이터 레지던시규제

국가, 산업 규제로 특정 리전 안에 데이터를 보관해야 하는 경우

배포 blast radius 축소운영

한 리전씩 순차 배포하면 잘못된 변경의 영향 범위가 리전 하나로 제한

공짜가 아닙니다: 인프라 이중화, 리전 간 데이터 전송 요금, 일관성 설계, 페일오버 연습까지 비용이 늘어납니다. 목표 RTO, RPO가 이 비용을 정당화하는지 먼저 확인하세요.

Active-Active냐, Passive냐

Active-Active

모든 리전이 동시에 트래픽 처리, 사용자는 가까운 리전으로
리전 하나를 잃어도 다른 리전이 이미 서비스 중
쓰기를 양쪽에서 받으면 충돌 해결 또는 동기 합의가 필요
각 리전이 전체 부하를 흡수할 용량을 유지해야 함

Active-Passive

Primary만 트래픽 처리, secondary는 대기 또는 축소 운영
DR 전략 스펙트럼: Backup & Restore, Pilot Light, Warm Standby
단방향 복제라 충돌이 없고 구현이 단순
페일오버 절차와 승격 시간이 RTO를 결정

이 세션의 선택: 읽기는 Active-Active, 쓰기는 Active-Passive. 두 리전 모두 트래픽을 받되 쓰기는 us-east-1 한 곳으로 모읍니다 (Write-Primary / Read-Local).

CAP은 장애 때, PACELC는 평소에

CAP: Partition이 나면

리전 간 연결이 끊긴 순간, 쓰기를 거부해 일관성(C)을 지키거나 각자 받아 가용성(A)을 지킨다

PACELC: Else, 평소에는

장애가 없어도 동기 복제는 리전 간 RTT만큼 느리다. 지연(L)과 일관성(C) 중 하나를 고른다

DynamoDB global tables (MREC)

기본 모드. 리전마다 로컬 쓰기, 비동기 복제, 충돌은 last writer wins

PA / EL

DynamoDB global tables (MRSC)

정확히 3개 리전(복제본 3 또는 2 + witness), 다른 리전 1곳 이상에 동기 복제 후 응답

PC / EC

Aurora DSQL multi-Region

peered cluster 2개 + witness Region, 양쪽 읽기, 쓰기 모두 강한 일관성

PC / EC

Aurora Global Database

writer는 primary 1곳, secondary는 비동기 읽기 전용(일반적으로 lag 1초 미만)

쓰기 C / 읽기 L

일관성은 데이터마다 고른다

보장

어느 리전에서 읽어도 마지막으로 커밋된 쓰기가 보임

대가

쓰기, 강한 읽기 지연이 참여 리전 간 RTT에 비례

AWS 예

DynamoDB MRSC, Aurora DSQL multi-Region, Aurora write forwarding GLOBAL 모드

적합

결제 승인, 재고 차감처럼 중복이나 역전이 치명적인 데이터

아키텍처 한눈에 보기

Edge (global)

Route 53

CloudFront

WAF

↓ VPC origin (private) ↓

us-east-1PRIMARY, writer

internal ALB

→

EKS: order, payment, catalog, cart

us-west-2SECONDARY, reader

internal ALB

→

EKS: 동일 서비스 세트

↓ 리전별 데이터 계층, primary → secondary 복제 ↓

Aurora PostgreSQL Global DB
order, payment

DocumentDB Global Cluster
catalog

ElastiCache Valkey
Global Datastore

MSK
이벤트

DynamoDB Global Tables
idempotency

OpenSearch
검색

S3
이미지, 아카이브

쓰기는 한 곳, 읽기는 가까운 곳

us-east-1 (primary)

쓰기writer instance

읽기로컬 reader

접속global writer endpoint

→ 비동기 복제storage 기반, 일반적으로 1초 미만

← write forwardingsecondary에서 받은 쓰기를 primary로 전달

us-west-2 (secondary)

쓰기forwarding 또는 primary 직접

읽기로컬 reader

접속cluster reader endpoint

충돌 없음

writer가 하나라 충돌 해결 로직이 필요 없음

서부 쓰기는 느리다

forwarding된 쓰기는 리전 간 RTT를 그대로 부담, SERIALIZABLE 격리 미지원

연결 상한

forwarding 세션은 primary writer max_connections의 기본 25%까지만 허용

리전마다 독립된 EKS 클러스터

클러스터는 리전 단위

EKS 컨트롤 플레인은 리전 서비스. 리전마다 독립 클러스터를 두고 서로 의존하지 않게 설계

버전을 맞춘다

두 리전 모두 같은 Kubernetes 버전. 2026-10 기준 최신은 1.37 (EKS 출시 2026-10-01)

GitOps로 같은 매니페스트

하나의 Git 저장소에서 두 클러스터로 배포, 리전 차이는 overlay 값(endpoint, ARN)으로만

이미지도 리전마다

ECR 리전 간 복제로 각 리전에서 로컬 pull. 다른 리전 레지스트리에 의존하지 않음

IAM은 Pod Identity

IAM role은 글로벌, association은 클러스터마다 생성. 리전별 리소스 ARN 범위 확인

흡수 용량 계획

한 리전이 빠지면 나머지가 전체 부하를 받는다. 페일오버 순간 스케일아웃에 기대지 않도록 여유 확보

CIDR은 겹치지 않게, 티어는 셋으로

10.0.0.0/16

us-east-1 VPC

10.1.0.0/16

us-west-2 VPC

10.2~10.15

향후 리전, 환경 예약

겹치면 못 붙인다

VPC peering은 CIDR이 하나라도 겹치면 생성 불가, TGW도 목적지가 모호해짐

IPAM으로 할당

Amazon VPC IPAM pool에서 리전별로 나눠주면 중복을 사전에 차단

Pod IP도 계산

VPC CNI는 Pod마다 VPC IP를 쓰므로 노드 수가 아니라 Pod 수로 산정

리전 간 연결, 세 가지 선택지

static route만

peering attachment를 향한 static route를 TGW route table에 직접 추가 (BGP 전파 없음)

암호화, 백본

리전 간 트래픽은 AWS 백본에서 AES-256으로 암호화, 인터넷을 거치지 않음

리전을 넘지 못하는 것

SG 참조, Route 53 Resolver 기반 상대 리전 private DNS 해석은 peering 너머로 동작하지 않음

상한

TGW 쌍당 peering 1개, TGW당 peering 기본 50개, MTU 8500

# us-east-1 TGW route table (us-west-2는 대칭)
10.0.0.0/16 → vpc attachment (local VPC, propagation)
10.1.0.0/16 → peering attachment (static, us-west-2)

NAT 대신 endpoint, 손익분기 계산

Gateway endpoint (무료)

S3, DynamoDB. ECR 이미지 레이어도 S3에서 받으므로 항상 생성

Interface endpoint (EKS 필수군)

ecr.api, ecr.dkr, sts, eks-auth(Pod Identity), logs

gateway endpoint의 한계

peered VPC의 다른 리전, TGW, 온프렘에서는 사용할 수 없음. 리전마다 따로 생성

AWS API 트래픽 (GB/월)

3,000 GB

Interface endpoint 수

5개

AZ 수

3 AZ

-

NAT 경유 처리 요금

-

Interface endpoint 요금

-

손익분기 트래픽

us-east-1, 월 730시간 기준: NAT 처리 $0.045/GB, endpoint $0.01/AZ-hour + $0.01/GB. NAT 시간 요금은 다른 egress가 있어 유지된다고 가정, 리전 1개 기준

이번 블록의 아키텍처 결정

영역	결정	대가, 주의점
데이터 패턴	Write-Primary / Read-Local, 데이터별 일관성 선택	서부 쓰기는 리전 간 RTT 부담
진입	CloudFront → VPC origin → internal ALB	VPC에 IGW 필요, ALB SG는 CloudFront prefix list 또는 VPC origin SG만 허용
컴퓨트	리전별 독립 EKS, 같은 버전, GitOps 배포	흡수 용량을 평소에 확보
네트워크	겹치지 않는 /16, 3-tier, public 티어엔 NAT만	Pod IP까지 포함해 CIDR 산정
리전 간	TGW peering + static route	SG 참조, DNS 해석 불가. 리전 3개 이상이면 Cloud WAN 검토
AWS API	Gateway endpoint 항상, EKS 필수 interface endpoint	리전마다 생성, 손익분기 확인
IAM	EKS Pod Identity	association은 클러스터마다

Key Takeaways

1목적이 패턴을 정한다

가용성, 지연, 레지던시 중 무엇이 목표인지가 Active-Active와 Active-Passive를 가른다

2평소의 지연이 진짜 비용

PACELC 관점에서 데이터마다 Strong, Session, Eventual을 고른다

3쓰기는 한 곳에 모은다

Write-Primary / Read-Local은 충돌을 없애는 대신 서부 쓰기 지연을 받아들인다

4네트워크는 처음에 정한다

겹치지 않는 CIDR, private 진입, TGW static route는 나중에 바꾸기 가장 어렵다

Knowledge Check

Q1: Aurora PostgreSQL write forwarding의 기본 consistency_mode인 SESSION의 의미는?

Q2: Transit Gateway inter-Region peering에 대해 옳은 것은?

Q3: CloudFront VPC origin 뒤 internal ALB의 SG 설정으로 옳은 것은?

Thank You

Block 1: Multi-Region Foundation 완료

← 목차로 돌아가기 다음: Data Sync & Replication →