How to Deploy a Next.js App on AWS in 2026: A Practical Guide

TL;DR

• For most teams, AWS Amplify Hosting is the simplest and fastest way to get a Next.js app on AWS. Connect a Git repo, Amplify auto-detects Next.js, and it builds, deploys, and serves SSR, SSG, ISR, App Router, middleware, and image optimization on AWS-managed compute with built-in CI/CD. It supports Next.js versions 12 through 15, charges pure pay-as-you-go ($0.01 per build minute, $0.15 per GB served, $0.023 per GB stored, plus SSR request and duration fees), and has no per-seat cost.
• If you want lower cost at scale, full control, and the complete Next.js feature set (including on-demand ISR and streaming, which Amplify does not support), use OpenNext + SST, which packages Next.js onto Lambda + CloudFront + S3 with DynamoDB and SQS for ISR and revalidation. For maximum control or existing container infrastructure, run Next.js in standalone or Docker mode on ECS Fargate. AWS App Runner stops accepting new customers on April 30, 2026, and AWS now points new users to ECS Express Mode. For fully static sites, export to S3 + CloudFront.
• The reason none of this is one-click like Vercel: Next.js bundles many server-dependent features (SSR, React Server Components, the App Router, API routes, ISR, middleware, image optimization, streaming) that each need specific compute and caching infrastructure. On AWS you must either use a managed service (Amplify) or an adapter (OpenNext) to map those features onto AWS primitives.

Why Next.js on AWS is not trivial

Vercel built Next.js, and Vercel's platform is purpose-built to run every Next.js feature with zero configuration. Next.js is not just a static site generator. It is a full-stack framework whose features each have different runtime requirements:

• Static Site Generation (SSG) produces HTML at build time (just files to serve).
• Server-Side Rendering (SSR) and React Server Components / the App Router render HTML on a server per request, which needs live compute.
• API routes are server endpoints that need compute.
• Incremental Static Regeneration (ISR) regenerates static pages in the background on a schedule (revalidate) or on demand, which needs a shared, durable cache plus a mechanism to trigger and store regenerations.
• Middleware runs logic before requests resolve, often at the edge.
• Image Optimization (next/image) resizes and encodes images on demand, which needs a compute function (and the Sharp library).
• Streaming sends HTML in chunks as it renders.

Vercel maps all of this onto its own infrastructure automatically. AWS gives you raw primitives (Lambda, CloudFront, S3, DynamoDB, SQS, ECS, and so on) but does not, by itself, know how to translate "this is an ISR page" or "this is a server component" into the right service wiring. So on AWS you either (a) use a managed service that does the mapping for you (Amplify Hosting), (b) use an adapter that maps it and hands artifacts to your IaC (OpenNext), or (c) run the whole Next.js Node server yourself in a container and accept its single-instance assumptions. The official Next.js self-hosting docs confirm that with next start, image optimization and ISR work with zero configuration on a single instance, but caching breaks down across multiple replicas unless you configure a custom cache handler.

As of June 2026, the current Next.js major is Next.js 16 (16.2 shipped March 18, 2026; the latest patch is 16.2.6, shipped May 7, 2026). Next.js 16 renamed middleware to proxy (running on the Node.js runtime) and introduced Cache Components with the "use cache" directive. Importantly, Next.js 16.2 shipped a stable Adapter API built with OpenNext, Netlify, Cloudflare, AWS Amplify, and Google Cloud, so platforms no longer need to reverse-engineer the build output. New first-party adapters for AWS, Cloudflare, and Netlify are in active development on top of this API and are expected later in 2026. This piece is the technical follow-up to our AWS for non-technical founders guide; if you want the platform context before diving into Next.js specifics, start there.

The four main deployment options at a glance

Option 1: AWS Amplify Hosting (the recommended default)

