“Should my Next.js app go on Vercel? Or is Cloudflare or AWS cheaper?” is one of the most common questions in tech-selection consults. Comparison articles online tend to skew toward extreme position-taking — either “Vercel is expensive” or “Vercel is the only choice” — which makes them useless for deciding.
This article, from the standpoint of having operated multiple Next.js products in production, including on Vercel, compares the four options as unbiased as possible and presents a decision framework for “which to choose for which scale and which requirements.” Vercel's features are evaluated faithfully to the official documentation; the competitors by their established, general characteristics (each vendor's prices and limits change, so always confirm the latest values in each official source before a final decision).
Bottom line up front: there is no universal right answer. “Dev speed / hands-off = Vercel,” “bandwidth cost / wide-area edge = Cloudflare,” “AWS integration / governance = AWS,” “multi-framework Jamstack = Netlify.” We break it down axis by axis below. For production operations after choosing Vercel, see the Vercel production-operations guide.
The four options in one line
| Platform | In one line | Best fit |
|---|---|---|
| Vercel | Next.js's first-party platform. Best DX and hands-off | Ship Next.js fast and safely. Small teams, startups |
| Netlify | A multi-framework Jamstack platform | Diverse SSG/frontends; Vercel-like DX from a different vendor |
| Cloudflare (Pages + Workers) | Wide-area edge + cheap bandwidth | Global delivery, bandwidth-cost-first, edge execution |
| AWS (Amplify Hosting / DIY ECS·Lambda + OpenNext) | Deep AWS integration and full control | VPC/compliance/existing AWS assets/large-scale governance |
Axis ①: developer experience (DX) and Next.js parity
Vercel is the maker of Next.js, so new features (App Router, Cache Components/PPR, Server Actions, use cache, etc.) reach production fastest and with zero config. Preview URLs, Instant Rollback, Rolling Releases, ISR, and image optimization “just work” without thinking (deploys, caching).
- Vercel: ◎ best for Next.js. Almost zero time lost to new-feature compatibility.
- Netlify: ○ DX is close. Multi-framework. Next.js parity trails Vercel slightly.
- Cloudflare: △–○ Pages is good. But running Next.js's latest features fully may require an adapter like OpenNext or extra config.
- AWS (DIY): △ Amplify Hosting has improved, but building SSR/ISR/image optimization yourself needs build-out with OpenNext/SST etc. Maximum control, minimum DX.
DX is a cost. On a small team, “time that melts into config, compatibility, and ops” is the biggest expense. There are many situations where Vercel's DX directly saves labor cost.
Axis ②: the compute model
| Platform | Execution model | Implications |
|---|---|---|
| Vercel | Fluid Compute (regular Node.js/Python, same region, same price, multiple requests per instance) | Full Node.js compatibility. Reduced cold starts. Cheaper the more I/O-bound it is (Functions) |
| Netlify | Netlify Functions (AWS Lambda-based) / Edge Functions | Standard serverless. Lambda-compatible constraints |
| Cloudflare | Workers (V8 isolates) | Ultra-low-latency, wide-area. But gaps in Node.js compatibility can trip up native modules and some APIs |
| AWS | Lambda / ECS / Fargate, free choice | Anything goes. But you design and operate it all |
Cloudflare Workers' “spin up a V8 isolate instantly on edges worldwide” is technically powerful, excelling at latency and scale. On the other hand, if you need full Node.js compatibility (run existing npm packages as-is), Vercel's Fluid Compute is the safe bet. In 2026, Vercel recommends “Fluid (regular Node.js), not Edge,” letting you get low latency while avoiding the compatibility traps.
Axis ③: cost (bandwidth, usage, TCO)
This is the most misunderstood part. You should look at it as “total cost of ownership (TCO),” not “the platform's unit price.”
Unit-price tendencies for bandwidth/usage
- Cloudflare: overwhelmingly strong on bandwidth cost. R2 has free egress (outbound transfer), and Workers' free tier is large. It tends to be the cheapest band for high-volume/media delivery.
- Vercel: usage billing uses the Active CPU model (charges only for CPU execution time, not I/O wait), efficient for I/O-bound apps (cost). But bandwidth (Fast Data Transfer), image optimization, and function usage tend to get relatively higher as you scale. It changes a lot with cache design.
- Netlify: similar structure to Vercel. Plan + metered bandwidth.
- AWS (DIY): unit price can be the lowest, but labor cost for design, operations, and monitoring rides on top.
Thinking in TCO
Total cost of ownership (TCO) = infrastructure + operating labor + opportunity cost (slowness, outages)
- Ship fast with a small team: Vercel's dev speed and hands-off operations save a lot of labor cost. It often outweighs a modest difference in infra unit price.
- Large-scale delivery, bandwidth-dominant: Cloudflare's bandwidth advantage kicks in. Or build it out on AWS.
- Already have a strong AWS team: you can recoup DIY AWS's unit-price edge with operational muscle.
An honest guideline: for a product with thousands to tens of thousands of PV/month, “Vercel is expensive” is in many cases an illusion. A bill that spikes is usually caused by an undesigned cache (functions run every time) or overusing image optimization. Vercel can run cheaply enough with cache design and cost optimization. Only when you truly reach bandwidth-dominant, large-scale delivery does migrating to Cloudflare/AWS become economically rational.
Axis ④: edge and global delivery
- Cloudflare: the breadth and proximity of its edge network is unmatched. Combined with edge execution (Workers), you can build ultra-low-latency dynamic processing.
- Vercel: a global CDN + Fluid cross-region/AZ failover. Functions are single-region by default (multiple on Pro/Ent). More “regular Node.js, nearby” than edge execution.
- Netlify: CDN + Edge Functions.
- AWS: CloudFront + Lambda@Edge / DIY multi-region. Maximum freedom, maximum operations.
Axis ⑤: lock-in and exit strategy
- Vercel/Netlify: as long as you write in standard frameworks (Next.js etc.), code lock-in is small. The more you depend on Vercel-specific features (Edge Config, Blob, Firewall rules, Rolling Releases), the higher the migration cost.
- Cloudflare: going deep on the Workers runtime, D1, KV, and Durable Objects raises specificity.
- AWS (DIY): assembling with IaC (Terraform/CDK) gives high reproducibility, but the design becomes AWS-premised.
Practical wisdom: write the app's core logic in framework standards, and use platform-specific features behind a boundary (a thin adapter). This keeps the “ship fast on Vercel → migrate if needed” option open (the ETC: ease of change principle).
Decision flowchart
Q1. Using Next.js, and dev speed + hands-off ops are the top priority?
→ YES: Vercel (when in doubt, here. The default for small teams/startups)
Q2. Is bandwidth/media delivery the dominant cost term? Need wide-area edge execution?
→ YES: Cloudflare (R2 free egress, Workers)
Q3. Need existing AWS assets, in-VPC communication, strict compliance/governance?
Have a strong platform-ops team?
→ YES: AWS (Amplify Hosting or DIY ECS/Lambda + OpenNext/SST)
Q4. Diverse-framework Jamstack with a different vendor's DX?
→ YES: Netlify
Multiple apply → a hybrid of "core fast on Vercel, only the heavy delivery on
Cloudflare/AWS" also works (e.g. app = Vercel, large media = R2/S3 + CDN)
Recommendations by case
| Case | Recommendation | Why |
|---|---|---|
| A startup's new SaaS (Next.js) | Vercel | Save labor cost with speed and hands-off ops; ship safely with preview/rollback |
| Global media/e-commerce (high-volume delivery) | Cloudflare or hybrid | Bandwidth-cost-first, edge low latency |
| Finance/healthcare/public sector (VPC, audit, governance) | AWS | Compliance, network governance, existing integration |
| Multi-framework, agency production | Netlify / Vercel | Uniform DX across diverse projects |
| Already all-in on AWS, dedicated SRE on staff | DIY AWS + OpenNext | Recoup the unit-price edge with operational muscle |
Conclusion: platform selection is a "design decision"
There's no single answer to “which is best?” Working backward from requirements (speed, cost structure, governance, team makeup) is what tech selection is.
- Next.js × speed/hands-off → Vercel (the default for small teams; the bill can be lowered enough by design)
- Bandwidth / wide-area edge → Cloudflare
- AWS integration / governance / large scale → AWS (Amplify/DIY + OpenNext)
- Multi-framework Jamstack → Netlify
- Decide on TCO (infrastructure + labor + opportunity cost), and go hybrid if needed
I'm not an agent for any particular vendor — I help you choose the platform best suited to your requirements. If you go with Vercel, I take on production operations, cost optimization, and migration; I also take on comparative design against other platforms.
The Vercel statements in this article are based on the Vercel official documentation (as of June 2026). Competitors' prices, limits, and features change. Always confirm the latest values in each vendor's official source before adopting in production.