☁️Cloud/Alibaba
Alibaba Cloud: CDN → ALB → Backend 구성 & 오리진 보호(클라이언트는 CDN으로만 인입)
Diven
2026. 3. 29. 17:28

목표
- 클라이언트 트래픽은 CDN 가속 도메인으로만 인입
- 오리진은 ALB
- ALB 뒤에 백엔드 서버 2대
- 테스트를 위해 https://chj-test.example.com/test요청 시 백엔드 서버 IP가 번갈아 바뀌는 지 확인
- 최종적으로 ALB 오리진 도메인 직접 접근은 차단, CDN 경유 요청만 허용 </aside>
아키텍처
- Client → CDN 가속 도메인 : https://chj-test.example.com
- CDN → Origin Server(ALB Domain)
- ALB → Server Group(Backend Server 2대) 로 로드밸런싱 (WRR/WLC 등)
- Backend nginx → /test 에서 테스트 페이지 제공
Backend 에서 /test 엔드포인트 페이지 생성 (Ubuntu, conf.d)
- /test 로 접속하면 nginx 기본 페이지가 나오게 하고,
- 동시에 어떤 백엔드인지 확인할 수 있게 헤더로 IP 내려줌
설정파일
/etc/nginx/conf.d/test.conf
server {
listen 80;
listen [::]:80;
server_name _;
root /var/www/html;
index index.nginx-debian.html index.html;
location = /test {
try_files /index.nginx-debian.html /index.html =404;
# 백엔드 식별용(선택)
add_header X-Backend-IP $server_addr always;
# CDN 테스트 시 캐시 방지(선택)
add_header Cache-Control "no-store, no-cache, must-revalidate, max-age=0" always;
add_header Pragma "no-cache" always;
add_header Expires "0" always;
}
location = /test/ { return 301 /test; }
location / {
try_files $uri $uri/ =404;
}
}
적용:
nginx -t
systemctl reload nginx
ALB 설정(Server Group + Forwarding Rule)
Server Group 구성
- Backend ECS 2대를 같은 Server Group에 등록
- Health Check 정상 확인
Forwarding Rule (Host + Path 기반 라우팅)
chj-test.example.com + /test 요청만 특정 Server Group으로 전달
- Domain Name(Host) : chj-test.example.com
- Path : /test (또는 /test*)
- Action : Forward → Backend Server Group
CDN 설정 (Origin = ALB)
가속 도메인 설정
- CDN 콘솔에서 가속 도메인 (예 : chj-test.example.com ) 추가
Origin 설정
- Origin Type : Domain
- Origin Domain : ALB 도메인
💡 중요: /test 는 캐시 OFF로 설정
테스트 목적이 “오리진까지 매번 들어가서 로드밸런싱 확인” 이기 때문에 /test 는 반드시 미캐시 권장
- Cache Expiration Rule 추가:
- Type: Object
- Object: /test
- TTL: 0
- 적용 후 /test 경로 Purge(Refresh/Purge) 실행
<aside> 💡
/ 같은 루트 경로에 TTL이 길게 걸려 있으면 CDN POP에서 응답이 나가서 “백엔드가 안 바뀌는 것처럼” 보일 수 있음
</aside>
오리진 보호: “클라이언트는 CDN으로만 인입, ALB 도메인으로 직접 접근 차단”
ALB의 화이트리스트로 처리하기에는 CDN 에 대한 IP 가 변경되기 때문에 비권장합니다. 따라서 CDN → Origin(ALB) 요청에 “토큰 헤더”를 붙여서 토큰 헤더가 있는 요청만 ALB 허용하도록 합니다.
목표:
- https://chj-test.example.com (CDN) → 허용
- http://<ALB-domain>/test (직접) → 차단(403)
접근 차단 정석:
CDN→ Origin(ALB) 요청에만 “토큰 헤더” 붙이고, ALB에서 그 헤더가 없으면 Fixed Response 403으로 차단
CDN 에서 Origin 요청 헤더 추가
CDN 도메인 설정 → Back-to-Origin/Origin Request Header 설정에서:
- Header : X-Origin-Auth
- Value : <내가 생성한 긴 랜덤 토큰>
토큰 생성 예시(서버에서):
openssl rand -hex 32
ALB Forwarding Rule에 토큰 조건 추가:
허용 룰
- 조건 : X-Origin-Auth==<토큰값>
- Action : Forward → Backend Server Group
차단 룰
- 조건 : /*
- Action : Return Fixed Response 403
<aside> 💡
Fixed Response는 보통 ALB Standard/WAF-enabled 에서 사용 가능.
이렇게 하면 nginx까지 요청이 전달되기 전에 ALB에서 차단됨.
</aside>
CDN → ALB(Origin)→Backend(nginx): SSL offloading 베스트 프렉티스
A안: CDN에서만 TLS 종료(클라이언트↔CDN만 HTTPS), CDN → ALB는 HTTP
베스트 상황:
- 오리진(ALB/Backend)이 같은 VPC 내부
- 내부 구간은 보안그룹/네트워크 정책으로 외부 노출이 없음
- “오리진까지 종단 간 TLS”가 규정상 필수 아닐 때
장점:
- 인증서 관리가 CDN 한 군데에서 끝나 제일 단순
- 오리진(ALB/Backend) 부하 감소
설정 요약:
- CDN 도메인에 HTTPS 인증서 설정 (CDN POP에 배포)
- CDN 오리진 프로토콜을 HTTP로 설정
- ALB는 HTTP 리스너(80)로 Backend 전달
B안: CDN과 ALB 둘 다 TLS 종료(클라이언트 ↔ CDN HTTPS + CDN ↔ ALB HTTPS) = “Origin 까지 HTTPS”
베스트 상황:
- 규정/감사/보안 요구로 CDN→오리진 구간도 암호화가 필요할 때
- 오리진(ALB)이 퍼블릭/크로스 네트워크 경로로 접근될 가능성이 있어 종단 간 암호화가 필요할 때
- “토큰 헤더 기반 오리진 보호” 같은 기능을 쓸 때도, 헤더 노출 위험을 줄이려면 HTTPS가 유리
장점:
- CDN→ ALB 구간도 TLS라 “중간 구간 평문” 걱정 없음
설정 요약:
- CDN 도메인에 HTTPS 인증서 설정
- CDN 오리진 프로토콜을 HTTPS 설정
- ALB에 HTTPS 리스너(443) 추가 + 인증서 연결 + TLS 보안정책 선택
- (중요) 오리진이 도메인 기반(SNI)이라면 SNI 설정 불일치로 5xx가 날 수 있음. CDN/오리진의 HTTPS/SNI 설정을 같이 맞춰야 함