What it supports. Amplify Hosting compute fully manages SSR for apps built with Next.js versions 12 through 15. AWS states Amplify "supports Next.js 15 applications without the need for an adapter." Per the supported features docs, supported items include: SSR pages, static pages, API routes, dynamic and catch-all routes, SSG, ISR, i18n routing (sub-path, domain, automatic locale detection), middleware, environment variables, image optimization, the Next.js 13-plus app directory, and Edge API routes. Image optimization works out of the box on Next.js 13-plus (Amplify deploys Sharp for you), with a maximum optimized image output size of 4.3 MB.

Step-by-step deployment. Per AWS's deploy guide:

1. Push your Next.js app to GitHub, GitLab, Bitbucket, or AWS CodeCommit.
2. Open the Amplify console, choose Deploy an app, pick your Git provider, and authorize access.
3. Select the repository and branch. Amplify automatically detects a Next.js SSR app (it inspects the build script in package.json: next build signals SSG + SSR).
4. Amplify generates build settings, or you provide an amplify.yml. For SSR or hybrid apps the build output directory (baseDirectory) is .next. Example:

   version: 1
   frontend:
     phases:
       preBuild:
         commands:
           - npm ci
       build:
         commands:
           - npm run build
     artifacts:
       baseDirectory: .next
       files:
         - '**/*'
     cache:
       paths:
         - node_modules/**/*

5. Amplify requires an IAM service role to deploy SSR resources on your behalf (it provisions S3, CloudFront, Lambda@Edge, and an SQS queue if using ISR). Choose "Create and use a new service role."
6. Set environment variables in the console.
7. Add a custom domain with a free managed SSL certificate. Use branch-based deployments and PR previews for staging and review environments.

Pricing (confirmed). Per the Amplify pricing page, pay only for what you use, no per-seat fees:

• Build and deploy: Standard instance (8 GB / 4 vCPU) is $0.01 per build minute (first 1,000 minutes a month free). Large (16 GB / 8 vCPU) is $0.025 per minute. XLarge (72 GB / 36 vCPU) is $0.10 per minute.
• Data storage: $0.023 per GB per month (first 5 GB free).
• Data transfer out: $0.15 per GB served (first 15 GB free).
• SSR request count: $0.30 per 1M requests (first 500,000 a month free).
• SSR request duration: $0.20 per GB-hour (first 100 GB-hours a month free).
• Optional WAF: $15 a month per app plus WAF usage.

AWS's own worked examples on the pricing page: a 5-developer team with 300 daily active users committing twice a day (about 600 build minutes a month) has estimated total monthly charges of $8.08. A higher-traffic app (10,000 daily active users, about 440 GB served, 2 updates a month) has estimated total monthly charges of $65.98, dominated by data transfer.

Known limitations (per the Amplify SSR troubleshooting docs): On-Demand ISR is not supported. Next.js streaming is not supported. Edge middleware is not supported (only Edge API routes). Running middleware on static assets and optimized images is not supported. unstable_after is not supported. Build output for SSR apps is capped at 220 MB and the maximum SSR HTTP response size is 5.72 MB (larger responses return 504s). With next/image, images served via the Lambda@Edge path can hit a 1 MB response limit returning 503s. CloudFront limits accounts to 25 distributions with attached Lambda@Edge functions. Amplify is also closed-source, so deep issues may require an AWS support ticket. Re-verify Next.js 16 support before relying on it, since AWS docs as of mid-2026 still state support "up through Next.js 15."

When to choose Amplify: you want the fastest path to production on AWS, Git-based CI/CD, preview environments, and you do not depend on on-demand ISR, streaming, or edge middleware. If the bottleneck on your existing setup is performance and SEO, the same Core Web Vitals logic from our Next.js vs WordPress SEO guide applies regardless of which AWS path you pick.

Option 2: OpenNext + SST (the serverless power path)

What OpenNext is. OpenNext is an open-source Next.js adapter, maintained by the SST team, that takes the Next.js build output and converts it into packages deployable to AWS (and now Cloudflare, Netlify, and a plain Node server). It started in 2023 as an AWS Lambda adapter, and OpenNext V3 (May 2024) turned it into a multi-platform project. It "aims to support all Next.js 15 features," with Next.js 16 support landing in recent releases. The current package is @opennextjs/aws, latest version 4.0.2 (renamed from open-next in version 3.1.4). Source on GitHub.

