[AWS CloudFront] AWS에서 CDN서비스 사용하기.
01. What is a CDN?
CloudFront를 알아보기에 앞서, CDN이 무엇인지 알고 CF에 대해서 알아보도록 하자.

💁♂️ CDN 이란?
Content Delivery Network라고 불리며, 전 세계에 분산된 서버 네트워크를 통해 콘텐츠를 빠르고 안정적으로
사용자에게 전달하는 기술을 의미한다.
특히나 웹사이트의 이미지나 JavaScript, CSS 파일 등과 같은 정적 콘텐츠의 로딩 속도를 개선하고
트래픽을 효율적으로 분산시키는데 핵심적인 역할을 합니다.
💁♂️ CDN의 주 기능
1. 캐싱 (Cashing)
- 콘텐츠를 사용자와 가까운 엣지 서버에 저장하여 빠르게 전달.
- 자주 요청되는 파일은 원본 서버가 아닌 CDN 서버에서 제공된다.
2. 지리적 분산
- 전 세계 여러 지역에 서버가 위치해 있어 사용자와 가장 가까운 서버에서 콘텐츠를 제공한다.
3. 트래픽 분산 및 부하 감소
- 원본 서버의 부하를 줄이고 대규모 트래픽에도 안정적으로 대응.
4. 가용성 향상 & 보안 기능
- 특정 서버에 문제가 생겨도 다른 엣지 서버가 콘텐츠를 제공하므로 서비스 중단을 방지.
- DDoS 방어, SSL 인증서 관리, WAF 등 보안 기능을 제공하는 CDN 솔루션도 많다.
02. Why use CF?
그렇다면, 여러 CDN 솔루션 중에서 굳이 CloudFront를 사용하는 이유가 있을까?
- AWS 서비스 (S3, ALB, EC2, CloudWatch 등)와 같이 AWS 생태계 환경에서 연동성이 뛰어나다.
- 사용량 기반 과금 구조여서 트래픽이 적은 경우에 비용이 저렴할 수 있다.
- 전 세계 수백 개의 엣지 서버를 보유하고 있으며 특히 한국, 일본, 미국 지역의 엣지 서버에 특화되어있다.
- 경로 기반 캐싱, 헤더/쿠키 기반 캐싱, TTL 설정 등 쉽고 간편한 세밀한 제어가 가능하다.
솔직히 엔지니어로써 AWS 생태계라면 CF를 사용하는 것이 관리 포인트 측면에서 큰 장점이 되서 쓰는 것 같다 !!!
📌 CF의 동작 방식
이해를 돕기 쉽도록, 고객이 콘텐츠를 요청하는 순간부터 콘텐츠가 전달되고 캐싱되는 과정에 대해 소개해볼게요.
■ 고객이 웹, 앱에 웹사이트 검색 (요청)
■ DNS를 통해 CloudFront 엣지 로케이션으로 라우팅

- 요청된 도메인은 CloudFront의 글로벌 DNS를 통해 가장 가까운 엣지 로케이션으로 연결된다.
- 이 과정은 위에서 설명드렸던 CDN 주 기능중 지리적 분산에 해당된다.
■ CloudFront 엣지 서버에서 캐시 확인
- 엣지 서버는 해당 콘텐츠가 이미 캐시 되어 있는지 확인한다.
✅ 캐시 HIT: 캐시된 콘텐츠를 즉시 사용자에게 전달 → 빠른 응답
❌ 캐시 MISS: 캐시되지 않은 경우 → Origin 서버로 요청 전달
캐시를 확인한다는 말이 추상적일 수도 있어서 살을 좀 덧붙혀서 설명드리자면 ...
고객이 요청한 적이 있는지 여부를 저장하는 것이 아니라 요청 조건에 맞는 콘텐츠가 있는지 여부를 판단한다.
실제 logs를 보면, 정적 컨텐츠에 대한 요청은 아래와 같이 볼 수 있다.

즉, 고객이 정적 콘텐츠를 요청(쇼핑몰에서 상품 이미지를 클릭)하였을때 해당 이미지에 대한 경로가 엣지 서버에
캐싱이 되어 있으면 HIT 처리가 되고, 캐싱이 되어있지 않다면 Origin (실제 웹서버) 으로 요청을 전달한다.
■ Origin 서버로 요청 전달 [캐싱이 없어서 MISS 처리시]
- CloudFront에 설정된 원본 서버 (S3, ALB 및 실제 웹서버 EC2 등..)으로 요청을 전달한다.
- 이때 CloudFront에 설정된 캐싱 정책에 따라 요청이 조정될 수 있다.

