[AWS] CloudFront 기본 개념과 활용 : Origin(원본) & Behavior(동작) & Distribution(배포)

웹 서비스의 사용자들은 위치에 관계없이 빠르고 안정적인 응답을 기대한다. 이에 따라 컨텐츠를 효율적으로 전송하기 위한 CDN(Content Delivery Network)의 중요성이 점점 더 커지고 있다.

AWS CloudFront는 Amazon이 제공하는 대표적인 CDN 서비스로, 전 세계에 분산된 엣지 로케이션을 통해 컨텐츠를 빠르게 전달할 수 있도록 도와준다. 다양한 AWS 서비스와 연동하여 사용할 수 있으며, 트래픽 최적화, 보안, 캐싱 전략까지 유연하게 설정할 수 있는 장점이 있다.

 

 

이번 포스팅에서는 CloudFront를 이해하기 위한 기본 개념들을 살펴보고, 간단한 적용을 실습해 볼 예정이다.

1. AWS CloudFront : 주요 개념 및 기능
2. 배포(Distribution)
3. 원본(Origin) : 종류(Custom Origin & S3 Origin), 추가 기능(Origin Group, Custom Header)
4. 동작(Behavior) : Origin 설정, Viewer 설정, Policy 설정 (캐시 정책 & 원본 요청 정책 & 응답 헤더 정책)
5. CloudFront 활용 : 원본 서버 배포
6. CloudFront 활용 : Failover

 

 

---

AWS CloudFront

 

CloudFront는 AWS가 제공하는 글로벌 컨텐츠 배포 서비스이다. 전 세계 수백 곳에 위치한 캐시 서버(Edge Location)를 통해, 사용자에게 가장 가까운 서버에서 컨텐츠를 전달함으로써 리소스를 더 빠르게 제공할 수 있도록 지원한다.

1. AWS에서 제공하는 CDN (Content Delivery Network) 서비스
   1. 컨텐츠(정적 및 동적)를 전 세계 사용자에게 빠르고 안정적으로 전달한다.
   2. 정적 컨텐츠와 동적 컨텐츠는 다른 캐시 처리 전략이 필요하다.
2. 글로벌 서비스 : 전 세계 수백 개 엣지 로케이션 활용 (리전은 US-east1 취급)
3. 비용 : 데이터 송신/수신 & 엣지 컴퓨팅 & 추가 기능 + 프리티어에서 지원을 많이 해주는 편이다.

 

---

주요 개념

 

1. CDN 서버 : 컨텐츠를 본래 서버에서 받아와 캐싱하여 빠르게 컨텐츠를 제공하는 캐시 서버
   • 사용자의 지리적 위치와 가까운 CDN 서버에서 응답을 제공해 지연(latency)을 줄임.
2. Edge Location : AWS의 CloudFront 등의 CDN 서비스들을 가장 빠른 속도로 캐싱하기 위한 거점, 즉 가장 가까운 데이터센터에서 컨텐츠를 가져오는 지점. → Global Accelerator와 유저를 연결하는 거점
   • Regional Edge Cache : Edge Location의 상위 단위, 좀 더 큰 캐싱 거점
3. 원본(Origin) : 실제 컨텐츠가 존재하는 서버(EC2, S3 등)
4. 배포(Distribution) : CloudFront의 CDN 구분 단위 → 여러 엣지 로케이션으로 구성된 컨텐츠 제공 채널
5. 동작(Behavior) : 프로토콜, 캐싱 정책, 로그 등 컨텐츠 전달 방식 설정

 

 

---

주요 기능 

 

1. 컨텐츠 가속화 (Content Acceleration)
   • 정적 컨텐츠 캐싱 : 이미지, JS, CSS, HTML 같은 정적 컨텐츠를 캐싱하여 빠른 응답 제공
   • 동적 컨텐츠 응답 최적화 : API 등의 동적 컨텐츠도 캐싱 및 TLS 및 Keep-Alive 등의 네트워크 최적화로 Acceleration 가능
   • 원본 서버(Origin)의 부하 감소 & 정밀한 캐시 정책 적용 가능