How it maps Next.js to AWS. Per the OpenNext architecture docs, open-next build runs next build then emits a .open-next/ folder. The architecture provisions:

• Server function (Lambda): handles SSR, ISR, SSG, and API requests by wrapping Next.js's standalone NextServer.
• Image optimization function (Lambda): handles next/image requests using the bundled Sharp library (compiled for arm64 by default).
• Revalidation function (Lambda): polls a FIFO SQS queue and sends HEAD requests to revalidate routes.
• Warmer function (Lambda, optional): invoked on an EventBridge schedule (for example, every 5 minutes) to reduce cold starts.
• Static assets on S3, served via CloudFront, which routes static paths to S3 and dynamic paths to the server Lambda's function URL.
• ISR / cache: OpenNext's docs state, "By default we use S3, DynamoDB and SQS for handling ISR/SSG and the fetch cache." S3 holds the incremental and fetch cache (HTML, RSC, JSON), DynamoDB holds the tag cache (revalidateTag and revalidatePath), and SQS (FIFO) is the revalidation queue.

Deploying with SST. OpenNext does not create infrastructure. You use SST, AWS CDK, Terraform, or Serverless Framework. The easiest path is SST's sst.aws.Nextjs component (SST v3, "ion"), which "uses OpenNext to build your Next.js app, and transforms the build output to a format that can be deployed to AWS." Practical steps per the SST quickstart:

1. Configure AWS credentials (aws configure).
2. In your Next.js app: npx sst@latest init (SST detects Next.js).
3. SST generates sst.config.ts. Add the Nextjs component (and link resources like S3 buckets and secrets).
4. npx sst deploy --stage production. SST provisions CloudFront, the Lambda functions, S3, DynamoDB, and SQS, and returns a CloudFront URL.

SST manages custom domains on Route 53, Cloudflare, and Vercel automatically. For other DNS providers you supply an ACM cert. Note that CloudFront requires the ACM certificate in us-east-1, which SST handles for you. SST's exposed nodes confirm the mapping: nodes.server (Lambda renderer), nodes.revalidationQueue (SQS), nodes.revalidationTable (DynamoDB), and nodes.assets (S3). SST v3 is built on Pulumi and Terraform providers under the hood. As an alternative IaC, AWS CDK can wire the same .open-next artifacts (community constructs like cdk-nextjs exist).

Cost model. Pay-per-use serverless: Lambda invocations and duration, CloudFront data transfer and requests, S3 storage, DynamoDB, and SQS. It scales to near-zero at low traffic and is frequently far cheaper than Vercel at scale. Independent practitioner reports claim large savings at scale (one guide cites "80-95% cost savings at scale" for SaaS apps moving off Vercel Pro), but these are vendor and blog estimates, not guarantees. Actual costs depend heavily on traffic shape, region, and feature mix. The honest framing: you trade Vercel's premium and per-seat pricing for raw AWS pricing plus your own ops time. The same cost-vs-control trade-off shows up on the tooling side in our Claude Code small-team pricing piece.

When to choose OpenNext + SST: you want the full Next.js feature set (including on-demand ISR and streaming), cost efficiency at medium-to-high or spiky traffic, data residency or compliance in your own AWS account, and you have (or can build) some AWS and IaC capability. The main downsides are setup complexity, Lambda cold starts (mitigable with the warmer function or provisioned concurrency), and the need to keep OpenNext versions in sync with Next.js releases.

Option 3: Containers on ECS Fargate (the full-control path)

Standalone output plus Dockerfile. Set output: 'standalone' in next.config.js. Next.js traces dependencies and emits a minimal self-contained server in .next/standalone (run with node server.js). The official Next.js deploying docs confirm standalone Docker output as a first-class deployment mode that supports all Next.js features. A typical multi-stage Dockerfile uses a deps then builder then runner pattern on node:20-alpine, copying .next/standalone, .next/static, and public, running as a non-root user, and exposing port 3000.

