Zero Bandwidth Hosting: Why Edge Platforms Skip the Meter

Your product succeeds. Traffic doubles. Then the hosting bill arrives and doubles too. Not because you added features. Not because you used more compute. Because your users looked at your pages.

That is the bandwidth trap. And it is the single most overlooked cost driver in modern hosting.

Some platforms charge you per gigabyte of data transferred. Others include bandwidth entirely. The difference between those two models is negligible when you are small. It is enormous when you scale. Understanding why some platforms can afford to skip the meter -- and what that means for your architecture decisions -- is the difference between a hosting bill that grows linearly with success and one that stays flat.

The Two Models

There are fundamentally two approaches to bandwidth pricing in the hosting market today.

Model 1: Metered bandwidth. You get an allocation -- typically 100GB to 1TB per month depending on your plan. Exceed it and you pay per gigabyte. Vercel charges $0.15 per gigabyte after exceeding the Pro plan's 1TB allowance. AWS CloudFront charges roughly $0.085 per gigabyte. These numbers sound small until you multiply them by the terabytes that a successful application serves.

Model 2: Zero bandwidth charges. The platform includes all data transfer in your base price. No meter. No overage. No surprise line items. Cloudflare pioneered this model. Platforms built on Cloudflare's network -- including Waymaker Host -- inherit it.

The distinction is not a marketing gimmick. It reflects a fundamental difference in how these companies make money.

Why Metered Platforms Charge for Bandwidth

Traditional cloud providers and the platforms built on them treat bandwidth as a consumable resource. AWS charges for data transfer out of its regions. Vercel, which runs on AWS infrastructure, passes some of that cost to you through its own metering.

The math is straightforward. When your infrastructure provider charges you for every byte that leaves the data centre, you charge your customers for every byte that leaves the data centre. The margin sits between what you pay AWS and what your customer pays you.

This model works well for the platform. It creates a revenue stream that scales automatically with customer success. The more popular your application becomes, the more you pay. For the platform, your growth is their growth -- in the most literal, invoice-level sense.

For you, though, it creates a cost curve that bends upward at exactly the wrong moment: when your product is gaining traction but before revenue has caught up.

What the Numbers Look Like

Consider a content-heavy web application -- a portfolio site, an image gallery, a documentation platform, a dashboard with charts and media. At modest scale, bandwidth costs are invisible.

At 1,000 users, the models are identical. At 100,000 users, you are paying $1,350 per month just for the privilege of delivering bytes to browsers. Not for compute. Not for storage. For transfer.

And these estimates assume standard web pages. If your application serves high-resolution images, video thumbnails, large documents, or API responses with substantial payloads, the curve steepens faster. A camera platform, a design tool, a media-heavy SaaS product -- any of these can hit the overage threshold with far fewer users.

The bandwidth bill is often the first cost that doubles when your product succeeds. Not the one you planned for.

Why Edge Platforms Can Afford Zero Bandwidth

Cloudflare does not charge for bandwidth because bandwidth is not how they make money. Understanding this is the key to understanding why the zero-bandwidth model is sustainable, not subsidised.

Cloudflare operates one of the largest networks in the world -- 330 or more locations in cities across every continent. They built that network to sell security services: DDoS mitigation, Web Application Firewall, bot management, SSL/TLS, and enterprise threat protection. The network exists to inspect and filter traffic. Serving that traffic to end users is a byproduct, not the product.

When you deploy on Cloudflare's network, your data does not leave a centralised data centre, traverse the open internet, and arrive at the user's browser. It is already at the edge -- cached in the city closest to the user. The marginal cost of serving a cached response from a location that already exists, already has power, already has connectivity, and already handles traffic for security purposes is close to zero.

This is the critical insight: Cloudflare does not lose money by including bandwidth. They have already paid for the network. Serving your content is a rounding error on their security revenue.

AWS, by contrast, built data centres to sell compute. Bandwidth is a profit centre, not a cost of doing business. The same byte costs them money to move out of the region, and they pass that cost -- with margin -- to every platform built on top of them.

The business model difference is architectural:

• AWS model: You rent compute in a region. Moving data out of that region costs money. Platforms on AWS inherit that cost.
• Cloudflare model: You deploy to a global network that already handles traffic. Data does not leave because it is already everywhere. The cost structure is fundamentally different.

What This Means for Your Architecture

The bandwidth pricing model does not just affect your invoice. It affects how you design your application.

On metered platforms, you optimise to avoid transfer

Teams on metered bandwidth learn to compress aggressively, defer image loading, reduce payload sizes, and cache at every layer. These are good practices regardless. But on a metered platform, they are also cost-avoidance strategies. Every unoptimised image, every large API response, every redundant asset download is a line item on next month's bill.