2. 유연한 원본(Origin) 설정 및 장애 대비
   • S3, EC2, ALB, API Gateway, 외부 서버 등 다양한 오리진 지원
   • 장애(Failover) 발생 시 백업 오리진으로 자동 전환 및 커스텀 에러 페이지 지원
3. HTTPS / TLS 지원 : AWS Certificate Manager를 통해 TLS 인증서를 발급받아 무료로 적용 가능 
4. 다양한 최적화 및 보안 기능 제공
   • 보안 및 접근 제어: S3 Origin에 대한 접근 제어(OAI, OAC) & AWS WAF 연동
   • 서버리스 엣지 처리: Lambda@Edge, CloudFront Functions
   • 모니터링 및 분석: 로그 저장(S3), CloudWatch, 캐시 히트율 등 확인 가능
   • 파일 전송 최적화: 대용량 파일 분할 전송, 압축 등
5. 유스케이스 
   
   • 이미지, 영상 등 정적 컨텐츠의 빠른 글로벌 응답 제공, 전송 최적화 및 스트리밍 서비스 가속화 
   • API 응답의 지연을 줄이기 위한 동적 컨텐츠 가속화 활용
   • Route 53과 함께 사용하여 도메인 연결 및 HTTPS 인증서 설정 구성 가능

 

 

 

 

 

 

 

---

배포 (Distribution)

 

 

CloudFront에서 컨텐츠를 전 세계에 전달하기 위해 사용하는 CDN 구성 단위를 배포(Distribution)라고 한다.
하나의 배포는 원본(Origin), 경로 단위의 정책 설정(Behavior)을 포함하고 있으며, 생성 시 고유한 CloudFront 도메인을 자동으로 할당받는다.

• 하나의 배포는 여러 Origin과 Behavior를 포함할 수 있으며, 요청 경로에 따라 라우팅이 달라질 수 있다.

 

AWS Console에서의 배포

 

 

 

 

 

 

 

 

 

---

원본 (Origin)

 

컨텐츠의 실제 출처가 되는 서버를 Origin(원본)이라고 하며, 보통 S3, EC2, ALB, API Gateway, 또는 외부 HTTP 서버 등이 사용된다.

CloudFront는 실제 파일이나 데이터를 보관하는 서버로부터 요청이 들어올 때 캐시가 존재하지 않는다면 원본(Origin)에서 컨텐츠를 가져와 전달한다.

1. 특징
   • IP 주소는 사용할 수 없으며, 도메인 기반으로 설정해야 한다.
   • HTTP 또는 HTTPS 접근 방식을 선택할 수 있다.
2. 종류
   1. Custom Origin : EC2, ALB, Lambda URL, S3 정적 호스팅, 온프레미스 등 S3 외의 HTTP 서버를 대상으로 한다.
   2. S3 Origin : S3 객체에 대한 직접 POST/PUT 요청 기능 및 접근 제어 기능(OAI / OAC)이 포함된 Origin이다.
      • 도메인 지정 규칙 : {bucketname}.s3.{region}.amazoneaws.com으로 지정해야 S3 Origin으로 인식한다.
3. 추가 기능
   • Origin Group : 여러 Origin을 Primary / Secondary로 묶어 Failover 시나리오를 구성할 수 있다.
   • Origin Custom Header : CloudFront가 Origin으로 요청을 보낼 때 커스텀 헤더를 추가할 수 있다. 아래는 대표적인 유스케이스이다.
     • 요청 추적 : CloudFront 요청임을 식별할 수 있도록 헤더를 추가한다.
     • 보안 강화 : 비공개 인증 헤더를 삽입해 Origin이 CloudFront 요청만 허용하도록 할 수 있다.
     • 응답 제어 : A/B 테스트, 환경 분기 등 동적 처리를 위해 헤더 기반으로 응답을 조절할 수 있다.

 

 

 

AWS Console에서의 Origin

 

 

 

 

 

 

 

 

---

동작 (Behavior)

 

Behavior는 CloudFront가 들어오는 요청을 어떻게 처리할지 정의하는 설정의 묶음이다. 특정 경로로 들어오는 요청에 대해 어떤 Origin으로 전달할지, 어떤 방식으로 캐싱하고 응답할지를 세부적으로 지정할 수 있다.

