AWS CloudFront 이해

AWS에서 제공하는 Amazon CloudFront를 이해해보자.
- Amazon CloudFront 개요
 - Amazon CloudFront 동작 방식
 - Amazon CloudFront 구성
 - Amazon CloudFront 기능
 - Amazon CloudFront 정책
 - Amazon CloudFront 보안
 
Amazon CloudFront 개요
AWS에서 소개하는 Amazon CloudFront 설명을 보면
Amazon CloudFront는
개발자 친화적 환경에서짧은 지연 시간과빠른 전송 속도로 데이터, 동영상, 애플리케이션 및 API를전 세계 고객에게 안전하게 전송하는 고속 콘텐츠 전송 네트워크(CDN) 서비스입니다.
1. 엣지 로케이션

위 그림은 전세계의 AWS 엣지 로케이션의 위치를 나타냄
엣지 로케이션이란, 컨텐츠가 캐싱되고 유저에게 제공되는 지점입니다.
2. Content Delivery Network(CDN)
Content Delivery Network(CDN)란 다음과 같습니다.
웹페이지, 이미지, 동영상 등의 컨텐츠를 본래 서버에서 받아와 캐싱해당 컨텐츠에 대한
요청이 들어오면캐싱해 둔 컨텐츠를 제공컨텐츠를 제공하는 서버와실제 요청 지점간의지리적 거리가 매우 먼 경우, 혹은통신 환경이 안좋은 경우요청지점 근처의 CDN을 통해 빠르게 컨텐츠 제공 가능서버로 요청이 필요 없기때문에,서버의 부하를 낮추는효과가 있음

위 그림은 세계 각 지점(검정색)에서 우리나라에 위치한 서버(초록색)로 데이터를 요청 할 때의 상황을 나타낸 것입니다.
각 지점으로부터 우리나라까지의 위치가 굉장히 멀리 떨어져 있기 때문에, 필연적으로 속도가 느려집니다.

따라서 위 그림과 같이 각 지역별로 엣지 로케이션(청록색)을 둠으로서 서울에 위치한 서버로부터 엣지 로케이션으로 각각 데이터를 받아와 전송해줄 수 있습니다.
Amazon CloudFront 동작 방식
Amazon CloudFront 동작 방식은 다음과 같습니다.
요청 받은 컨텐츠가
엣지 로케이션에 있다면, 바로 전달요청 받은 컨텐츠가 엣지 로케이션에
없다면, 컨텐츠를 제공하는 근원에서 제공받아 전달
Amazon CloudFront 구성
- Origin : 
실제 컨텐츠가 존재하는 근원(S3, EC2, ELB, Route53 등)- AWS 서비스(EC2, ELB, S3 등)
 - 온프레미스 서버
 
 Distribution : CloudFront의
CDN 구분 단위로여러 엣지 로케이션으로 구성된 컨텐츠 제공 채널- 주요 설정 및 용어
- TTL(Time To Live) : 
캐싱된 아이템이 살아 있는 시간-> TTL 초 이후 캐싱에서 삭제 - 파일 무효화(invalidate) : 
TTL이 지나기 전에 강제로 캐시를 삭제하는 것- 주로 새로운 파일을 업데이트 한 후 TTL을 기다리지 못할 상황에 사용
 - 비용 발생
 - CloudFront API, 콘솔, Third-Party 툴 등을 사용 가능
 
 - Cache Key
어떤 기준으로 컨텐츠를 캐싱할 것인지 결정기본적으로 URL- 이후 
Header와 Cookie, 쿼리 스트링 등을 사용 가능 
 - 정책(Policy)
- CloudFront가 
동작하는 방법을 정의한 정책 어떻게 캐싱을 할지, 어떤 내용을 Origin에 보낼지, 어떤 헤더를 허용할 지 등을 결정
 - CloudFront가 
 
 - TTL(Time To Live) : 
 
