AWS Section 15. CloudFront

📌 CloudFront

 

💡 CloudFront 개요 (Introduction)

• CloudFront는 콘텐츠 전송 네트워크 (CDN)로, 사용자의 콘텐츠를 전 세계에 있는 엣지 로케이션(POP)에 캐시 처리하여 성능을 높인다.
• 콘텐츠가 엣지에서 캐시됨으로써 읽기 성능을 개선하고, 사용자 경험을 향상시킨다.
• 전 세계에 216개의 엣지 로케이션이 있으며, 이는 AWS의 DDoS보호와 통합되어 있다.

전 세계 엣지 로케이션이 표시됨. 각 로케이션에서 콘텐츠가 캐시되어 사용자 요청에 응답하는 구조

 

💡 CloudFront 오리진 (Origins)

• CloudFront의 오리진은 콘텐츠가 실제로 저장되어 있는 S3 버킷 또는 커스텀 오리진 (HTTP) 일 수 있다.
  • 커스텀 오리진으로는 Application Load Balancer, EC2 인스턴스, 또는 HTTP 백엔드를 설정할 수 있다.
• S3 버킷은 파일을 분산하고 캐시하는 데 사용되며, 오리진 액세스 제어 (OAC)를 통해 보안을 강화할 수 있다.

S3 버킷과 HTTP 백엔드가 오리진으로 작동하는 구조를 보여주는 다이어그램을 통해, 콘텐츠가 어떻게 캐시되고 분산되는지 보여줌

 

🦾 CloudFront 작동 원리 (How it works)

• CloudFront는 엣지 로케이션을 통해 클라이언트 요청을 처리하며, 캐시된 콘텐츠를 제공하여 성능을 향상시킨다.
• 클라이언트가 콘텐츠를 요청하면 엣지 로케이션에서 먼저 캐시를 확인한 후, 없으면 오리진에서 가져온다.

클라이언트가 CloudFront 엣지 로케이션에 연결하는 과정

 

🆚 CloudFront와 S3 리전 간 복제 비교

• CloudFront는 전 세계 엣지 네트워크를 통해 콘텐츠를 전송하며, 캐시된 콘텐츠를 TTL (Time to Live) 동안 유지한다.
• S3 리전 간 복제는 특정 리전 간에만 콘텐츠를 복제하며, 실시간으로 업데이트됩니다. 주로 동적 콘텐츠를 빠르게 제공하는 데 적합하다.

 

🔒 CloudFront 보안 및 DDoS 보호

• CloudFront는 전 세계에 걸쳐 분산된 엣지 로케이션을 통해 DDoS 공격에 대한 방어를 제공하며, AWS Shield와 AWS WAF(웹 애플리케이션 방화벽)와 통합되어 있다.
• 사용자는 CloudFront를 통해 보안 및 성능을 동시에 유지할 수 있다.

 

📌 CloudFront 캐싱 및 캐싱 정책, 무효화

 

💡 CloudFront Caching 개요

• 캐시 저장 위치: 캐시는 CloudFront의 엣지 로케이션에 저장된다.
• 캐시 키 : CloudFront 캐시 키는 캐시 내 객체를 식별하는 고유한 값
  • 기본적으로, 캐시 키는 호스트 이름과 URL의 리소스 부분으로 구성된다.
• 캐시 히트 : 엣지 로케이션에 캐시된 콘텐츠를 바로 제공할 수 있는 경우
  • 캐시 히트(Caching Hit) 극대화: 오리진 서버에 대한 요청을 줄이기 위해서는 캐시 적중률을 극대화하는 것이 중요하다.
    • CloudFront 캐시 정책: 캐시 히트를 높이려면, 정책을 통해 캐시 키를 확장.
• 캐시 키 확장: 특정 사용자, 기기, 언어, 위치 등에 따라 콘텐츠가 달라지는 경우에는 HTTP 헤더, 쿠키, 쿼리 문자열을 포함하여 캐시 키를 확장할 수 있다.
• 캐시 무효화(Cache Invalidation): 객체가 TTL(만료 시간) 전에 변경되거나 만료되면 CreateInvalidation API를 사용해 캐시의 일부를 무효화할 수 있다.