Deploying to ECS Fargate. Push the image to Amazon ECR, define an ECS task (for example, 512 CPU units / 1 GB memory), create a Fargate service in a cluster, and put an Application Load Balancer in front (with an ACM cert for HTTPS), optionally CloudFront in front of the ALB. App Runner was historically the simplest "give it an image, get a URL" option, but per the App Runner availability notice it "will no longer be open to new customers starting April 30, 2026," and AWS "recommend[s] that customers explore Amazon Elastic Container Service (Amazon ECS) Express Mode when migrating from AWS App Runner."

ECS Express Mode provisions a Fargate service, a shared ALB with SSL, auto scaling, and a URL from just a container image at no additional charge (you pay only for the underlying resources). It is Fargate-only and does not support blue/green deployments. AWS positioned the launch in a 2025 announcement.

ISR caveat for containers. Running multiple container replicas breaks Next.js's default filesystem ISR cache. You need a shared cache (a custom cacheHandler, for example Redis or @neshca/cache-handler) so all instances stay consistent. This is the single biggest gotcha with the container path.

When to choose containers: you already run containers, want predictable always-on performance with no cold starts, need full control over networking and compliance, and have DevOps capacity. Do not start new projects on App Runner given the April 30, 2026 cutoff.

Option 4: Static export to S3 + CloudFront

For a fully static Next.js site, set output: 'export' (and images: { unoptimized: true }, since on-demand image optimization is unavailable in static export). next build produces an out/ folder of HTML, CSS, and JS. Host it on a private S3 bucket (blocked public access), serve it through CloudFront with Origin Access Control, add an ACM cert and Route 53 record for your domain, and sync with aws s3 sync out/ s3://BUCKET --delete plus a CloudFront invalidation. This is the cheapest and simplest option, but it supports no SSR, API routes, or server features.

A common gotcha is routing: direct navigation to routes can 404 or 302 unless you set trailingSlash, use folder-style output, or add a small CloudFront Function or Lambda@Edge to rewrite URLs. Choose this only for truly static content (marketing sites, docs, blogs without server features). The same "start static if you can" logic shows up in our WordPress vs custom build guide.

Head-to-head comparison

All cost figures are estimates except the confirmed Amplify and CloudFront list prices cited above. Model your own workload with the AWS Pricing Calculator before committing.

Prerequisites and general steps

Before deploying, you need:

• An AWS account.
• Node.js 20-plus. AWS ended support for Node 14, 16, and 18 in Amplify builds after September 15, 2025, and Next.js 16.2 targets Node 20.9-plus.
• A working Next.js app in a Git repo.
• The AWS CLI configured with credentials (for the SST, CDK, or container paths).
• A domain if you want a custom URL, plus an ACM certificate (which for CloudFront must be in us-east-1).

Preparation: decide your output mode (standalone for containers, export for static, default for Amplify), externalize configuration into environment variables, and make sure your build and start scripts are correct. The same scoping discipline we cover in our web app design contract questions guide applies to the deployment scope itself: agree on the path before you spend a sprint on it.

Decision framework: which path to pick

• Choose Amplify if you want the fastest, lowest-ops path, Git-based CI/CD, and preview environments, and you do not need on-demand ISR, streaming, or edge middleware.
• Choose OpenNext + SST if you need the full Next.js feature set, want serverless cost efficiency and scale-to-zero, want to own the infrastructure in your AWS account (compliance, data residency, no lock-in), and can handle some IaC.
• Choose containers (ECS Fargate or Express Mode) if you already run containers, want predictable always-on performance with no cold starts, or need deep networking and compliance control.
• Choose static export to S3 + CloudFront if your site is fully static with no server features.

Quick checklist:

1. Does the app use SSR, API routes, or other server features? If no, use static export to S3 + CloudFront. If yes, continue.
2. Do you need on-demand ISR, streaming, or edge middleware? If yes, use OpenNext + SST or containers (not Amplify).
3. Do you want minimum ops and built-in CI/CD? If yes, use Amplify.
4. Do you have AWS and IaC capability and want cost efficiency at scale or full control? If yes, use OpenNext + SST.
5. Do you already run containers or need always-on, no-cold-start performance? If yes, use ECS Fargate or Express Mode.

