목적과 흐름

목적

Client → (DNS) → CDN → (Origin) WAF → (Origin) ALB → Backend(svr-01/02)

최종 사용자 도메인이 a.example.com일 때

Domain to accelerate: a.example.com (클라이언트가 입력하고 들어오는 도메인)
Origin Address(원본): WAF가 발급한 CNAME (xxxx.aliyunwaf.com) (WAF 구성 시 생성되는 CNAME)
Origin Host(Host header): a.example.com (필수급)
(CDN→WAF가 HTTPS면) Origin SNI: a.example.com (필수급)

가장 많이 쓰는 운영형(안정/호환/운영 난이도↓):

핵심 포인트:

💡 “WAF에서 HTTPS(443) 리스너 켜면 오리진(ALB)도 HTTPS로 바뀌는 것처럼 보인다”

Listener(앞단 수신)와 Forwarding Rule(뒷단 오리진)이 분리인데,
UI에서 Origin Protocol을 직접 고르는 게 아니라 Enable HTTP Back-to-Origin 스위치로 HTTP 내려보내야 함.

ALB는 “WAF back-to-origin IP 대역만 허용”으로 잠그는 게 정석입니다.

(CNAME 방식은 원본 우회가 가능하므로, ALB를 인터넷에 그대로 열어두면 WAF 우회가 됩니다.)

위의 이미지 버튼 누르면 WAF → ALB로 들어가는 CIDR 확인할 수 있음. (ALB에 SG를 설정해서 해당 CIDR만 Allow)

💡 근데 ALB SG를 WAF CIDR만 allow로 했는데도 내 PC에서 ALB CNAME 접근이 된다?

여기서 핵심 의문이 생김:
- ECS SG는 기본 Deny인데,
- ALB SG는 Allow만으로는 기본 차단이 안 되고 Deny 규칙을 따로 넣어야 화이트리스트가 된다는 점.
💡 ECS SG vs ALB SG 동작 차이에 대한 근본 의문
“왜 ECS SG는 기본 Deny인데, ALB SG는 Deny를 명시해야 하냐?”
- 이름은 SG지만 동작 모델/목적이 다르다는 점이 핵심 논점이었음:
  - ECS SG: NIC 앞 방화벽(implicit deny)
  - ALB SG: 서비스형 LB에 붙는 접근정책(우선순위 기반 allow/deny 성격), 기본을 닫지 않음

/ 또는 .html은 TTL 0~짧게(예: 0~5s)
“페이지가 안 바뀌는 문제”는 대부분 CDN 캐시 때문이므로:
- 변경 후 Refresh(Purge) 또는
- HTML을 no-store로 운영하는 게 편합니다.

즉, 이미지만 CDN 캐시가 목적이면, 웹페이지/동적 경로는 “캐시 안 함”이 정답에 가깝습니다.

💡 ALB 로드밸런싱이 “안 되는 것처럼 보이는” 이유

curl -sI <https://chj-test.example.com/> | egrep -i "x-cache|age|via|cache-control"

가장 확실한 방법:

# WAF 동작 테스트
curl -i "<https://chj-test.example.com/alert(xss)?t=$RANDOM>"
curl -i "<https://chj-test.example.com/?id=1%20or%201=1&t=$RANDOM>"