사용자가 원격지에 있는 Origin Server로부터 HTML, CSS, JS 등의 Contents를 다운받을 때 물리적으로 가까이 있는 서버에서 받는 것보다 시간이 좀 더 오래 걸린다.
그렇기 때문에 이 응답 시간을 줄이려면 Cloudfront와 같은 CDN 서비스를 이용해 사용자가 있는 위치에서 가장 가까운 곳에 위치한 Cache Server에 해당 Contents를 저장해 캐싱하고, Content 요청 시에 멀리 있는 Origin Server가 아닌, 가까이에 있는 Cache Server가 응답을 줄 수 있도록 해야한다.
보통 이런 CDN은 전 세계적으로 서비스를 할 때에 중요시된다.
넷플릭스를 예로 들자면, 넷플릭스는 전 세계로 동영상 스트리밍 서비스를 제공하기 때문에, 콘텐츠를 더 안정적이고 빠르게 사용자에게 제공할 필요가 있다.
실제로 넷플릭스는 2011년 자체 CDN을 구축하기도 했다. 하지만 이 예시처럼 글로벌한 서비스를 하는 경우가 아니라, 특정 국가나 지역만을 타깃으로 할 때에는 CDN 서비스가 오히려 불필요한 연결 지점을 늘릴 수 있어 성능 저하를 가져올 수 있다.
S3는 우리가 사용자에게 보여줄 정적인 파일들을 넣어두는 역할을 한다.
그리고 S3이 제공하는 많은 속성 중에, 정적인 웹 호스팅 속성을 통해 호스팅도 가능하다.
버킷에 퍼블릭 권한을 심어주어야 한다.
모든 버킷은 최초 생성 시 프라이빗으로 접근이 불가능하게 되어 있는데
위에서 버킷 생성 시 설정한 퍼블릭 엑세스 차단을 비활성화 했을 뿐이지
실제로 이 버킷은 퍼블릭이 아니므로 따로 퍼블릭 권한 설정을 줘야 한다.
버킷 정책은 JSON 형식의 문서인데 JSON을 직접 작성하기는 어려우니 정책생성기를 이용해 자동으로 JSON을 생성할 수 있다.
arn:aws:s3:::bucket_name/*
여기서 bucket_name이라고 적혀있는 부분에 자신이 만든 버킷의 이름을 넣어주면 된다.
뒤에 /* 의 뜻은 모든 오브젝트에 대해서라는 뜻!
Cloudfront는 사용자와 S3에서 호스팅하는 페이지 중간에서 사용자에게 빠르게 페이지를 응답할 수 있도록 사용자와 지리적으로 가까운 Cache Server에 페이지를 캐싱을 하고, 보안을 강화해주는 역할을 한다고 보면 된다.
맨 처음에는 [사용자 → Cloudfront → S3] 이렇게 웹 페이지를 요청하게 되는데, Cloudfront의 캐싱 이후에는 S3까지 요청이 가지 않고, [사용자 → Cloudfront] 사이에서 응답과 요청이 처리되게 된다.
AWS의 Cloudfront는 기본 24시간동안의 웹 컨텐츠를 캐싱할 수 있다. 이 말인즉슨 배포를 한 번 하고 하루가 지나지 않았는데 또 배포를 한다면 변경사항이 바로 적용되지 않고, 24시간 후에 적용된다. 그렇기 때문에 만약 변경사항을 바로바로 확인해야한다면, Caching Optimized가 아닌 Caching Disabled option을 설정하면 된다.