CDN과 WAF의 최적 조합 이해하기

1. CDN → WAF → Origin

알리바바 클라우드 공식 가이드에서 권장 하는 기본 아키텍처 입니다.

“CDN은 인그레스(최전방)에서 가속, WAF는 중간에서 필터링”이라고 명시합니다.

성능/비용 유리 : 정적 리소스는 CDN에서 캐시 히트면 엣지에서 바로 응답하니, WAF까지 가는 요청수가 줄어듭니다. (특히 이미지/CSS/JS) 게다가 CDN 에서 WAF를 켜면 “해당 도메인으로 들어오는 요청을 WAF가 스캔하고 요청 수로 과금”이어서, WAF로 들어가는 요청이 줄면 비용도 줄어드는 구조입니다.
클라이언트 IP 처리 주의 : CDN이 앞단 프록시라서 WAF에서 “앞단에 L7 프록시(CDN)가 있음”을 설정하고, 실제 클라이언트 IP를 어떤 헤더에서 읽을지 설정해야 합니다.
적용 범위 차이 : “CDN 캐시 히트(엣지에서 바로 응답)는 WAF 까지 안가기 떄문에, WAF 로그/룰 적용은 “오리진으로 포워딩되는 트래픽(캐시 미스/동적 요청)” 중심이 됩니다.

이건 논리적으로느 가능해 보이지만, 알리바바가 공식 문서로 안내하는 표준 결합 형태는 1번(CDN→ WAF) 입니다. ** 비표준이다

WAF가 모든 요청을 먼저 받음 : 정적/동적/캐시 가능한 요청까지 전부 WAF를 먼저 통과하니
- WAF의 처리량/지연/병목 위험이 커지고
- 요청 수 과금 모델이면 비용도 불리해지기 쉽다.
CDN의 ‘엣지에서 막아주는’ 이점이 약해짐 : CDN이 뒤에 있으니, “일단 WAF까지 트래픽이 몰리는 구조가 돼서 대량 요청 상황에서 운영상 불리할 수 있다.
로그/클라이언트 IP 가시성은 단순 : WAF가 최전방이면 WAF 입장에선 클라이언트가 “직접 들어오는 것처럼”보이기 쉬워서 IP 처리 자체는 단순해질 수 있다.

다만, 이 경우 CDN 쪽 로그는 ‘접속 주체가 WAF’로 보일 수 있어(WAF가 CDN에 요청하니까) 분석 관점에서 또 복잡해질 수 있습니다.