클라우드 프론트는 CDN을 사용하고, 글로벌 엣지 로케이션에 콘텐츠를 뿌려 앞단에서 캐싱하는 서비스이다. Origin은 대표적으로 S3를 사용하고, EC2, ALB 등의 서버도 사용한다. 다만, Origin이 EC2나 ALB면은 엣지 로케이션의 IP를 허용해야 한다.
S3를 배울 때, CRR을 배웠다. 리전 간의 객체 복제를 바탕으로 다른 리전에 낮은 지연율로 사용하게 가능한 것 말이다. 하지만 클라우드 프론트는 글로벌이고, CRR은 적은 수의 리전이라는 데 차이점이 있다. CRR은 기본적으로 S3의 객체를 리전 간에 읽기 전용으로 복제하는 것이기 때문에 비용 측면에서 차이가 난다.
하지만 CRR이 더 좋은 점은 Cloud Front는 실시간으로 파일 업데이트 하기가 캐싱 때문에 까다롭지만, CRR은 실시간으로 파일 업데이트가 가능하다.
어쨋든 저쨋든 클라우드 프론트는 엣지 로케이션에서 캐싱을 한다. 캐시 Hit을 높이는 전략이 필요하다. 이는 개발자가 생각해 내야 한다.
기본적으로 TTL을 0 ~ 1년까지 가능하고 디폴트 설정(min 1초 max 1년 core 하루)이 있다. 여러 헤더를 통해 캐시 컨트롤이 가능하고, CreateInvalidation API를 통해서 캐시 무효화가 가능하다.
지리적 위치(지리적 IP 주소 범위)를 기반으로 화이트 리스트와 블랙리스트를 정의할 수 있다.
지리적 엣지로케이션 당 가격이 다르다. 그래서 price class가 존재한다.
이렇게 나뉜 이유는 네트워크 비용이 유럽 / 북미 쪽이 싸고 남미 / 오세아니아 쪽이 비싸기 때문이다. 우리나라에서는 price class 200을 사용하면 된다.
멀티 오리진 설정이 가능하다. 즉, A URL 패스는 ALB로 가고, B URL 패스는 S3 정적 컨텐츠로 가게 할 수 있다는 뜻이다.
오리진 그룹 설정이 가능하다. Primary A 서버 요청이 실패하면 Secondary B 서버로 요청이 가능하다. S3나 ALB, EC2 모두 가능하다.
서명된 URL이나 서명 데이터 쿠키를 통해서 서명하여 인증 상태를 확인하고 액세스 승인하는 것이 가능하다.
Signed URL로 사용하면 개별 파일의 인증만 가능하고, 쿠키는 여러 파일의 인증이 가능하다. 클라우드프론트 서비스의 키 그룹에 Public Key를 넣고, 해당 쿠키 데이터나 URL을 만들 EC2 서버 상에 Private Key를 넣어서 인증할 수 있다.
AWS 루트 계정을 통해서 계정 자체의 키 그룹을 설정할 수 있는데, 이는 IAM 유저가 할 수 없는 일이기 때문에 권하지 않는다.
엣지 로케이션에서 Public Key를 이용해서 암호화하고 웹서버에서 Private Key를 이용해 해독하는 방법이다. SSL에다가 부가적으로 암호화를 해버린다고 생각하면 된다. 이를 사용하는 것은 엣지 로케이션에서부터 웹서버로 오는 과정까지 데이터를 더 안전하게 옮기기 때문이다.