CDN? CloudFront? (1)

이유성·2025년 5월 27일
aws

CDN?

CDN(Content Delivery Network)
웹 콘텐츠를 전 세계에 분산된 서버 네트워크를 통해 빠르게 전달하기 위한 기술

CloudFront?

AWS에서 제공하는 CDN 서비스로 개발자 친화적 환경에서 짧은 지연 시간과 빠른 전송 속도로 데이터, 동영상, 애플리케이션 및 API를 전 세계 고객에게 안전하게 전송하는 고속 콘텐츠 전송 네트워크(CDN) 서비스이다.
필자는 "CloudFront? React 배포할 때 쓰는 거 아닌가?"정도의 수준만 알고 있었지만 이번 프로젝트에 S3에서 많은 정적 파일들을 다루며 비용 및 성능을 이유로 CDN 도입을 고려하였기에 CDN을 공부하고 설정한 내용을 작성해보려 한다.

아래는 CDN 및 CloudFront를 정리한 내용이다

AWS CloudFront

  • AWS에서 제공하는 Content Delivery Netwokr(CDN)
    • 웹페이지, 이미지, 동영상 등의 컨텐츠를 본래 서버에서 받아와 캐싱
    • 해당 컨텐츠에 대한 요청이 들어오면 캐싱해둔 컨텐츠를 제공
    • 컨텐츠를 제공하는 서버와 실제 요청 지점간의 지리적 거리가 매우 먼 경우, 요청 지점 근처의 CDN을 통해 빠르게 컨텐츠 제공 가능
  • 엣지 로케이션에서 데이터를 캐싱
    • 따라서 원본이 변해도 캐싱이 만료되지 않는다면 유저가 보는 내용은 변하지 않음
  • 정적 컨텐츠, 동적 컨텐츠 모두 호스팅 가능
정적 컨텐츠(Static Contents)동적 컨텐츠(Dynamic Contents)

| - 서버에 저장된 파일이 모든 사용자에게 동일하게 전달되는 컨텐츠

  • 매번 서버에 요청할 필요 없이 캐싱 가능
  • HTML/JS 등으로 구성 | - 시간, 사용자, 입력 등에 따라 내용이 변경되는 컨텐츠
  • 매번 서버에 요청하여 내용을 구성하고 전달받아야함
  • PHP, JSP, ASP.net 등으로 서버 처리 |
    | ex) 이미지, 글 뉴스 등 | ex) 로그인이 필요한 내용, 게시판, 댓글 등 |
  • 글로벌 서비스, 단 리전은 US-East-1 취급
    • 글로벌 서비스이지만 ACM 인증서 발금 등은 US-East-1에서 해야하기 떄문임

엣지 로케이션(Edge Location)

  • AWS의 CloudFront(CDN)등의 여러 서비스들을 가장 빠른 속도록 제공(캐싱)하기 위한 거점
  • Global Accelerator와 유저를 연결하는 거점
  • 전 세계에 여러 장소에 흩어져 있음
  • 경찰로 예를 들면 Edge Location은 파출소 느낌 → 간단한 업무 처리 가능

용어 정리

  • 원본(Origin) : 실제 컨텐츠가 존재하는 서버(S3, EC2등)
  • 배포(Distribution) : CloudFront의 CDN 구분 단위로 여러 Edge Location으로 구성된 제공 채널
  • 동작(Behavior) : 프로토콜, 캐싱 정책, 로그 등 어떻게 컨텐츠를 전달할지 설정
  • Edge Location(aka. Points of Presence or POP) : 데이터를 가장 빠른 속도로 제공(캐싱)하기 위한 거점
  • Regional Edge Cache : Edge Location의 상위 단위로 좀 더 큰 캐싱 거점

원본(Origin)

  • 뷰어에게 보여줄 컨텐츠의 원본이 있는 거점
  • 두 가지 종류
    • Amazon S3
    • Custome Origin
      • EC2
      • ELB
      • 기타 EC2 및 다른 HTTP 소스
  • 기본 최대 25/Distribution

S3 Origin

  • Amazon S3을 Origin으로 설정해 컨텐츠를 제공하는 경우
  • 도메인 형식은 {bucketname}.s3.{region}.amazonzws.com
  • S3 Origin 만의 추가 기능
    • S3의 접근 제한 가능 (OAC/OAI) → OAC가 최신
    • Post/Put 등으로 직접 S3에 컨텐츠 업데이트 가능
  • 기타 활용 : S3 Object Lambda

