CloudFront란

• 콘텐츠 전송 네트워크, CDN(Content Delivery Network)
• 여러 엣지 로케이션에서 웹사이트의 콘텐츠를 캐시 처리해 읽기 성능을 높임
• 전 세계에서 콘텐츠가 캐싱 처리되기 때문이 지연시간이 줄고 사용자 경험히 향상됨
• 전 세계 216개의 접속 지점(POP)이 있고 이는 aws의 엣지 로케이션에 해당함
• DDoS 공격으로부터 보호하기 위해 Shield와 Web Application Firewall을 사용함

Origin

• S3 버킷
  • CloudFront를 사용해 엣지에 파일을 분산하고 캐시 처리하는데 사용됨
  • CloudFront만 S3 버킷에 엑세스하도록 하기 위해 오리진 엑세스 제어(OAC, Origin Access Control)를 사용함
  • 기존의 오리진 엑세스 ID(OAI)를 대체함
  • CloudFront를 이용해 데이터를 S3 버킷에 전송할 수 있음(ingress)
• 사용자 지정 오리진(HTTP)
  • ALB
  • EC2 인스턴스
  • S3 웹사이트(버킷을 static S3 웹사이트로 설정해야 함)
  • 그 외 어떤 HTTP 백엔드

작동방식

1. 엣지 로케이션이 전 세계에 있고 오리진에 연결됨(S3 or HTTP)
2. 클라이언트가 엣지 로케이션에 연결에 HTTP 요청을 보내면 엣지 로케이션에서는 캐시에 콘텐츠가 먼저 있는지 확인
3. 캐시에 없으면 오리진으로 가서 요청 결과를 확보하여 로컬 캐시에 캐시 처리
4. 다른 클라이언트가 동일한 엣지 로케이션에 동일한 콘텐츠를 요청하면 엣지 로케이션에서 오리진에 연결할 필요가 없음

S3가 오리진인 클라우드

1. 특정 리전에 오리진인 S3 버킷이 있고 전 세계에 엣지 로케이션이 있음
2. 특정 리전에 있는 엣지 로케이션에 사용자가 엑세스하면 이 엣지 로케이션을 통해 바로 콘텐츠를 이용할 수 있음
3. 단, 엣지 로케이션은 프라이빗 네트워크를 통해 S3 오리진에서 콘텐츠를 가져와야 함
4. S3 버킷은 OAC를 사용하고 S3 버킷 정책을 수정해 보안 처리함
5. 다른 리전에도 콘텐츠를 제공하기 위해 엣지 로케이션과 S3 버킷 사이에 프라이빗 네트워크 연결이 사용됨

=> CloudFront와 엣지 로케이션을 사용하면 한 리전의 S3 버킷에 있는 콘텐츠가 엣지 로케이션, 즉 접속지점(POP)를 통해 전 세계에 분산됨

CloudFront vs S3 Cross Region Replication(리전 간 복제)

CloudFront

• 글로벌 엣지 네트워크 사용
• 216개의 POP으로 이루어져 있고, 각 엣지 로케이션에서 파일이 하루 정도 캐시 처리됨
• static 콘텐츠가 있으면 매우 유용하다

S3 Cross Region Replication

• 복제하려는 각 리전을 설정해야 함(전세계 모든 리전 적용 x)
• 파일이 거의 실시간으로 업데이트 됨
• 캐시 처리가 되지 않으며 읽기 전용
• 변경이 자주 되는 동적 콘텐츠를 소수의 리전에 짧은 지연시간 안에 제공해야 할 때 유용

캐싱 및 캐싱 정책

캐싱

• 캐시는 CloudFront 엣지 로케이션 각각에 저장되기 때문에 엣지 로케이션 수만큼 캐시가 생성
• 캐시의 각 객체는 캐시 키로 식별됨
• 오리진으로 보내는 요청을 최소화하고 캐시 적중률을 극대화하는게 좋음
• TTL 기준으로 만료될 때까지 기다릴 일 없이 무효화(CreateInvalidation API)를 이용해 캐시에서 객체를 제거할 수 있음

