AWS CloudFront란 무엇인가: CDN 동작 원리와 캐시 전략

CloudFront는 AWS의 글로벌 CDN 서비스로, 전 세계 750개 이상의 Edge Location에서 콘텐츠를 캐싱해 사용자에게 낮은 지연 시간으로 응답을 전달합니다. 단순 정적 파일 배포를 넘어, 동적 콘텐츠 가속, 보안 계층, 엣지 컴퓨팅까지 포함하는 콘텐츠 배포 플랫폼입니다.

핵심 요약

• CloudFront는 사용자와 가장 가까운 Edge Location에서 콘텐츠를 서빙해 응답 지연을 줄입니다.
• Origin(S3, ALB, EC2, 외부 서버)에서 콘텐츠를 가져와 Edge에 캐시합니다.
• Cache Policy로 TTL, Cache Key를 설계해 캐시 적중률(Hit Ratio)을 최적화합니다.
• AWS Origin에서 CloudFront로의 데이터 전송은 추가 비용이 없습니다.
• CloudFront Functions와 Lambda@Edge로 엣지에서 요청/응답을 가공할 수 있습니다.

1. 왜 CDN이 필요한가

웹 서비스를 서울 리전 EC2에서 운영한다고 가정합니다. 한국 사용자는 빠르게 접근하지만, 미국이나 유럽 사용자는 물리적 거리만큼 네트워크 지연이 발생합니다.

CDN 없이 운영하면 다음 문제가 발생합니다.

• 해외 사용자의 응답 시간이 200~400ms 이상 늘어납니다.
• Origin 서버에 모든 요청이 집중돼 부하가 커집니다.
• 동일한 정적 파일(이미지, JS, CSS)을 매번 Origin에서 전송하므로 데이터 전송 비용이 불필요하게 높아집니다.
• 트래픽 급증 시 Origin이 직접 부하를 받아 장애 위험이 높아집니다.

CDN은 이런 문제를 해결하기 위해 글로벌 엣지 네트워크에 콘텐츠를 캐싱하고, 사용자와 가장 가까운 위치에서 응답을 전달합니다.

2. CloudFront의 글로벌 네트워크 구조

CloudFront 글로벌 네트워크 구조

CloudFront는 2단계 캐시 계층으로 동작합니다.

계층	설명	수량
Edge Location	사용자와 가장 가까운 캐시 서버. 최초 요청 처리 지점	750+ PoP
Regional Edge Cache	Edge Location과 Origin 사이의 중간 캐시 계층	13개
Origin	원본 콘텐츠가 저장된 서버 (S3, ALB, EC2, 외부 HTTP 서버)	사용자 정의

동작 흐름:

1. 사용자 요청이 DNS를 통해 가장 가까운 Edge Location으로 라우팅됩니다.
2. Edge Location에 캐시가 있으면 즉시 응답합니다 (Cache Hit).
3. 캐시가 없으면 Regional Edge Cache를 확인합니다.
4. Regional Edge Cache에도 없으면 Origin으로 요청을 전달합니다.
5. Origin 응답은 Regional Edge Cache와 Edge Location에 캐싱된 후 사용자에게 전달됩니다.

이 2단계 구조의 이점은 Origin으로의 요청 횟수를 줄이는 것입니다. 여러 Edge Location이 같은 콘텐츠를 요청할 때, Regional Edge Cache에서 한 번만 Origin에 요청하고 나머지 Edge Location에 공유합니다.

3. CloudFront 요청 처리 흐름

CloudFront 요청 처리 흐름

실무에서 스타트업이 React SPA + API 서버를 운영한다면, CloudFront를 다음과 같이 구성합니다.

