--- source_url: "https://tomodahinata.com/en/blog/vercel-vs-netlify-cloudflare-aws-amplify-platform-selection-guide" title: "Vercel vs Netlify vs Cloudflare vs AWS: a tech-selection guide for Next.js/frontend platforms [2026 · an honest comparison] | Tomoda Hinata — SaaS/DX" mirrored_at: 2026-08-10T15:39:36.590Z host: tomodahinata.com cited_in_42a: true mirror_canonical: "https://index.42a.ai/tomodahinata.com/en/blog/vercel-vs-netlify-cloudflare-aws-amplify-platform-selection-guide" --- > **Original source:** https://tomodahinata.com/en/blog/vercel-vs-netlify-cloudflare-aws-amplify-platform-selection-guide “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](https://tomodahinata.com/en/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](https://tomodahinata.com/en/blog/vercel-deployments-cicd-rollback-rolling-releases-guide), [caching](https://tomodahinata.com/en/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](https://tomodahinata.com/en/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](https://tomodahinata.com/en/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 - **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](https://tomodahinata.com/en/blog/vercel-caching-isr-cache-components-ppr-guide) and [cost optimization](https://tomodahinata.com/en/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](https://tomodahinata.com/en/blog/typescript-type-safety-discipline-zod-nevererror-no-any) principle). * * * ## Decision flowchart * * * ## 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.