CloudFront 오리진(Origin)과 캐시 동작(Behavior) 나눠서 이해하기 – VPC Origins, 캐시 정책, Function 연결까지

작성자 이 주완 작성일 10월 14, 2026 조회수 44

안녕하세요. GS Neotek 이주완 입니다.

CloudFront를 설정하다 보면 원본(Origin) 편집 화면과 캐시 동작(Behavior) 화면을 오가며 비슷해 보이는 값을 여러 번 고르게 됩니다.
그런데 두 화면은 서로 다른 질문에 답하는 설정이고, 이 둘을 섞어서 이해하면 캐싱이나 보안 설정이 쉽게 꼬입니다.

이번 글에서는 실제 콘솔 화면 두 장을 기준으로, CloudFront가 요청 하나를 처리하는 동안 각 설정이 무엇을 결정하는지 따라가 보겠습니다.
VPC Origins, 캐시 정책과 오리진 요청 정책의 차이, Function 연결처럼 실무에서 자주 헷갈리는 부분 위주로 정리했습니다.

한눈에 보기

요청 한 번의 전체 흐름

하나의 배포(Distribution)에는 여러 개의 Origin을 등록할 수 있습니다.
여러 개의 Behavior가 경로 패턴(Path Pattern)으로 요청을 분류하고, 그중 하나의 Origin으로 보냅니다.
즉 Behavior는 “어느 Origin으로 보내고 어떻게 캐싱할지”를 정하고, Origin은 “실제로 어떻게 연결할지”를 정합니다.

요청이 들어왔을 때의 순서는 아래와 같습니다.

1. 뷰어 → 엣지 위치
   요청 경로를 Behavior의 경로 패턴과 맞춰 봅니다.
2. 캐시 정책으로 캐시 키 생성
   캐시에 있으면(HIT) 엣지에서 바로 응답합니다.
3. 캐시 미스(MISS) 시 오리진 요청 정책 적용
   오리진에 보낼 헤더·쿠키·쿼리스트링을 정합니다.
4. Origin Shield(선택) → 오리진
   Origin 설정(프로토콜, 포트, TLS)대로 접속합니다.
5. 응답 반환
   캐시 정책의 TTL만큼 저장하고, 응답 헤더 정책을 적용해 뷰어에 돌려줍니다.

