[AWS] S3를 이용한 정적 웹사이트 호스팅 3. CloudFront, Route 53 연동시키기

 

시리즈 순서

1. S3 정적 파일 올리기

2. Route 53으로 S3 버킷 연동 시키기

3. CloudFront, Route 53 연동시키기

 

Cloud Front란 무엇인가?

Amazon CloudFront는 .html, .css, .js 및 이미지 파일과 같은 정적 및 동적 웹 콘텐츠를 사용자에게 더 빨리 배포하도록 지원하는 웹 서비스입니다. CloudFront는 엣지 로케이션이라고 하는 데이터 센터의 전 세계 네트워크를 통해 콘텐츠를 제공합니다. CloudFront를 통해 서비스하는 콘텐츠를 사용자가 요청하면 지연 시간이 가장 낮은 엣지 로케이션으로 요청이 라우팅되므로 가능한 최고의 성능으로 콘텐츠가 제공됩니다.

 

우리는 ACM과 CloudFront를 생성한 후에 Route53과 연동하는 이 과정을 거칠 것이다. 

 

먼저 ACM에서 SSL 인증서를 생성할 것이다. 우리는 HTTP 뿐만 아니라 HTTPS로도 연결을 허용할 것이므로 그러기 위해서 인증서가 필요하다.

AWS에서는 이러한 인증서를 무료로 생성해 준다. 

 

먼저 인증서 유형을 퍼블릭으로 요청한 후 다음을 누른다.

 

그 다음 자신이 생성했던 Route 53, S3 버킷 이름과 동일하게 도메인 이름을 작성해야 한다. 그 이후 요청을 누른다.

 

 

그러면 이렇게 생성된 것을 볼 수 있다. 상태가 검증 대기중이고 사용중이 아니라고 한다. 

 

생성된 인증서를 클릭해보면 도메인이 검증 대기중이라고 뜬다.

이것을 Route 53에 연동을 시켜야 한다. 그러므로 Route53에서 레코드 생성을 클릭한다.

 

그러면 Route 53 레코드 생성이 가능해진다. 레코드 생성 버튼을 클릭한다. 

 

레코드 생성을 하면 이렇게 상태가 성공으로 바뀌고 발급됨으로 바뀌는 것을 볼 수 있다.

 

이제 해 줄 것은 CloudFront를 만들어서 User들이 S3를 바로 접근하는것이 아닌 CloudFront를 거쳐서 접근하게 만든 후 Route 53과 연동하는 것이다. 

 

CloudFront에 들어간 후 배포 생성을 클릭한다.

 

원본 도메인을 클릭하면 S3를 선택할 수 있다. S3를 선택하면 원본 도메인과 이름이 자동으로 선택된다.

그 다음 S3 버킷 액세스를 OAI 사용으로 해야한다. 그렇지 않으면 버킷을 CloudFront를 거치지 않고도 접근이 가능하므로 우리가 설계하려고 하는 구성에 어긋난다. 그 이후 새 OAI 생성을 누르면 정책이 생긴다.

그 후 버킷 정책에 업데이트 할 수 있도록 버킷 정책 업데이트를 선택한다. 

물론 수동으로 넣을 수 있지만 자동으로 업데이트 하는 것이 훨씬 편하다. 

 

그 이후 Origin Shield는 기본값인 아니요로 놔둔다. 경로 패턴, 자동으로 객체 압축을 모두 기본 값으로 유지한다.

뷰어 프로토콜 정책을 Redirect HTTp to HTTPS로 설정했다. 우리는 ACM에서 인증서 생성을 완료했기 때문에 HTTP보다는 더욱 안전한 HTTPS로 연결을 하게 하려고 설정했다. 

그 이후 HTTP 방법을 선택한다. 

 

그 이후 함수 연결역시 따로 생성한 것이 없으므로 그냥 기본값인 연결 없음으로 놔두면 된다. 

 

가격 분류를 나는 모든 엣지 로케이션으로 선택했지만 사실 자신이 서비스할 국가에 해당하는 엣지 로케이션을 하는 것이 금액적으로 절감이 된다. 그 이후 대체 도메인 이름을 내 S3 버킷과 똑같이 해야한다.  

