Hacker News Reader

Comment by michaelt | Hacker News Reader

Vimeo advertises [1] "Unlimited bandwidth" but that "Users in the top 1% of monthly bandwidth usage may be charged for excessive usage"

According to [2] the 99th percentile of bandwidth usage "usually starts at 2-3 TB per month"

Van Baarle has 4,446 patrons [3] and assuming a 1080p video stream is 5 Mbps, to hit the 2TB threshold would only need 12 minutes of video per patron, per month.

And you're right, of course, that if you're paying $0.05/GB for outbound bandwidth and using 2-3 TB/month, you're using $1200-$1800 of bandwidth per year. So $3500 isn't entirely beyond belief.

Still, the takeaway from this, for me, is that Vimeo's "unlimited bandwidth" is anything but.

[1] https://vimeo.com/upgrade [2] https://vimeo.zendesk.com/hc/en-us/articles/360037761072-Ban... [3] https://www.patreon.com/loish

View on HN

One point I'd make to clients when doing cost estimates was, essentially, that CPU and RAM want a long-term relationship, disk space likes to meet for a cup of coffee, per-use APIs say hi when they see you on the street, and bandwidth has an incandescent hate for you and is barely restraining itself from plunging a knife in your eye.

I feel like I both understand and don't understand this analogy. In my experience, databases want your eternal soul, and not in a good way. At least they are 80% of our cloud costs.

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). 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. (The ever-invaluable Duckbill does a nice job of laying out all the places where AWS levies its bandwidth tax: https://www.duckbillgroup.com/wp-content/uploads/2019/12/dbg...).

Depending 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.

(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.)

Pricing relative to your rank as a percentile has some weird properties, one month you might be in the 99% then next month it cost you big $$ in the 1% with exactly the same traffic.

That would be surprising to most people I’d expect, totally not deterministic and kinda hostile. A more explicit “unlimited = 2TB/month” no matter your percentile would be more honest, but then you’ve said “unlimited == limited” which is a lie.

The percentile thing seems like a fairly obvious hack to keep using the word unlimited. Probably an MBAs idea..

> Pricing relative to your rank as a percentile has some weird properties, one month you might be in the 99% then next month it cost you big $$ in the 1% with exactly the same traffic.

Yeah, it seems like one thing that could happen as a result of this is that the current top 1% of users will leave the platform, creating a new top 1% from the people who used to be the top 2%. Then these people will probably leave the platform as well, creating a new top 1%, and so on. It's a nice algorithm for getting rid of your most successful creators.

Not sure how much Vimeo cares to keep their most expensive loss leaders. The algorithm seems like it would work well though if there's some retention. You lose 0.75% off the top. Then again, and again a few times, but after a few iterations you've identified a top 1% that's willing to pay, and still have the other 99% for word of mouth advertising.

interesting idea, expect vimeo would be paying for bandwidth as a flat rate per GB/sec not per GB transferred. So their costs vs what they are charging would be quite different, also if their bandwidth costs are roughly flat (not based on transfer) then culling/causing churn in the 1% reduces the utilisation of their fixed cost.. or maybe they are running a very high utilisation and culling the top 1% every month gives them more headroom =)

That was the beginning of what I came here to say (to be followed by some other stuff that already got said).

step 2 of any analysis: project forward

You did this well.

Maybe they read HN =)

https://vimeo.com/blog/post/improving-policy-on-video-bandwi...

History shows anyone claiming "unlimited bandwidth" isn't going to offer truly unlimited bandwidth. It's an old hoster lie which continues to be recycled for subscriber growth.

> And you're right, of course, that if you're paying $0.05/GB for outbound bandwidth and using 2-3 TB/month, you're using $1200-$1800 of bandwidth per year. So $3500 isn't entirely beyond belief.

This is extremely expensive compared to cloudflare stream. They price it by viewing time instead of by counting bandwidth and quotes ~$500 to serve 72,000 minutes of viewing time.

Or if you're on budget you can convert your video to HLS with ffmpeg and host it on your own server from providers with cheap bandwidth like hetzner or ovh to save on cdn cost.

True, but if you compare to AWS, the S3 "First 10 TB / Month" tier is $0.09 per GB [1], and the Cloudfront "First 10TB" north America tier is $0.085 per GB and more for other regions [2] - or if you look at KeyCDN [3] for America that's $0.04 per GB, and again more for other regions.

So HillRat's $0.05/GB figure isn't the most expensive out there :)

[1] https://aws.amazon.com/s3/pricing/ [2] https://aws.amazon.com/cloudfront/pricing/ [3] https://www.keycdn.com/pricing

Reply on news.ycombinator.com