여기서 핵심은 캐시 정책은 적중 여부를 결정하고, 오리진 요청 정책은 미스가 났을 때 오리진으로 무엇을 들고 갈지를 결정한다는 점입니다.
예를 들어 /static/*은 S3 오리진으로, /api/*는 ALB 오리진으로 보내는 배포라면 경로 패턴이 라우팅을, Origin 설정이 연결 방식을, Behavior의 나머지 정책이 그 경로의 동작 방식을 결정합니다.

Origin 심화

Origin 설정은 결국 “CloudFront가 이 서버에 어떻게 접속할 것인가”에 관한 것입니다.
어떤 프로토콜과 포트, 어떤 TLS 버전으로 접속할지, 그리고 최근에는 퍼블릭 인터넷을 거칠지 말지까지 이 화면에서 정합니다.

오리진의 종류

원본 설정 필드 살펴보기

아래는 퍼블릭 ALB를 오리진으로 등록한 원본 편집 화면입니다.

VPC Origins – 퍼블릭 노출 없이 프라이빗 오리진 쓰기

전통적으로 CloudFront가 오리진에 접속하려면 오리진이 인터넷에서 해석 가능해야 했습니다.
그래서 보안 그룹에서 CloudFront의 IP 대역 전체(관리형 프리픽스 리스트)를 허용하는 방식을 많이 썼습니다.
VPC Origins는 CloudFront가 프라이빗 서브넷 안에 서비스 관리형 ENI를 직접 만들어 오리진에 도달하는 방식으로, 이 전제를 바꿉니다.

• 지원 리소스
  프라이빗 서브넷의 ALB, NLB, EC2 인스턴스입니다. Gateway Load Balancer, 듀얼스택 NLB, TLS 리스너 NLB는 지원하지 않습니다.
• 네트워크 요건
  VPC에 인터넷 게이트웨이가 연결되어 있어야 하지만, 서브넷 라우팅 테이블은 프라이빗 그대로 둡니다.
  서브넷에 사용 가능한 IPv4 주소가 있어야 하고, IPv6 전용 서브넷은 지원하지 않습니다.
• 보안 그룹
  CloudFront가 만든 CloudFront-VPCOrigins-Service-SG(또는 관리형 프리픽스 리스트)만 오리진 보안 그룹에서 허용하면 됩니다. NLB를 쓸 때는 보안 그룹이 붙어 있어야 합니다.
• 제약
  gRPC 트래픽, 오리진 쪽 Lambda@Edge 트리거는 지원하지 않고, 네트워크 ACL은 VPC Origin 트래픽에 평가되지 않습니다.
• 확장
  2025년 11월 계정 간(cross-account) VPC Origins, 2026년 5월 WebSocket 지원이 추가됐습니다.

사용자 정의 헤더로 “CloudFront를 거쳤는지” 확인하는 방식은 헤더가 유출되면 우회될 수 있습니다.
ALB를 프라이빗 서브넷으로 옮기고 VPC Origin으로 등록하면, 오리진 직접 접근을 네트워크 단계에서 막을 수 있습니다.

Origin Access Control과 Origin Groups

Origin Access Control(OAC)은 VPC Origins와 목적이 다릅니다.
OAC는 S3 버킷이 CloudFront의 서명된 요청(SigV4)만 받도록 하는 인증 방식이고, VPC Origins는 네트워크 경로 자체를 프라이빗으로 만드는 방식입니다.
오리진이 ALB라면 OAC는 해당하지 않고, ALB·NLB·EC2 오리진에서 같은 문제를 푸는 것이 VPC Origins라고 이해하면 됩니다.
OAC는 기존 OAI를 대체하며 모든 리전, KMS 고객 관리형 키, PUT/DELETE 같은 동적 요청까지 지원합니다. 다만 S3를 웹사이트 엔드포인트로 구성하면 OAC를 쓸 수 없습니다.

Origin Groups(오리진 그룹)는 기본 오리진이 지정한 상태 코드(주로 5xx)로 실패하면 보조 오리진으로 자동 전환하는 기능입니다.
장애 시 정적 안내만으로 충분하다면 커스텀 에러 페이지가 더 간단하고 저렴하며, 실제 백업 처리가 필요하다면 오리진 그룹이 맞습니다.

Behavior(캐시 동작) 심화

Behavior는 경로 패턴으로 트래픽을 나눈 뒤, 그 경로에서 “뷰어와 어떻게 주고받을지”와 “오리진과 어떻게 주고받을지”를 정합니다.
헷갈리는 부분은 대부분 캐시 정책과 오리진 요청 정책을 같은 것으로 보는 데서 시작됩니다.

경로 패턴과 뷰어 설정

• 경로 패턴
  Behavior는 목록 순서대로 평가됩니다. /booth/api/*처럼 구체적인 패턴을 위에, 기본 동작(*)을 맨 아래에 둬야 세부 규칙이 무시되지 않습니다.
• 뷰어 프로토콜 정책
  Redirect HTTP to HTTPS는 HTTP 요청을 HTTPS로 리다이렉트합니다. HTTPS only보다 사용자 경험이 부드럽고 HTTP and HTTPS보다 안전합니다.
• 허용된 HTTP 방법
  GET, HEAD, OPTIONS, PUT, POST, PATCH, DELETE는 쓰기 작업까지 처리하는 API 프록시 용도라는 뜻입니다. 정적 자산이라면 보통 GET, HEAD로 충분합니다.
• 뷰어 액세스 제한
  No는 서명된 URL·쿠키로 접근을 통제하지 않는다는 뜻입니다. 로그인이 필요한 API는 보통 오리진의 애플리케이션 인증으로 처리합니다.

캐시 정책 vs 오리진 요청 정책

2020년 정책 기반 모델 이전에는 “이 헤더를 오리진에 전달할지”와 “캐시 키에 넣을지”가 한 설정에 섞여 있었습니다.
지금은 두 개의 정책으로 완전히 나뉩니다.

위 화면의 캐시 정책 CachingDisabled는 AWS 관리형 정책입니다.
반면 오리진 요청 정책 DefaultCustomOrigin은 AWS 관리형 정책 목록에 없는 이름이라, 계정에서 직접 만든 커스텀 정책일 가능성이 높습니다.
이름만으로는 무엇을 전달하는지 알 수 없으니 콘솔에서 실제 내용을 한 번 확인해 보는 것을 권합니다. 캐싱을 꺼도 불필요하게 큰 쿠키·헤더를 통째로 넘기면 오리진 트래픽과 지연 시간에 영향을 줍니다.

AWS 관리형 캐시 정책

AWS 관리형 오리진 요청 정책

응답 헤더, 압축, Function 연결

응답 헤더 정책은 뷰어로 가는 응답에 HSTS 같은 보안 헤더나 CORS 헤더를 CloudFront에서 넣어 줍니다.
객체 자동 압축은 텍스트 계열 응답을 Gzip·Brotli로 압축해 전송량을 줄입니다.
필드 레벨 암호화는 폼의 특정 필드(카드 번호 등)를 오리진까지 암호화한 채로 전달할 때 씁니다.

뷰어 요청·응답 단계에서 끝낼 수 있는 로직은 CloudFront Functions로, 오리진 요청·응답을 다뤄야 하는 로직만 Lambda@Edge에 두는 것이 비용과 지연 시간 모두에 유리합니다.

예시 화면을 합쳐서 읽어 보기

두 화면을 합치면 퍼블릭 ALB 오리진 + API 경로 + 캐싱 비활성화 + 전체 HTTP 메서드 허용 + HTTPS 강제 구성입니다.
전형적인 API 패스스루(pass-through) Behavior이고, 정적 자산은 별도 Behavior에서 캐싱하고 API 경로만 캐싱을 끄는 구성은 합리적입니다.
다만 아래 세 가지는 점검해 볼 만합니다.

• 1. Origin Shield는 꺼 두는 것이 맞습니다.
  캐싱하지 않는 API 오리진에서는 Origin Shield가 줄여 줄 캐시가 없으니 비용만 늘어납니다.
• 2. ALB의 퍼블릭 노출은 다시 볼 만합니다.
  사용자 정의 헤더 방식은 헤더가 유출되면 ALB로 직접 요청할 수 있습니다. VPC Origins로 바꾸면 이 우회 경로가 사라집니다.
• 3. 커스텀 오리진 요청 정책의 실제 내용을 확인해 보는 것이 좋습니다.
  특히 인증 관련 쿠키·헤더가 의도한 범위만 전달되는지 확인합니다.

점검 체크리스트

마무리

Origin은 “어디에, 어떻게 연결할지”, Behavior는 “어떤 요청을, 어느 오리진으로, 어떻게 다룰지”를 정합니다.
그리고 Behavior 안에서도 캐시 정책과 오리진 요청 정책은 관여하는 시점이 다릅니다.

이 세 가지를 나눠서 보면 CloudFront 설정 화면의 필드 대부분이 어느 단계에 영향을 주는지 바로 보입니다.

참고 자료

• Amazon CloudFront 개발자 안내서 – 오리진 사용
• Amazon CloudFront 개발자 안내서 – 캐시 동작 설정
• Amazon CloudFront 개발자 안내서 – 관리형 캐시 정책
• Amazon CloudFront 개발자 안내서 – 관리형 오리진 요청 정책
• AWS What’s New – CloudFront VPC Origins 출시(2024-11)