클라우드 프론트 Quick Start

실습용 파일 준비

 

Cloud Front 를 직접 활용해보기 위해 간단한 웹사이트를 위한 HTML/CSS/Javascript 파일들을 준비해봅시다.

 

 

저는 과거에 제가 사용했던 포트폴리오 웹사이트를 사용하겠습니다.

 

 

 

S3 에 파일 업로드

 

(s3 업로드 방법은 여기서 따로 다루지는 않겠습니다) 별다른 설정 없이 s3 에 index.html 을 비롯한 각종 웹 자원들을 업로드했다면 기본으로 퍼블릭 엑세스가 차단되어 있을 것입니다.

 

 

그리고 이건 정적 호스팅을 활성화하더라도 마찬가지입니다.

 

이제 파일의 접근권한을 이대로 내버려둔채로 정적 호스팅을 위해 Cloud Front 서비스를 이용해봅시다.

 

 

Cloud Front 도메인 배포

 

 

처음 cloud front 를 이용한다면 위와 같은 화면을 보게 될 것입니다. Create a CloudFront distribution 버튼을 눌러서 본격적으로 클라우드 프론트 도메인을 만들어봅시다.

 

 

버튼을 눌렀다면 위와 같은 많은 설정 항목들을 마주하실 것입니다. 항목이 어마무시하게 많은지라 중요한 설정들 위주로 설명드리겠습니다.

 

Origin

 

Origin domain

 

클라우드 프론트가 'Origin' 으로 설정할 도메인을 입력하는 부분입니다. 말씀드렸 듯이, 클라우드 프론트가 하는 일은 '중계'입니다. 그렇기에 콘텐츠를 받아올 서버가 따로 필요하고 이를 Origin 이라고 부릅니다. 직접 사용하고 있는 도메인을 그대로 입력해도 되지만 저는 그냥 편하게 S3에서 제공해주는 정적 호스팅을 위해 마련된 도메인을 Origin domain 으로 설정했습니다.

 

 

Origin path

 

만일 위에서 설정한 도메인 url에 더해서 추가적인 path를 클라우드 프론트가 제공하는 도메인의 루트 path로 지정하고 싶다면 이 옵션을 사용할 수 있습니다. 저는 이용자에게 전달하고자 하는 index.html 이 버킷의 루트 디렉토리에 존재하므로 딱히 지정하지는 않겠습니다.

 

 

S3 bucket access

 

만일 클라우드 프론트가 사용할 origin이 S3에 접근하게 되는 origin 이라면 이 설정 항목을 잘 활용해야 합니다. 클라우드 프론트는 S3에 접근하는데 사용되는 권한 객체로서의 OAI 라는 것을 생성할 수 있습니다. S3는 클라우드 프론트의 배포 도메인이 특정 bucket 에 접근하려 할 경우, 버킷이 허용하는 OAI를 해당 배포 도메인이 가지고 있는지를 검사하여 파일을 내어줄지 내어주지 않을지를 판단합니다.

 

이 OAI를 만들기 위해 복잡한 작업이 필요하지는 않습니다. 기존에 생성한 OAI가 없다면 create new OAI 버튼을 눌러 새로 생성한 후 적용하기만 하면 되고, 기존에 생성한 것을 그대로 재활용할 수도 있습니다.

 

 

Default cache behavior

 

 

Path pattern

 

만일 캐싱이 적용되었으면 하는 파일들과 그렇지 않을 파일들을 분류하고 싶다면 이 작성란을 정규표현식으로 채워주시면 됩니다. 저는 굳이 지정하지 않겠습니다.

 

 

Viewer

 

이 작성란에서 할 수 있는 일은 다음과 같습니다.

 

• 이용자가 오떤 이유에서든 http를 이용해서 사이트에 접근해도 이를 https 로 리디렉션 시킬 수 있습니다.
• 허용할 HTTP 메서드 종류를 선택합니다. 이 Cloud Front 는 단지 S3 와 이용자를 중계해주는 역할을 해줄 것이기 때문에 저는 GET, HEAD 만을 허용하도록 하겠습니다.
• 이용자가 클라우드 프론트 서버에 오직 클라우드 프론트가 배포한 도메인을 통해서만 접속할 수 있도록 제한합니다.

 

Cache key and origin requests

 

• 이전에 말했듯 자세한 캐싱 설정을 이곳에서 수행할 수 있습니다. 이 웹사이트는 포트폴리오 웹사이트이기에 업데이트가 잦을 수 있고 어떤 경우에서든 최신 내용이 보여져야 하기 때문에 저는 캐싱 자체를 disabled 로 설정하도록 하겠습니다.
• Origin request policy 를 따로 생성하여 설정하면 이용자가 특정 쿠키, 요청 헤더, queryString 을 가져야만 접속할 수 있도록 제한하는 규칙을 설정할 수 있습니다. 저의 경우는 필요 없으니 None 인 상태로 두겠습니다.

 

 

캐시 정책 생성

하지만 본인이 직접 캐시 정책을 생성해보고 싶다면 Create policy 를 눌러서 캐싱 정책을 직접 만들 수 있습니다. 만일 원하는 것이 캐싱을 '어느 정도 시간 동안' 유지할 것인지라면 간단히 TTL 만을 설정하는 것으로도 충분합니다.

 

 