- CashingOptimized : Origin Server에 등록된 로컬 캐싱 정책을 무시하고, CF의 캐싱 정책을 따름.
- UseOriginCacheControlHeaders : Origin Server에 등록된 로컬 캐싱 정책을 읽어와서 CF에 적용.
■ Origin 서버에서 콘텐츠 응답
- Origin 서버는 요청된 콘텐츠를 CloudFront 엣지 서버로 반환합니다.
- 응답에는 캐싱 관련 헤더 (Cache-Control, ETag 등)가 포함된다.
■ CloudFront 엣지 서버에서 콘텐츠 캐싱
- 응답받은 콘텐츠는 엣지 서버에 캐싱됩니다.
- TTL(Time-To-Live) 설정에 따라 얼마나 오래 캐시할지 결정된다!
■ 고객에게 콘텐츠 전달
- 이후 동일한 요청이 들어오면 캐싱 정책에 의거하여 콘텐츠를 빠르게 제공할 수 있다.
- 엣지서버에서 바로 고객에게 콘텐츠를 전달함.
📌 요약

★ 캐싱이 엣지 로케이션에 저장된 경우
- 고객의 요청 → CloudFront 엣지 로케이션 → 캐시된 콘텐츠가 바로 응답 → 고객에게 전달.
★ 캐싱이 엣지 로케이션에 저장되지 않은 경우
- 고객의 요청 → CloudFront 엣지 로케이션 → Origin Sever 에서 콘텐츠 디렉토리에서 조회 →
- CloudFront 엣지 로케이션으로 콘텐츠 반환 및 캐싱 → 고객에게 전달
03. 현업에서는 어떻게 사용할까?
먼저 정적 콘텐츠, 동적 콘텐츠를 분리해서 제공하며, 아래와 같이 분리하게된다.

💁♂️ 정적 콘텐츠란?
- 변경이 거의 없으며 image, html, css, js 등 파일 형태로 존재하는 콘텐츠를 의미한다.
- 위와 같은 파일 형태는 CDN에서 엣지 로케이션에 저장하고 캐싱하기에 적합.
💁♂️ 동적 콘텐츠란?
- 사용자 요청에 따라 실시간으로 생성되는 콘텐츠로, 요청마다 결과가 달라질 수 있는 콘텐츠.
- 서버에서 처리 후 생성(DB 조회, 사용자 인증, 계산 등..)되는 콘텐츠를 의미하며, 캐싱하기에 부적합.
- 중요한 정보가 들어있으므로 보안 및 정확성 문제로 캐싱을 저장하지 않고 Origin Server에 직접 요청.
📌 CloudFront 현업 운영 구조
- CloudFront의 Origin을 S3와 ALB로 생성한다.
- 정적 콘텐츠는 S3에 저장 후에 CloudFront에서 정적 콘텐츠가 저장된 경로의 Origin을 S3로 설정.
- 동적 콘텐츠는 EC2에 저장되며 CloudFront Behavior에서 EC2 내부의 디렉토리 경로를 지정.
- 동적 콘텐츠의 Origin은 ALB가 되며, 동적 콘텐츠의 요청이 왔을 때 EC2에서 가져온다.
보통 직접 EC2를 지정하지 않고 현업에서는 ALB를 많이 사용하기 때문에 CloudFront의 Origin은 S3 또는 ALB로 구성된다.
현재 저희 AWS 인프라는 중,소규모라 S3를 사용하지 않고 정적, 동적 콘텐츠가 모두 EC2 내부에 저장되어 있다.

04. CloudFront + S3 구성
첫번째로, 당연하게도 보안성 강화를 위해 ACM에서 인증서를 발급 후 CloudFront에 배포하자.
두번째로, S3에서 보안성 강화를 위해 OAI/OAC 정책을 적용한다.
- OAI : S3 버킷의 URL로 직접 접근을 방지하고, CF를 통해서만 콘텐츠에 접근 가능.
- OAC : IAM Role을 좀 더 세부적으로 관리하는 OAI의 업그레이드 버전임.
세번째로, CloudFront에서 Behavior에 정적, 동적 콘텐츠 경로를 지정한다.
- S3는 정적 콘텐츠만 배포를 할 수 있기 때문에 동적 콘텐츠에 대해서는 다른 서비스로 분기시켜야 한다.
| 경로 | Origin | 설명 |
| /static/* | S3 Bucket | 정적 콘텐츠 (이미지, JS, CSS 등) |
| /api/*, /login, /dashboard 등 | ALB | 동적 콘텐츠 (사용자 요청, DB 연동 등) |
이런 식으로 서비스 별로 분기를 시켜 효율적으로 운영할 수 있다.
하지만 동적 콘텐츠는 Origin에서 데이터를 가져와서 배포하기 때문에 속도 측면에서 살짝 느릴 수 있다.
결론!!
S3를 구성하고, CF에 있는 Behavior 기능을 사용해서 로딩이 빠른 웹사이트를 운영해보자!