Cloudflare R2 (their S3 clone) has free egress. We are in the middle of migrating about 5TB of fairly active data from Google Cloud Storage to R2. For years now, most of our cloud bill has been egress from GCS. Activity spiked recently and doing something about it became urgent. R2 has an S3-compatible API (we're using the Amazon-provided S3 Java SDK). Storage is 25% cheaper than GCS standard. Making our code multi-p…
Why cloud bandwidth is so obscenely expensive and what you can do about that
81–90 of 164 posts
Re: Why cloud bandwidth is so obscenely expensive and what you can do about that
#82Beware of cloud providers that don't "charge for egress" but do charge on a metric that is effectively a proxy for egress. For example, a cloud streaming service that charges for video delivery by per minute streamed is just charging for egress with extra steps.
Eh? If you're delivering video at scale there's no way anybody is going to do that for free? Whereas with AWS they charge you for traffic between AWS regions last time I checked?
Re: Why cloud bandwidth is so obscenely expensive and what you can do about that
#83Beware of cloud providers that don't "charge for egress" but do charge on a metric that is effectively a proxy for egress. For example, a cloud streaming service that charges for video delivery by per minute streamed is just charging for egress with extra steps.
Eh? If you're delivering video at scale there's no way anybody is going to do that for free? Whereas with AWS they charge you for traffic between AWS regions last time I checked?
Re: Why cloud bandwidth is so obscenely expensive and what you can do about that
#84It allows you to incrementally migrate off of providers like S3 and onto the egress-free Cloudflare R2. Very clever idea.
Re: Why cloud bandwidth is so obscenely expensive and what you can do about that
#85Re: Why cloud bandwidth is so obscenely expensive and what you can do about that
#86Earlier quoted context omitted.
If you can sign a yearly bandwidth commit (not sure what the minimum bandwidth requirement is, but 1PB / year may be in the ballpark) - you will get prices that are extremely competitive (maybe like 90%+ off base list pricing?)
You can get it down to ~1c/g at best then if you want cheaper you gotta build your own
Re: Why cloud bandwidth is so obscenely expensive and what you can do about that
#87Re: Why cloud bandwidth is so obscenely expensive and what you can do about that
#88Earlier quoted context omitted.
You can get it down to ~1c/g at best then if you want cheaper you gotta build your own
Did you see the sibling comment posted 45 minutes before you saying they pay 0.1c/g at aws when committing to spending 1500$/month?
Re: Why cloud bandwidth is so obscenely expensive and what you can do about that
#89I'm kind of amazed that AWS is the cheapest on this list, as they're typically the first example people give when they talk about overcharging for bandwidth. When I worked at Malwarebytes between 2008 and 2014 we measured our bandwidth in petabytes, but it was still only about $25k/month. This was obviously a custom contract, but it really is interesting how bandwidth pricing has remained relatively static over the l…
Yeah I think the list is only highlighting the worst offenders. It would be more useful to also include the cheap VPS providers mentioned later, that would be: - Scaleway: $0 - Hetzner: ~$490 _(article says bandwidth is free but I think above 20TB it's charged at 1 Euro/TB)_ - DigitalOcean/Vultr: ~$5k depending on compute usage _(you get a free bandwidth allowance based on compute)_
It doesn't say on the pricing page, VPS info page, or the various pdf documents with terms and conditions. Maybe you need to sign up and get to the ordering page before you can see the conditions applying to your VPS or maybe I overlooked it, but this is where I stopped looking
Re: Why cloud bandwidth is so obscenely expensive and what you can do about that
#90The other thing is that I’m not sure how willing I am to jump to endorse an efficient cache policy as a blanket prescription like they seem to. I suppose I’m not opposed to the advice, but it has very strong “draw the owl” vibes. Project requirements vary, and I’d even argue that sometimes minimal or no caching is wise when requirements are subject to change or you’re doing a lot of static deployments because the savings can sometimes not be worth the headache. End-users are very demanding nowadays. Sometimes “it’ll roll over soon” isn’t good enough. Caching is tricky. Make sure you really get it right in addition to doing the math on the cost-savings if you go down that road.