# Vercel vs Netlify vs Cloudflare vs AWS: a tech-selection guide for Next.js/frontend platforms [2026 · an honest comparison]

> An honest comparison of deployment platforms for Next.js / frontend apps — Vercel, Netlify, Cloudflare (Pages/Workers), and AWS (Amplify/DIY). Across DX, the compute model, cost, edge, and lock-in, it explains — from a practitioner's unbiased view — which to choose for which scale and which requirements. A no-hype decision framework.

- Published: 2026-06-28
- Author: 友田 陽大
- Tags: Vercel, アーキテクチャ設計, Next.js, コスト最適化, インフラ, B2B SaaS, DX
- URL: https://tomodahinata.com/en/blog/vercel-vs-netlify-cloudflare-aws-amplify-platform-selection-guide
- Category: Vercel in production
- Pillar guide: https://tomodahinata.com/en/blog/vercel-production-platform-guide

## Key points

- Bottom line: if Next.js DX, dev speed, and hands-off operations are the priority, Vercel. If global edge and bandwidth cost are the priority, Cloudflare. If deep AWS integration, compliance, and full control are required, AWS (Amplify/DIY + OpenNext). If you're multi-framework Jamstack-centric, Netlify. There's no universal right answer — it's decided by requirements.
- Vercel's strengths: oneness with Next.js (fastest feature parity), Fluid Compute (regular Node.js at the same price), preview/Instant Rollback/Rolling Releases, zero-config ISR/image optimization. Its weakness: bandwidth/usage cost tends to grow relatively higher at scale.
- Cloudflare's Workers (V8 isolates) give ultra-low-latency, wide-area edge, and R2 (free egress)/KV/D1 make it overwhelmingly strong on bandwidth cost. Its weakness: gaps in Node.js compatibility and the effort of Next.js integration (OpenNext etc. may be needed).
- AWS (Amplify Hosting / DIY ECS / Lambda+OpenNext) is strong on deep AWS integration, VPC, compliance, and cost control, but operational complexity (= labor cost) grows. Decide by what you gain in exchange for carrying yourself the 'server-management cost' that Vercel erases.
- Look at cost not as 'the cheap platform' but as 'total cost of ownership (TCO) = infrastructure + labor + opportunity cost.' Shipping fast with a small team, Vercel's dev speed can save a lot of labor cost. Conversely, DIY wins for large-scale delivery and strict governance.

---

“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](https://vercel.com/docs); 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](/blog/vercel-production-platform-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](/blog/vercel-deployments-cicd-rollback-rolling-releases-guide), [caching](/blog/vercel-caching-isr-cache-components-ppr-guide)).

- **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](/blog/vercel-functions-fluid-compute-streaming-cron-guide)) |
| **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](/blog/vercel-cost-active-cpu-pricing-optimization-guide)). 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](/blog/vercel-caching-isr-cache-components-ppr-guide) and [cost optimization](/blog/vercel-cost-active-cpu-pricing-optimization-guide). 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](/blog/typescript-type-safety-discipline-zod-nevererror-no-any) 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.

1. **Next.js × speed/hands-off → Vercel** (the default for small teams; the bill can be lowered enough by design)
2. **Bandwidth / wide-area edge → Cloudflare**
3. **AWS integration / governance / large scale → AWS (Amplify/DIY + OpenNext)**
4. **Multi-framework Jamstack → Netlify**
5. **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](https://vercel.com/docs) (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.