Custom Origin

  • S3를 제외한 모든 Origin
    • MediaStore
    • S3 Static Hosting
    • Lambda Function URL
    • Application Load Balancer
    • EC2 or other HTTP Source
  • Origin Group
    • 여러 Origin을 그룹으로 묶어 Failover 시나리오에 대응 가능
    • ex) Primary에서 HTTP status 500을 반환할 경우, Secondary에서 컨텐츠 가져오기
  • HTTP/HTTPS로 접근할지 선택 가능
  • IP주소는 사용 불가 : 도메인만 가능

Origin Group

  • Failover를 대비하여 Primary, Secondary 두 Origin을 그룹으로 묶어 관리 가능
  • Primary에서 실패한 경우 자동으로 Secondary에 요청
    • 실패를 나타내는 HTTP 코드가 반환된 경우
    • Primary에 통신을 할 수 없는 경우(타임아웃 등)
      • 기본 10초 - 3번 시도
      • 시도 횟수와 시간 조절 가능
    • 요청의 응답이 늦어지는 경우
      • 기본 30, 최대 60초 조절 가능
  • GET, HEAD, OPTION Method에만 적용
  • Primary/Secondary 모두 실패한 경우에 커스텀 에러페이지 생성 가능

Origin Custom Header

  • CloudFront에서 Origin에 요청 시 커스텀 추가 헤더 전달 가능
  • 이미 요청에 포함되어 있으면 덮어씌움
  • 최대 10개 (증가 요청 가능)
  • 별도로 추가 불가능한 Header 존재
    • ex) Host, Range, Connection, Cache-Control, X-Amz-* 등

CloudFront의 캐싱 티어

  • CloudFront의 캐싱은 2티어
  • 요청 순서
    • Edge Location
    • Regional Edge Cache
    • Origin

CloudFront의 Cache Key

  • 요청에 따라 어떤 캐시 내용을 보여줄지를 결정하는 정보의 조합
    • 각 오브젝트는 고유의 Cache Key 단위로 캐시됨
  • Cache Hit : 뷰어가 특정 Cahce Key로 오브젝트를 요청하였을 때, Edge Location에서 해당 Cache 오브젝트를 가지고 있어 원본에 요청 과정 없이 제공할 수 있는 상황
    • Origin의 부하 경감 가능
    • 더 빠르게 컨텐츠 제공 가능
    • 즉 CDN이 Cache Hit이 많을수록 더 좋은 퍼포먼스 제공 가능
  • 주요 Cache Key 구성 요소
    • 경로(기본), query string, HTTP Header, Cookie

HTTP Header based Cache

  • Cache Key 중 HTTP Header를 활용
  • 활용 사례
    • 언어별 캐싱
    • Device Type 별로 캐싱
      • CloudFront에서 별도로 User-Agent를 기반으로 전용 헤더 생성
    • 지역별 캐싱
      • CloudFront에서 전용 헤더 생성 CloudFront-Viewer-Country
  • 헤더 명은 대소문자를 구분하지 않지만 값은 구분
  • Cookie를 기반으로 컨텐츠 내용을 캐시
    • Cookie를 활용하지 않는 HTTP 서버 혹은 S3에서 사용할 경우 퍼포먼스만 저하될 수 있음

Cache 만료

  • 캐시된 Object는 일정 기간(TTL, Time To Live) 이후 만료
    • 그 다음 요청이 올 경우 CloudFront는 Origin에 Object 갱신 여부를 확인
    • Origin이 304 Not Modified를 줄 경우 갱신 필요 없음
    • 200 ok와 파일을 줄 경우, 갱신

Cache TTL

  • TTL(Time To LIve) : Cache Object를 얼마나 오래 보관할지에 관한 설정
    • 기본 24시간
    • 모든 CloudFront의 Object에 적용
    • 파일 단위에서는 Origin에서 Cache-Control 헤더 혹은 Expires 헤더를 포함해서 조절 가능
  • TTL의 종류
    • Minimum TTL : 최소 TTL, 즉 파일 단위 컨트롤에서 줄 수 있는 최소 TTL
    • Maximum TTL : 최대 TTL, 즉 파일 단위 컨트롤에서 줄 수 있는 최대 TTL
    • Default TTL : 별도의 설정이 없을 경우 부여되는 기본 TTL

Cache TTL 컨트롤

  • 파일 단위에서는 Origin에서 Cache-Control 헤더 혹은 Expires 헤더를 포함해서 조절 가능
  • Cache-Control : 얼마나 오래 Object를 Cache 하는지 기간을 설정
    • max-age : CloudFront와 브라우저 둘 다 영향
    • s-maxage : CloudFront만 영향
    • no-cache, no-store : 캐싱하지 않음(단, Min TTL이 0 이상일 경우 Min TTL로 최저 설정)

