Next.js 배포할 때, CloudFront + S3 vs ECS 뭐가 다를까?

Next.js 프로젝트를 AWS에 배포할 때 고려해야 할 점.

첫번째. CloudFront + S3

S3는 AWS에서 제공하는 객체 스토리지 서비스로 배포방식은 Next.js 프로젝트를 npm run build 후 생성되는 결과물 폴더를 그대로 업로드 하여 생성된 주소로 접근하는 것이다.

하지만 이 방식은 Next.js의 SSR기능을 사용할 수 없다.
S3로 배포할때는 반드시 CSR 즉, 정적인 사이트로 만들어졌을때만 유용하다는 점.

그렇다면 굳이 Next.js 프로젝트를 S3로 배포할 큰 이유가 없어 보인다. React 프로젝트에 적합한듯

두번째. ECS
결국 Next.js의 온전한 기능을 살려 배포하려면 ECS가 최적이다.

(vercel은 운영으로 가져가기엔 너무 비쌈, 무료버전 또는 MPV 단계에서 적합

AWS Amplify도 많이 쓴다고 해서 찾아봤는데, 워드프레스가 AWS로 진화한 느낌...
)

아래 글은 제가 작성한 글을 바탕으로 ChatGPT에서 수정을 요청한 글입니다. 가독성을 위해 함께 첨부합니다!

Next.js 배포할 때, CloudFront + S3 vs ECS 뭐가 다를까?

Next.js로 만든 프로젝트를 AWS에 배포하려고 할 때, 가장 먼저 고민하게 되는 건 어떤 방식으로 배포할 것인가입니다. 대표적인 두 가지 방법을 비교해보며 어떤 선택이 적절한지 정리해봤습니다.

1. CloudFront + S3

S3는 AWS에서 제공하는 객체 스토리지 서비스로, 정적인 파일을 저장하고 서빙하는 데 최적화되어 있습니다. Next.js 프로젝트를 npm run build 한 후 생성된 out 폴더(혹은 .next → HTML export된 결과)를 S3에 업로드하고, CloudFront를 통해 CDN으로 배포하는 방식입니다.

장점:

비용이 저렴하다.
정적인 웹사이트(CSR 또는 SSG)에 적합하다.
배포가 간단하고 빠르다.

단점:

Next.js의 핵심 기능 중 하나인 SSR(Server-Side Rendering) 을 사용할 수 없다.
동적인 라우팅, API Routes 등 서버 기능을 쓸 수 없다.

즉, 이 방식은 사실상 Next.js를 정적 사이트 생성기(Static Site Generator) 로만 활용할 수 있을 때 의미가 있습니다. 그래서 엄밀히 말하면, React 프로젝트(또는 Next.js의 SSG만 사용하는 경우)에 더 적합한 배포 방식입니다.

2. ECS (Elastic Container Service)

Next.js의 SSR이나 API Routes 같은 서버 기반 기능까지 온전히 활용하고 싶다면 ECS가 좋은 선택입니다.

Next.js를 Docker 컨테이너로 감싸서 ECS에서 실행하면, Next.js의 모든 기능(SSR, API, ISR 등)을 사용할 수 있습니다.

장점:

SSR, API Routes, ISR 등 Next.js의 서버 기능을 전부 지원한다.
확장성과 유연성이 높아 대규모 트래픽 대응이 가능하다.

단점:

초기 설정이 복잡하고 인프라 지식이 필요하다.
비용이 상대적으로 높다.

특히 운영단계에서 인프라 제어권이 중요한 경우(트래픽 최적화, 로깅, 보안 설정 등), ECS는 매우 강력한 선택지입니다.

그 외 고려해본 옵션들

Vercel
Next.js의 공식 배포 플랫폼답게 가장 간편하고 기능이 풍부합니다. 다만 유료 요금제가 비싸기 때문에 MVP 단계나 개인 프로젝트에서는 무료 요금제가 적합하지만, 상용 서비스 운영에는 비용 부담이 큽니다.
AWS Amplify
프론트엔드 배포와 CI/CD에 특화되어 있지만, 서버 렌더링보다는 정적 배포에 적합한 구조입니다. 개인적으로는 "AWS판 워드프레스" 같은 느낌이 들기도 했습니다.