• 요청 경로(Path Pattern)에 따라 Behavior를 구분하여 설정할 수 있다.
• 하나의 배포(Distribution)는 여러 개의 Behavior를 가질 수 있다.

 

 

---

주요 구성 항목

 

1. Origin 설정 : 이 Behavior에 대한 요청을 어떤 Origin(S3, EC2 등)으로 전달할지 지정한다.
2. Viewer 설정
   • 프로토콜: CloudFront에 접근할 때 HTTP/HTTPS를 어떻게 처리할지 선택 (HTTP and HTTPS / Redirect HTTP to HTTPS / HTTPS only)
   • HTTP Method: 허용할 요청 메서드(GET, POST, PUT, DELETE 등)를 선택
   • 접근 제한: Presigned URL 또는 Presigned Cookie를 사용하여 접근 제어 가능
3. Policy 설정
   • Cache Policy (캐시 정책): 특정 요청에 대한 캐시의 동작에 대한 설정 (Cache Key, Cache TTL, 컨텐츠 압축 관련 설정 등)
   • Origin Request Policy (원본 요청 정책): CloudFront에서 Origin으로 요청을 보낼 때 포함시킬 HTTP 정보(Header, Query String 등)을 선택하여 요청 가능
   • Response Header Policy (응답 헤더 정책) : Origin의 응답을 Viewer에게 제공할 때 추가하거나 제거할 Header 지정 가능 (단, Authorization Header는 설정 불가)
4. 기타 기능
   • Lambda@Edge / CloudFront Functions를 통해 요청 또는 응답을 실시간으로 조작 가능
   • Field Level Encryption을 통해 민감한 데이터 필드 암호화 처리 가능

 

 

---

캐시 정책 (Cache Policy)

 

CloudFront는 요청된 컨텐츠를 Origin에서 매번 가져오지 않고, 엣지(Edge Location)에 미리 저장해두었다가 빠르게 응답할 수 있다.
이때 캐시 동작 방식을 결정하는 것이 바로 캐시 정책(Cache Policy)이다. 이것은 CloudFront의 Behavior에 연결되어 적용된다

1. 캐시의 동작 구조 : 요청에 대해 먼저 Edge Location에서 캐시 데이터 확인 → 없다면 상위인 Regional Edge Cache, 이후 Origin 순으로 요청됨.
   • Cache Hit : Edge Location에 캐시 데이터가 존재하여 바로 응답 가능한 경우를 캐시 히트라고 하며, CloudFront를 운영할 때 캐시 히트의 빈도를 높일 수 있도록 하는 것이 중요하다.
2. 설정 항목 : Cache Key 구성 기준, TTL, 컨텐츠 압축 등
   1. Cache TTL : 캐시된 객체의 보관 시간을 설정하는 값
      • 구성 항목 : Default TTL(기본), Minimum TTL(최소), Maximum TTL(최대)
      • 적용 범위 : 특정 CloudFront 배포의 모든 Object에 대해서 Default TTL 일괄 적용
        • 파일 단위에서는 Origin에서 Cache-Control & Expires Header를 통해 개별적 TTL 조절 가능
          • Cache-Control : 얼마나 오래 Object를 Cache할 지 기간을 설정
          • Expires : Cache가 만료되는 시점을 설정 → CloudFront + 브라우저 모두 영향
          • CloudFront의 Min-Max TTL 범위 안에서만 설정 가능
   2. Cache Key : 캐시 데이터는 Key-Value 형태로 Edge Location에 저장된다. 이때 Key를 구성하는 기준을 의미한다.
      • Key의 기본값은 요청 경로(Path)이며, 여기에 Header, Query String, Cookie의 포함 여부를 결정할 수 있다.
      • 효율적인 캐시 전략은 이 Cache Key 구성을 얼마나 잘 하는가에 달려 있다.
        • 예를 들어 http://example.com/image/banner?location=kr에 대해서 생각해보자.
        • 모든 지역에서 동일한 컨텐츠를 제공한다면, 즉 location 파라미터가 실제 응답에 영향을 주지 않는다면, 쿼리스트링을 Cache Key에서 제외하는 것이 더 효율적이다. 
        • 반대로 지역마다 다른 컨텐츠를 제공한다면(location 파라미터에 따라 응답이 달라진다면), 쿼리 스트링을 Cache Key에 포함시키는 것도 고려할 수 있다.
