☁️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)

가속 도메인 설정

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 허용하도록 합니다.

목표:

접근 차단 정석:

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 설정을 같이 맞춰야 함