Common pitfalls and best practices

• ISR and caching across instances. The default filesystem cache breaks with multiple replicas (containers). Use a shared cache handler (Redis or @neshca/cache-handler). OpenNext solves this with S3 + DynamoDB by default.
• Cold starts on Lambda paths. Per the AWS Compute Blog, cold starts typically occur in under 1% of invocations, and AWS Lambda docs note a cold start's duration "varies from under 100 ms to over 1 second." They can spike during bursty traffic. Mitigate with OpenNext's warmer function, provisioned concurrency (priced at memory times concurrency times hours, billed whether used or not), smaller bundles, and arm64. Do not over-provision. Teams routinely overspend on provisioned concurrency for a problem that monitoring shows is small.
• Image optimization costs and limits. Amplify caps optimized image output at 4.3 MB and Lambda@Edge image responses at 1 MB. OpenNext runs Sharp on Lambda. Consider a custom loader or external CDN for heavy image workloads.
• Data transfer and CloudFront costs. Data transfer out is usually the biggest line item. Per the CloudFront pricing page, the first 1 TB a month is free, then US and Europe data transfer out starts at $0.085 per GB (next 9 TB), with HTTPS requests at $0.0100 per 10,000 (HTTP $0.0075 per 10,000). APAC and South America cost more. Data from AWS origins (S3 or ALB) to CloudFront is free. Use Price Classes to limit edge regions if your audience is regional, and set aggressive cache headers. Amplify charges $0.15 per GB served.
• Environment variables and secrets. Never commit secrets. .env.local does not exist on Lambda. Use SST Secrets (SSM parameters), AWS Secrets Manager, or Amplify console env vars.
• Region selection. Pick one primary region and stay consistent. Remember the CloudFront ACM cert must live in us-east-1.
• Monitoring and budgets. Use CloudWatch (Amplify and OpenNext both emit logs) for INIT duration, p99 latency, and errors. Set AWS Budgets with alerts at 80% and 100% of expected spend. The same day-one discipline applies to any AWS workload, as we covered in our AWS for founders guide.
• CI/CD. Amplify is built-in. For SST and containers, use GitHub Actions with OIDC (assume-role) rather than stored access keys.
• Version skew. Rolling deployments can break Server Actions ("Failed to find Server Action") unless you keep a consistent encryption key per environment and a shared, persisted cache. Keep OpenNext in sync with your Next.js version.
• Understand what runs underneath. Amplify and OpenNext both abstract S3, CloudFront, and Lambda, but when something breaks you will debug those services directly. Know the architecture.

How Brandrums recommends choosing

