Hacker News Reader

Comment by nakodari | Hacker News Reader

I really wish they reduce their public bandwidth cost to half. It will make such a major impact on the internet as a whole that we will see lots of companies grow faster and newer video heavy apps launching.

View on HN

Here's a few ideas to start a video heavy app on a budget:

You could store files in a Backblaze B2 bucket and serve them via Cloudflare with zero bandwidth fees. Or try DigitalOcean's Spaces offering with their built-in CDN at $0.01/GB for bandwidth.

Hardware video encoding could be done using cheap Hetzner servers that include GTX 1080 GPU's (lookup NVENC) or try Intel Quick Sync encoding (perhaps using OVH's overclocked i7-7700K CPU's).

>You could store files in a Backblaze B2 bucket and serve them via Cloudflare with zero bandwidth fees.

From Cloudflare's TOS [0]:

>2.8 Limitation on Non-HTML Caching

>The Service is offered primarily as a platform to cache and serve web pages and websites. Unless explicitly included as a part of a Paid Service purchased by you, you agree to use the Service solely for the purpose of serving web pages as viewed through a web browser or other application and the Hypertext Markup Language (HTML) protocol or other equivalent technology. Use of the Service for the storage or caching of video (unless purchased separately as a Paid Service) or a disproportionate percentage of pictures, audio files, or other non-HTML content, is prohibited.

Of course Cloudflare offers commercial plans that feature video CDN, but it will cost you and it will cost you similarly to other video CDN providers.

[0] https://www.cloudflare.com/terms/

Yeah, I meant zero egress fees from B2. It's a shame that Cloudflare isn't more transparent about their bandwidth limits but my guess is that traffic would still be cheaper than from Amazon. Maybe someone from their team could weigh in ..

All this means is that your main website, where these files are embedded/served from, also needs to be on Cloudflare (and proxied).

I'm not sure that would follow

> disproportionate percentage of pictures, audio files, or other non-HTML content, is prohibited.

If your video sharing app has any decent usage your ratios are gonna get in their red zone pretty quick...

I think you have a very different idea of what constitutes "mainly HTML."

Base64 encode the video and embed it in the HTML?

E: typo

Using Backblaze which is only in US and Hetzner which is only in EU might not be the best idea, you might have issues with networking between locations.

Good point. The last I heard, they were still working on bringing up an EU location (I believe it was Amsterdam).

You can have multiple cheap origins behind your CDN, and use DNS to load balance/failover between them.

Is YouTube still operating at a loss? If so, then don't expect video distribution to be cheap.

They probably weren't ever operating at a loss. There were some stories speculating about YouTube's costs a few years back, but they were based on market prices for hosting which would be much, much higher than Google's internal costs.

Depends on how you want to measure revenue. YT itself is a massive cash hole. It's the advertising that carries it. YT Red (and other types of paid service) are bumps in the economic redline.

"Google has never revealed YouTube's revenue" but you can quantify it (roughly) from known values and costs.

Ultimately profitability of a product within Alphabet depends on how you want to categorize technology within Alphabet. DFP and YT, at the very least, are separate products.

Why do you think they have the margins to afford this?

What do you mean? Their bandwidth charges currently would be considered egregious for even a medium sized company. Someone the size of Amazon has obviously negotiated far, far lower peering rates than that. The only reason their outbound prices are so high is to keep people from getting out in a cost effective manner. They want to make customers think long and hard before leaving.

> The only reason their outbound prices are so high is to keep people from getting out in a cost effective manner.

This doesn't make any sense. Getting out is a one time operation, vs paying a higher recurring fee.

Lots of data must be kept for e.g. 7 years yet is never used. Maybe that should never have been in AWS in the first place, but once it's there this is a factor.

Amazon will happily ship you a disk : https://aws.amazon.com/snowball/disk/details/

That's not free either.

You can get an 80 TB Snowball to use for 10 days for $250, and pay a minor shipping charge to get it to and from the AWS datacenter. That's not free but its cheap enough that it should be a tiny decimal point percentage of the value of the 80 TB of business data you can fit on the Snowball.

And yes Snowball goes both ways: you can get data into AWS or out of AWS.

And how many businesses have 80TB of valuable data that is valuable when it's offline for potentially weeks while it's moved onto the snowball, shipped, taken off of the snowball, and then converted into a usable format onsite?

Ignoring the fact you lose all metadata transferring via snowball and any ACLs depending on the type of data and where you pulled it from. You can't pull from anything BUT S3 either. So that database? Sorry, online. The Glacier archive? Going to have to rehydrate it first.

The $250 is a rounding error for sure, but not on the cost of the data, on the cost of restoring the data. Even S3 itself you're ignoring the fact that you've got $2,500 in transfer fees alone on that 80TB.

Thanks, that's great info. Hopefully the snowball is considered to be in the same "availability zone"?

In theory, but this would not be true in practice. The cost is meant to make Redshift the default data warehouse versus that “cool new service” over there as an example. Each one of these types of decisions creates more AWS team expertise, and a harder decision to migrate to another service.

Getting out is not necessarily a one-time operation. It can mean switching some services to a competing offer, even just for an evaluation period. So for example, say, you're using a bunch of hosted AWS services and Google's BigQuery.

Their gross margin is over 20% according to their public reports and their networking margin is about 90% according to the AWS network engineer I talked to last year so I think they could afford it.

That doesn't seem high enough to justify halving prices unless it significantly increases revenue, which is pretty unlikely at this point.

But OP's hypothesis is "It will make such a major impact on the internet as a whole that we will see lots of companies grow faster and newer video heavy apps launching." Disagree with that if you like, but if that's true then the revenue will take care of itself.

Losing money on every exabyte and making it up in volume?

90% margins -> cut prices in half -> lose money?!?

Well, yes, if you're paying $1.00 per unit of bandwidth and selling it for $1.90, that's what will happen. What else would you expect?

I suppose that could be interpreted as ~50% margins, rather than ~90%. Not sure how that calculation is actually supposed to be performed.

20% Doesn't help to just consider network margins.

That's all we're talking about; thread parent said "reduce their public bandwidth cost to half". Obviously, you can argue that this price change idea is not strategically in AWS interest (AWS management agrees right now), but the trivial nitpicking ITT is misguided.

Reply on news.ycombinator.com