그다음 사용자 정의 SSL 인증서를 아까 ACM에서 생성했던 인증서를 클릭한다. 

나머지도 기본값으로 놓고 배포를 생성한다.

 

그 이후 Route 53에서 레코드에서 S3로 연동한 것은 삭제한다. 그 이후 레코드 생성을 누른다. 

 

그 다음 Route53에서 S3 레코드를 생성했던 것처럼 진행하면서 트래픽 라우팅 대상만 CloudFront로 바꿔주면 된다. 

 

그럼 세팅은 모두 끝이 난다. 그 다음 접속을 해본다. 

 

그냥 접속해보면 HTTPS로 연결은 잘 됐지만 Deny가 뜬다. 

 

하지만 뒤에 index.html을 붙이니 아까 설정한 파일이 잘 보인다.

도대체 왜 그런 걸까??

 

아마존 공식 문서에는 이렇게나와있다.

CloudFront 기본 루트 객체의 동작은 Amazon S3 인덱스 문서의 동작과 다릅니다. Amazon S3 버킷을 웹 사이트로 구성하고 인덱스 문서를 지정하면 사용자가 버킷의 하위 디렉터리를 요청하더라도 Amazon S3는 인덱스 문서를 반환합니다. (인덱스 문서의 사본은 모든 하위 디렉터리에 있어야합니다.) Amazon S3 버킷을 웹 사이트로 구성하는 방법과 인덱스 문서에 대한 자세한 내용은 Amazon Simple Storage Service 개발자 가이드의 Amazon S3에서 웹 사이트 호스팅 장을 참조하십시오.

 

즉 S3에서 보였다고 CloudFront에서는 똑같이 작동을 안할 수 있다는 것이다. 

 

만약 도메인 뒤에 /index.html을 사용하지 않고 도메인만 클릭해도 index.html을 확인하고 싶으면  CloudFront를 편집하면 된다. 

 

기본값 루트 객체를 index.html로 설정한 후 변경사항을 저장한다.

 

그 전 같은 경우는 도메인을 입력하면 https://(도메인 이름) 이런식으로 바라봤기 때문에 index.html이 바로 뜨지 않고 뒤에 /index.html을 붙여야 화면이 보였다.

그러나 기본값 루트 객체를 선택하면 https://(도메인이름)로 접속해도 바로 index.html이 기본값으로 보여지게 되는 것이다.

 

보면 도메인 뒤에 /index.html이 없지만 내가 설정한 index.html의 화면이 잘 보여지는 것을 확인할 수 있다.

 

그렇다면 만약 다른 index 파일을 다른 파일로 바꾸고 싶으면 어떻게 해야할까? 과연 이게 실시간으로 반영이 될까?

CloudFront로 배포되는 파일은 캐시가 유지되는 시간이 기본 24시간이므로 파일을 새로 올린다 하더라도 계속 예전 파일을 바라보며 오리진 HTTP 헤더의 캐시 설정을 이용해 캐시가 유지되는 시간을 조절을 할 수 있다.

하지만 캐시가 만료되기전 파일을 급하게 바꿔야 한다면 무효화를 사용하면 된다. 

먼저 무효화를 진행하기 위해 index.html을 CloudFront 무효화 Test로 바꿔 주었다.

그 후 S3로 업로드 하였고 그 다음 접속해 보았다. 

하지만 캐시가 만료되지 않았기 때문에 여전히 예전 index.html을 바라보고 있는것을 확인할 수 있다. 

 

내가 생성한 CloudFront에 가서 무효화 탭을 클릭한다. 

그 이후 무효화 생성을 클릭한다.

 

무효화 경로에 /* 라고 작성한다.

이는 하위 모든 폴더나 파일에 적용하기 위해서 작성하는 것이다. 이후 무효화 생성을 클릭한 후 무효화가 완료가 되면

 

무효화를 통해 파일 캐시를 지우고 새로운 index.html을 바라보는 것을 확인할 수 있다.