[Udemy][day-29,30] Section14 : CloudFront

#AWS Certified Developer Associate

 

너무오랜만이고 ㅋㅋ

 

(11.3 시작)

 

152. CloudFront 개요

컨텐츠 전달 네트워크 (CDN - Content Delivery Network)

컨텐츠가 엣지 로케이션에서 분배 및 캐시되기때문에 판독 능력이 향상된다.

글로벌적으로 216개의 엣지 로케이션이 존재함 (강의 촬영 기준)

DDoS 보호 기능 - 서비스 거부를 배포하는 공격에 대한 보호

인증서를 로드하여 외부 HTTPS 엔드포인트를 노출하고 해당 트래픽을 암호화 해야 하는 경우 내부 HTTPS 에서 애플리케이션에 내부적으로 통신하게끔 해줌

 

Origins

- S3 bucket

엣지 로케이션에 파일을 배포하거나 캐시할 수 있음

오리진 액세스 신분으로 클라우드 프론트와 s3 버킷 사이의 보안 강화 가능 - s3 버킷이 오직 클라우드 프론트하고만 소통할 수 있게 해줌

클라우드 프론트를 세계 어디서든 파일을 s3에 업로드할 입구(ingress)처럼 사용할 수 있음

 

- Custom Origin (HTTP 엔드포인트 필요)

HTTP 프로토콜을 준수하는 무엇이든 가능

ALB

EC2

S3 website

any HTTP backend

 

 

CloudFront Geo Restriction (지리적 제한)

분산으로의 액세스에 제한을 둘 수 있음

- 화이트리스트 : 이 리스트에 있는 허용된 국가의 사용자들만이 클라우드 프론트에 액세스 할 수 있게 함

- 블랙리스트 : 이 리스트에 있는 국가들은 분배에 액세스 할 수 없도록 함

 

제3자 회사의 지리적 IP DB를 이용해 국가들의 허용 여부가 결정됨

특정 콘텐츠에 액세스를 제한하는 저작권법이 있을때 유용

 

 

CloudFront vs S3 Cross Region Replication

cloudfront

- 글로벌 엣지 네트워크

- TTL 에 맞춰 파일이 캐시됨 (maybe a day)

- 전 세계적으로 사용되는 정적인 콘텐츠에 적합함

 

s3 cross region replication

- 복제가 일어나도록 할 각 리전에 설정되어야 함

- 파일이 실시간으로 업데이트 되야 함

- 읽기 전용이기 때문에 읽기 성능이 좋음

- 적은 수의 리전(선택된 리전)에서 낮은 지연 시간으로 사용이 가능해야 하는 동적인 컨텐츠에 적합함

 

 

 

 

153. CloudFront 실습

 

S3를 만들어줌

다른 설정은 건드리지 않음

 

이후 간단히 사진을 보여주는 index.html 파일과 이미지 파일 하나를 업로드해서

미리 서명된 url 로 열어보면 index.html 은 보이지만 사진은 보이지 않음

퍼블릭 설정도 안했고 권한 설정도 안했기 때문

 

클라우드 프론트를 통해 파일로의 액세스 허용

cloudfront

origin domain

s3 외에도 ELB 나 다른 HTTP 를 지원하는 도메인을 넣어서 custom 하게 만들 수도 있다

강의에선 만들어두었던 s3를 사용함

 

OAI 사용

버킷 정책을 자동으로 업데이트 해준다

OAI 가 Origin Access Identity 이라고 한다 원본 엑세스 id 라네요

 

 

OAI 생성

루트 객체 선택

루트 객체를 index.html로 입력해줌

 

배포

배포되는데 5분정도 소요된다고 한다

 

cloudfront

cloudfront 로 배포되는걸 확인할 수 있음

 

좋은 점은 이러한 파일들이 캐시 되었다는 것

도쿄리전에 올려놓은 파일이

서울리전 엣지 로케이션에 캐시되어있는 상태임

 

 

 

 

 

154. CloudFront 캐싱 및 캐싱 무효화

CloudFront Caching

캐시 구성

- 헤더 값

- 세션 쿠키

- 쿼리 문자열 파라미터 등

모든 캐시는 엣지 로케이션에 저장됨

 

클라이언트가 엣지 로케이션으로 요청을 보내면

헤더 값, 쿠키 및 캐시 문자열 파라미터를 기반으로 해서 캐시가 확인됨

그리고 캐시는 캐시 내의 TTL 을 기반으로 만료됨

캐시에 값이 없는 경우엔 쿼리 또는 전체 HTTP 요청이

오리진(원본)으로 직접 전달되며 그 후에 캐시가 쿼리 회신으로 채워지게 됨

 

따라서 클라우드 프론트의 역할은 캐시 히트를 늘려서 오리진에서의 요청 수를 최소화 하는 것

캐시 히트란 캐시에서 바로 제공되는 요청의 수를 의미함

TTL 값은 0초에서 1년 사이로 조정 가능