3.  캐시 정책의 종류
   • Managed Policy: AWS에서 미리 제공하는 기본 정책 사용 (ex : CachingOptimized)
   • Custom Policy: 사용자가 직접 캐시 기준을 정의한 정책

 

 

 

---

CloudFront는 요청 경로별로 서로 다른 동작(Behavior)을 정의하고, 그에 맞는 캐시 정책을 적용할 수 있다. 아래 그림은  /images/*와 /api/* 경로에 대해 실제 설정된 예시이다.

 

1. 이미지 요청 (/images/*)
   1. 이미지는 변경이 거의 없고, 여러 사용자에게 동일한 응답을 반복적으로 제공해야 하는 정적 컨텐츠의 성격이다. 따라서 리소스를 엣지에서 캐싱하면 응답 속도는 빨라지고, Origin 부하는 줄어든다.
   2. 캐시 정책(Managed-CachingOptimized)은 TTL을 길게 설정하고, 불필요한 쿼리/헤더/쿠키는 제외하는 정책이다.
2. API 요청 (/api/*)
   1. API 응답은 사용자 상태, 인증 정보, 요청 시간 등에 따라 달라질 수 있는 동적 컨텐츠이다.
   2. 캐시 정책(Managed-CachingDisabled)으로는 캐시를 아예 하지 않고, 원본 요청 정책(Managed-AllViewer)으로 모든 요청 정보를 Origin에 전달해 정확한 응답을 보장하는 정책을 적용했다.
   3. 해당 Behavior은 예시일 뿐, API도 모든 요청을 반드시 실시간 처리할 필요는 없으며 캐시를 활용할 수 있다. 공용 데이터, 읽기 중심 API는 목적에 따라 캐싱이 효과적으로 활용될 수 있다. 예를 들어 게시판 조회 등이 있다.

 

 

 

 

 

 

 

 

 

 

---

CloudFront 활용 

 

지금부터는 CloudFront를 활용하여 EC2로 배포된 간단한 웹을 Origin Server로 설정하고, CDN의 캐시 활용이 실제 응답에 어떤 영향을 주는지 확인해보려고 한다. 

 

 

배포(Distribution) 생성 및 원본(Origin) 설정

 

• CloudFront Distribution(배포)를 생성하면서, EC2 인스턴스를 Origin으로 설정하는 단계이다.
• Origin은 CloudFront가 컨텐츠를 가져오는 실제 서버로, 이 설정이 캐싱 대상의 출처가 된다. 이후 설정될 Behavior에 따라 캐시 전략과 처리 방식이 결정된다.
• 도메인 입력란에는 EC2의 퍼블릭 DNS 주소를 입력하고, 기본 포트는 80으로 설정했다.
• HTTP 또는 HTTPS 프로토콜을 선택할 수 있으며, 이번 실습에서는 HTTP를 사용한다.

 

 

 

---

디폴트 동작(Behavior) 설정

 

• 배포 구성 시점에 Default Behavior를 함께 설정해야 한다. 모든 요청(*)에 대한 기본 정책으로서 해당 Behavior가 사용되게 된다. 추후에 경로별 Behavior를 추가하여 세분화할 수 있다.
• HTTP 및 HTTPS 요청을 모두 허용하고, GET과 HEAD 메서드로 제한했다.
• 캐시 정책은 Customize 유형으로 직접 설정했다. 캐시 Key는 오리진의 캐시 헤더를 그대로 사용하도록 설정하고, TTL은 기본 10초로 지정하였다.
  
  

 

 

 

 

---

결과 확인

 

• CloudFront 배포를 정상적으로 진행했다면 도메인을 확인할 수 있으며 약간 기다리면 CDN이 활성화된다. 해당 도메인으로 접속하면 원본 서버의 웹 사이트가 브라우저상에 나타나는 것을 확인할 수 있다.

 

 

for i in {1..30}; do curl -s https://d2dihhan48ten1.cloudfront.net/; sleep 1; done

• crul 명령어를 통해서 1초 간격으로 30번의 요청을 해 보았다.

 

• 이 때 Origin 서버의 Access Log의 마지막 Tail 부분을 확인해보면 모든 요청이 Origin까지 전달되지는 않았다.
• 마지막 로그에 찍힌 요청은 10초 간격으로 3건으로, 이는 CloudFront가 캐시된 컨텐츠를 재사용했음을 의미한다.
• 이 때 10초는 캐시 정책의 TTL로 설정했던 기간이었다. CloudFront는 최초 요청 이후 10초 동안 동일한 요청을 캐시에서 처리한 것이다.

 

 

 

 

 

 

 

 

 

---

CloudFront 활용 : Failover

 

이어서 추가적으로 Origin 설정으로 Origin Group을 활용하고, Behavior를 변경하여 원본 서버가 비정상일 때 대응할 수 있는 대체 리소스를 제공하는 Failover 대응 방법에 대해서도 알아보자.

 

CloudFront 단에서의 Failover 구현을 통해서 자동으로 예비 리소스로 전환하여 고가용성을 확보하거나 서비스 장애 안내 등의 높은 사용자 경험을 제공할 수 있다.

 

 

이전 포스팅에서는 Route 53에서도 Failover를 구현하였었다. 두 서비스에서의 Failover의 주요 목적은 다음과 같다.

• Route53의 Failover : 도메인 레벨의 가용성 확보가 목적이다. 즉 호스팅하는 도메인에 대한 서비스의 지속성을 위한 Failover를 구현해야 한다.
• CloudFront의 Failover : 컨텐츠 단위의 가용성 확보, 즉 요청에 대한 응답의 지속성이 목적이다. 특정 Origin 서버 단위의 문제에 대응하기 적합하며, 대체 컨텐츠 및 안내 페이지 제공에 활용된다.

 

 

 

Secondary Origin 생성

 

• 생성했던 배포(Distribution)에서 원본(Origin)을 하나 더 추가해주자.
• 추가할 Origin은 Secondary Origin으로서 활용할 것이며, 서비스 이용 불가능을 안내하는 웹 사이트를 제공하는 EC2 인스턴스를 연결해주었다.

 

 

 

 

 

---

원본 그룹 생성

 

• Origin Group 기능을 통해 Primary Origin이 비정상일 경우 자동으로 Secondary Origin으로 전환할 수 있다.
• 두 개의 EC2 인스턴스를 Primary와 Secondary로 등록해주었다. Primary는 정상 웹 서비스이며, Secondary는 대체 웹 서비스이다.
• Failover 조건으로는 HTTP 상태 코드 404, 500, 503을 선택하여, 이 응답이 발생하면 자동으로 대체 Origin으로 요청이 전환되도록 설정하였다.

 

 

 

 

 

---

동작(Behavior) 수정

 

• 기존에 개별 Origin으로 지정되어 있던 기본 동작(Behavior)을 수정하여, 앞서 생성한 Origin Group으로 변경하는 과정이다.
• 경로 패턴이 기본값(*)으로 설정되어 있기 때문에 모든 요청에 대해 Failover가 적용되도록 구성된다.

 

 

 

 

 

 

---

결과 확인

 

• 기본적인 상황에서는 Primary Origin에 연결되어 정상 페이지와 함께 인스턴스 ID가 출력된다.

 

 

---

• Primary 인스턴스를 중지시켜 보았다. 즉 서버가 비정상 상황임을 가정하였다. 만약 Failover 처리를 하지 않았다면 503, 504 Error 등이 뜰 것이다.
• 그렇지만 우리는 Failover 처리를 해 두었기 때문에 Secondary Origin으로 연결되는 것을 확인할 수 있다.

 

 

 

 

 

 

 

 

 

---

References

 

https://docs.aws.amazon.com/

https://docs.aws.amazon.com/

 

 

https://www.inflearn.com/course/%EC%89%BD%EA%B2%8C-%EC%84%A4%EB%AA%85%ED%95%98%EB%8A%94-aws-%EA%B8%B0%EC%B4%88/dashboard

쉽게 설명하는 AWS 기초 강의 강의 | AWS 강의실 - 인프런