Alibaba Cloud: CDN → WAF → ALB → Backend(2) 구성

목적과 흐름

목적

• CDN: 이미지/정적 리소스를 POP에서 캐시해서 오리진 부하/지연 감소
• WAF 3.0: 웹 공격(XSS/SQLi/봇 등) 탐지/차단
• ALB: Backend 서버(svr-01/02)로 부하분산
• Backend: 실제 앱/웹 서비스

최종 트래픽 흐름

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

---

도메인/값 매핑

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

① DNS

• a.example.com CNAME → CDN CNAME(CDN 구성 시 생성되는 CNAME)
• 클라이언트는 CDN으로 진입

② CDN

• 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 3.0 (CNAME Record Mode)

• Domain Name(보호 도메인): a.example.com (클라이언트가 입력하고 들어오는 도메인)
• → “이 Host/SNI 트래픽에 WAF 정책/인증서/로그 적용”
• WAF CNAME: WAF가 자동 생성하는 값 (xxxx.aliyunwaf.com)
• → 이 값은 DNS에 직접 걸지 않고(CDN 쓰는 경우), CDN Origin으로 사용
• Origin(Forwarding Rule): origin.example.com(권장) 또는 ALB DNS**(CNAME)**

④ ALB

• Listener(80/443) + Forward to Server Group(svr-01/02)

---

SSL(HTTPS) 권장 구성

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

• Client → CDN: HTTPS(443) 종료(Offloading)
• CDN → WAF: HTTPS(443) 재암호화(권장)
• WAF → ALB: HTTP(80) (운영 단순화, SNI/인증서 이슈 감소)
• ALB → Backend: HTTP 또는 HTTPS(환경에 맞게)

핵심 포인트:

• CDN→WAF를 HTTPS로 하면, WAF에 a.example.com 인증서가 있어야 하고
• CDN에서 Origin SNI/Host를 a.example.com으로 맞춰야 인증서/도메인 매칭이 정상

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

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

---

보안(우회 방지) 핵심 1줄

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 성격), 기본을 닫지 않음

---

CDN 캐시 정책(당신 목적: 이미지 캐시) Best Practice

이미지/정적은 길게 캐시

• jpg,jpeg,png,gif,webp,svg,ico → TTL 1개월(또는 더 길게)
• Weight는 높게(예: 99) → 우선 적용

HTML/동적은 캐시 최소(또는 미캐시)

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

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

 

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

• CDN이 HIT로 응답하면 오리진(ALB)까지 요청 자체가 안 내려감
• /을 캐시(5초라도)하면 그 5초 동안은 오리진을 안 타니 “한 서버만 가는 느낌”이 납니다 </aside>

---

모든 구성 후: 동작 확인(검증) 체크리스트

CDN 캐시 확인(이미지)

• 같은 이미지 URL을 2~3번 요청
• 헤더에서 X-Cache: HIT, Age 증가 확인

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

WAF 동작 확인

가장 확실한 방법:

• WAF에 강제 차단 룰 생성(예: /waf-test-block 차단)
• https://a.example.com/waf-test-block?t=$RANDOM 호출
• 403/405 차단 + WAF 로그 이벤트 확인

# 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>"

ALB 분산 확인

• /whoami 만들고 서버별로 다른 값 반환
• ?nocache= 붙여서 여러 번 호출해 분산 확인