Vercel to AWS: the target architecture, the Next.js gotchas and the cutover.
Vercel is the fastest place to ship a Next.js app and, past a certain traffic level, an expensive place to run it. This playbook covers the four AWS targets (Amplify Hosting, OpenNext with SST, ECS on Fargate, or S3 and CloudFront for static sites), how each Vercel feature maps, the Next.js quirks that bite, and a near-zero-downtime DNS cutover. Many teams can do this themselves. This page also says when a partner is worth it.
- Teams leave Vercel mainly for cost at scale and for control. Vercel meters bandwidth, function invocations, middleware, ISR writes and image optimization on top of the infrastructure underneath, so once traffic grows, owning the CloudFront, Lambda and S3 stack directly is usually cheaper. Model your own bill first: for a small app the savings may not be worth the work.
- There are four sensible targets. AWS Amplify Hosting is the closest managed experience (SSR, ISR, git-push deploys, preview branches). OpenNext, deployed with SST, compiles your Next.js app onto Lambda, CloudFront and S3 in your own account. ECS on Fargate runs Next.js as an always-on Node server. S3 and CloudFront alone serve fully static exports.
- The hard parts are Next.js-specific: ISR and on-demand revalidation, edge middleware, image optimization and preview deploys. Amplify or OpenNext handles most of them. A small app can move without a partner. If the move is part of bigger AWS work, such as moving the backend off another cloud or launching an AI feature, a vetted partner can check whether MAP, POC or IW funding applies. AWS approves.
IWhy teams leave Vercel
Nobody leaves Vercel because the developer experience is bad. It is the best in the category. Teams leave because that experience is priced on every unit of traffic, and once the app succeeds, the bill becomes the line finance asks about.
Cost at scale. Vercel runs on cloud infrastructure and adds a margin for convenience, and it meters what a busy app does most: bandwidth past the plan allowance, function invocations and duration, edge middleware, ISR writes and image optimization. Each is reasonable on its own. Together, at scale, they grow with every request.
Control. Vercel bundles the CDN, the function runtime, the build pipeline and the edge network into one opinionated product. That is ideal at v1 and limiting once you need a private connection to your database, custom WAF rules, a specific caching policy, multi-account isolation for compliance, or the app next to the rest of your AWS services.
Consolidation. Many teams that outgrow Vercel already run their backend on AWS (RDS or Aurora, SQS, S3, Cognito, and more and more often Bedrock). A front end on Vercel means a second vendor, a second bill, cross-cloud traffic to your data and a second compliance surface.
The honest counterpoint: Vercel's previews and zero-config Next.js support are excellent, and AWS asks you to own more (a build pipeline, a CDN distribution, function packaging and the Next.js adapter layer). Weigh that against the savings before you move.
Pull three months of Vercel invoices and split them by line: bandwidth, function invocations and duration, middleware, ISR and image optimization. Price the same traffic on CloudFront, Lambda (or Fargate) and S3 with the AWS Pricing Calculator. If the gap is small, stay on Vercel. If it is large and grows with traffic, the move pays for itself.
IIThe four AWS targets, and which one fits
Vercel to AWS is not one architecture. The right target depends on whether the app is dynamic (SSR, ISR, middleware) or a static export, and how close to the Vercel experience you want to stay.
Target A: AWS Amplify Hosting (closest managed experience)
AWS's managed hosting with Next.js support: SSR, ISR and SSG, API routes, image optimization, git-based deploys and preview branches. Connect the repo and Amplify builds, deploys and runs the CloudFront, Lambda and S3 pieces for you.
Best for teams that want a low-ops, git-push workflow. Watch for: Amplify supports a defined set of Next.js versions and features, and the newest App Router or middleware behavior can lag. Check your exact version against Amplify's support list before you commit.
Target B: OpenNext with SST (self-owned serverless)
OpenNext is an open-source adapter that turns a Next.js build into AWS pieces: the server on Lambda, static assets in S3, CloudFront as the CDN, ISR backed by S3, DynamoDB and an SQS revalidation queue, and image optimization on its own Lambda. SST deploys it as code.
Best for teams that want the full Vercel feature set in their own AWS account, with control over caching, networking and cost. Watch for: you own the configuration and its upgrades as Next.js changes.
Target C: ECS on Fargate (always-on container)
Next.js in output: 'standalone' mode, in a container behind an Application Load Balancer, with CloudFront in front and static assets in S3.
Best for teams already on ECS, apps that need no cold starts, and long-lived connections (WebSockets, streaming). Watch for: you pay for the container around the clock, and ISR needs a shared cache handler (S3 or Redis) so every task sees the same pages.
Target D: S3 and CloudFront (pure static export)
If the app is fully static (output: 'export'), it is just files in S3 served by CloudFront, with ACM for TLS and Route 53 for DNS. No Lambda, no server, and by far the cheapest target.
Watch for: apps that look static but use a couple of dynamic routes. Find them before you choose this target.
IIIFunctions, edge middleware, ISR and images on AWS
The static and CDN layer is easy: CloudFront plus S3, with Route 53 and free ACM certificates for domains. The real work is reproducing Vercel's function and edge behavior. OpenNext and Amplify exist to do exactly that.
Functions and API routes become Lambda functions behind CloudFront (OpenNext uses one server Lambda for SSR and route handlers). Tune memory, timeouts and packaging, and use provisioned concurrency on latency-critical routes. On Fargate they run inside the always-on Node server, with no cold starts.
Edge middleware splits by weight. Light logic (auth-cookie checks, header rewrites, redirects, A/B buckets) runs as a CloudFront Function: fast and cheap, with a limited runtime. Heavier middleware that needs full Node runs on Lambda@Edge, which has its own size and timeout limits, no VPC access and global deploys. OpenNext maps Next.js middleware onto these for you.
ISR and on-demand revalidation need a cache store. OpenNext uses S3 for rendered pages, DynamoDB for tags and an SQS queue for background revalidation, so revalidate, revalidateTag() and revalidatePath() behave as on Vercel. Amplify manages this internally. On Fargate you add a shared cache handler.
Image optimization (next/image) becomes its own Lambda that resizes on demand and caches results in S3 and CloudFront. Because Vercel meters images, this is often where a noticeable share of the savings comes from.
IVPreview deploys, env vars and the build pipeline
The thing teams fear losing most is the preview deploy per pull request. It reproduces on AWS; how closely depends on the target.
On Amplify Hosting it is nearly like for like: Amplify builds on every push, creates a preview per pull request with its own URL, and keeps per-branch environment variables. On OpenNext/SST or Fargate, keep GitHub Actions (or use CodePipeline and CodeBuild) and deploy a stage per pull request; SST makes short-lived stages straightforward. It is more setup than Amplify, with no per-preview platform cost.
Move secrets (API keys, database credentials) into AWS Secrets Manager and plain config into SSM Parameter Store. One Next.js subtlety: NEXT_PUBLIC_* variables are inlined at build time, so they must exist in the build environment, while server-only secrets load at runtime. Mixing them up either leaks a secret into the public bundle or ships an undefined value.
VThe cutover: build in parallel, then switch DNS
This is one of the gentler cutovers, because a Next.js front end holds no durable state. The database usually is not moving, so the new stack can be built and tested without touching production.
Stand up the AWS target, point it at the same backend, and deploy behind a temporary hostname. Test every route, SSR and ISR behavior, middleware and auth, images, API routes and previews. Public traffic still goes to Vercel the whole time.
Lower your DNS TTL a day ahead, then point the domain at CloudFront (or the Amplify domain). Both stacks serve the same backend, so visible downtime is the propagation window, commonly 0–5 minutes. Rollback is the same move in reverse: keep Vercel live for a few days, and point DNS back if anything is wrong. If your database is also moving, that move sets the downtime window, not the front end.
The front end is stateless. The cutover is a DNS change between two stacks serving the same backend, not a data migration, so you get near-zero downtime, an instant rollback and no risk to your data. The work is in reproducing Next.js behavior, not in the switch.
VIStep by step
For a typical Next.js app this is a 2–6 week project, most of it parallel, none of it touching production until the DNS switch.
- 1. Assess: List the Next.js version, App or Pages Router, which routes use SSR, SSG or ISR, middleware, image use, API routes and env vars. Split the current Vercel bill by line. Pick the target and model the before and after cost.
- 2. Build the foundation: Set up the AWS account structure, CloudFront, S3, IAM roles, ECR for Fargate, and Secrets Manager and Parameter Store.
- 3. Deploy the app: Amplify: connect the repo. OpenNext: write the SST config and deploy. Fargate: build the standalone image, push to ECR and run the service behind an ALB and CloudFront.
- 4. Wire the Next.js specifics: Confirm SSR, ISR, middleware and image optimization behave as on Vercel. Move env vars, with NEXT_PUBLIC_* in the build environment.
- 5. Test, then switch DNS: Run the full suite against a temporary hostname, then switch DNS with a low TTL and keep Vercel warm as rollback.
- 6. Optimize and cancel Vercel: Tune the CloudFront cache policy and Lambda memory or concurrency, set CloudWatch alarms, then cancel the Vercel plan. The savings start when the old bill stops.
VIINext.js-on-AWS gotchas
Most Vercel to AWS moves that go sideways do so for the same few reasons. All are cheaper to know than to discover at cutover.
- Amplify version support: Check your Next.js version and features against Amplify's support list. On the newest features, OpenNext is often the safer target.
- ISR needs a real cache: Without a shared cache store, pages never revalidate or each Lambda or task regenerates on its own. This is the top surprise in hand-built stacks.
- Edge limits differ: CloudFront Functions have a limited runtime and Lambda@Edge has size and timeout limits and no VPC access. Heavy middleware may belong in the origin instead.
- Build-time public variables: NEXT_PUBLIC_* values are baked into the client bundle at build time. Server secrets are not. Keep them apart.
- Cold starts: Lambda scales to zero. Use provisioned concurrency on latency-critical routes, or choose Fargate.
- Streaming and WebSockets: Long-lived connections fit a long-running server (Fargate) better than per-request Lambda.
- Paying twice: Keep Vercel as rollback for a short, defined window, then cancel it.
VIIIDo it yourself, or with a partner?
Most small Next.js apps can make this move without outside help. A partner is worth it when the stakes or the scope are bigger.
If your app is a handful of routes on a few hundred dollars a month of Vercel spend, pick Amplify Hosting or OpenNext with SST, follow the steps above and keep Vercel as a fallback for a week. You do not need us for that.
A partner is worth it when the app is large or business-critical, when ISR, middleware and streaming are heavy, when your team has little AWS serverless experience, or when the front end is one part of a bigger move.
On funding, be realistic. MAP (the AWS Migration Acceleration Program) is built for migrations with meaningful AWS spend after the move, so a small Next.js front end on its own is unlikely to qualify. It can apply when the Vercel move is part of a larger migration, for example the backend and database moving off another cloud too. If you already run on AWS and are launching new work, such as an AI feature on Bedrock, ask about POC or incremental workload (IW) funding. In each case your matched partner files the request when the work qualifies, and AWS approves it. For startups, partner-filed funding is typically $50K to $150K. Depends on the workload; AWS approves.
CloudRoute is free for you. Partners pay CloudRoute a monthly membership plus 10% of AWS-approved funding.
Vercel feature to AWS approach
Every Vercel feature, how you reproduce it on AWS, who generates it and the effort. Amplify and OpenNext generate most of the medium-effort rows for you.
| Vercel feature | AWS approach | Who generates it | Effort |
|---|---|---|---|
| Global edge CDN | Amazon CloudFront | Amplify, OpenNext or manual | Trivial |
| Static assets | Amazon S3 behind CloudFront | Amplify, OpenNext | Trivial |
| Static export | S3 and CloudFront only, no server | Direct deploy | Low |
| SSR and Server Components | Lambda (OpenNext, Amplify) or Node on Fargate | OpenNext, Amplify | Medium |
| API routes and Route Handlers | AWS Lambda, or the Fargate Node server | OpenNext, Amplify | Medium |
| Edge Functions and Middleware | CloudFront Functions (light) or Lambda@Edge (heavy) | OpenNext | Medium to high |
| ISR and on-demand revalidation | S3, DynamoDB and SQS (OpenNext); shared cache on Fargate | OpenNext, Amplify | High |
| Image optimization | Image Lambda, cached in S3 and CloudFront | OpenNext, Amplify | Medium |
| Preview deployments | Amplify previews, or a per-PR SST stage | Amplify (built in), SST | Low to medium |
| Env vars and secrets | Secrets Manager and SSM Parameter Store | Scripted export | Low |
| Build pipeline | CodePipeline and CodeBuild, or keep GitHub Actions | Your CI | Medium |
| Custom domains and TLS | Route 53 and ACM (free certificates) | Manual, one time | Low |
How a match works (example)
- You tell us about the work
You fill in a short form: what you run today, what you want to move, test or build, your stage and your region.
- We pick one partner
We read your answers and pick one vetted AWS consulting partner that fits the work, the stack and the region. We reply within 24 hours; your matched partner reaches out within 5 business days.
- The partner checks MAP funding
Your matched partner scopes the migration with you. Then it checks whether the move qualifies for MAP (Migration Acceleration Program) funding. MAP is for teams that are not on AWS yet.
- The partner files, AWS decides
If the work qualifies, the partner files the funding request with AWS. AWS reviews it and decides. The amount depends on the workload.
- You pay nothing
CloudRoute is free for startups. Partners pay CloudRoute a monthly membership plus 10% of AWS-approved funding.
AWS Activate credits are separate, and you apply for them yourself. Use Activate Founders if no investor backs you. Use Activate Portfolio with the Org ID or invite from your VC, accelerator, incubator or angel group if it is an Activate Provider. A consulting partner cannot apply for Activate on your behalf.
Common questions
Can I run Next.js on AWS with the same features as Vercel?
Which AWS target should I choose for my Next.js app?
How much will I save moving off Vercel?
How much downtime is there at cutover, and can I roll back?
What about ISR, edge middleware and image optimization?
Do I lose Vercel's preview deployments?
Can AWS pay for a Vercel to AWS migration?
Moving off Vercel as part of something bigger?
Tell us about the app and the rest of your stack. If it is a simple move, we will say you do not need a partner. If it is part of bigger AWS work, a vetted AWS partner can run it and file MAP, POC or IW funding when the work qualifies: typically $50K to $150K for startups. Depends on the workload; AWS approves. CloudRoute is free for startups.