클라이언트가 요청을 보내면, 캐시 키 (요청 URL 기반으로 생성된 값)를 이용해 캐시된 콘텐츠를 확인 (캐시 히트 / 캐시 미스)

 

💡 CloudFront Cache Policy

• 캐시 정책(Cache Policy): 캐시는 HTTP 헤더, 쿠키, 쿼리 문자열에 따라 설정될 수 있다.
  • 헤더(Headers): 캐시 키에 포함할 헤더를 정의할 수 있습니다. 선택지는 None, Whitelist 다.
  • 쿠키(Cookies): 캐시 키에 포함할 쿠키를 선택할 수 있습니다. None, Whitelist, Include All-Except, All의 선택지가 있다.
  • 쿼리 문자열(Query Strings): 캐시 키에 포함할 쿼리 문자열을 설정할 수 있다.
• TTL 제어: TTL(Time to Live)을 0초에서 최대 1년까지 설정할 수 있으며, 오리진 서버의 Cache-Control 또는 Expires 헤더에 의해 설정될 수 있다.
• 정책 설정: 사용자는 사전 정의된 관리형 정책을 사용할 수 있으며, 필요에 따라 사용자 정의 캐시 정책을 생성할 수 있다.

 

💡 CloudFront Caching - Cache Policy HTTP Headers

 

HTTP 헤더 기반 캐싱

• None: 기본적으로 어떤 헤더도 캐시 키에 포함되지 않는다. 헤더는 전달되지 않으며, 가장 빠른 캐싱 성능을 제공한다.
• Whitelist: 특정한 헤더만 선택적으로 캐시 키에 포함할 수 있다. 이를 통해 필요한 정보만 캐시하고 오리진에 전달할 수 있다.