캐시 키

• 캐시에 있는 각 객체의 고유 식별자
• 기본적으로 호스트 이름 + URL의 리소스 부분으로 구성됨
  • 호스트 : mywebsite.com
  • URL 리소스 : /content/stories/example-story.html
  • 동일한 호스트 이름, 리소스 부분을 사용하는 유사한 요청이 발생하면 캐시가 적중(HIT)됨
• 사용자, 디바이스, 언어, 사용자의 위치 등에 따라 콘텐츠가 달라질 수 있음
• CloudFront 캐시 정책을 사용해 캐시 키에 정보를 추가하여 HTTP 헤더, 쿠키, 쿼리 문자열을 추가할 수 있음

캐시 정책

• HTTP 헤더를 기준으로 캐시 처리
  • None
    • 헤더가 캐시 처리되지 않음
    • 다른 설정이 없는 한 오리진에 전달되지 않음(기본적으로 전달되지 않음(
    • 캐시에 헤더가 포함되지 않아 캐시 성능은 최상
  • Whitelist
    • 특정 헤더만 캐시 키에 추가 가능
    • 특정 헤더만 오리진에 전달됨
• 쿠키를 기준으로 캐시 처리
  • None
  • Whitelist(포함할 항목 선택)
  • Inclute All Except(제외 항목 이외의 모든 것 선택)
  • All(전부 선택)
• 쿼리 스트링을 기준으로 캐시 처리
  • None
    • 쿼리 문자열이 캐시 키에 사용되지 않음
    • 쿼리 문자열이 오리진에 전달되지 않음
  • Whitelist
    • 포함할 쿼리 문자열을 지정
  • Inclute All Except
    • 제외할 항목만 지정해서 나머지는 모두 포함됨
  • All
    • 모든 쿼리 문자열이 캐시 키에 포함되고 전달됨
    • 포함하는 항목이 많아 성능이 가장 안 좋음
• TTL도 제어할 수 있음(0초에서 1년)
  • 헤더를 이용해 설정을 제어함
  • Cache-Control, Expires 헤더가 있음
• 캐시 정책을 만들 수도 있고 aws에 사전 정의된 관리형 정책을 사용할 수 있음
• 캐시 키에 추가한 모든 HTTP 헤더, 쿠키, 쿼리 문자열은 오리진 요청에 자동으로 포함되어 전달됨

오리진(원본) 요청 정책

오리진 요청에는 포함하되 반대로 캐시 키에 포함되지 않았으면 할 때 오리진 요청 정책을 사용

추가 HTTP 헤더, 쿠키, 쿼리 문자열을 포함하여 이러한 항목을 오리진에 전달하지만 캐시 키에는 사용하지 않음

오리진 요청 정책에서 사용자 지정 HTTP 또는 CloudFront HTTP 헤더를 오리진에 추가할 수도 있음(뷰어의 요청이 없어도)
ex) api 키나 보안 키

자채 정책을 생성하거나 사전 관리된 정책을 이용할 수 있음

캐시 무효화

CloudFront에는 백엔드 오리진이 있는데, 백엔드 오리진을 업데이트할 경우 CloudFront 엣지 로케이션에서는 이를 알 수 없음, 캐시의 TTL이 만료된 후에 백엔드 오리진으로부터 업데이트된 콘텐츠를 받음
=> 바람직하지 않음

전체적 또는 부분적인 캐시 리프레시를 적용해 캐시에 있는 모든 TTL을 제거해야 하는데, 이를 위해 CloudFront 무효화(Invalidation)라는 기능을 사용함

파일 경로를 지정하면되며, *를 사용해 모든 파일을 무효화하거나 특정 경로(/images/*)를 무효화할 수 있음

캐시 동작

서로 다른 url 경로 패턴에 각기 다른 오리진과 캐시를 사용하려는 경우
ex) 오리진 웹 서버를 기반으로 모든 jpg 이미지에 하나의 특정 캐시 동작을 사용

콘텐츠 유형 또는 경로 패턴을 기준으로 각기 다른 오리진 또는 오리진 그룹으로 라우팅하는 것
ex) /images/*는 s3로, /api/*는 내 오리진으로, /*(캐본 캐시 동작) 기본 오리진으로,

CloudFront 배포에는 두 가지 캐시 동작이 있음

• /api/*는 애플리케이션 로드 밸런서 오리진으로 보냄
• /*는 기본 캐시 동작으로 S3 버킷 같은 오리진으로 리디렉션할 수 있음

캐시 동작을 추가하면 기본 캐시 동작인 /*는 항상 마지막으로 처리됨
더 구체적으로 일치하는게 있는지 확인한 다음에 없으면 기본 캐시 동작으로 보냄

경로 패턴 - 기본값이 /*임

캐시 적중률을 극대화하는 사례

Amazon S3에 접근하는 정적 요청에 대해서는 캐시 정책에 헤더나 세션을 설정하지 않고, 일치하는 리소스만 찾아서 캐시 적중률을 극대화할 수 있음

반면 로드 밸런서나 EC2를 사용하는 REST 또는 HTTP 서버와 같은 동적 콘텐츠에 대해서는 캐시 정책에 정의한 정확한 헤더와 쿠키를 기준으로 캐시 처리함

오리진으로서의 ALB

CloudFront에는 프리이빗 VPC 연결이 없기 때문에 EC2 인스턴스에 요청을 보낼 때 EC2 인스턴스를 공개로 설정해야 함
CloudFront 엣지 로케이션의 모든 퍼블릭 IP 목록을 허용하는 보안 그룹을 설정해서 보안이 호환되고 작동하는지 확인해야 함

ALB를 이용하는 경우 ALB 역시 공개되어야 하고, 그러면 EC2 인스턴스는 프라이빗 설정이 가능함
ALB와 EC2 인스턴스 간에 프라이빗 VPC 연결이 있기 때문
EC2 인스턴스 보안 그룹에서도 로드 밸런서의 보안 그룹을 허용하면 됨
사용자가 엣지 로케이션에 엑세스하고 엣지 로케이션의 퍼블릭 IP가 ALB의 보안 그룹에서 허용되어 있으면 됨

CloudFront의 지리적 제한

배포판에 접근할 수 있는 사용자를 국가에 따라 제한할 수 있음

• 허용 목록을 설정하여 승인 국가 목록을 정의할 수 있음
• 차단 목록을 설정하여 금지 국가 목록을 설정할 수 있음

국가는 GeoIP 데이터베이스를 사용하여 사용자의 IP를 해당 국가에 매핑하는 방식으로 결정

지리적 제한을 사용하는 사례는 콘텐츠에 대한 접근을 제어하기 위한 저작권법

CloudFront 서명된 URL/쿠키

CloudFront에서 어떤 사용자가 어떤 콘텐츠에 엑세스 권한이 있는지 확인할 때 사용

ex) CloudFront 배포를 비공개로 설정해서 프리미엄 사용자에게만 유료 공유 콘텐츠 엑세스를 제공할 때 서명된 URL/쿠키를 사용함

• CloudFront 서명된 URL/쿠키
  • 만료 시점 지정
  • 데이터에 엑세스 할 수 있는 IP 범위 지정(ex 클라이언트의 대상 IP)
  • 신뢰할 수 있는 서명자 지정(서명된 URL을 생성할 수 있는 aws 계정)

URL의 유효기간은 영화나 음악 같은 콘텐츠를 공유한다면 몇 분으로 짧아도 됨
사용자가 오랫동안 엑세스할 개인 콘텐츠이면 서명된 URL이나 쿠키는 몇 년 동안 유지되도록 지정

서명된 URL은 개별 파일의 엑세스를 제공하므로 파일 하나에 URL이 하나임
서명된 쿠키는 여러 파일에 대한 엑세스를 제공하고 재사용이 가능함, 여러 파일에 하나의 서명된 쿠키

CloudFront 서명된 URL vs S3 Presigned URL

• CloudFront 서명된 URL

  • 오리진과 상관없이 경로의 엑세스를 허용
  • 계정 전체에 적용되는 키 페어이기 때문에 루트만 관리 가능
  • IP, 경로, 날짜를 필터링할 수 있음
  • 캐시 기능 이용 가능

• S3 Presigned URL

  • 미리 서명한 사람의 권한으로 요청을 발행
  • IAM 보안 주체와 IAM 키를 이용해 URL에 서명하면 동일한 권한을 얻음
  • 제한된 수명
  • S3 Presigned URL을 이용해 S3 버킷에 바로 엑세스 가능

CloudFront 서명된 URL 방식, 키 그룹

서명자는 두 부류로 나뉨

1. 신뢰할 수 있는 키 그룹의 사용(권장)

• api를 활용하여 키를 생성하고 순환하게 할 수 있음
• api 보안에 iam을 활용할 수 있음

2. 클라우드 프론트 키 페어를 보유한 계정을 사용

• 루트 계정 자격 증명이 필요 => 권장되지 않음
• 키 페어를 관리할 api가 없어 자동화 불가능

클라우드 프론트 분산에는 하나 혹은 그 이상의 신뢰할 수 있는 키 그룹이 가능함

공용키, 개인키 생성 가능

• 개인키는 애플리케이션에서 EC2 인스턴스가 url에 서명하려는 경우에 사용
• 공용키는 url 서명을 검증하는데에 사용

CloudFront 고급 옵션

요금, 가격 등급

CloudFront 엣지 로케이션이 전 세계에 퍼져있음
엣지 로케이션에 따른 데이터 전송 비용이 다름
엣지 로케이션이 위치한 대륙 또는 지리적 위치에 따라 요금이 달라짐

가격 등급

전 세계에 걸쳐 CloudFront 분산에 사용할 엣지 로케이션의 수를 줄여 가격을 낮출 수 있음

• 가격 등급
  • Price Class All : 모든 지역 제공 - 최상 성능 - 높은 비용
  • Price Class 200 : 가장 비싼 지역을 제외한 대부분의 지역 제공
  • Price Class 100 : 가장 저렴한 지역만을 제공

다중 오리진, 오리진 그룹

콘텐츠의 유형이나 경로에 따라 CloudFront를 거치는 라우트나 경로를 리다이렉팅해 다른 오리진으로 라우팅할 수 있음

/images/*, /api/*, /*

오리진 그룹

고가용성을 증가시키고 한 오리진에서 장애가 발생한 경우 장애 조치가 가능하게 해줌

오리진 그룹 : 하나의 주 오리진과 하나의 보조 오리진으로 구성됨

주 오리진에 장애가 발생하면 CloudFront가 보조 오리진을 사용함

S3와 CloudFront를 함께 사용하면 지역 단위의 고가용성과 재해 복구가 가능함
=> 버킷들 사이의 복제 설정

Field Level 암호화

애플리케이션 스택을 통해 민감한 정보를 보호하는 기능

HTTPS를 사용하는 인플라이트 암호화와 더불어 추가적인 보안을 더해줌

사용자가 민감한 정보를 전송할 때마다 엣지 로케이션이 암호화함
=> 개인 키에 대한 권한을 지닌 사용자만이 이 정보를 해독할 수 있도록 함

비대칭 암호화 사용

• CloudFront로 보내는 post 요청의 경우 암호화를 원하는 필드를 최대 10개까지 지정 가능함(ex 신용카드 정보)
• 이 필드를 해독할 공용 키도 함께 지정

CloudFront 실시간 로그

CloudFront에서 수신한 모든 요청은 Kinesis 데이터 스트림에 실시간으로 전송할 수 있음

콘텐츠 전송 성능을 모니터링 및 분석하고 그에 따라 조치를 취하기 위한 목적

샘플링 비율 - Kinesis 데이터 스트림에 수신할 요청의 비율을 선택할 수 있음(api나 엔드포인트의 트래픽이 높을 경우 모든 요청이 아닌 일부 샘플만 수신할 수 있음)
Kinesis 데이터 스트림에서 엑세스할 필드나 캐시 동작(경로 패턴)도 지정할 수 있음