Amazon CloudFront 기능
1. CDN
- CDN : 
컨텐츠를 최적화하여 보다빠르게 유저에게 제공- 정적/동적 컨텐츠 모두 최적화
 - 정적(Static) 컨텐츠 : 서버를 거치지 않고 
클라이언트에서 직접 보여주는 내용- 이미지
 - CSS
 - 기타 서버가 필요 없는 내용들
 
 - 동적(Dynamic) 컨텐츠 : 
서버 계산, DB조회 등이 필요한 내용- 로그인
 - 게시판
 
 
 
보통의 다른 CDN에서는 동적 컨텐츠는 캐싱을 잘 못시키는데, CloudFront에서는 동적 컨텐츠 또한 지원합니다.

일반적인 CloudFront의 처리 패턴은 위 그림과 같습니다. 
 동적 컨텐츠는 동적 컨텐츠를 제공하는 Origin으로, 정적 컨텐츠는 정적 컨텐츠를 제공하는 Origin으로 경로 패턴을 분기 처리 합니다.
각 컨텐츠별 최적화 방식을 보면
정적 컨텐츠 :
캐싱으로 접근 속도 최적화동적 컨텐츠 :
네트워크 최적화, 연결 유지, Gzip 압축 등을 사용- DNS Lookup, TCP Connection, Time to First Byte 등을 최적화
 
2. HTTPS 지원
- HTTPS 지원
Origin에서 HTTPS를 지원하지 않더라도 HTTPS 통신을 지원할 수 있도록 구성 가능
 
일반적으로 웹 브라우저를 통해서 웹서버에 접근하면 HTTP만을 지원합니다.

이 경우 위와 같이 주의 요함이 뜨게 됩니다.
하지만 CloudFront를 사용하면 지원 가능하며 다음과 같습니다.

웹서버(EC2)와 CloudFront간의 통신은 HTTP 통신이지만, 사용자와 CloudFront 사이의 통신은 AWS Certificate Manager(ACM)를 통해서 HTTPS 통신으로 만듭니다.
3. 지리적 제한
- 지리적 제한 : 
특정 지역의 컨텐츠 접근을 제한 가능 
다른 나라에서의 저작권이나 계약에 의해 해당 지역에서 서비스를 지원할 수 없을 경우 접근을 제한
4. 다른 서비스와 연계
- 다른 서비스와 연계
- AWS WAF(웹 애플리케이션 방화벽 보안 서비스), Lambda@Edge 등과 연동 가능
 
 
I. Lambda@Edge
Lambda를 사용사용 사례
- 예 : 
한국에서 요청이 올 경우한국 웹 서버,미국에서 올 경우미국 웹 서버로 분산 커스텀에러 페이지- Cookie를 검사해 
다른 페이지로 리다이렉팅 -> A/B 테스팅 - CloudFront에서 
Origin에 도착 이전에 인증등 
- 예 : 
 
과정은 다음과 같습니다.

Lambda@edge는 위와 같이 4가지 case으로
사용자로부터 CloudFront에 도착하기 전(Viewer Request), 
 CloudFront에서 웹서버(Origin)로 요청을 보내기 전(Origin Request),
 웹서버에서 CloudFront로 응답을 보내기 전(Origin Response), 
 마지막으로 CloudFront에서 사용자에게 응답을 보내기 전(Viewer Response)
각 단계에서 Lambda를 실행해서 전달 내용을 변경, 로깅, 분석 등을 할 수 있습니다.
II. CloudFront Function
Lambda@edge 1/6의 비용으로 경량 javascript 실행사용 사례 :
캐싱, 헤더 조작등
5. 리포팅
- 주요 CloudFront 이용 지표 확인 가능
캐시 상태가장 요청을 많이받은 컨텐츠- Top Referrer
어디서 들어와서 해당 웹 애플리케이션을 보고 있는지
 
 
다음은 위 요소들의 화면으로

Total requests

Top referrers

