AWS CloudFront

1. CDN

CDN(Content Delivery Network)은 지리, 물리적으로 분산된 서버 네트워크를 통해 사용자에게 콘텐츠를 더 빠르게 제공하는 시스템이다. 사용자가 원격지 서버(Origin Server)로부터 이미지, 동영상, HTML 등을 내려받을 때 멀리 있는 서버에서 직접 받으면 지연(Latency)이 발생한다. CDN은 이 문제를 사용자 가까이에 있는 캐시 서버(Edge Server)를 두어 해결한다.

CDN의 핵심 동작 원리

1. 최초 요청 시: 원본 서버(Origin)에서 콘텐츠를 가져와 사용자에게 전송하면서 동시에 Edge 서버에 캐싱한다.
2. 이후 요청 시: CDN이 지정한 만료 시점(TTL)까지는 캐시된 콘텐츠를 Edge에서 바로 제공한다.
3. 캐시 미스(Miss) 시: 해당 콘텐츠가 캐시에 없으면 Origin으로 다시 요청하여 가져온 뒤 캐싱한다.
4. 자주 요청되지 않는 콘텐츠는 주기적으로 캐시에서 삭제되어 공간을 확보한다.

CDN을 사용해야 하는 이유

• 물리적 지연 감소: 지구 반대편 사용자도 가까운 Edge 서버에서 콘텐츠를 받을 수 있다.
• Origin 부하 분산: 트래픽이 갑자기 몰릴 때 Origin이 아닌 CDN 캐시가 처리하므로 병목을 방지한다.
• 비용 절감: 캐시 히트율이 높을수록 Origin 서버로 가는 요청이 줄어 인프라 비용이 낮아진다.

 

2. Amazon CloudFront 개요

Amazon CloudFront는 AWS가 제공하는 CDN 서비스로 정적 및 동적 웹 콘텐츠(.html, .css, .js, 이미지, 동영상 등)를 사용자에게 빠르게 배포하도록 지원한다. 단순한 정적 파일 캐싱을 넘어 보안, 엣지 컴퓨팅, 글로벌 가속 기능까지 통합 제공하는 것이 특징이다.

CloudFront의 주요 특징

• 글로벌 엣지 네트워크: 전 세계 225개 이상의 엣지 로케이션(POP)을 보유하고 있어 어디서든 낮은 지연 시간을 보장한다.
• AWS 백본 네트워크 활용: 사용자 요청이 반드시 통과해야 하는 공용 인터넷 구간을 최소화하고 Amazon 소유의 고가용성 전용 네트워크를 통해 데이터를 전송한다. 수만 개 네트워크와 인터페이스하는 400GbE 병렬 파이버로 구성되어 있다.
• 정적+동적 콘텐츠 모두 처리: 이미지나 CSS 같은 정적 파일뿐 아니라 API 응답, 라이브 스트리밍 등 동적 콘텐츠도 가속할 수 있다.
• AWS 서비스와 긴밀한 통합: S3, EC2, ALB, API Gateway 등과 자연스럽게 연동된다.

 

3. CloudFront 아키텍처 : 3계층 캐싱 구조

CloudFront는 단순히 엣지 서버 하나가 아니다. 요청이 처리되는 과정에는 최대 3개의 캐싱 계층이 존재한다.

[사용자]
    ↓ (DNS 라우팅 → 가장 가까운 POP으로)
[1계층] Edge Location (POP) — 225개 이상, 최전선 캐시
    ↓ (캐시 미스 시)
[2계층] Regional Edge Cache (REC) — 리전별 중간 캐시
    ↓ (REC도 미스 시)
[3계층] Origin Shield (선택 옵션) — 중앙화된 추가 캐시
    ↓ (모두 미스 시)
[Origin] S3, EC2, ALB, Custom Origin 등

1계층: Edge Location (POP, Point of Presence)

가장 사용자에 가까운 캐시 계층이다. 사용자 요청은 DNS를 통해 지연 시간이 가장 낮은 POP으로 라우팅된다. 자주 요청되는 콘텐츠를 여기서 즉시 응답하며 캐시 공간이 부족하면 사용 빈도가 낮은 객체를 제거한다.

