Vimeo is actually correct and you're about to become the next niche online creator subsidy vehicle Vimeo doesn't have the scale necessary for peering and is thus getting a raw deal on bandwidth that you've managed to avoid somehow Vimeo is very wrong about how they calculate their bandwidth costs per user Everything I know about how networks pay each other for this would suggest that you're charging a blended rate for a good whose cost is highly variable. I have to wonder how your pricing model of 'views' is going to fare when Vimeo is dumping what they consider to be their worst customers onto you.

They are so big that every ISP absolutely has to peer with them, and that drives down their costs significantly.

This is the particular reason why Google is able to provide YouTube at all. Vimeo's cited custom plan pricing in the article is basically assuming a video per month on average at those rates. Delivering that over 800 views will run about $320 per video. Given that I can't find hosting providers with lower bandwidth costs, DO/Vultr either have very specific peering agreements or are subsidizing their bandwidth charges either of which would be utterly broken by the amount of bandwidth that the person from the article appears to need for their multi-hour art tutorials.Įven if they had an amazing deal on transit, or were peered with everyone, and were able to provide $0.01/GB to video hosting at scale, we're still talking 20-40GB/view (assuming 45Mbps delivery of multi-hour video content). I looked at AWS EC2 and Fastly and they both cited outgoing bandwidth that was twice as high. The $0.05/GB pricing cited is for CDN delivery, which implies having a bunch of servers in different areas of the world ready to deliver your files wherever they need to be. (All this gets upended if you're on something like SFDC or Dynamics, though, where costs looks nice and forecastable until you get to disk storage, where their pricing models appear to be put together by the kind of guys who usually present their invoices alongside a menacingly-brandished lead pipe.) ).ĭepending on what your application is, this may never be an issue, or, if you're pushing heavy file and content traffic, it could form a huge chunk of variable costs that you need to figure out cost recovery for in your business model. (The ever-invaluable Duckbill does a nice job of laying out all the places where AWS levies its bandwidth tax. Bandwidth and network services, however, are insanely expensive for what you get, show up all over your service architecture, and are hard to forecast, so they like to jump out of dark corners at the end of your billing cycle and mug you. Yeah, it's really just a way to talk through cloud architectural choices when you're designing for cost: committing to reserved instances for VMs (goodbye, eternal soul - for at least the next three years), minimizing your data retention or migrating through storage classes for bucket data, and ruthlessly optimizing your use of per-usage services (bucket ops, API calls, serverless functions, and charge-per-op databases like Firebase, to name a few).

Vimeo pricing