s3로 배포했을 경우) root 주소 말고 다른 주소로 들어가서 새로고침시 403 error 뜰때

> 이슈

CloudFront를 거쳐 AWS S3에 static web hosting으로 배포한 회사 웹페이지를

 

google search console에서 각 라우터마다 URL 테스트를 했을때 아래 이미지와 같은 403 에러가 발생했다.

 

예시) /about 페이지

> 원인

처음에는 S3에 "/"로 접근하지 않는 다른 URL을 차단하는 설정이 되어있는 것으로 생각했지만

  "/"를 제외한 URL을 막는 설정은 없었다.

 

구글링을 통해 알게된 사실은

CSR로 하게되면 해당 URL에 파일이 없어서 에러가 나니까

이 때 에러를 "/"로 전달하게 하면 된다는 내용이었다. 

 

우리가 개발하고 있는 Web App에는 Route마다 보여야 하는 페이지가 다를 수 있는데,

만약 /about라는 Route가 존재한다고 하면

현재 상태에서 해당 Route로 접근 시 에러가 발생하게 된다는 것이다.

내가 react-router-dom 등을 이용하여 앱 내부적으로 Route를 나누었어도 실제로는 제대로 동작하지 않는다!

 

아래와 같이 실제로 해당 Route에 들어가서 새로고침 했을 때

네트워크 도구에서 403 에러가 발생하는 것을 확인할 수 있었다.

예시) /about 페이지

 

에러의 이유는 바로 Cloudfront가 about라는 파일을 찾아 유저에게 전달하려고 하기 때문이라고 한다.

 

Cloudfront는 단순히 S3의 Object들을 유저에게 가장 가까운 Edge에 Caching 해두어

요청이 왔을 때 보다 빠르게 Object를 전달해주기 위해 만들어진 서비스이기 때문이다.

 

즉, 에러가 났을 때도 index.html로 접근 할 수 있도록 설정해 주어야 한다!

이러한 설정은 CloudFront의 Error pages 설정을 가지고 해결 할 수 있다.

 

서버에 정해진 File이 존재하지 않을 때 발생하는 Error인 403 Forbidden의 response로

index.html을 대신 전달하게 하면 문제를 해결 할 수 있다.

 

> 해결

CloudFront > 배포 > 오류페이지 > "사용자 정의 오류 응답 생성"을 클릭

 

아래과 같이 설정 후에 생성을 눌러준다.

반영되는 시간이 조금 걸리니 일정 시간이 흐른 후 /about에 다시 접근해 보도록 하겠다.

 

 

설정 후 해당 Route에서 다시 새로고침시 Error가 뜨지 않고 제대로 Rendering 되는 모습을 볼 수 있다!

"/"을 제외한 모든 Route에서 전부 에러가 사라진 것을 확인하였다.

 

 

[참고 URL]

https://blog.pkiop.me/aws-s3-static-distribution-access-denied/

https://blog.dramancompany.com/2019/09/aws%EB%A1%9C-%EC%84%9C%EB%B2%84-%EC%97%86%EC%9D%B4-%EC%9B%B9-%EC%84%9C%EB%B9%84%EC%8A%A4-%EC%9A%B4%EC%98%81%ED%95%98%EA%B8%B0-1/