2계층: Regional Edge Cache (REC)

개별 POP보다 캐시 용량이 훨씬 크다. POP에서 캐시 미스가 발생하면 바로 Origin으로 가지 않고 우선 REC를 확인한다. 덜 자주 요청되는 콘텐츠도 REC에는 더 오래 유지되기 때문에 Origin으로의 불필요한 요청을 상당히 줄여준다. 예를 들어 유럽의 CloudFront POP은 Origin 서버로 돌아가기 전에 먼저 프랑크푸르트의 REC로 이동하여 객체를 찾는다. 이 기능은 별도 설정 없이 모든 CloudFront 배포에서 기본 활성화되어 있다.

3계층: Origin Shield (선택 옵션)

Origin Shield는 Origin 바로 앞에 위치하는 추가적인 중앙화 캐싱 계층이다. 활성화하면 모든 REC에서 Origin으로 향하는 요청이 반드시 Origin Shield를 거친다. 이를 통해 Origin Shield의 캐시에서 히트되면 Origin까지 요청이 도달하지 않아 Origin 부하를 낮출 수 있다.

Origin Shield가 특히 효과적인 경우:

• 최종 사용자가 여러 지역에 분산되어 있을 때
• 비디오 스트리밍용 JIT(Just-in-time)패키징처럼 Origin에서 연산이 발생하는 워크로드
• 다중 CDN 아키텍처에서 여러 CDN 간 중복 Origin 요청을 줄이고 싶을 때

 

4. CloudFront 핵심 구성요소

Origin (오리진)

클라이언트에게 보여줄 콘텐츠의 원본이 있는 곳이다. 크게 두 종류로 나뉜다.

• S3 Origin: Amazon S3 버킷을 오리진으로 사용. 정적 웹사이트 호스팅에 최적.
• Custom Origin: S3를 제외한 모든 HTTP 서버. EC2 인스턴스, ALB(Application Load Balancer), API Gateway, 온프레미스 웹 서버 등이 해당된다.

Distribution (배포)

CloudFront 설정의 단위다. 어디서(Origin) 콘텐츠를 가져오고 어떻게(Behavior) 전달할지 어떤 도메인으로 서빙할지 등을 정의한다. 배포 생성 후 전 세계 엣지 로케이션에 전파되기까지 약 15분이 소요된다.

CloudFront는 두 가지 배포 유형을 제공한다.

• 표준 배포: 단일 웹사이트나 앱을 위한 고유 구성.
• 다중 테넌트 배포: SaaS 공급자처럼 여러 고객의 도메인을 하나의 공유 설정으로 관리하고 싶을 때 사용.

Behavior (동작)

