Vercel to AWS: What Platform Graduation Actually Costs — Part 1
Published: 2026-06-15
Part 1 of 2 — Introduction & cost reality check
Part 2 covers service mapping, architecture patterns, and a verdict
Vercel is, genuinely, the best way to ship a web app fast. Zero config, preview deployments on every push, global CDN out of the box — it removes infrastructure decisions from the equation entirely, which is exactly what an early-stage startup needs. If you’re building something new and want to move fast, Vercel is hard to beat.
But every managed platform has a ceiling. Vercel’s is higher than most — but it exists.
The signs tend to follow a pattern. A compliance question surfaces about where user data actually lives. Real-time features hit a structural wall — Vercel Functions can’t act as a WebSocket server, and Fluid Compute doesn’t change that. The monthly bill starts climbing past the point where the convenience premium makes sense. Or a background process that needs to stay alive turns out to be something Vercel Workflows can handle in part, but not fully.
These aren’t Vercel bugs. They’re the natural edges of a well-designed PaaS — and hitting them is, in the startup world, something of a rite of passage. Firebase to AWS. Supabase to AWS. Vercel to AWS. The pattern has a name: platform graduation.
It’s not a new problem. But it’s one that most teams still navigate without a reliable map.
I came to this topic not from having made the move myself, but from trying to understand what the move actually involves. This post is what I found: real cost numbers from the AWS Pricing Calculator, a service-by-service mapping from Vercel to AWS, and two architecture patterns to consider. Not a prescription — a map.
The cost reality check
The first thing most engineers assume when they start thinking about moving away from Vercel is that AWS will be cheaper. At early scale, that assumption is almost always wrong.
Here’s what the numbers actually look like, based on AWS Pricing Calculator estimates for a small but real workload: two engineers, ~10,000 MAU, 500 GB of bandwidth per month, running in ap-southeast-2 (Sydney). All figures use on-demand pricing with no reserved instances or savings plans — which is the realistic baseline for a team that isn’t ready to make year-long infrastructure commitments.
These numbers reflect a deliberately conservative baseline — 10,000 MAU with two engineers. It’s the scale where platform graduation becomes a real conversation, not yet the scale where cost alone forces the decision.
At this scale, Vercel wins on cost. That’s worth saying plainly, because it’s often not what people expect going into this research.
But there are two things those numbers don’t show.
First, Vercel’s 150–300 before the team notices. Vercel’s published rates are transparent, but cost is metered across more than a dozen independent dimensions — bandwidth, origin transfer, edge requests, CPU time, memory, function invocations, build minutes, and more, each with regional multipliers. The interaction between them becomes difficult to model as traffic patterns change.
Second, AWS costs compress with commitment. Reserved Instances bring the Container-First estimate down to roughly $140–150 per month. That said, a startup that can’t yet predict its traffic patterns probably shouldn’t be locking into 1-year infrastructure commitments anyway — so on-demand is the honest comparison.
The practical inflection point, based on patterns reported across similar migrations, lands somewhere around $300–800 per month on Vercel. That’s the range where overages start compounding and platform constraints tend to surface at the same time. At that point, the AWS math starts looking different.
Cost alone, though, rarely drives the decision. The more interesting question is what you can’t do on Vercel at all — which is where we’ll go next.
Part 2 covers service mapping, architecture patterns, and a verdict.