Block 3: Traffic Routing & Edge
공개 입구는 CloudFront 하나, 리전 선택은 Edge에서, 절체 스위치는 데이터 플레인에
공개 입구는 CloudFront 하나뿐
사용자
브라우저, 앱
mall.example.com
mall.
Route 53alias → CloudFront
→
Edge: 유일한 공개 입구
CloudFront
WAF web ACL→
Behavior 분기
/static/*
→ S3 (OAC)
→ S3 (OAC)
/api/*
→ CF Function
→ origin group
→ CF Function
→ origin group
→
VPC origin
internal ALBus-east-1 (primary)
internal ALB
us-west-2 (secondary)
us-west-2 (secondary)
→
EKS 서비스
order, paymentcatalog, cart
금지 목록
internet-facing LB, compute의 public IP, 보안 그룹의 0.0.0.0/0 및 ::/0 ingress. 우회 경로가 하나라도 있으면 WAF와 Edge 정책이 무력화됩니다.
리전 선택은 DNS가 아니라 Edge에서
판단 근거
recursive resolver IP, 또는 EDNS0 client subnet이 있으면 잘린 client IP. 회사 resolver가 다른 대륙이면 엉뚱한 리전이 나올 수 있음
latency 데이터
일정 기간 측정값 기반이라 바뀔 수 있음. 이번 주 Oregon이 다음 주 다른 리전이 될 수 있음 (실시간 측정 아님)
요금
latency 질의 $0.60/M, 표준 질의 $0.40/M. CloudFront로 가는 alias 질의는 무료
VPC origin과의 관계
VPC origin은 ALB ARN에 묶임. DNS 응답을 바꿔도 다른 리전 ALB로 가지 않으므로 공개 경로의 리전 선택은 Edge에서 해야 함
viewer request 함수
우선순위: session affinity cookie → weighted → geo (
CloudFront-Viewer-Country-Region)cf.createRequestOriginGroup()선택한 리전의 VPC origin을 primary로, 다른 리전을 secondary로 하는 origin group을 요청마다 구성
KeyValueStore
가중치, 활성 리전 값을 함수 재배포 없이 변경. 값은 invocation 사이에 반영
요금
Functions $0.10/M invocation, KVS read $0.03/M (각각 월 2M 무료)
import cf from 'cloudfront';
const kvs = cf.kvs();
async function handler(event) {
const req = event.request;
const pin = req.cookies['mr-region']; // affinity
const region = pin ? pin.value
: (await kvs.get('routing', { format: 'json' })).active;
const ids = region === 'us-west-2'
? ['alb-usw2', 'alb-use1'] : ['alb-use1', 'alb-usw2'];
cf.createRequestOriginGroup({
originIds: ids.map(id => ({ originId: id })),
failoverCriteria: { statusCodes: [500, 502, 503, 504] }
});
return req;
}
runtime 2.0, viewer request
origin 수정 helper는 viewer request 이벤트에서만 동작
behavior 기본값
기본 origin을 origin group으로 둔 behavior에 연결
입력 처리
쿠키가 us-west-2가 아니면 us-east-1 순서로 처리 (설명용 예시)
한 줄 정리
공개 경로는 Edge가 리전을 고르고, Route 53 latency는 private hosted zone의 내부 서비스 이름처럼 DNS가 직접 스위치인 곳에 씁니다.
헬스체크는 internal ALB를 못 본다
판정 규칙
전 세계 checker 중 18% 초과가 healthy라고 보고하면 healthy
간격, 임계값
간격 10초(fast, 유료 옵션) 또는 30초, 생성 후 변경 불가. 연속 실패 1~10 (기본 3)
HTTP(S) 기준
TCP 연결 4초 이내, 연결 후 2초 이내 2xx/3xx. HTTPS 체크는 인증서를 검증하지 않음
VPC 내부 대상
checker는 VPC 밖에 있음. internal ALB는 CloudWatch alarm 기반 health check로 감시
3회
60초
-
감지 (주기 × 횟수)
-
DNS 전환 근사 (+TTL)
AWS 블로그의 근사식 Failover = TTL + Interval × Threshold. resolver가 TTL을 지키지 않거나 alarm 평가 지연이 있으면 더 길어집니다. 요금: AWS endpoint 체크 $0.50/월, 옵션 기능(HTTPS, fast 등)마다 $1.00/월.
절체 스위치는 데이터 플레인에 둔다
on/off 스위치
routing control 상태가 Route 53 health check로 노출되어 failover 레코드를 움직임
클러스터
5개 리전 엔드포인트로 상태 조회, 변경. 한 리전이 장애여도 다른 엔드포인트 사용
safety rule
"최소 1개 ON" 같은 assertion, gating 규칙으로 두 리전을 동시에 끄는 실수 방지
요금
클러스터 $2.50/시간 (계정당 최대 2개). 여러 routing control을 한 클러스터에
plan = workflow
activate/deactivate workflow 안에 execution block을 순차, 병렬로 배치. active/passive, active/active 모두
execution block 예
Route 53 health check, routing control, Aurora Global DB, EKS resource scaling, Lambda custom action, manual approval
활성화할 리전에서 실행
Regional data plane 구조라 장애 리전에 의존하지 않음. CloudWatch alarm으로 자동 트리거 가능
요금, 연결점
plan당 $70/월. 우리 구조에서는 Lambda block이 KVS의 활성 리전 값을 바꾸는 설계가 가능 (설계 예시)
2026-04-30부터 신규 고객 불가
ARC readiness check는 신규 가입이 닫혔고 기존 고객은 계속 사용 가능
새 설계에서는
Region switch plan과 정기 연습, 리전별 capacity alarm으로 "절체 가능한 상태"를 확인
Route 53 accelerated recovery
2025-11 출시. us-east-1 장애 시 대부분 1시간 안에 public hosted zone 레코드 변경을 복구, 추가 비용 없음
한 줄 정리
장애 시 control plane API(레코드 편집, 배포)에 기대지 말고, 미리 만든 스위치의 상태만 바꾸세요.
Behavior: 캐시할 것과 안 할 것
동적 API: 캐시 끄고, 함수가 리전을 고른 origin group으로
PathPattern: /api/*
TargetOriginId: og-api # origin group (alb-use1, alb-usw2)
CachePolicy: Managed-CachingDisabled
OriginRequestPolicy: Managed-AllViewerExceptHostHeader
AllowedMethods: [GET, HEAD, OPTIONS, PUT, POST, PATCH, DELETE]
ViewerProtocolPolicy: redirect-to-https
FunctionAssociations:
- EventType: viewer-request
Function: mr-region-router # KVS 연결, 앞 슬라이드 코드
버전이 붙은 정적 자산: 길게 캐시, S3는 OAC로만
PathPattern: /static/*
TargetOriginId: s3-assets # OAC, 버킷 public access 차단
CachePolicy: Managed-CachingOptimized # 기본 TTL 1일
AllowedMethods: [GET, HEAD]
Compress: true
ViewerProtocolPolicy: redirect-to-https
# 파일명에 해시를 넣어 배포마다 새 URL (invalidation 최소화)
SPA 라우팅: custom error response 대신 함수로 rewrite
PathPattern: "*" # default behavior
TargetOriginId: s3-assets
CachePolicy: Managed-CachingOptimized
FunctionAssociations:
- EventType: viewer-request
Function: spa-rewrite # 확장자 없는 경로 → /index.html
# CustomErrorResponses(403/404 → 200 index.html)는 배포 전체에 적용되어
# /api/*의 404까지 HTML 200으로 바꿔 버림
Origin 잠금: VPC origin과 SG
Internet gateway
VPC에 붙어 있어야 함. "인터넷 트래픽을 받는 VPC" 표시용이며 origin 라우팅에는 쓰지 않음
private subnet IP
CloudFront가 service-managed ENI를 만들 IPv4 1개 이상 (dual-stack이면 IPv6도)
ALB Active 후 생성
VPC origin은 Deployed까지 최대 15분. ALB, NLB, EC2 지원 (GWLB, TLS listener NLB 불가)
AZ 예외
us-east-1은 use1-az3 제외, us-west-2는 전체 지원. ALB subnet AZ ID를 확인
권장: Service SG 참조
CloudFront-VPCOrigins-Service-SG를 소스로. 내 distribution 트래픽으로만 제한되어 가장 엄격 (VPC origin 생성 후 가능, 이 SG는 편집 금지)대안: managed prefix list
com.amazonaws.global.cloudfront.origin-facing (dual-stack은 ipv6 목록도). 모든 CloudFront 고객의 origin-facing IP라 더 넓음prefix list weight 55
SG 기본 60 rules 중 55 사용. HTTP, HTTPS 두 규칙이면 110이라 quota 초과, 443 하나만 열기
| 항목 | VPC origin에서 | 대응 |
|---|---|---|
| gRPC | 미지원 | gRPC는 별도 경로 설계 (예외 심사) |
| Lambda@Edge origin request/response | 미지원 | origin 선택은 viewer request CloudFront Function으로 |
updateRequestOrigin() | 요청 실패 | selectRequestOriginById(), createRequestOriginGroup() |
| NACL | inbound 미평가, outbound는 평가 | 반환 경로용 ephemeral TCP 1024~65535 outbound 허용 |
ALB scheme
항상
internal. internet-facing LB는 생성 자체를 IaC 정책 검사에서 차단public IP
EC2, EKS 노드, ECS task에 public IP, EIP 금지. subnet 자동 할당도 끔
SG ingress
0.0.0.0/0, ::/0 금지. 소스는 SG 참조 또는 사설 CIDR만, 배포 후 AWS Config로 상시 점검
한 줄 정리
ALB를 private subnet에 숨기고, SG는 VPC origin Service SG에서 443만 받으면 WAF를 우회할 경로가 사라집니다.
Origin Shield: 캐시될 때만 이득
Edge
서울, 도쿄, 시애틀 PoP
→
Regional edge cache
여러 REC
→
Origin Shield
us-east-1
(origin과 같은 리전)
(origin과 같은 리전)
→
Origin
ALB, S3
origin마다 지정
origin group이면 alb-use1은 us-east-1, alb-usw2는 us-west-2로 각자 Shield 리전을 둠
동적 요청은 항상 과금
PUT, POST, PATCH, DELETE와 TTL 3600초 미만 또는 캐시 비활성 GET, HEAD는 Shield가 언제나 추가 계층
캐시 요청은 일부만 과금
Shield와 같은 리전의 REC에서 오는 요청은 Shield를 건너뛰어 무과금, 다른 리전 REC에서 올 때만 과금
판단
/static/*은 켬. /api/*는 모든 요청이 과금 대상이므로 지연 개선을 측정한 뒤 결정. 미국 요금 $0.0075/10K
Origin failover는 GET만 구한다
조건
설정한 상태 코드(예: 500, 502, 503, 504) 또는 연결 실패, timeout. viewer 메서드가 GET, HEAD, OPTIONS일 때만
stateless
health 상태를 기억하지 않아 모든 요청이 primary부터 시도. 장애 중에는 요청마다 지연이 붙음
timeout 튜닝
connection attempts 1~3 (기본 3) × connection timeout 1~10초 (기본 10) → 기본값이면 넘어가기까지 최대 약 30초
쓰기 요청은 앱이 책임
POST /api/orders는 primary 오류가 그대로 사용자에게 갑니다. idempotency key + client retry, 그리고 KVS 활성 리전 전환으로 새 요청을 옮기세요.
WAF 순서: 넓게 거르고 좁게 본다
0IP allow/block set운영팀 명시 결정, 가장 먼저
1Anti-DDoS AMR
AWSManagedRulesAntiDDoSRuleSet, 상단 배치, scope-down 금지2Rate-basedwindow 60, 120, 300, 600초, 약 10초마다 평가
3IP reputationAmazonIpReputationList, AnonymousIpList
4ExploitCommonRuleSet, KnownBadInputs, SQLiRuleSet
5Bot Control + label 규칙scope-down 적용, 뒤에서 label로 예외 처리
scope CLOUDFRONT
CloudFront용 web ACL은 us-east-1에서 생성. ALB용 REGIONAL ACL과 별개
WCU
web ACL 기본 1,500 WCU. 초과 시 500 WCU마다 $0.20/M 요청 추가
요금
web ACL $5/월, 규칙 또는 rule group $1/월, 요청 $0.60/M
Bot Control은 Count로 시작한다
Common
자기 신고형 봇, 검증된 봇 분류. 구독 $10/월, 월 10M 요청 무료, 이후 $1/M
Targeted
정교한 봇 탐지. 월 1M 요청 무료, 이후 $10/M. flat-rate 플랜에서는 미지원
verified bot
검색 엔진 등은 차단하지 않고
bot:verified label만 붙임. web bot auth label은 v4.0 이상모바일 앱
SignalNonBrowserUserAgent는 기본 Block. 앱의 비브라우저 User-Agent가 막힘서버 간 호출
결제사 webhook, 파트너 SDK, synthetic 모니터링이 HTTP library 분류로 잡힐 수 있음
scope-down
사람이 쓰는 경로만 검사 (예: /api/payments/webhook 제외). 탐지 범위와 Bot Control 요청 요금이 함께 줄어듦
"ManagedRuleGroupStatement": {
"VendorName": "AWS",
"Name": "AWSManagedRulesBotControlRuleSet",
"ManagedRuleGroupConfigs": [
{ "AWSManagedRulesBotControlRuleSet": { "InspectionLevel": "COMMON" } }
],
"RuleActionOverrides": [
{ "Name": "SignalNonBrowserUserAgent", "ActionToUse": { "Count": {} } }
]
}
// 다음 규칙: label awswaf:managed:aws:bot-control:signal:non_browser_user_agent
// AND NOT (앱 User-Agent) → Block
1) Count로 배포 → 2) WAF 로그에서 label 분포 확인 → 3) label + 조건으로 예외 규칙 → 4) Block 전환
한 줄 정리
Bot Control의 결정은 label로 남기고, 차단은 우리가 쓴 다음 규칙이 하게 만드세요.
CloudFront와 GA는 층이 다르다
| 항목 | CloudFront |  Global Accelerator |
|---|---|---|
| 계층, 프로토콜 | L7 HTTP(S), WebSocket | L4 TCP, UDP |
| 입구 주소 | DNS 이름 (Anycast static IP 옵션 있음) | 고정 anycast IPv4 2개 |
| 캐시, WAF | Edge 캐시, WAF를 Edge에서 적용 | 캐시 없음, WAF는 뒤쪽 ALB에 붙임 |
| 리전 분배 | origin group, CloudFront Function | traffic dial, endpoint weight, 자동 failover |
| private origin | VPC origin (ALB, NLB, EC2) | internal ALB endpoint (client IP 보존) |
| 과금 | 요청 + 전송량, AWS origin fetch 무료 | $0.025/시간 + DT-Premium (미국→미국 $0.015/GB) + public IPv4 |
쇼핑몰: CloudFront 단독
HTTP(S) 트래픽, 정적 캐시, Edge WAF, VPC origin이 모두 필요
GA는 예외 심사
비HTTP(TCP/UDP) 요구가 생기면 별도 공개 입구가 되므로 보안 검토 후 결정
고정 IP 요구
파트너 방화벽 allowlist 때문이라면 CloudFront Anycast static IP를 먼저 검토
한 줄 정리
HTTP라면 CloudFront, 비HTTP라면 GA. 둘 다 쓰면 공개 입구가 두 개가 된다는 사실부터 인정하세요.
Edge 비용: 종량제 vs 정액제
100M
5TB
-
종량제 합계 (월)
$1,000
flat-rate Premium (월)
이 구조는 Premium이 필요합니다.
VPC origin은 Business 이상, 자동 origin failover와 Origin Shield는 Premium 전용. Premium 기본 한도 500M 요청, 50TB. 추정 가정: 미국 viewer, 전송량 첫 10TB 구간, 1TB=1,000GB 근사, WAF 규칙 8개, Anti-DDoS AMR, 로그, Route 53, ARC 제외.
Knowledge Check
Q1: POST /api/orders 처리 중 primary origin이 503을 반환하면?
Q2: VPC origin 뒤 internal ALB의 SG 소스로 가장 엄격한 것은?
Q3: Bot Control(Common)을 켠 뒤 모바일 앱 요청이 막혔다. 원인과 대응은?
Key Takeaways
입구는 하나
CloudFront → VPC origin → internal ALB. internet-facing LB, public IP, 0.0.0.0/0 없음
리전은 Edge가 고름
CloudFront Function + KVS +
createRequestOriginGroup(), DNS latency는 내부 이름에감지와 스위치 분리
internal ALB는 alarm 기반 health check, 절체는 routing control, Region switch
failover는 GET만
쓰기 API는 idempotency key, 재시도, 활성 리전 전환으로 보완
Bot Control은 Count부터
모바일 앱, webhook을 label로 확인한 뒤 Block
비용은 구조로 결정
VPC origin + failover + Shield면 flat-rate는 Premium. 종량제와 실측 비교