요청을 보내면서 HTTP 헤더 정보(User-Agent, Authorization, Language 등을 포함함

 

💡 CloudFront Cache Policy - Query Strings

 

쿼리 문자열 기반 캐싱

• None: 쿼리 문자열을 캐시 키에 포함하지 않으며 오리진에도 전달되지 않는다.
• Whitelist: 특정 쿼리 문자열만 캐시 키에 포함되고 오리진에 전달된다.
• Include All-Except: 제외할 쿼리 문자열을 지정하고, 나머지는 모두 포함시킨다.
• All: 모든 쿼리 문자열을 캐시 키에 포함시켜 오리진에 전달하지만, 성능이 저하될 수 있다.

 

 

💡 CloudFront Policies - Origin Request Policy

오리진 요청 정책

• 캐시 키에는 포함되지 않지만, 오리진 요청에 추가로 전달하고자 하는 값을 지정할 수 있다.
• HTTP 헤더, 쿠키, 쿼리 문자열을 선택하여 포함할 수 있으며, API 키 또는 보안 헤더와 같은 추가 헤더를 지정할 수도 있다.
• 이를 통해 콘텐츠가 캐시에 저장되지만, 추가적인 정보는 오리진에만 전달되어 보안을 강화할 수 있다.

 

🆚 Cache Policy vs. Origin Request Policy

• 캐시 정책(Cache Policy)은 캐시에 포함될 항목을 정의하며, 이를 통해 적중률을 높인다.
• 오리진 요청 정책(Origin Request Policy)은 캐시에는 포함되지 않지만, 오리진에 요청할 때 필요한 추가 정보를 포함한다. 이를 통해 캐시 효율성을 높이면서도 오리진에서 정확한 데이터를 받을 수 있다.
• Cache Policy는 캐시 키를 구성하는 반면, Origin Request Policy는 오리진 요청에 포함되는 정보를 관리합니다. 둘은 다른 목적을 가지고 있으며, 적절히 사용해야 합니다.

캐시 정책과 오리진 요청 정책의 차이점

• 캐시 키에 어떤 항목이 포함되고, 오리진 요청에 어떤 추가 항목이 포함되는지를 보여준다.

 

💡 캐시 무효화

• 백엔드 오리진에서 파일을 업데이트할 경우, TTL이 만료되기 전에 업데이트된 콘텐츠를 제공하기 위해 Cache Invalidation을 사용한다.
• 경로를 지정하여 특정 파일 또는 전체 파일을 무효화할 수 있다.

 

클라이언트가 파일 요청 > 캐시 무효화 요청 (Invalidate) >> CloudFront는 이 무효화 요청을 받아들이고, 각 엣지 로케이션에 해당 파일들의 캐시를 무효화 >> 각 엣지 로케이션에서 파일이 캐시에서 제거됨 >> 이후 클라이언트가 다시 동일한 파일을 요청하면, CloudFront는 엣지 로케이션에 캐시가 없기 때문에 S3 버킷(오리진)에서 새로 업데이트된 파일을 가져오게 됩니다.

 

📌 CloudFront - 캐시 동작

 

🤖 CloudFront – Cache Behaviors

1. 캐시 동작
   • CloudFront의 캐시 동작(Cache Behavior)은 서로 다른 URL 패턴에 대해 다른 설정을 적용할 수 있다.
   • 예시: 이미지 파일(images/*.jpg)에는 S3 버킷 오리진을, /api/* 경로에는 애플리케이션 로드 밸런서를 오리진으로 설정할 수 있다.
   • 또한, 경로 패턴이나 콘텐츠 유형에 따라 오리진 또는 오리진 그룹으로 라우팅을 설정할 수 있다.
2. 라우팅 옵션
   • /images/*: 이미지 파일은 S3 버킷 오리진으로 보내기.
   • /api/*: API 요청은 애플리케이션 로드 밸런서 오리진으로 보내기.
   • /*: 기본적으로 모든 다른 요청은 S3 버킷 오리진으로 보내기.
3. 기본 캐시 동작
   • 추가적인 캐시 동작이 추가되더라도, 기본 캐시 동작인 /*은 항상 마지막에 처리된다.

서로 다른 경로 패턴에 따른 다양한 오리진으로의 라우팅을 보여줌

 

🔐 CloudFront – Cache Behaviors – Sign In Page

1. 로그인 캐시 동작
   • /login 경로는 EC2 인스턴스를 오리진으로 설정하고, 로그인된 사용자에게 서명된 쿠키(Signed Cookies)를 제공하여 다른 리소스에 액세스할 수 있게 한다.
2. 서명된 쿠키의 역할
   • 사용자는 로그인 후 쿠키를 통해 인증된 상태로 CloudFront 배포의 다른 리소스에 액세스할 수 있다.

사용자가 로그인 후 서명된 쿠키를 받는 과정과, 쿠키를 통해 S3 버킷이나 EC2 인스턴스에 접근하는 흐름

 

CloudFront – Maximize Cache Hits by Separating Static and Dynamic Distributions

캐시 적중률을 높이기 위한 분리

• 정적 콘텐츠는 캐시 처리하고, 동적 콘텐츠는 헤더와 쿠키 기반으로 처리해 캐시 적중률을 최대화할 수 있다.

정적 요청과 동적 요청이 서로 다른 경로로 처리되고, 각각의 오리진으로 보내지는 과정

 

📌 CloudFront - 오리진으로서의 ALB

• CloudFront와 EC2 인스턴스 연결
  • CloudFront는 EC2 인스턴스를 오리진으로 사용할 수 있다.
  • 그러나 CloudFront는 퍼블릭 네트워크에서만 EC2 인스턴스에 접근할 수 있기 때문에, EC2 인스턴스는 반드시 퍼블릭이어야 한다.
  • 이를 위해서는 CloudFront 엣지 로케이션의 모든 퍼블릭 IP 목록을 EC2의 보안 그룹에 허용하여 액세스할 수 있도록 설정해야 한다.
• CloudFront와 ALB 연결
  • CloudFront는 또한 애플리케이션 로드 밸런서 (ALB)를 오리진으로 사용할 수 있다.
  • ALB는 퍼블릭이어야 하지만, 이 경우 EC2 인스턴스는 프라이빗으로 유지할 수 있다.
  • ALB와 EC2 인스턴스 간에는 VPC 프라이빗 연결을 통해 연결이 가능하며, EC2 인스턴스의 보안 그룹에서 ALB의 보안 그룹을 허용하면 된다.

CloudFront 엣지 로케이션이 퍼블릭 IP로 EC2 인스턴스 또는 ALB에 접근하는 과정

 

📌 CloudFront - 지리적 제한

• CloudFront Geo Restriction을 통해 사용자의 콘텐츠 접근을 국가별로 제한할 수 있다.
  • Allowlist(허용 목록): 지정된 국가 목록에 있는 사용자만 콘텐츠에 접근할 수 있다.
  • Blocklist(차단 목록): 지정된 국가 목록에 있는 사용자는 콘텐츠 접근이 차단된다.
• 국가 결정은 3rd party Geo-IP 데이터베이스를 사용하여, 사용자의 IP 주소를 해당 국가와 매핑하는 방식으로 이루어진다.
• 주요 활용 사례로는 저작권법을 준수하기 위해 특정 국가에서의 콘텐츠 접근을 제어하는 것이다.

 

📌 CloudFront 서명 URL/쿠키

 

CloudFront 서명된 URL 및 서명된 쿠키 개요

• CloudFront 배포를 비공개로 설정하여 전 세계 프리미엄 사용자에게 유료 공유 콘텐츠 액세스를 제공.
• 서명된 URL 또는 서명된 쿠키를 이용해 특정 사용자에게만 콘텐츠 접근 권한 부여.
• 정책을 연결하여 URL이나 쿠키의 만료 시점, 액세스 가능한 IP 범위, 신뢰할 수 있는 서명자 지정.
• 서명된 URL과 서명된 쿠키의 유효 기간 설정 예시:
  • 영화나 음악: 몇 분
  • 개인 콘텐츠: 몇 년

 

CloudFront 서명된 URL 작동 방식

클라이언트가 서명된 URL을 통해 CloudFront 배포에 접근하고, CloudFront가 오리진인 EC2 인스턴스와 통신하는 과정

• CloudFront 배포에 여러 엣지 로케이션 존재.
• Amazon S3 버킷 액세스 정책에 오리진 액세스 제어(OAC) 적용.
• OAC를 통해 S3 버킷의 객체에 오직 CloudFront만 접근 가능.
• 사용자 인증 및 권한 부여 후 서명된 URL 생성.
• 클라이언트는 서명된 URL을 통해 CloudFront에서 객체 접근.

 

서명된 URL vs 서명된 쿠키

서명된 URL

• 개별 파일에 대한 접근 제공.
• 파일마다 별도의 URL 필요.
• 예: 100개의 파일 → 100개의 URL

서명된 쿠키

• 여러 파일에 대한 접근 제공.
• 하나의 쿠키로 여러 파일 접근 가능.
• 효율적이고 재사용 가능.

 

서명된 URL vs S3 미리 서명된 URL

 

CloudFront 서명된 URL

• 오리진에 상관없이 경로의 접근 허용.
• 오리진이 S3이든 다른 HTTP 백엔드이든 관계없이 작동.
• 계정 전체에 적용되는 키 페어로 루트만 관리 가능.
• IP, 경로, 날짜, 만료일 기준 필터링 가능.
• CloudFront의 모든 캐시 기능 활용 가능.

 

S3 미리 서명된 URL

• S3의 파일에 직접 접근 허용.
• 서명된 URL 생성자의 권한 상속.
• URL 수명 제한적.
• CloudFront와 연동되지 않음.

 

CloudFront 서명된 URL

• 서명자의 종류
  • 신뢰할 수 있는 키 그룹(권장):
    • API를 활용하여 키 생성 및 순환 가능.
    • IAM을 통해 API 보안 관리.
    • CloudFront에서 공용 키를 검증하는데 사용.
  • AWS 계정에 있는 CloudFront 키 페어
    • 루트 계정을 사용하여 키 관리.
    • AWS 콘솔에서 관리 필요 (권장하지 않음).
    • 자동화 X
• 키 그룹 생성:
  • CloudFront 분산 배포에서 하나 이상의 신뢰할 수 있는 키 그룹 생성 가능.
• 공용 키와 개인 키의 생성:
  • 개인 키: 애플리케이션 (예: EC2)에서 서명된 URL을 생성하는 데 사용.
  • 공용 키: CloudFront가 서명된 URL을 검증하는 데 사용.

 

📌 CloudFront 고급 개념

 

CloudFront 가격 및 가격 등급

• CloudFront의 데이터 전송 비용은 엣지 로케이션의 위치에 따라 달라진다.
• 엣지 로케이션은 전 세계에 걸쳐 퍼져 있으며, 각 로케이션의 데이터 전송 비용이 다르다.

예: 미국의 엣지 로케이션에서는 10TB의 데이터 전송 비용이 1GB당 0.085달러인 반면, 인도의 경우 0.17달러로 더 비쌈

데이터를 많이 전송할수록 요금이 낮아지는 구조를 가지고 있으며, 각 지역마다 요금이 다르기 때문에, 전송 데이터를 최적화하는 것이 중요하다.

 

• 가격 등급(Price Class)을 사용해 비용을 최적화할 수 있다.
  • Price Class는 세 가지로 나뉜다.

• Price Class All: 모든 엣지 로케이션을 포함하여 최상의 성능을 제공하지만, 비용이 가장 비싸다.
• Price Class 200: 가장 비싼 지역을 제외한 대부분의 엣지 로케이션을 포함한다.
• Price Class 100: 비용이 가장 저렴한 엣지 로케이션만 사용하여 비용을 절감할 수 있다.

 

Price Class 100, 200, All에 포함된 지역을 보여줌

 

💡 다중 오리진(Multiple Origins)

경로에 따라 다른 오리진으로 트래픽을 라우팅하는 과정 (/api/* 경로는 ALB로, /* 경로는 S3 버킷으로 라우팅)

• CloudFront는 다중 오리진을 지원하여, 경로 패턴에 따라 서로 다른 오리진으로 트래픽을 라우팅할 수 있다. 이를 통해 콘텐츠 유형별로 트래픽을 분리하고 성능을 최적화할 수 있다.
• 예를 들어, /images/* 경로는 S3 버킷에서 이미지를 제공하고, /api/* 경로는 애플리케이션 로드 밸런서(ALB)를 통해 API 응답을 처리하도록 설정할 수 있다.
• 이를 통해 각 콘텐츠 유형별로 적절한 오리진을 선택하여, 성능과 비용을 최적화할 수 있다.

 

👥 오리진 그룹 (Origin Groups)

주 오리진에서 장애가 발생했을 때 보조 오리진으로 전환되는 과정

• CloudFront는 오리진 그룹을 사용하여 고가용성을 보장할 수 있다. 오리진 그룹은 하나의 주 오리진(Primary Origin)과 하나의 보조 오리진(Secondary Origin)으로 구성된다.
• 주 오리진에서 장애가 발생하면, CloudFront가 자동으로 보조 오리진으로 트래픽을 전환하여 서비스 중단을 최소화할 수 있다.
• 이 기능은 특히 재해 복구나 지역 간 가용성을 보장하는 데 유용하다.
• 예를 들어, 두 개의 S3 버킷을 오리진 그룹으로 설정하고, 주 오리진에 문제가 발생했을 때 자동으로 보조 오리진에서 데이터를 제공할 수 있다.

 

🔒 필드 수준 암호화 (Field-Level Encryption)

공용 키로 데이터를 암호화하고 개인 키로 이를 해독하는 과정 / 클라이언트에서 데이터를 제출할 때, 필드가 암호화되어 엣지 로케이션과 CloudFront를 통해 안전하게 전송되는 과정

• CloudFront는 필드 수준 암호화를 통해 민감한 데이터를 보호할 수 있다. 이는 비대칭 암호화를 사용하여 데이터 전송 중 특정 필드를 암호화하고, 오직 개인 키를 소유한 수신자만 해당 데이터를 해독할 수 있다.
• 이 기능은 HTTPS로 보호된 연결 위에 추가적인 보안 계층을 제공하여, 민감한 데이터를 엣지에서 암호화하여 안전하게 전송한다.
• 예를 들어, 클라이언트가 신용카드 정보를 제출할 때 해당 필드만 암호화하고, 서버에 도착하기 전까지 중간에 있는 모든 시스템은 이 데이터를 볼 수 없다.

 

📌 CloudFront - 실시간 로그

 

💡 CloudFront 실시간 로그 소개

• CloudFront 실시간 로그 기능을 통해 사용자 요청을 Kinesis 데이터 스트림에 전송하여 실시간으로 기록하고, 이를 분석해 콘텐츠 전송 성능을 최적화할 수 있다.
• 실시간 로그는 콘텐츠 전송 지연을 최소화하고 빠른 의사결정을 돕는 도구로 사용되며, 실시간 분석이 필요한 서비스에 매우 유용하다.
• 예를 들어, 사용자가 이미지 파일을 요청했을 때, 이 요청이 언제, 어디에서 발생했는지 기록되며, 성능 문제 발생 시 빠르게 확인하고 조치를 취할 수 있다.

 

💡 실시간 로그와 Kinesis 데이터 스트림

• 이때 Kinesis 데이터 스트림은 실시간으로 로그를 처리할 수 있는 인프라로, 요청이 발생한 시점에서 즉시 데이터를 수집하고 저장한다.
• 람다(Lambda) 함수를 통해 이 데이터를 실시간으로 분석하거나 추가 조치를 취할 수 있다. 예를 들어, 특정 요청이 실패했을 경우, 이를 즉시 확인하여 빠르게 복구할 수 있는 구조다.
• Use case: 실시간 이벤트 기반 시스템에서 API 호출의 성공 또는 실패 여부를 즉시 파악하여 대처하는 상황.

CloudFront에서 Kinesis 데이터 스트림으로 로그가 전송되고, Lambda가 이를 실시간으로 처리하는 과정

 

 

📝 Near Real-Time Processing

• 실시간 처리가 불필요하거나 대량의 데이터를 다룰 경우, Kinesis Data Firehose를 통해 배치 처리 방식으로 로그를 저장할 수 있다.
• 이 경우, 데이터를 실시간으로 처리하기보다는 일정 주기로 모아서 Amazon S3, OpenSearch 등의 스토리지나 분석 서비스로 전송하게 된다.
• 배치 처리 방식은 대규모 트래픽을 효율적으로 처리하고, 비용을 절감하는 데 적합하다.
• 예를 들어, 웹사이트에 대량의 이미지를 배포하고 분석할 경우, 실시간 처리보다는 일정 주기로 데이터를 수집하여 분석하는 것이 더 적합할 수 있다.

Kinesis Data Firehose로 로그가 배치 처리되고 Amazon S3로 저장되는 과정

 

⏳샘플링 비율과 경로 필터링

• 샘플링 비율을 설정하여 모든 요청을 로그로 기록하지 않고, 특정 비율만 선택하여 처리할 수 있다.
• 예를 들어, 100%의 요청을 모두 기록하는 것이 과도한 트래픽과 비용을 초래할 수 있는 경우, 샘플링을 통해 일부 요청만 처리하여 효율적으로 운영할 수 있다.
• 또한, 필드 및 캐시 동작 설정을 통해 특정 경로에 대한 요청만 로그로 기록할 수 있습니다. 예를 들어, /images/* 경로에 대한 요청만 기록하도록 설정하면, 이미지 요청에 대한 로그만 집중적으로 분석할 수 있다.
• 이를 통해 비용을 절감하고 효율적인 로그 관리가 가능하다.

샘플링 비율과 경로 필터링이 적용되는 과정