SPA 공개 시의 S3+CloudFront와 S3의 차이

introduction

React로 만든 싱글 페이지 애플리케이션(SPA)을 공개할 때는 CloudFront+S3이 많다. 이 구성은 React의 거동에 얼마나 Critical인지 궁금했기 때문에 실제로 SPA를 호스팅해 보았다. 그 조사 · 작업 Log.

CloudFront+S3의 경우에 신경이 쓰인 결과는 없었기 때문에, S3만으로의 호스팅을 중심으로 정리한다.

AWS 서비스

S3: 스토리지 서비스. HTML을 업로드하여 호스팅을 할 수 있습니다.
CloudFront: 콘텐츠 전송 서비스. 여기를 통해 S3에 액세스 할 수 있습니다.

준비

react-router-dom의 QuickStart 에서 페이지 전이가 있는 React SPA를 작성.

1의 SPA를 build한 것을, 공개하는 S3 버킷에 업로드.

S3을 관리 콘솔에서 구성.

CloudFront를 관리 콘솔에서 구성.

AWS 설정은 참고 문헌을 처음으로 다양한 기사가 있으므로 생략.

S3에서 라우팅 설정

SPA의 호스팅 문제로 라우팅에서 path가 변경된 후 다시 로드하면 그대로 404가 되어 버리는 문제가 있는 것 같다.
CloudFront에서는, 에러시의 리디렉션으로 해결하고 있었지만, S3에서도 같은 설정을 실시할 수 있다.


이것으로 해결할 수 있을지 어떨지를 검증.

결과

S3만으로도 SPA의 거동에 문제는 없었다고 생각한다.
궁금한 점은, 에러의 리디렉션시에 404가 돌아 버리기 때문에, statusCode를 사용해 제어하고 있는 경우는, 의도하지 않은 거동이 될지도 모른다.

할 수있는 일

SPA 라우팅을 확인할 수 있었다.

리로드시에, 리로드했을 때의 path로 이동할 수 있다.

할 수 없었던 것

https는 할 수 없다. ( S3 공식 Document , SSL은 지원하지 않습니다.)

오류 리디렉션 중에 404로 남아 있습니다. CloudFront의 경우는 200으로 바꿀 수 있다.

S3의 리다이렉트 룰을 이용하는 경우, 리로드시에 index.html로 이동해 버린다.

이용한 S3의 리디렉션 규칙은 다음과 같습니다.

[
    {
        "Condition": {
            "HttpErrorCodeReturnedEquals": "404"
        },
        "Redirect": {
            "HostName": "HOST_NAME",
            "Protocol": "http",
            "ReplaceKeyWith": "index.html"
        }
    }
]

도전

미확인

API를 호출했을 때의 거동은 미확인.

state의 보존등에 대해서는 미확인.

위의 내용은 S3과 CloudFront에서 할 수 있는 것에 차이가 없다고 생각하기 때문에 아마 문제는 없다.

지식 부족

S3에 대한 액세스 권한. 이번에 실시한 버킷 정책(꽤 느슨한)으로, 보안상 문제가 없는 것인가라고 하는 것.

http에서는 왜 안 되는가. http/https의 기초 지식.

S3에 접근하는 방법. REST API 엔드포인트와 웹사이트 엔드포인트의 주요 차이점.

감상

스스로 만든 SPA를 공개한다면, S3에서도 할 것 같다.
한편, Amprify를 사용하는 것이 간단한 느낌도하고 있기 때문에, 어떻게 할까라고 하는 기분.

참고문헌

S3 전용입니다. 생각했던 작업 방침으로 할 수 있다는 것은 아래의 기사에서 알았습니다.
또한 SPA의 호스팅에서 리로드 이외에 문제가 되는 점이 다른 일이 될 것 같은 것을 파악할 수 있었습니다.



CloudFront 사용의 경우. 클래식 구성을 위해 여러 가지가 있지만, CloudFront의 설정은 아래의 기사를 참고로 했습니다.