Introduction

For a Next.js app that truly uses server-side rendering, you need compute that can execute Node.js request handlers, not just static hosting. As of March 11, 2026, the cheapest answer depends on what you mean by cheap: the lowest raw monthly bill is usually a single small server, while the cheapest managed AWS option for small traffic is usually Amplify Hosting compute.

Start by Separating "Cheapest" from "Least Operations"

There are two very different cost targets:

• lowest absolute monthly spend
• lowest spend for a managed deployment with minimal ops work

If you are willing to patch a server, manage process restarts, handle logs, and accept single-instance failure, a tiny VM is usually the cheapest absolute option. On AWS, that typically means Amazon Lightsail or a small EC2 instance.

If you want AWS to handle the SSR hosting layer for you, Amplify is usually the cleanest cost-to-effort choice for small and moderate apps. AWS documents that Amplify Hosting compute supports Next.js SSR, and its pricing includes free monthly SSR request and duration tiers before usage charges start.

Cheapest Absolute Bill: One Small Lightsail Instance

For a low-traffic side project, a single Lightsail Linux instance is usually the easiest way to minimize monthly spend. AWS currently advertises a $5 / month Linux bundle with 1 GB memory, 1 vCPU, 40 GB SSD, and 2 TB transfer on its pricing page.

A simple deployment shape is:

• build the app once
• run next start behind a process manager such as pm2
• optionally place Nginx in front for TLS termination and caching

Minimal scripts in package.json:

1{
2  "scripts": {
3    "build": "next build",
4    "start": "next start -p 3000"
5  }
6}

That is cheap because you pay for one always-on machine and nothing more. The tradeoff is operational burden. You own patching, monitoring, restarts, scaling, backups, and the consequences of that single instance going down.

Cheapest Managed Default: Amplify Hosting Compute

If you want the platform to understand Next.js SSR directly, Amplify is the most practical managed default on AWS today. AWS documents that Amplify Hosting compute supports Next.js versions 12 through 15, and its deployment flow detects an SSR app from the build script.

A minimal amplify.yml for SSR looks like this:

1version: 1
2frontend:
3  phases:
4    preBuild:
5      commands:
6        - npm ci
7    build:
8      commands:
9        - npm run build
10  artifacts:
11    baseDirectory: .next
12    files:
13      - '**/*'
14  cache:
15    paths:
16      - node_modules/**/*

That baseDirectory: .next detail matters for SSR builds.

Cost-wise, Amplify is attractive at the low end because AWS currently lists these monthly SSR free-tier allowances on the pricing page:

• up to 500,000 SSR requests
• up to 100 GB-hours of SSR duration

After that, pricing is usage-based. For small personal or internal apps, this often lands cheaper than keeping a traditional always-on EC2 plus load balancer stack running full time.

Why Elastic Beanstalk Is Not Usually the Cheapest Here

Elastic Beanstalk has no separate service fee, but AWS states that you still pay for the underlying resources you run. For a Next.js SSR app, that normally means at least an EC2 instance and often load-balancing or other supporting infrastructure.

That can still be a valid option if you want more direct server control than Amplify gives you. It is just not usually the cheapest answer for a small SSR app once you factor in always-on compute.

A Practical Decision Rule

Use this simple rule:

• choose Lightsail if you want the lowest monthly bill and can operate a server
• choose Amplify if you want the lowest-ops managed SSR setup on AWS
• choose Elastic Beanstalk or App Runner only if you specifically need their deployment model or runtime controls

For many small hobby or MVP projects, the real budget killer is not request volume. It is paying for infrastructure that stays up all month whether anyone visits or not.

Common Pitfalls

The most common mistake is treating a true SSR Next.js app like a static React build. Static export can be hosted almost anywhere cheaply, but SSR needs runtime compute.

Another mistake is picking EC2 or Elastic Beanstalk because there is "no extra service fee" while overlooking the cost of the underlying always-on instance, storage, logs, and possibly a load balancer.

A third problem is optimizing only for cloud cost and ignoring operations cost. A $5 instance is cheap on paper, but not if downtime, patching, or manual deployments become expensive in developer time.

Summary

• As of March 11, 2026, the cheapest absolute AWS option for low-traffic Next.js SSR is usually one small Lightsail or EC2 instance
• The cheapest managed AWS default is usually Amplify Hosting compute for small SSR apps
• Amplify currently supports Next.js SSR and includes monthly free usage for SSR requests and duration
• Elastic Beanstalk has no extra service fee, but you still pay for the always-on AWS resources underneath it
• Pick based on both cloud bill and operational effort, not just sticker price