어떤 디바이스로 요청했는지도 알 수 있습니다.
이 뿐만 아니라 어떤 OS, 어떤 나라에서 접속했는지도 알 수 있으며 이러한 리포트들은 모두 Origin에 전달할 수 있습니다.
 아래 뷰어 정보 확인 항목 참조 바람.
Amazon CloudFront 정책
- 총 3가지 정책 설정 가능하며
- Cache Control : 
캐싱 방법 및 압축TTL 및 Cache Key 정책- CloudFront가 
어떻게 캐싱을 할 지를 결정 
 - Origin Request : 
Origin으로 어떤 내용을 보낼 것인가- Origin에 
쿠키, 헤더, 쿼리스트링 중어떤 것을 보낼 것인가 
 - Origin에 
 - 뷰어에게 보낼 HTTP header
- CloudFront가 
뷰어(사용자)에게응답과 같이 실어보낼 HTTP Header 
 - CloudFront가 
 
 - Cache Control : 
 
1. CloudFront의 뷰어 정보 확인
CloudFront에서
뷰어(사용자)의 정보를헤더에 더해 Origin에 전송확인 가능한 뷰어의 정보
- 디바이스 타입 : Android/IOS/SmartTV/Tablet/Desktop
 - IP Address
 - Country/도시/위도, 경도/타임존 등
 
이를 토대로 사용자에게 보여줄 컨텐츠를 분기할 수 있습니다.
 뷰어의 정보 중 Country가 미국이라면, 영어로 된 컨텐츠를 보여주고, 한국이라면 한글로 된 컨텐츠를 보여주는게 가능
Amazon CloudFront 보안
1. Signed URL
- Signed URL : 
애플리케이션에서 CloudFront의 컨텐츠에 접근할 수 있는URL을 제공하여 컨텐츠 제공을 제어하는 방법- URL에는 
시작시간, 종료시간, IP파일명, URL의 유효기간 등의 정보를 담을 수 있음 - 이 URL 접근 이외의 접근을 막고 허용된 유저에게만 URL을 전달하여 컨텐츠 제공을 제어 가능
 - 단 하나의 파일 또는 컨텐츠에 대한 
허용만 가능 - S3 Signed URL과 비슷한 방식
 
 - URL에는 
 
2. Signed Cookie
- Signed Cookie : 다수의 컨텐츠의 
제공 방식을 제어하고 싶을 때 사용- Signed URL과 마찬가지로 여러 제약 사항 설정 가능
 - 다수의 파일 및 스트리밍 
접근 허용 가능 - 예 : 로그인 했을 때 해당 사용자에게 
허락된 컨텐츠들을 제공 - 예 : 
프리미엄 유저만볼 수 있는 강의 동영상 등 
 
3. Origin Access Identity(OAI)
- Origin Access Identity(OAI)
- S3의 컨텐츠를 
CloudFront를 사용해서만 볼 수 있도록 제한하는 방법- S3의 컨텐츠는 
정적이기 때문에 CloudFront를 자주 사용함 
 - S3의 컨텐츠는 
 CloudFront만 권한을 가지고 S3에 접근하고나머지 접근권한은 막음S3 Bucket Policy로CloudFront의 접근을 허용해야 사용 가능
 - S3의 컨텐츠를 
 
4. Field Level Encryption
- Field Level Encryption
- CloudFront로부터 Origin 사이의 통신을 암호화
 최대 10개의 필드까지공개 키 방식으로 암호화 ->CloudFront에 공개 키를 제공 후Origin에서 Private Key로 해독
과정은 다음 그림과 같습니다.

유저가CloudFront에 요청을 보내고CloudFront에서웹서버(EC2)로 요청을 보냅니다.
이 과정에서생각보다 많은 과정을 거치게 되기 때문에CloudFront에 Public Key를 제공하여암호화하도록 시킵니다.
암호화된 요청(필드)은웹서버(EC2)에서 Private Key를 통해 해독됩니다.이러한 과정에 꺼려진다면
웹서버에 HTTPS 통신을 사용하도록 구현하면 되나 과정에 까다로울수 있습니다. 
- Ref