Vercel to AWS: What Platform Graduation Actually Costs — Part 2

Published: 2026-06-16

Part 2 of 2 — Service mapping, architecture patterns & verdict

Part 1 covers the cost reality check

Service mapping: from Vercel to AWS

Vercel’s strength is abstraction — one platform handles CDN, compute, storage, and observability without exposing the underlying pieces. Moving to AWS means making each of those pieces explicit. The table below maps Vercel services to their AWS equivalents, with an honest note on migration effort.

Three services deserve a specific callout.

Next.js SSR/ISR has three deployment paths on AWS. The most common is open-next, an open-source adapter that packages Next.js for Lambda — it covers the majority of use cases, but ISR requires S3 and DynamoDB for cache storage and manual CloudFront invalidation on revalidation, which behaves differently from Vercel’s ISR. AWS Amplify Hosting is a simpler managed alternative that supports ISR natively and is worth considering if operational simplicity is the priority. Running Next.js in a Docker container on ECS Fargate is the most complete option — no adapter required, full feature support — at the cost of higher infrastructure overhead.

ElastiCache for Redis is the natural replacement for Vercel KV, but it’s the service most likely to catch you off guard. Unlike Vercel KV, which is accessible over the public internet with an API key, ElastiCache lives inside your VPC — which means your application needs to be in the same VPC to reach it, security groups need to be configured correctly, and there’s no public endpoint to test against locally. It’s not difficult once you understand the model, but it’s a meaningful mental shift coming from a fully managed PaaS. Budget time for it.

Preview deployments are where the gap is most visible. Vercel’s branch-based previews are seamless enough that most teams take them for granted. AWS Amplify Hosting is the closest equivalent, but the setup and developer experience are meaningfully different. If preview environments are core to your workflow, factor that into the migration cost.

Two patterns for the same destination

Once you’ve decided to move, the next decision is which AWS architecture to land on. There are two realistic options, and they solve different problems.

The diagram above is what you’re starting from: a single platform handling CDN, compute, and storage as one abstraction. Clean, but with the ceilings described in Part 1.

Pattern A: Serverless-First

The Serverless-First pattern maps closest to how Vercel works: stateless functions, CDN at the edge, managed database. Lambda + API Gateway handles the compute layer, CloudFront replaces the Edge Network, and S3 takes over from Vercel Blob. At this scale, Lambda falls entirely within the free tier. The biggest cost driver is CloudFront at $57/month, which is a fixed function of bandwidth rather than application complexity. Total:$85.94/month.

The notable absence in this diagram is a NAT Gateway. Because Lambda can be configured to run outside a VPC for public API calls, the architecture avoids one of AWS’s most reliably expensive line items. It’s a meaningful design choice, not an oversight.

The one honest caveat: Next.js ISR works via open-next, but requires S3 and DynamoDB for cache storage and manual CloudFront invalidation on revalidation — it behaves differently from Vercel’s ISR. If simpler managed deployment is the priority, AWS Amplify Hosting supports ISR natively and is worth considering as an alternative path.

Pattern B: Container-First

The Container-First pattern replaces Lambda with ECS Fargate — always-on containers that can hold persistent connections, run background workers, and support WebSocket traffic natively. This is the architecture to reach for when Serverless-First’s limitations are precisely the reason you’re leaving Vercel.

The tradeoff is cost and operational complexity. ECS requires an Application Load Balancer, ElastiCache for session caching, and — critically — a NAT Gateway so containers in a private subnet can reach external services. That NAT Gateway costs $43.66/month before a single byte of traffic passes through it. It's the single largest reason Container-First comes in at$191.67/month versus $85.94 for Serverless-First.

Which pattern fits your situation

If your main driver is cost or data residency, Serverless-First is the right starting point. If you’re moving specifically because of WebSocket requirements, persistent workers, or a need for custom runtime environments, Container-First is worth the additional cost — because those are things Serverless-First can’t solve either.

Verdict

Vercel is not broken. The decision to move isn’t about fixing something — it’s about recognizing when a platform that was right for one stage of a product stops being right for the next.

There are four signals worth watching. WebSocket requirements that can’t be delegated to a third-party provider. Background processes that need to stay alive beyond what Vercel Workflows can support. Data residency obligations that require infrastructure outside a US-incorporated company’s legal reach. And a monthly Vercel bill climbing into the $300–800 range, where overages start compounding and the cost-to-control tradeoff tips.

If none of those apply, staying on Vercel is a reasonable choice. The platform has improved significantly — Fluid Compute, longer execution times, deprecation of Edge Runtime restrictions. The gap has narrowed.

If one or more do apply, the question becomes which pattern. The short version: start with Serverless-First unless Container-First solves a specific problem you have right now. The NAT Gateway alone adds $43/month before anything runs, and the operational overhead of ECS is real. Don’t pay for complexity you don’t need yet.

Wrap Up

Platform graduation is a well-worn path. The teams that navigate it well tend to share one thing: they made the move deliberately, with a clear reason, rather than reacting to a bill or a blocked feature at the worst possible moment.

I hope this series helps make that decision a little more legible before the moment arrives.

Keep on building.

Further Reading

• From Vibe to Production: A Startup’s Guide to Graduating from Supabase to AWS

  • This piece does a great job of defining the exact triggers for platform graduation. It doesn’t just tell you when to move, but actually maps out a secure, low-risk migration path. A perfect case study for graduating from a BaaS to AWS.

• A ‘Best of Breed’ Strategy with Vercel + AWS: SANU’s Architecture for Speed and Sustainable Growth (Written in Japanese)

  Vercel + AWS で実現する「Best of Breed」戦略。開発速度と持続的成長を両立した SANU 社のアーキテクチャとは

  • What I liked about this article is that it focuses on architectural evolution rather than platform replacement. Instead of framing the discussion as “Vercel vs. AWS,” it shows how a growing startup can gradually reshape its architecture while continuing to leverage both platforms.

• Migrating Next.js Landing Page Projects from Vercel to AWS

  • This article provides a raw, firsthand account of achieving dramatic cost savings through a Vercel-to-AWS migration. By spelling out the clear benefits of infrastructure consolidation, it serves as a highly practical reference for engineers looking to scale efficiently.