Step 1: start with Amplify Hosting for your first AWS deployment unless you have a hard requirement it cannot meet. It is the fastest route and the closest experience to Vercel. Benchmark: if your monthly Amplify bill stays low (small-to-mid sites land roughly $0 to $70 a month, consistent with AWS's worked examples of $8.08 and $65.98) and you do not hit the unsupported-feature wall, stay here.

Step 2: switch to OpenNext + SST when you hit one of these thresholds: you need on-demand ISR, streaming, or edge middleware. Your data-transfer or SSR bill on Amplify (or Vercel) becomes a material line item. Or compliance requires the infrastructure to live in your own AWS account. Start new cost-sensitive projects directly on SST rather than migrating later.

Step 3: use ECS Fargate (or ECS Express Mode) when you already run containers, need always-on performance with no cold starts, or want maximum control. Do not start new projects on App Runner given the April 30, 2026 cutoff.

Step 4: use static export to S3 + CloudFront only for fully static sites.

Step 5: always set up CloudWatch monitoring and AWS Budgets from day one, and model costs in the AWS Pricing Calculator before committing.

This is the operating discipline we bring to website development, app design and development, and digital marketing retainers: pick the lightest path that does not block work, monitor it, and graduate on data. For teams sizing the build alongside the infrastructure bill, our USA custom development cost guide and Malta developer hiring guide set realistic bands. And if your AWS spend is climbing because the wrong path was picked early, the same redesign discipline in our web app redesign checklist applies to infrastructure too.

Key takeaways

• Four real paths: Amplify (managed, fastest, the right default), OpenNext + SST (open-source, full feature set, cheap at scale), ECS Fargate (full control, no cold starts), and static export (S3 + CloudFront for purely static sites).
• Amplify is closed-source and confirmed for Next.js 12 to 15. Re-verify Next.js 16 support before you commit. The hard gaps are on-demand ISR, streaming, and Edge middleware.
• OpenNext + SST gives you the full Next.js feature set on your own AWS account. The trade is more setup and ops responsibility.
• App Runner stops accepting new customers April 30, 2026. ECS Express Mode is AWS's replacement for the simple-container use case.
• Set AWS Budgets and CloudWatch alarms on day one regardless of path. Data transfer via CloudFront is usually the biggest line item.

FAQ

What is the easiest way to deploy Next.js on AWS in 2026?

AWS Amplify Hosting. Connect a Git repo, Amplify auto-detects Next.js, builds and deploys it, serves SSR and SSG on managed compute, and gives you Git-based CI/CD with PR previews. It is closest to the Vercel experience on AWS.

Does AWS Amplify support all Next.js features?

No. Amplify supports Next.js 12 through 15 and a long list of features, but it does not support On-Demand ISR, Next.js streaming, or Edge middleware (only Edge API routes). If you need any of those, use OpenNext + SST or a container.

What is OpenNext and why does it exist?

OpenNext is an open-source adapter, maintained by the SST team, that takes a Next.js build and converts it into deployable packages for AWS Lambda, CloudFront, S3, DynamoDB, and SQS. It exists because Next.js's server features need specific compute and caching infrastructure, and OpenNext maps those onto AWS primitives so you do not have to reverse-engineer it yourself.

Is SST or AWS CDK the better way to deploy OpenNext?

SST is the easiest path. Its sst.aws.Nextjs component uses OpenNext under the hood and provisions CloudFront, Lambda, S3, DynamoDB, and SQS for you. CDK is fine if your org is already standardised on it. Either way, OpenNext does not create infrastructure on its own; you need an IaC layer.

Should I use App Runner for Next.js?

Not for new projects. Per AWS's App Runner availability notice, App Runner stops accepting new customers on April 30, 2026 and AWS recommends ECS Express Mode for new and migrating customers. ECS Express Mode is Fargate-only and gives you a service, ALB, SSL, and URL from a container image with no additional charge beyond the underlying resources.

How much does Next.js on AWS cost?

Workload-dependent. AWS's own Amplify worked examples land at $8.08 a month (5 devs, 300 DAU) and $65.98 a month (10K DAU, 440 GB served). OpenNext + SST scales to near-zero at low traffic and is frequently cheaper than Vercel at scale, but data transfer via CloudFront is the biggest variable. Always model your own workload in the AWS Pricing Calculator and set AWS Budgets.

Will the new Next.js Adapter API change this?

Probably yes, later in 2026. Next.js 16.2 shipped a stable Adapter API built with OpenNext, Netlify, Cloudflare, AWS Amplify, and Google Cloud. First-party adapters for AWS, Cloudflare, and Netlify are in active development on top of this API. Once they ship, the OpenNext-style reverse-engineering will be unnecessary for the platforms that adopt the API. This is forward-looking, so re-verify at publish time.

Ready to pick the right path for your stack?

Most teams overpay on Vercel because nobody scoped the AWS path, or overpay on AWS because the wrong path was picked early. We help clients pick the lightest path that does not block work, model costs honestly in the AWS Pricing Calculator, wire up CI/CD and budgets, and graduate to OpenNext or containers only when the data says it is time. Same discipline we apply to website development and app design and development retainers. Tell us your stack and traffic shape and we will recommend a setup that fits. Or check our pricing options if you are scoping engineering support alongside the infrastructure spend.