URL 경로 패턴별로 서로 다른 캐싱 정책, 프로토콜, 허용 HTTP 메서드를 설정할 수 있다. 예를 들어 /api/* 경로는 캐싱 없이 Origin으로 바로 전달하고, /images/* 경로는 캐싱 TTL을 길게 설정하는 방식이다.

주요 Behavior 설정

• Viewer Protocol Policy: HTTP->HTTPS 리디렉션 또는 HTTPS 전용 설정.
• Cache Policy / Origin Request Policy: 캐시 키 구성 및 Origin에 전달할 헤더/쿼리스트링 제어.
• Allowed HTTP Methods: GET/HEAD만 허용할지 PUT/POST/DELETE 등 모두 허용할지.

TTL (Time to Live)

엣지 로케이션에서 캐시된 객체가 유효한 시간이다. 기본값은 24시간이며 최솟값은 0초 최댓값은 제한 없다. Origin의 Cache-Control 헤더와 CloudFront의 TTL 설정이 함께 적용된다.

Invalidation (캐시 무효화)

TTL이 만료되기 전에 특정 파일의 캐시를 강제로 삭제하는 기능이다. 배포 후 파일을 변경했을 때 즉시 최신 내용을 반영하려면 Invalidation이 필요하다. 경로를 직접 지정하거나 /*로 전체 무효화할 수 있다.

매번 수동으로 무효화하기 번거롭다면 S3에 새 파일이 업로드될 때 Lambda 함수가 자동으로 해당 파일의 CloudFront 캐시를 무효화하도록 자동화할 수 있다.

 

 

5. CloudFront 동작 원리 (요청 흐름)

사용자가 CloudFront를 통해 콘텐츠를 요청할 때 내부적으로 아래 순서로 처리된다.

1. 사용자가 웹사이트/앱에 액세스하여 파일을 요청
2. DNS가 요청을 가장 가까운 CloudFront POP(엣지 로케이션)으로 라우팅
3. POP에서 캐시 확인
   -> 캐시 히트(Cache Hit): 즉시 사용자에게 응답
   -> 캐시 미스(Cache Miss): 다음 단계로
4. POP -> 가장 가까운 Regional Edge Cache(REC) 확인
   -> REC 캐시 히트: POP에 전달 -> 사용자에게 응답
   -> REC 캐시 미스: 다음 단계로
5. (Origin Shield 활성화 시) REC -> Origin Shield 확인
   -> Origin Shield 캐시 히트: 응답
   -> Origin Shield 캐시 미스: 다음 단계로
6. Origin(S3, EC2 등)에서 파일 가져오기
7. 오리진에서 첫 번째 바이트가 도착하면 즉시 사용자에게 전달 시작
8. 전달하면서 동시에 캐시에 저장

 

캐시 히트율(Cache Hit Rate)이란 전체 요청 중 캐시에서 직접 처리된 요청의 비율이다. 이 수치가 높을수록 Origin 부하가 줄고 응답이 빨라진다. CloudFront 콘솔에서 모니터링할 수 있으며, 올바른 TTL 설정과 Origin Shield 활용이 히트율을 높이는 핵심이다.

 

6. 캐싱 전략 심화

캐시 키(Cache Key)

CloudFront는 요청이 들어올 때 캐시 키를 기반으로 캐시 히트 여부를 판단한다. 기본적으로 URL이 캐시 키가 되지만 헤더, 쿼리스트링, 쿠키 등을 캐시 키에 포함하도록 설정할 수 있다.

• 캐시 키에 포함하는 값이 많을수록 -> 캐시 키 조합이 늘어나 히트율이 낮아짐
• 캐시 키를 최소화 -> 히트율이 높아지지만 다른 사용자에게 잘못된 콘텐츠가 제공될 수 있음

Cache Policy와 Origin Request Policy를 분리해서 관리하는 것이 AWS 권장 방식이다. Cache Policy는 캐시 키(사용자 응답 구분)를 정의하고 Origin Request Policy는 Origin에 실제로 전달할 헤더/쿼리를 정의한다.

정적 vs 동적 콘텐츠 처리 전략

콘텐츠 유형	캐싱	전략 예시
정적 파일	긴 TTL + 파일명에 해시값 포함	app.a1b2c3.js, logo.png
API 응답	TTL=0 또는 매우 짧게, 또는 캐싱 비활성화	/api/users, /api/orders
HTML 파일	짧은 TTL + Invalidation 자동화	index.html
이미지/미디어	긴 TTL	.jpg, .mp4

자동 압축

CloudFront는 텍스트 및 바이너리 데이터를 자동으로 Gzip/Brotli 압축할 수 있다. 캐시 동작 설정에서 자동 압축을 활성화하고 클라이언트가 요청 헤더에 Accept-Encoding: gzip을 포함하면 자동으로 압축된 응답을 제공한다. 대부분의 최신 브라우저는 이를 기본으로 수행한다.

 

7. 보안

CloudFront는 단순한 CDN을 넘어 다층적인 보안 레이어를 제공한다.

7-1. OAC (Origin Access Control) - S3 직접 접근 차단

S3를 오리진으로 사용할 때 가장 먼저 설정해야 할 보안 기능이다. OAC를 설정하면 S3 버킷을 퍼블릭으로 공개하지 않아도 CloudFront를 통해서만 콘텐츠를 제공할 수 있다. S3의 직접 URL(bucket.s3.amazonaws.com/file.jpg)로는 접근이 차단된다.

OAI vs OAC: OAI(Origin Access Identity)는 구형 방식이고 OAC가 현재 AWS 권장 방식이다. OAC는 OAI 대비 다음의 장점이 있다.

• 단기 자격 증명 및 빈번한 자격 증명 교체 지원
• SSE-KMS(AWS KMS 기반 서버 측 암호화)로 암호화된 S3 객체 접근 가능
• SigV4를 요구하는 AWS 리전에서 POST 메서드 지원
• IAM 서비스 보안 주체 기반의 세분화된 정책 구성

 

7-2. Shared Secret - Custom Origin 직접 접근 차단

OAC는 S3 전용이다. EC2, ALB처럼 Custom Origin을 사용할 때는 OAC를 쓸 수 없다. 이때 사용하는 것이 Shared Secret이다.

CloudFront가 Custom Origin에 요청을 보낼 때 미리 약속한 비밀 값을 HTTP 헤더에 포함시킨다. Origin은 이 헤더 값을 확인하여 CloudFront에서 온 요청인지 직접 접근인지 판별한다.

CloudFront → ALB 요청 시:
X-Origin-Verify: "secret-value-1234"  ← Shared Secret

ALB에서 확인:
헤더 값 일치 → CloudFront 요청 허용
헤더 값 없음 → 직접 접근 차단

비밀 값이 노출되면 의미가 없어지므로 AWS Secrets Manager와 연동하여 주기적으로 자동 교체하는 것이 권장 방식이다. Secrets Manager가 비밀 값을 교체하면 CloudFront 설정과 Origin의 WAF 규칙을 자동으로 업데이트한다.

	OAC	Shared Secret
적용 대상	S3 전용	EC2, ALB 등 Custom Origin
인증 방식	AWS 내부 서명 (위조 불가)	비밀 헤더 값
키 관리	AWS 자동 관리	Secrets Manager 연동 권장

 

7-3. AWS WAF(Web Application Firewall) 통합

CloudFront 배포에 AWS WAF Web ACL을 연결하면 사용자 요청이 Origin에 도달하기 전에 엣지 레벨에서 필터링된다.

• SQL 인젝션, XSS 등 일반적인 웹 공격 차단
• IP 기반 허용/차단 목록 설정
• 특정 국가에서의 접근 제한(지리적 차단, Geo Restriction)
• 요청 속도 기반 Rate Limiting

엣지에서 악성 요청을 차단하기 때문에 Origin 서버의 부하 자체가 줄어든다.

 

7-4. Signed URL과 Signed Cookie - 프라이빗 콘텐츠 보호

유료 콘텐츠, 구독자 전용 미디어처럼 특정 사용자에게만 콘텐츠를 제공해야 할 때 사용한다.

Signed URL: 암호화된 서명이 URL에 포함되어 특정 파일에 대한 임시 접근을 허용한다. 개별 파일 접근 제어에 적합하다.

https://d1234.cloudfront.net/video.mp4
  ?Expires=1735689600
  &Signature=abc123...
  &Key-Pair-Id=APKAXYZ...

Signed Cookie: 여러 파일에 대한 포괄적 접근을 허용할 때 유용하다. URL마다 서명을 생성하지 않아도 되므로 여러 리소스(예: /premium/* 경로 전체)에 대한 접근 권한을 한 번에 부여할 수 있다.

구분	Signed URL	Signed Cookie
적합한 상황	개별 파일 접근 제어	여러 파일/경로 일괄 접근
구현 방식	URL에 서명 파라미터 포함	쿠키에 서명 정보 포함
URL 변경 여부	URL이 길어짐	URL 유지

 

Signed URL/Cookie를 사용할 때는 CloudFront Key Group을 사용하는 것이 권장된다. 루트 계정을 사용하는 구형 방식(Trusted Signers)보다 보안상 안전하다.

 

7-5. HTTPS 강제 및 종단 간 암호화

CloudFront는 기본적으로 HTTPS를 지원하며 Behavior 설정에서 HTTP를 HTTPS로 리디렉션하거나 HTTPS만 허용하도록 강제할 수 있다. 또한 CloudFront에서 Origin으로의 통신도 HTTPS로 강제하여 종단 간(End-to-End) 암호화를 구성할 수 있다.

커스텀 도메인을 사용할 경우 AWS Certificate Manager(ACM)에서 인증서를 발급받아 연결한다. ACM을 통한 인증서는 반드시 us-east-1(버지니아 북부) 리전에서 생성해야 한다.

 

7-6. DDoS 보호 - AWS Shield 통합

CloudFront는 추가 비용 없이 AWS Shield Standard가 자동 적용된다. 모든 CloudFront 배포에 대한 L3/L4 DDoS 공격은 엣지에서 실시간으로 감지, 완화된다. 정적 콘텐츠에 대한 요청은 엣지 로케이션에서 처리되므로 대규모 DDoS 트래픽을 흡수하는 효과도 있다.

 

 

 

8. 비용 구조

CloudFront의 비용은 크게 세 가지로 구성된다.

데이터 전송 비용: 엣지 로케이션에서 사용자에게 전달되는 데이터 양에 따라 리전별로 다르게 과금된다.

HTTP/HTTPS 요청 비용: 요청 수와 사용 리전에 따라 과금된다.

Origin 데이터 전송: AWS 오리진(S3, EC2, ELB, API Gateway 등)에서 CloudFront로의 데이터 전송은 무료다. 즉 S3에 파일을 저장하고 CloudFront로 서빙할 때 S3->CloudFront 구간 비용은 발생하지 않으며 CloudFront->사용자 구간 비용만 청구된다.

Price Class를 설정하여 특정 리전의 엣지 로케이션만 사용하도록 제한하면 비용을 줄일 수 있다. 전 세계 서비스가 필요 없다면 북미+유럽만 포함하는 Price Class 100을 선택하는 방법이 있다.

 

 

9. 자주 쓰이는 활용 패턴

S3 + CloudFront 정적 웹사이트 배포

React/Vue.js 같은 SPA(Single Page Application)를 배포할 때 대표적으로 사용되는 패턴이다.

빌드된 정적 파일
    → S3 버킷 (퍼블릭 액세스 차단)
    → CloudFront 배포 (OAC 설정)
    → 사용자 (HTTPS)

• S3 버킷은 퍼블릭 공개 없이 OAC를 통해 CloudFront만 접근 허용
• ACM 인증서 + 커스텀 도메인 연결
• index.html 배포 시 CloudFront Invalidation 실행

EC2/ALB + CloudFront 동적 콘텐츠 가속

API 서버나 웹 애플리케이션 앞에 CloudFront를 붙이는 패턴이다.

• 정적 리소스(/assets/*)는 캐싱, API 요청(/api/*)은 캐싱 없이 Origin 전달
• WAF 연결로 악성 트래픽 엣지에서 차단
• DDoS 보호 자동 적용

CloudFront + Lambda@Edge를 활용한 인증/인가

사용자 → CloudFront 요청
    → Lambda@Edge (Viewer Request) → JWT 검증
    → 유효: Origin으로 요청 전달
    → 무효: 401/403 응답 반환

미디어 스트리밍 서비스

비디오 콘텐츠를 HLS, MPEG-DASH 등의 프로토콜로 스트리밍할 때 CloudFront를 활용한다. Signed URL/Cookie로 유료 구독자에게만 접근 허용하고, Origin Shield를 활성화하여 JIT 패키징 Origin의 부하를 최소화한다.

 

 

AWS CloudFront는 단순한 CDN을 넘어 보안, 엣지 컴퓨팅, 글로벌 가속을 통합한 플랫폼이다. 핵심을 정리하면 다음과 같다.

• 3계층 캐싱 구조: POP -> REC -> Origin Shield -> Origin
• OAC로 S3 직접 접근 차단, WAF로 웹 공격 방어, Signed URL/Cookie로 프라이빗 콘텐츠 보호
• AWS 오리진 -> CloudFront 데이터 전송 무료, 사용자 방향 아웃바운드만 과금

 

참고 자료

• AWS 공식 문서: https://docs.aws.amazon.com/ko_kr/AmazonCloudFront/latest/DeveloperGuide/
• AWS CloudFront FAQ: https://aws.amazon.com/ko/cloudfront/faqs/
• AWS CloudFront 기능 소개: https://aws.amazon.com/ko/cloudfront/features/