Vercel vs. AWS: When to Outgrow Managed Hosting
I've moved two backends off Vercel to AWS this year. Not because Vercel is bad — it's incredible for velocity. But at a certain scale, the constraints become real problems. Here's when and how to make the move.
The Hard Limits You'll Hit First
Vercel's serverless model has concrete boundaries[citation:1]:
| Limit | Value | When It Hurts |
|---|---|---|
| Function execution | 13.3 min max | ETL, video processing, large exports |
| Memory per function | 4GB | ML inference, large datasets |
| Concurrency (Pro) | 30,000 | Unexpected traffic spikes[citation:2] |
| Docker support | ❌ None | Custom runtimes, legacy services[citation:1] |
| Persistent storage | ❌ No volumes | Stateful workloads[citation:1] |
Real example: Our CSV export feature started failing at 8 minutes. Users with 50k+ rows couldn't generate reports. The fix wasn't optimizing code — it was leaving Vercel.
The Economic Inflection Point
Raw compute isn't the full story. Here's what costs look like at 100k MAU[citation:6][citation:7]:
| Platform | Monthly Infra | DevOps Hours | Total Monthly (inc. labor) |
|---|---|---|---|
| Vercel (Pro) | ~$100-300 | 5-10 | ~$350-800 |
| AWS Fargate | ~$200-400 | 60-100 | ~$3,200-5,400 |
| AWS Lambda | ~$150-300 | 20-40 | ~$1,150-2,300 |
Key insight: Vercel's "premium" is paying for DevOps. AWS only makes sense once you have dedicated ops headcount[citation:6].
The Migration Decision Matrix
Stay on Vercel if:
- Team size < 5 engineers
- No dedicated DevOps
- Workloads under 10 min execution
- Frontend-heavy architecture
- Need preview deployments for every PR[citation:8]
Move to AWS if:
- Hitting function timeouts or memory limits[citation:1]
- Need Docker / custom runtimes
- Compliance requires infrastructure ownership (SOC2, HIPAA)[citation:3]
- Monthly Vercel bill > $2,000
- You have dedicated ops or budget to hire[citation:6]
The Migration Path That Works
Don't rewrite everything. Here's the sequence[citation:3]:
Step 1: Move Only the Backend
Frontend stays on Vercel. Preview deployments, ISR, and edge logic still work great there[citation:8].
// Backend moves to AWS Fargate or Lambda
// Frontend calls it via API
const api = new API('https://your-aws-backend.com');
Step 2: Extract Heavy Workloads First
Long-running functions → ECS/Fargate tasks. Background jobs → SQS + workers. Scheduled jobs → CloudWatch Events
Step 3: Port Databases and Storage
Vercel Postgres (Neon) → RDS PostgreSQL. Vercel Blob → S3. Vercel KV → ElastiCache or SQS (if queue pattern)
What You Gain (and Lose)
Gain:
-
No function timeouts
-
Persistent storage via EBS volumes
-
Full VPC control
-
Predictable reserved instance pricing
-
Compliance-ready infrastructure
Lose:
-
Preview deployments (git push → live URL)
-
Automatic edge optimization
-
Built-in analytics
-
Zero-config monitoring
-
15-minute setup time
The Final Verdict
Don't migrate preemptively. Vercel's velocity advantage is massive for teams under 10 people. I've seen startups waste months on AWS configuration that could have been shipping features.
Do migrate when you hit limits. The moment a customer-facing feature breaks due to timeouts or concurrency, start planning. That's the real trigger — not cost, not scale, but broken user experience.
For most teams reading this, the answer is still Vercel. But if your exports are timing out or your bill is shocking, AWS becomes the right answer. Just budget for the operational overhead. It's real.