사용자 → CloudFront → Behavior 1: /api/* → ALB (동적 API)
                    → Behavior 2: /*     → S3 (정적 파일)

CloudFront는 Distribution 단위로 동작하며, 각 Distribution은 여러 Behavior를 가질 수 있습니다.

Distribution 구성 요소

구성 요소	역할
Origin	원본 콘텐츠 서버 (S3, ALB, Custom HTTP)
Behavior	URL 패턴별 캐시/라우팅 규칙
Cache Policy	TTL, Cache Key 정의
Origin Request Policy	Origin으로 전달할 헤더/쿠키/쿼리스트링 정의
Response Headers Policy	응답 헤더(CORS, Security Headers) 자동 추가

Origin 유형별 사용 시나리오

Origin 유형	사용 시나리오
S3 Bucket	정적 웹사이트, SPA, 이미지, 동영상
ALB	API 서버, 동적 콘텐츠
EC2	레거시 서버, 커스텀 웹 서버
MediaStore / MediaPackage	라이브/온디맨드 스트리밍
외부 HTTP 서버	온프레미스 서버, 타사 API

4. 캐시 동작 원리: Cache Key와 TTL

CloudFront 캐시 정책 구조

Cache Key란

CloudFront가 "이 요청은 캐시에서 응답할 수 있는가?"를 판단하는 기준이 Cache Key입니다.

기본 Cache Key는 URL(호스트 + 경로)입니다. 여기에 쿼리스트링, 헤더, 쿠키를 추가하면 Cache Key가 세분화됩니다.

기본: https://example.com/images/logo.png
확장: https://example.com/images/logo.png?size=large + Accept-Language: ko

Cache Key에 포함되는 요소가 많을수록 캐시가 세분화되어 Hit Ratio가 낮아집니다. 반대로 너무 적으면 서로 다른 응답이 같은 캐시로 서빙될 수 있습니다.

Cache Key 설계 원칙

원칙	설명
필요한 것만 포함	응답이 달라지는 요소만 Cache Key에 추가
쿼리스트링 정규화	순서가 다른 쿼리스트링도 같은 캐시로 처리
불필요한 헤더 제외	User-Agent 등 변동이 큰 헤더는 제외
압축 지원	Accept-Encoding은 자동 정규화 (gzip, br)

TTL(Time to Live) 설계

TTL은 캐시된 콘텐츠의 유효 기간입니다. CloudFront의 TTL은 3단계로 결정됩니다.

최종 TTL = max(MinTTL, min(MaxTTL, Origin 헤더 기반 TTL 또는 DefaultTTL))

TTL 설정	기본값	역할
Minimum TTL	0초	Origin이 no-cache를 보내도 최소한 이 시간은 캐시
Default TTL	86400초 (24시간)	Origin이 Cache-Control 헤더를 보내지 않을 때 적용
Maximum TTL	31536000초 (365일)	Origin이 긴 TTL을 보내도 이 값을 초과하지 않음

콘텐츠 유형별 TTL 설계 예시

콘텐츠	권장 TTL	이유
정적 이미지 (logo.png)	365일	파일명에 해시를 포함해 무효화 불필요
JS/CSS 번들 (app.a1b2c3.js)	365일	빌드 시 해시가 변경되므로 장기 캐시 가능
HTML (index.html)	0~60초	배포 시 즉시 반영되어야 함
API 응답 (/api/products)	0~300초	데이터 변경 주기에 따라 결정
사용자별 응답 (/api/me)	0초 (캐시 안 함)	개인화된 응답은 캐시 불가

5. 캐시 전략: 실무 시나리오

시나리오: 이커머스 웹사이트

상품 이미지 500만 개, 하루 1000만 페이지뷰를 처리하는 이커머스 서비스를 운영한다면 캐시 전략을 다음과 같이 설계할 수 있습니다.

Behavior 구성:

Path Pattern	Origin	Cache Policy	TTL
/static/*	S3	CachingOptimized	365일
/images/*	S3	CachingOptimized	365일
/api/products/*	ALB	Custom (쿼리스트링 포함)	300초
/api/cart/*	ALB	CachingDisabled	0초
/* (기본)	S3	Custom (MinTTL: 0)	60초

설계 판단 기준:

• /static/*, /images/*: 파일명에 해시를 포함하므로 장기 캐시. 변경 시 새 URL이 생성됩니다.
• /api/products/*: 상품 정보는 5분 정도 지연을 허용할 수 있습니다. 가격 변경이 즉시 반영되어야 하면 TTL을 줄이거나 캐시 무효화를 사용합니다.
• /api/cart/*: 장바구니는 사용자별 데이터이므로 캐시하지 않습니다.
• /*: HTML은 짧은 TTL로 배포 반영 속도를 확보합니다.

AWS 관리형 Cache Policy 활용

AWS는 자주 사용되는 패턴을 관리형 정책으로 제공합니다.

관리형 정책	용도
CachingOptimized	정적 콘텐츠 (압축 지원, 긴 TTL)
CachingDisabled	동적 콘텐츠 (캐시 안 함)
CachingOptimizedForUncompressedObjects	압축하지 않는 정적 파일
Amplify	AWS Amplify 호스팅용

커스텀 정책이 필요한 경우는 쿼리스트링 일부만 Cache Key에 포함하거나, 특정 헤더 기반으로 캐시를 분리해야 할 때입니다.

6. 캐시 무효화(Invalidation)

캐시된 콘텐츠를 TTL 만료 전에 강제로 제거해야 하는 경우가 있습니다.

# 특정 파일 무효화
aws cloudfront create-invalidation \
  --distribution-id E1ABC2DEF3GH \
  --paths "/index.html" "/api/products/featured"

# 경로 전체 무효화
aws cloudfront create-invalidation \
  --distribution-id E1ABC2DEF3GH \
  --paths "/images/*"

무효화 비용과 제약

항목	내용
무료 한도	월 1,000개 경로
초과 비용	경로당 $0.005
처리 시간	보통 수 분 내 완료 (보장은 아님)
와일드카드	/*는 1개 경로로 계산

무효화 대신 버전 관리

운영 환경에서는 무효화보다 파일명 버전 관리를 권장합니다.

# 무효화 방식 (비권장)
/css/style.css → 캐시 무효화 요청 필요

# 버전 관리 방식 (권장)
/css/style.a1b2c3.css → 새 빌드 시 자동으로 새 URL 생성

버전 관리의 이점:

• 무효화 비용이 발생하지 않습니다.
• 전파 지연 없이 즉시 새 버전이 서빙됩니다.
• 롤백 시 이전 버전 URL을 참조하면 됩니다.

다만 index.html처럼 URL이 고정된 파일은 버전 관리가 어려우므로, 짧은 TTL과 무효화를 조합합니다.

7. 엣지 컴퓨팅: CloudFront Functions와 Lambda@Edge

CloudFront 엣지 컴퓨팅 구조

CloudFront는 요청/응답 흐름의 4개 지점에서 코드를 실행할 수 있습니다.

이벤트	실행 시점	사용 예시
Viewer Request	사용자 요청이 Edge에 도착할 때	URL 리다이렉트, 인증 토큰 검증
Origin Request	Edge가 Origin으로 요청을 보내기 전	동적 Origin 선택, 헤더 추가
Origin Response	Origin 응답이 Edge에 도착할 때	응답 헤더 수정, 에러 페이지 커스텀
Viewer Response	Edge가 사용자에게 응답을 보내기 전	보안 헤더 추가, 쿠키 설정

CloudFront Functions vs Lambda@Edge

항목	CloudFront Functions	Lambda@Edge
실행 위치	모든 Edge Location	Regional Edge Cache
런타임	JavaScript (ES 5.1 호환)	Node.js, Python
최대 실행 시간	1ms 미만	5초 (Viewer), 30초 (Origin)
메모리	2MB	128~10,240MB
네트워크 접근	불가	가능
비용	요청 100만 건당 약 $0.10	요청 100만 건당 약 $0.60 + 컴퓨팅 시간
적합한 작업	URL 리다이렉트, 헤더 조작, 간단한 인증	외부 API 호출, 복잡한 인증, 이미지 리사이징

선택 기준:

• 단순 헤더 조작, URL 리라이트, 기본 인증 → CloudFront Functions
• 외부 API 호출, DB 조회, 복잡한 로직 → Lambda@Edge

8. 보안 기능

CloudFront는 콘텐츠 배포와 함께 보안 계층 역할도 수행합니다.

기능	역할
HTTPS 강제	HTTP → HTTPS 리다이렉트 또는 HTTPS Only 설정
ACM 인증서	커스텀 도메인에 무료 SSL/TLS 인증서 연결
OAC (Origin Access Control)	S3 Origin 직접 접근 차단. CloudFront를 통해서만 접근 허용
AWS WAF 연동	SQL Injection, XSS, Rate Limiting 규칙 적용
AWS Shield Standard	DDoS 방어 자동 적용 (추가 비용 없음)
Geo Restriction	특정 국가에서의 접근 차단/허용
Signed URL / Signed Cookie	인증된 사용자만 콘텐츠 접근 허용

OAC 설정이 필요한 이유

S3 버킷을 CloudFront Origin으로 사용할 때, 버킷을 퍼블릭으로 열어두면 CloudFront를 우회해 S3에 직접 접근할 수 있습니다. 이 경우 캐시를 거치지 않으므로 비용이 증가하고, WAF/Geo Restriction 같은 보안 규칙이 적용되지 않습니다.

OAC를 설정하면 S3 버킷은 CloudFront의 요청만 허용하고, 다른 모든 접근을 차단합니다.

9. 비용 구조와 최적화

과금 항목

항목	설명
Data Transfer Out	Edge → 사용자로 전송되는 데이터 (가장 큰 비용)
HTTP/HTTPS 요청 수	요청 건당 과금 (HTTPS가 HTTP보다 비쌈)
Origin에서의 전송	AWS Origin → CloudFront: 무료 / 외부 Origin: 별도 과금
무효화	월 1,000건 초과 시 건당 $0.005
엣지 함수	CloudFront Functions / Lambda@Edge 실행 비용
Origin Shield	추가 캐시 계층 활성화 시 요청당 추가 비용

리전별 Data Transfer 요금 (2026년 기준, 첫 10TB)

리전	GB당 요금
미국, 멕시코, 캐나다	$0.085
유럽, 이스라엘	$0.085
일본, 한국, 싱가포르	$0.114
인도	$0.109
남미	$0.110

볼륨이 증가하면 단가가 낮아지는 티어 구조입니다. 50TB 이상이면 CloudFront Security Savings Bundle이나 정액 요금제(Flat-Rate Pricing)를 검토할 수 있습니다.

비용 최적화 전략

전략	효과
Cache Hit Ratio 극대화	Origin 요청 감소 → 전송 비용 절감
불필요한 쿼리스트링 제거	Cache Key 단순화 → Hit Ratio 향상
압축 활성화 (gzip, Brotli)	전송 데이터량 감소
Origin Shield 활성화	동일 콘텐츠에 대한 Origin 요청 통합
로그를 S3로 전송	실시간 로그 대비 비용 절감
Price Class 설정	필요 없는 리전의 Edge 사용 제외

Price Class 활용:

모든 Edge Location을 사용할 필요가 없는 경우, Price Class를 설정해 비용이 높은 리전을 제외할 수 있습니다.

Price Class	포함 리전
Price Class All	전 세계 모든 Edge
Price Class 200	미국, 유럽, 아시아, 중동, 아프리카
Price Class 100	미국, 유럽만

한국 사용자만 대상이라면 Price Class 200으로 충분할 수 있습니다.

10. 운영 시 주의사항

캐시로 인한 문제 상황

상황	원인	대응
배포 후 이전 버전이 보임	TTL이 남아있어 캐시에서 응답	무효화 실행 또는 버전 관리 사용
특정 사용자만 다른 페이지를 봄	Cache Key에 필요한 변수가 누락됨	Cache Policy에 해당 쿠키/헤더 추가
Origin 장애인데 서비스는 정상	캐시된 콘텐츠로 응답 중	Custom Error Response로 fallback 설정
API 응답이 캐시됨	Behavior 설정에서 Cache Disabled 누락	해당 경로의 Cache Policy를 CachingDisabled로 변경

모니터링 지표

지표	확인 방법	기준
Cache Hit Ratio	CloudFront 콘솔 / CloudWatch	90% 이상이면 양호
4xx/5xx 에러율	CloudWatch Metrics	1% 미만 유지 목표
Origin Latency	CloudWatch	Origin 응답 시간 추적
요청 수 추이	CloudWatch	트래픽 패턴 파악

CloudFront vs 직접 Origin 서빙 비교

항목	CloudFront 사용	Origin 직접 서빙
지연 시간	사용자 근처 Edge에서 수 ms	Origin까지 RTT (수십~수백 ms)
Origin 부하	캐시 적중 시 Origin 접근 없음	모든 요청이 Origin에 도달
보안	WAF, DDoS 방어, HTTPS 자동 적용	별도 구성 필요
비용	Data Transfer Out 과금	EC2 Data Transfer가 CloudFront보다 비쌈
글로벌 성능	자동으로 최적 경로 선택	단일 리전에 종속

EC2에서 직접 인터넷으로 데이터를 전송하는 비용이 CloudFront를 경유하는 것보다 높은 경우가 많습니다. 따라서 비용 관점에서도 CloudFront 도입이 유리할 수 있습니다.

11. 실무 아키텍처 예시: SPA + API 서비스

CloudFront 실무 아키텍처

3인 스타트업이 React SPA와 REST API를 운영한다면 다음과 같이 구성할 수 있습니다.

구성:

• Origin 1: S3 (React 빌드 파일)
• Origin 2: ALB → ECS (API 서버)
• 도메인: app.example.com

Behavior 설계:

/api/*     → ALB (CachingDisabled, Origin Request Policy로 인증 헤더 전달)
/static/*  → S3 (CachingOptimized, 365일 TTL)
/*         → S3 (Custom: DefaultTTL 60초, index.html 서빙)

보안 설정:

• OAC로 S3 직접 접근 차단
• ACM 인증서로 HTTPS 적용
• AWS WAF로 Rate Limiting, SQL Injection 방어
• X-Content-Type-Options, Strict-Transport-Security 등 보안 헤더 추가 (Response Headers Policy)

배포 전략:

• 프론트엔드: S3에 빌드 업로드 → /index.html 무효화 (정적 파일은 해시로 버전 관리)
• API: ECS 서비스 업데이트 (CloudFront 설정 변경 불필요)

이 구조의 이점은 프론트엔드와 API를 같은 도메인에서 서빙하면서도 각각 독립적으로 배포하고 캐시 전략을 분리할 수 있다는 점입니다.

마무리

CloudFront를 도입할 때의 핵심 의사결정은 "무엇을 캐시하고, 얼마나 오래 캐시할 것인가"입니다. 캐시 전략이 잘못되면 사용자가 오래된 콘텐츠를 보거나, 반대로 캐시 적중률이 낮아 비용과 성능 이점을 얻지 못합니다.

설계 시 고려할 점:

• 콘텐츠 유형별 TTL을 분리하고, 변경이 잦은 파일은 짧은 TTL + 무효화를 조합합니다.
• Cache Key는 응답이 실제로 달라지는 요소만 포함합니다.
• 정적 파일은 파일명 해시 기반 버전 관리를 우선 검토합니다.
• Origin에서 적절한 Cache-Control 헤더를 보내도록 설정해야 CloudFront의 TTL 결정이 예측 가능합니다.
• 비용 최적화는 Cache Hit Ratio 모니터링에서 시작합니다.