캐시 제어 헤더나 만료 헤더 등의 몇가지 헤더를 통해 이를 제어할 수 있다.

 

CreateInvalidation API를 사용해 캐시의 일부를 무효화 할 수 있음

 

캐시 히트를 늘린다는 것?

정적 요청은 클라우드 프론트를 통해 정적 콘텐츠 홀더(보통 S3 버킷)로 가게 됨

이때 적용되어야 할 헤더나 세션 케싱 규칙은 없으며 모든 정적 콘텐츠는 클라우드 프론트에 캐시되어 캐시 히트가 최대화 하게 됨

반면 동적 콘텐츠의 경우는 클라우드 프론트를 통해 따로 분산되는데

이때는 ALB나 EC2 인스턴스와 같은 HTTP 서버로 전달된다.

 

클라우드 프론트에서 캐시를 동적 요청과 정적 요청으로 구별하는 것은 흔히 사용되는 전략이다.

 

 

 

 

155. CloudFront 캐싱 및 무효화 실습

생성한 클라우드 프론트의 behavior 탭에 들어간다

edit behavior

이를 통해 객체가 클라우드 프론트로 캐시되는 방식을 알 수 있다.

 

캐시 정책

CachingOptimized 정책을 사용하는 것 같다.

정책 보기를 눌러보자

 

정책 세부 정보

최대 TTL 이나 최소 TTL 등을 확인할 수 있다.

CloudFront 의 정책 탭에서 새 정책을 만들 수도 있다.

지금은 그냥 진행

 

이전에 업로드했던 index.html 을 통해 TTL 설정을 관찰한다고 함

index.html 파일을 조금 수정한 후 새로운 버전의 파일로 업로드 했다

버저닝을 안켰기 때문에 기존 파일을 대체하게 될꺼다

 

클라우드 프론트 도메인 접속

index.html 에서는 i love 사이에 RELLY 를 넣어서

원래대로라면 i REALLY love 가 되야하는데

TTL 값이 하루라서 바뀌지 않았다.

 

invalidations tab

무효화를 생성해준다

각 객체 경로를 추가해서 설정할 수도 있고 와일드 카드를 사용할 수도 있다고 한다

 

클라우드 프론트 캐시의 모든 객체는 삭제되고 Amazon S3에 있는 새로운 객체를 가져오게 됨

그래서 새로 추가한 REALLY 단어가 반영되어 보이는 모습

 

 

 

내일 마저 하자

(11.3 끝)

 

 

(11.8 시작)

156. CloudFront 보안

1. 지리적 위치를 기반으로 분산으로의 액세스 허용 여부를 제한하는 방식

화이트리스트나 블랙리스트를 설정할 수 있다 -  어떤 국가가 클라우드 프론트 분산에 허용 또는 거부 되는지를 정의하는 방법

이러한 국가의 식별에는 IP에 국가가 매핑된 제3자 회사의 지리적 IP DB를 사용한다.

 

2. HTTPS

뷰어 프로토콜 정책 : 클라이언트와 엣지 로케이션 사이에 적용함

- HTTP 에서 HTTPS 로 리다이렉팅 하는 것 (실무 추천-모든 클라이언트에서 적용 가능)

- HTTPS 만 사용

 

오리진 프로토콜 정책 (HTTP or S3) : 엣지로케이션과 오리진 사이 적용함

- HTTPS only

- Match Viewer (HTTP -> HTTP & HTTPS -> HTTPS)

 

S3 버킷의 웹사이트는 HTTPS 보안 정책을 지원하지 않음

 

뷰어 프로토콜 정책

 

CloudFront 지리적 제한 편집

허용 목록 - 화이트 리스트

차단 목록 - 블랙 리스트

 

 

 

157. CloudFront 서명 URL/쿠키

클라우드 프론트 분산을 비공개로 만들기 위해서는 세계 각지 사람들에게 프리미엄 유로 콘텐츠에 대한 액세스를 주어야 함

누가, 어떤 클라우드 프론트 분산에 액세스하는지를 알기 위해서 클라우드 프론트 서명된 url 이나 쿠키를 사용할 수 있다.

- 해당 url 이나 쿠키의 만료

- 특정 데이터에 접근할 수 있는 IP 범위는 어디인지 지정

- 어떤 aws 계정이 url 혹은 쿠키를 생성할 수 있는지 의미하는 신뢰할 수 있는 서명자 지정

 

URL 유효 기간

- 공유 컨텐츠 (영화, 음악) - make it short (a few minutes)

- 비공개 컨텐츠 (private to the user) : you can make it last for years (수년간 지속되게 할 수도 있음)

 

URL과 쿠키 차이점

서명된 url 은 개별 파일에 대한 액세스를 줌 - 파일별로 하나의 url 이 있음

서명된 쿠키는 다수의 파일에 액세스를 주고, 해당 쿠키는 재사용 가능, 즉 다수의 파일에 서명된 쿠키는 하나임

 

 

CloudFront Signed URL   vs   S3 Pre-Signed URL