Cache Policy

  • 캐싱과 관련된 내용을 정책으로 정의하여 CloudFront에 적용 가능
  • 주요 설정
    • 어떤 키 (HTTP Header, 쿠키, querystring 등)로 컨텐츠를 캐시하는지
    • 얼마나 오래 캐시하는지 (TTL)
    • 컨텐츠를 압축 저장 관련 설정
  • 두 가지 종류
    • Managed : AWS에서 직접 생성한 Policy로 다양한 상황을 미리 준비된 Policy
    • Custom : 직접 설정

Cache Behavior

  • CloudFront의 요청이 어떻게 처리되는지 정의하는 다양한 설정의 모음
  • 경로 패턴 단위로 Behavior를 구성
    • ex) files/, files/, *.png
    • 경로 패턴 목록 중 처음으로 매칭 된 패턴의 동작을 적용
    • 신규 생성시 *로 고정
  • 주요 구성 내용
    • Origin
    • 뷰어 설정
    • Cahce Policy, Viewer Response policy, Lambda@EDGE 연결

Viewwe 설정

  • Viewer 프로토콜
    • CloudFront에 접근하는 프로토콜
    • HTTP and HTTPS
    • Redirect HTTP to HTTPS
    • HTTPS only
  • HTTP Method
    • GET, HEAD, OPTIONS, PUT, POST, PATCH, DELETE
  • 뷰여 액세스를 제한 : Presigned URL / Presigned Cookie로만 접근 가능하도록 할지 여부

Policy 설정

  • Cache Policy
    • 어떤 키 (HTTP Header, 쿠키, querystring 등)로 컨텐츠를 캐시하는지
    • 얼마나 오래 캐시하는지 (TTL)
    • 컨텐츠를 압축 저장 관련 설정
  • Origin Request Policy
    • Origin에 컨텐츠를 요청할 때 어떤 내용을 전달할 것인지(HTTP Header, querystring 등)
    • Cache Key로 사용할지 여부와 독립적으로 설정 가능
  • Response Headers Policy
    • 응답 과정에서 어떤 HTTP Header를 제거하거나 더할지 설정

CloudFront의 파일 관리

  • CloudFront에서 파일은 크게 두 가지로 관리
    • 싱글 파일 : 파일명을 유지한 체로 캐시 만료 처리, 업데이트 등을 처리
      • 별도로 클라이언트 업데이트 필요 없음
      • 캐시 만료 전 제공 파일을 업데이트 하려면 Invalidation 필요
    • 버저닝 : 파일 이름에 다양한 방법으로 버전을 두어서 관리
      • 별도로 Invalidation 필요 없음
      • 파일 업데이트 시 클라이언트 업데이트 필요

Invalidation

  • 캐시 만료 전 파일을 갱신
  • 버저닝이 아닌 형태로 파일을 제공할 경우 캐시 만료 전 새 파일을 제공하고 싶다면 Invalidation 필요
  • 경로 기반
  • 한 번에 최대 3000 파일까지 Invalidate 가능
  • 한달에 1000 path Invalidations은 무료

컨텐츠 접근 제한

  • CloudFront에서 컨텐츠에 대한 접근 제한
    • CloudFront에 접근하는 주체 별로 다르게 컨텐츠의 접근 제한이 필요할 경우
    • CloudFront Origin에 대한 직접 접근 제한
      • CloudFront를 거치지 않고 직접 Origin에 접근을 막고 싶은 경우
  • 두 가지 방법
    • Signed URL : 권한 정보가 담긴 임시 URL을 발급하여 뷰어에게 전달하여 컨텐츠를 다운로드 할 수 있도록 허용
      • URL 당 하나의 파일만 사용 가능
    • Signed Cookie : 뷰어가 권한을 행사해 다운로드 할 수 있도록 컨텐츠 접근 권한을 가진 Cookie를 발급해 뷰어에 전달
      • 다수의 파일에 사용 가능
    • 만료 기간 설정 가능

Signer

  • Signed URL/Cookie를 만들 권한을 가진 주체
  • 두 가지 종류
    • Trusted Key Group (추천) : CloudFront에 Public/Private Key Pair 중 Public Key를 등록하고, 가지고 있는 Private key로 Presigned URL/Cookie를 생성하는 방식
    • AWS Account (비추천) : Root 사용자(IAM 사용자 불가능)로 계정의 CloudFront Key Pair를 다운받아 활용
      • 비추천 : AWS Root 사용자를 활용해야 하고, API를 사용할 수 없고, IAM을 통한 권한제어 불가능
  • CloudFront URL을 만들 때 Distribution 단위로 등록된 Key Group을 활용
    • Key Group : Private/Public Key로 이루어진 키 쌍의 집합으로 CloudFront에 업로드하는 하나 이상의 Public Key로 구성