하지만 이때 명심해야 할 것이 있습니다. 이 TTL 은 단순히 클라우드 프론트의 캐싱 외에도 origin 의 캐싱 정책 또한 고려해야 해서 설정된다는 것입니다. 이를 이해하지 못하면 왜 TTL 설정에 최소, 최대, 기본 TTL 항목이 존재하는지 이해하기 어려울 것입니다. TTL 값 하나만 설정하면 될텐데 왜 저렇게 3가지 분류를 적용해야하는 것일까요?

 

그 이유는 클라우드 프론트가 중계 해주는 Origin 서버 자체의 TTL 값이 설정되어 있을 수 있기 때문입니다. 보통의 경우, TTL은 http 요청의 헤더에

 

Cache-Control: max-age=3600

 

위의 형식으로 Cache-Control 을 명시해줬을 때 설정됩니다. 위의 경우엔 3600초 동안 캐싱을 유지하겠다는 의미입니다. 이러한 맥락에서 생각해보면

 

• '최소 TTL'은 만일 max-age 값이 최소 TTL 로 설정한 값보다 작다면 그 설정을 무시하고 최소 TTL 을 실제 TTL 로 적용하겠다는 의미
• '최대 TTL'은 만일 max-age 값이 최대 TTL 로 설정한 값보다 크다면 그 설정을 무시하고 최대 TTL 을 실제 TTL 로 적용하겠다는 의미
• '기본 TTL'은 만일 Origin 서버 자체에 설정된 TTL 이 없다면 적용될 TTL 을 의미

 

임을 알 수 있습니다.

 

 

 

Origin의 캐시 무효화

 

다만 위의 캐시 정책은 클라우드 프론트가 중계하는 모든 요청에 일괄적으로 적용된다는 문제점이 존재합니다. 다른 모든 요청에는 캐싱이 모두 적용하고 싶지만, 특정 파일 (ex: bundle.js)은 캐싱을 아예 적용하고 싶지 않을 수도 있습니다. 해당 파일 만큼은 항상 서버에서 최신 파일을 가져왔으면 싶은거죠. 그럴 땐 클라우드 프론트의 '무효화' 기능을 활용해볼 수 있습니다.

 

 

사용법은 간단합니다. 캐싱을 적용하고 싶지 않은 파일의 경로를 명시한 항목들을 생성해주고 '무효화 생성' 버튼을 눌러주면 됩니다. 이때 와일드카드(*) 를 통해 여러 파일들을 한꺼번에 지정할 수도 있습니다. 이 무효화를 적용하면 기존 Origin 서버의 해당 파일에 대한 캐싱 정책 또한 무효화 됩니다.

 

 

Settings

 

 

 

클라우드 프론트의 나머지 설정들입니다. 아래의 항목들에 대해서 설정할 수 있습니다.

 

• 클라우드 프론트가 특정 지역에만 국한된 CDN 만을 이용할지를 설정합니다. 당연히 가장 좋은 선택지는 모든 CDN 을 이용하는 것이겠지만 이럴 경우 클라우드 프론트 설정을 변경했을 때, 그 변경 사항이 반영되기까지의 시간이 오래 걸립니다. 게다가 가격도 조금 더 비쌉니다.
• 따로 구매한 도메인 주소를 적용시킬 수 있습니다.
• 직접 구매하고 지정한 SSL 인증서를 이곳에 적용시킬 수 있습니다.
• 도메인의 루트 경로로 접속했을 때 어떤 파일에 접근할지도 설정해줄 수 있습니다. 저의 경우는 index.html 을 설정하면 됩니다.

 

도메인 배포

 

 

모든 설정을 마무리하고 배포 시작 버튼을 눌렀다면 다음과 같은 화면을 볼 수 있습니다. 도메인이 배포되기까지 적어도 15분은 걸립니다.

 

 

리디렉션 설정

 

이용자가 서비스가 제공하지 않는 컨텐츠의 경로로 접근하려고 하면 이를 리디렉션 시켜줄 필요가 있습니다. 제공하는 웹앱이 SPA라면 새로고침에 대한 처리를 해야하니 이 설정은 필수라고 말할 수 있겠습니다.

 

 

클라우드 프론트에서는 별도의 리디렉션 설정 페이지가 존재하지는 않습니다. 하지만 이용자가 클라우드 프론트가 배포한 도메인에 잘못된 방식으로 접근했을 때 어떤 처리를 할지에 대한 설정을 이용해볼 수 있습니다. Create custom error response 를 눌러서 설정 페이지에 진입할 수 있습니다.

 

 

잘못된 경로로 진입시 루트 경로로 리디렉션

 

 

이용자가 접근할 수 없는 페이지에 접근하려고 하거나 SPA 어플리케이션 상에서 루트 경로 외의 페이지 경로에서 새로고침이 일어났을 때의 리디렉션 처리에 대한 예시입니다. 파일을 찾을 수 없다는 404 에러가 뜰 때는 루트 경로로 리디렉션 되도록 지정했습니다.