여태까지 프로젝트들을 모두 vercel로만 배포해봤기에
이번 사이드 프로젝트는 AWS로 배포해보기로 도전~!!
우선 AWS로 리액트 배포하기 검색했을 때 제일 많이 나오는 방법이 EC2 아니면 S3였다.
이 둘의 차이점이 뭘까 여기저기 검색해 본 정보를 간단하게 공유해보겠다.
| 특성 | EC2 | S3 |
| 배포 방식 | 서버 기반 애플리케이션 운영 | 정적 웹 애플리케이션 호스팅 |
| 비용 | 사용 시간에 따라 비용 발생, 상대적으로 높음 | 저장 공간과 요청량에 따라 비용 발생, 상대적으로 저렴 |
| 유지 보수 | 서버 관리 필요 | 별도 관리 필요 없음 |
| 사용 사례 | SSR 및 백엔드 통합이 필요한 경우 | SPA와 정적 사이트 호스팅 |
| 성능 | 서버 리소스 기반, 확장성 있음 | 정적 파일 제공, CloudFront 사용 시 성능 최적화 가능 |
백엔드분들은 Spring 을 사용하고, EC2로 이미 배포를 해둔 상태이다. 이걸 기반으로 차이를 알아보자면.
EC2
- 구성 방식: 백엔드와, 프론트엔드를 동일한 EC2 서버에서 운영하거나 , 백엔드는 EC2, 프론트는 Nginx 등으로 정적 파일을 서빙하는 방식
- 장점
- 통합 관리 가능 : 프론트랑 백엔드를 같은 인스턴스에서 관리할 수 있어 배포 과정이 단순하다.
- 네트워크 통신 최적화 : 같은 서버에서 통신하기 때문에 프론트엔드와 백엔드 간 네트워크 지연을 최소화 할 수 있다.
- 단점
- 서버 리소스 관리 필요 : 서버 리소스가 제한적이기 때문에 많은 트래픽이 발생하면 서버 성능이 영향을 받을 수 있다. 트래픽이 집중될 경우 프론트와 백엔드가 동일한 리소스를 공유하기 때문에 성능 저하가 생길 수 있다.
- 스케일링 제한 : 프론트와 백엔드의 성능 요구 사항이 다를 수 있는데, EC2인스턴스 하나에서 처리하다 보면 스케일링이 제한될 수 있다. 트래픽이 증가할 때 유연하게 확장하는 데 어려움이 있을 수 있다.
- 추천 상황
- 트래픽이 적고 작은 규모의 프로젝트
- 프론트엔드와 백엔드의 배포 주기가 비슷한 경우
- 네트워크 통신이 빠르고 통합 관리가 필요한 경우
S3+CloudFront
- 구성 방식: React 애플리케이션은 S3와 CloudFront를 통해 정적 파일로 배포하고, 백엔드는 EC2나 다른 서버에서 REST API를 제공하는 방식
- 장점
- 비용 절감 및 성능 향상 : 프론트엔드 정적 파일을 S3와 CDN인 CloudFront를 사용해 전 세계적으로 캐시해두면, 사용자는 자신의 위치에 가까운 CDN 서버에서 정적 파일을 받아 빠르게 사이트를 이용할 수 있다.
- 유연한 확장성 : 프론트와 백엔드를 분리하여 트래픽에 따라 각기 독립적으로 확장할 수 있다. 백엔드의 성능이 필요할 때는 EC2 서버를 스케일링 하고, 프론트의 성능이 필요할 때는 CDN을 통해 안정적인 트래픽 분산이 가능하다.
- 배포 간편화 : S3에 업로드 하면 배포가 완료되므로 유지 보수가 매우 간단하고, 프론트와 백엔드의 배포 주기를 독립적으로 가져갈 수 있다.
- 단점
- CORS 설정 필요 : 프론트가 백엔드가 다른 도메인에 위치하므로 CORS(Cross-Origin Resource Sharing) 설정이 필요하다. Spring에서 CORS 설정을 올바르게 해야 브라우저에서 API 요청이 정상적으로 작동한다.
- 네트워크 요청 지연 가능성 : 프론트엔드와 백엔드 서버가 물리적으로 분리되어 있어, API 호출 시 네트워크 지연이 발생할 수 있다. 특히, 프론트와 백엔드 서버의 물리적 위치가 멀다면 지연이 커질 수 있다.
- 추천 상황
- 트래픽이 많고 글로벌 사용자를 대상으로 하는 경우
- 프론트와 백엔드의 배포 주기가 다르거나 독립적으로 관리하고 싶은 경우
- 성능 최적화가 중요한 경우, 특히 정적 리소스를 빠르게 로드해야 하는 경우
우선 우리 프로젝트에서는 백엔드와 프론트의 배포 주기가 다르고, 사이드 프로젝트를 포폴용으로 개발중이기 때문에 비용 절감과, 배포가 간편하다는 점을 고려하여 S3 + CloudFront 방식으로 배포를 해보려고 한다.
배포 과정은 다음 글에 정리해두겠다. !