Presigned 정책

  • Presigned URL/Cookie를 만들 때 URL/Cookie 권한을 설정하기 위한 정책
  • 두 가지 종류
    • Canned(미리 준비된) Policy : 간단한 버전, 만료시간만 설정 가능
      • 단 URL이 짧아짐
    • Custom Policy : 모든 제약사항 설정 가능
  • 각 정책으로 Presigned URL/Cookie의 동작 범위(만료 시간, IP 제한 등)설정 가능
설명Canned PolicyCustom Policy
정책 재사용NoYes
사용 가능 시점 적용NoYes(optional)
만료 시점 적용YesYes
IP Range 제한NoYes(optional)

Origin Access Control (OAC)

  • OAI와 함께 CloudFront를 거치지 않은 S3에 접근을 방지하기 위한 기능
    • Origin Access Identity(OAI) : 예전 방식, OAC를 권장
  • OAC는 일종의 Identity : IAM 사용자 혹은 IAM 역할과 비슷한 Identity
    • 즉 S3에서 해당 OAC의 접근을 허용하고 CloudFront에서 OAC를 활용해서 S3와 소통
    • S3에서 기본적으로 모든 접근을 차단하고 OAC의 접근만 허용
  • OAC는 Lambda Function URL에도 사용 가능

Origin Access Control(OAC)의 세가지 Sign 방법

  • CloudFront가 S3와 소통하기 위한 요청에 Sign 방법을 정의 가능
  • 3가지 종류
    • Sgin Requests : CloudFront Iam Principle이 S3에 요청할 때 SigV4로 Sign
      • 즉 요청에 자격증명을 활용해 필요한 정보로 → Authorization Header를 구성 → S3에서 해당 내용을 검증해서 자격이 있는 요청인지 확인 → 요청 처리 or 거부
      • 클라이언트가 Sign한 헤더가 있다면 덮어씌움
    • Do not override authorization header : 클라이언트 Header가 있다면 사용, 없으면 새로 Sign
    • Do not sign requests : Authorization Header를 사용하지 않음 → OAC를 사용하지 않겠다와 비슷함
      • 언제 쓰냐? → 클라이언트가 항상 Sign을 통해 요청하거나, 컨텐츠가 퍼블릭인 경우

Custom Origin 보호

  • 방법 1 : Custom Header 활용
    • CloudFront에서 Header 생성 → Origin에서 해당 Header가 없으면 거부
  • 방법 2 : Origin에서 CloudFront IP를 제외한 모든 트래픽을 차단

뷰어 액세스 제한

  • CloudFront에 허용된 방법으로만 접근 가능하도록 설정하는 방법
  • 두 가지 접근 방법
    • CloudFront 서명된 URL : 파일 하나에만 접근 가능
    • CloudFront 서명된 쿠키 : 다수의 파일에 접근 가능
  • 서명 방법
    • Trusted Key : 등록된 퍼블릭에 대응하는 프라이빗 키로 Sign(권장하는 방법)
    • Trusted Signer : 등록된 AWS 계정의 권한으로 Sign(Root 계정 필요)
  • 유효 기간 설정 가능

지리적 배포 제한(Geo Restriction)

  • 두 가지 접근 방법
    • CloudFront 지리 배포 제한
      • Whitelist 혹은 Blacklist → 나라별 기준
      • 모든 배포에 제한 사항 포함
        • 즉 일부만 제한 걸기 불가능
      • IP 주소의 정확도는 99.8%
    • third Party 지리적 위치 서비스 사용
      • 커스터마이징 가능 → 브라우저 별, 쿠키 별 등등
      • Signed URL 기반

Field-Level Encryption

  • CloudFront를 활용하여 실제 데이터를 처리하는 주체까지 데이터를 암호화해서 전달할 수 있는 방법
    • HTTPS 통신과는 별도의 개념
  • Edgd Location에서 받은 데이터 중 특정 데이터를 주어진 퍼블릭 Key로 암호화
  • 이후 데이터를 처리하는 측에서 프라이빗 Key로 복호화하여 사용

본 내용은 아래 강의를 보고 작성하였습니다 (감사합니다..)
https://youtu.be/-r_S_kweXlk?si=v2DLd_0p9qj1vEHn

profile
이유성
Cloud Engineer
이전 포스트

Docker compose에 관하여..

다음 포스트

CDN? CloudFront? (2)

0개의 댓글