This creates a subtle tax on product decisions. Should you serve high-resolution product images? Mathematically, each image costs money. Should you offer a generous API with detailed responses? Each byte counts. Should you embed video previews? The bandwidth math says no.

When transfer is metered, your product team is unconsciously in a negotiation with your infrastructure bill. Every feature that increases data transfer increases cost.

On zero-bandwidth platforms, you optimise for the user

When bandwidth is included, the calculation changes. Serve the highest-quality images your users need. Return detailed API responses. Embed rich media. The cost of delivering a 2MB page versus a 200KB page is identical: zero incremental.

This does not mean you should be wasteful. Performance optimisation -- smaller bundles, efficient caching, responsive images -- still matters because it affects load time and user experience. But the motivation shifts from cost avoidance to quality improvement. You optimise because faster is better, not because slower is expensive.

That distinction matters more than it sounds. Teams that optimise for cost make different decisions than teams that optimise for users. Over hundreds of product decisions across months of development, the cumulative effect is significant.

The Edge Performance Bonus

Zero-bandwidth platforms built on edge networks deliver a second advantage that compounds the first: latency.

Traditional platforms serve content from a handful of regions -- typically 15 to 25 worldwide. A user in Jeddah might be served from Frankfurt. A user in Auckland might be served from Singapore. The further the data travels, the longer the wait.

Edge networks operate in hundreds of locations. Content is cached and served from the city the user is in, not a region somewhere on the same continent. For a global user base, the difference between 20 regions and 330 locations is measurable in every page load.

For applications with users in multiple countries, the edge model delivers consistently fast experiences without geographic luck determining load times. And because all of this traffic is included in your base price, serving users in 55 countries costs the same as serving users in one.

The combination -- zero bandwidth charges plus global edge delivery -- means that scaling internationally does not create a new cost line. You do not pay more to serve Australia, the Middle East, and South America. You serve them all from local edge nodes at no incremental cost.

When Metered Bandwidth Makes Sense

Metered bandwidth is not always the wrong model. At small scale, the included allowances on platforms like Vercel are generous enough that most teams never hit the limit. If your application serves lightweight pages to a domestic audience, bandwidth costs may never become material.

Metered also makes sense when you are locked into a specific framework with deep platform integration. Vercel's Next.js support is unmatched -- they built the framework. If you need ISR, streaming server components, and day-one feature support, the bandwidth cost may be an acceptable trade-off for developer experience.

The question is not whether metered bandwidth is inherently bad. The question is whether your growth trajectory will turn it into your largest infrastructure line item. If you serve media, images, documents, or API payloads at scale, the answer is almost certainly yes.

The Decision Framework

The right bandwidth model depends on your application profile and growth expectations.

Metered bandwidth is acceptable when:

• Your application is lightweight (text-heavy, minimal media)
• Your user base is concentrated in one or two regions
• Your monthly active users are under 10,000 and growing slowly
• You need framework-specific features that only the metered platform provides

Zero bandwidth is the better model when:

• Your application serves images, documents, video, or large payloads
• Your users are distributed across multiple countries or continents
• You expect significant growth in the next 12 to 24 months
• Predictable hosting costs matter for your financial planning
• You want product decisions driven by user experience, not transfer cost

For teams evaluating a switch from metered to edge-based hosting, the trigger is usually the first month where bandwidth overage appears on the invoice. That is the moment the invisible cost becomes visible -- and it only grows from there.

The Bigger Picture

Bandwidth pricing is one piece of a larger shift in how hosting platforms are structured. The traditional model -- rent compute in a region, pay for everything that moves -- was built for an era when data centres were expensive and bandwidth was scarce.

The edge model reflects a different reality. Networks already span the globe. Content delivery is a commodity. The value has moved up the stack to what you do with the network: security, compute, orchestration, and platform intelligence.

Platforms that still charge per gigabyte are monetising a cost that their infrastructure has already commoditised. Platforms that include bandwidth are acknowledging that reality and competing on what actually matters: the tools, the developer experience, and the platform capabilities that sit on top of the network.

For businesses building software in 2026 and beyond, the question is not just "where do I host my app?" It is "what does my hosting cost when my app succeeds?" If the answer includes a bandwidth meter, you are paying a tax on your own growth.

The platforms that skip the meter are not being generous. They are being honest about what bandwidth actually costs them. And they are betting that you will choose the platform where success does not come with a surcharge.

---

Building on Waymaker Host? Apps deploy to a global edge network with zero bandwidth charges, zero per-invocation fees, and 330+ edge locations worldwide. Your hosting bill stays flat while your user base grows. Learn how Host works or see the real cost of scaling on metered platforms.

---

Related reading: Understand what happens when your hosting bill doubles, learn when it makes sense to switch platforms, or explore why the cost of app sprawl compounds faster than you think.