CloudFront Signed URL : 

오리진에 상관 없이 경로에 대한 액세스를 허용하기 때문에 서명된 url 은 s3 오리진 뿐만 아니라 원하는 모든 http 백엔드 오리진에 작동함

이는 계정 내 키 페어이기 때문에 루트만 관리할 수 있고

ip, 경로, 날짜, 만료 등으로 필터링 할 수 있다.

클라우드 프론트에 있는 모든 캐싱 기능을 활용할 수 있다.

만약 사람들이 자신의 클라우드 프론트 분산에 액세스 하길 원하고  S3 버킷을 사용한다면 의도한 대로 s3 버킷에 액세스 할 수 없으므로 서명된 url 을 사용해야 한다. - 이를 oai 로 제한하는 버킷 정책 때문

 

S3 Pre-Signed URL : 

url 에 미리 서명한 사람으로서 요청을 발행함

자신이 자신만의 IAM 원칙으로 URL 에 서명하고 서명을 위해 자신의 IAM 키를 사용하게 되면 해당 URL 을 가진 사람은 자신과 같은 권한을 가지게 됨수명이 제한적임미리 서명된 url 을 사용해 클라이언트가 직접 s3 버킷에 액세스 할 수 있다.클라우드 프론트를 거치지 않고 s3 버킷에 직접 액세스해 파일을 사용하길 원할때 사용

 

 

 

 

158. CloudFront 서명된 URL - 키 그룹 + 실습two types of signers (서명자)

- 신뢰할 수 있는 키 그룹의 사용 (신규 권장 방식)

  - API 를 활용하여 이러한 키를 생성하고 순환하게 할 수 있으며

  - 키 그룹 및 api 키의 관리를 위한 api 보안에 iam 을 활용할 수 있다.

  - 공용 키가 이 그룹에 속함

- 클라우드 프론트 키 페어를 보유한 계정을 사용하는 것 (기존 방식)

  - 루트 계정 자격 증명 필요

  - not recommended - 루트 계정을 사용해선 안되기 때문

  - 이 클라우드 프론트 키 페어를 관리할 api가 없기 때문에 자동화 또한 완전 불가능함

 

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

공용키와 개인키를 생성할 수 있음

- 개인키는 자신의 애플리케이션에서 ec2 인스턴스가 url 에 서명하려는 경우 등에 사용됨

- 클라우드 프론트가 업로드하는 공용 키는 이러한 url의 서명을 검증하는 데에 사용됨

 

rsa key 생성기 검색

 

private key , public key 생성

 

클라우드 프론트 퍼블릭 키 생성

 

Your request contains empty/invalid/out of limits RSA Encoded Key

 

이렇게 오류가 나왔는데 사이트에서 몇번 재생성해서 시도하니 생성되었다.

 

 

키 그룹 생성

 

이 키 그룹은 클라우드 프론트로 하여금 사용자, 즉 ec2 인스턴스가 서명된 url을 생성할 수 있도록 허용하기 위해 참고하게 될 키 그룹이다.

 

 

기존 버전 키페어 등록

루트 접속 - my security credentials(보안 자격 증명) - cloudfront key pairs - 신규 키페어 생성 or 기존 키페어 등록

 

 

 

 

159. CloudFront 고급 개념

클라우드 프론트의 엣지 로케이션은 전세계에 퍼져있음

엣지 로케이션에 따른 데이터 전송 비용도 다름

국가에 따라 데이터단위 당 비용이 다름

 

가격 등급 (Price Classes)

전 세계에 걸쳐 클라우드 프론트 분산에 사용할 엣지 로케이션의 수를 줄여 가격을 낮출 수 있음

3가지 가격 등급

1. Price Class ALL : 모든 리전 - 최상의 성능

2. Price Class 200 : 가장 비싼 리전을 제외한 대부분의 지역 제공 

3. Price Class 100 : 가장 저렴한 지역만을 제공

 

 

• 다중 오리진 - 오리진 그룹

amazon 클라우드 프론트에서 사용되는 경로를 기반으로 다중 오리진이 정의됨

다중 오리진

 

오리진 그룹은 usecase 가 다름

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

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

만약 주 오리진에 장애가 발생하면 클라우드 프론트가 보조 오리진을 사용하는 것

 

만약 s3 와 클라우드 프론트를 오리진 그룹과 함께 사용한다면 지역 단위의 고가용성과 재해 복구가 가능하게 됨

 

 

 

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

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

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

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

비대칭 암호화 사용

 

Usage : 

amazon 클라우드 프론트로 보내는 post 요청의 경우 암호화를 원하는 필드를 최대 10개 까지 지정할 수 있음 (ex 신용카드)

그리고 이 필드를 해독할 공용 키도 함께 지정됨

필드 수준 암호화

클라이언트 - 엣지 로케이션 단에서 암호화가 진행되고

웹서버에서 private key 로 해독하게 됨

amazon cloudfront 와 alb 에서는 이 필드를 해독할 수 없음