Amplify vs Vercel vs S3+CloudFront for Next.js Hosting

Choose Vercel when you want every Next.js feature the day it ships and can accept a bill that grows with traffic. Choose AWS Amplify Hosting when billing, IAM, and EU data residency must stay inside AWS and the site is static-heavy with some server rendering. Choose S3 plus CloudFront when the site is genuinely static: it is the cheapest and simplest of the three, and it runs no server code at all. The decision hinges on three questions: how dynamic the site is, where data must live, and whose invoice you want.

How dynamic is your Next.js site, really?

Start by listing the server features you actually use: SSR, ISR, server actions, middleware, on-demand image optimization. A site that uses none of them can be exported as static files and hosted anywhere. A site that uses even one of them needs a runtime, which eliminates plain S3 and CloudFront immediately.

In our experience, this honest audit surprises teams. Marketing sites, documentation, and content sites rebuilt from a CMS are usually static or close to it: we detail that pattern in our guide to migrating WordPress to Next.js. Dashboards, authenticated areas, and personalised pages are not. A quick test: switch the build to a static export and read the error list. That list is your requirements document, written by the framework itself.

What does Vercel do better than the others?

Vercel builds Next.js, so every feature works there first: partial prerendering, server actions, the latest caching semantics, all supported on release day. Preview deployments on every pull request and near-zero configuration make it the strongest developer experience of the three. The trade-offs are cost shape and data residency.

Pricing combines per-seat fees with metered usage: bandwidth, function invocations and duration, and image transformations each sit on their own meter (Vercel's pricing page lists them all). At small scale this is a non-issue; at high traffic the bill climbs along several axes at once, and forecasting it takes real work. On residency, functions can be pinned to EU regions such as Frankfurt or Paris, but Vercel is a US company and parts of the platform operate from the US. A strict EU data requirement deserves a review with your legal team, not an assumption.

When does AWS Amplify Hosting make sense?

Amplify Hosting fits when the rest of your stack already lives on AWS: one invoice, IAM for access control, infrastructure as code alongside your other resources, and deployment in EU regions such as Paris or Frankfurt. It supports Next.js SSR and ISR, with one caveat worth stating plainly: feature lag.

Support for the newest Next.js capabilities has historically trailed Vercel, sometimes by a full version: check the supported features in the Amplify documentation against your Next.js major before committing. The cost shape is AWS-native: build minutes, data served per GB, and SSR requests metered separately (official pricing page). We run production Next.js sites on Amplify Hosting, including the site you are reading, deployed in an EU region with SSR and ISR enabled. For static-heavy sites with some server rendering it has been a stable, unremarkable choice, which is exactly what we want from hosting.

Is S3 plus CloudFront enough for Next.js?

Only if the site is fully static. In static export mode, Next.js produces plain HTML, CSS, and JavaScript that S3 stores and CloudFront serves from the edge. There is no server: no SSR, no ISR, no server actions, no built-in image optimization. Within that limit, it is the cheapest and most boring option available.

// next.config.ts
import type { NextConfig } from 'next';

const nextConfig: NextConfig = {
  output: 'export', // static HTML only: no SSR, ISR, or server actions
};

export default nextConfig;

The cost shape is per-GB storage, per-request pricing, and per-GB transfer, with no compute charge at all; the tiers are on the CloudFront pricing page, and a modest site often stays inside the free tier. The operational cost is yours: cache invalidations, redirects, security headers, and a pipeline that syncs the bucket on every deploy. The Next.js static export documentation lists exactly which features survive the export.

Amplify vs Vercel vs S3+CloudFront at a glance

This table is how we frame the choice with clients: feature coverage decides feasibility, residency decides compliance, cost shape decides the bill at scale, and operations decide who carries the pager. Read the last row first: if one "when it wins" cell describes your situation, start there.

Prices and supported features move; treat the table as a snapshot and verify the two cells that matter most to you before deciding. One hybrid worth knowing: keep the marketing site as a static export behind CloudFront and host the dynamic application separately, on Amplify or Vercel, under its own subdomain. Each part gets the cheapest host that can actually run it.

The decision checklist

Five questions settle most cases:

• Does a static export build cleanly? If yes, S3 plus CloudFront is hard to beat.
• Do you rely on a Next.js feature shipped in the last six months? Verify Amplify support first, or pick Vercel.
• Must data, logs, and processing stay in the EU under agreements you already hold? Amplify in an EU region is the simplest defensible answer.
• Is billing and access governance already consolidated on AWS? Amplify keeps hosting inside it.
• Is developer velocity worth a premium that grows with traffic? That is Vercel's trade, and it is often a good one.

We run this exact audit at the start of every project in our website creation service: static first, then a runtime only where the site earns it.