Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Removing data transfer fees when moving off Google Cloud

cloud.google.com

Post reply on HN
Print view View original

51–60 of 113 posts

Re: Removing data transfer fees when moving off Google Cloud

#51

Post by timenova »

Patrick_Devine wrote: post #40
gnfargbl wrote: post #21

So on the one hand Google now accepts that egress fees are outrageous. Great! On the other hand, they're only reducing (removing) the fees when you leave them. If this move were really about acting in customers' best interests, they would reduce the fees for everyone. Doing this only for departing customers feels performative.

Google is part of Cloudflare's Bandwidth Alliance [1] which is removing most egress fees. Google still charges for egress, but it's half of what AWS is charging. We moved everything off of S3 anyway and have been using Cloudflare's R2 storage along with Google Compute Engine instances. R2 can be a little flaky, but the cost savings for us more than makes up for it. [1] https://www.cloudflare.com/bandwidth-alliance/

Can you give a few more details on the flaky nature of R2?

Does it lose files? Fails to write but gives an error? Fails to read sometimes? Silently fails?

Re: Removing data transfer fees when moving off Google Cloud

#54

Post by qwertox »

TulliusCicero wrote: post #48
blibble wrote: post #18

Earlier quoted context omitted.

I read through a couple of these responses to the CMA by MS, Google and AWS and their smaller competitors as expected the hyperscalers refuse to acknowledge that the free ingress and expensive egress is a lock-in mechanism, and their smaller competitors complain bitterly about this the hyperscalers say they have to charge egress fees to pay for the costs in building their networks, but for some reason doesn't apply t…

"Egress can be no more expensive than ingress" seems like a reasonable rule.

But not during normal operation when egress to consumers is in higher demand than ingress. This would raise ingress prices unnecessarily.

Re: Removing data transfer fees when moving off Google Cloud

#55

Post by scottlamb »

logifail wrote: post #31
charcircuit wrote: post #22

Earlier quoted context omitted.

>but for some reason doesn't apply to ingress (which they're silent on) The industry standard for peering is paying the 95th percentile of egress or ingress depending on whichever is greater. Ingress is free for these clouds because egress > ingress overall.

> The industry standard Pfft... > for peering is paying the 95th percentile of egress or ingress depending on whichever is greater. Ingress is free for these clouds because egress > ingress overall How about customers pay for actual usage, rather than some [fake] averaged-across-all-customers usage?

Why would the cloud provider charge for usage that doesn't actually cost them money? Unless usage patterns drastically change industry-wide, the ingress really doesn't matter to them. The egress does.

It seems entirely reasonable to look more skeptically at cloud providers' exact charges vs cost for egress, particularly when high egress fees might contribute to lock-in, and when the public price sheet vs the preferred customer pricing might differ radically. But asking them to totally restructure the charges, inventing a charge for ingress when their actual total ingress cost is zero and, short of major industry-wide usage pattern changes, will remain zero? Why would you do that?

Re: Removing data transfer fees when moving off Google Cloud

#56

Post by arccy »

londons_explore wrote: post #47

The process seems a bit cumbersome... Why not: 1. Migrate your data out. 2. Close your account. 3. You will automatically be refunded all network egress fees incurred in the final 60 days, capped at the number of gigabytes you had stored in our products in the preceding 60 days.

your suggestion sounds more cumbersome (and probably refunds less)

Re: Removing data transfer fees when moving off Google Cloud

#57

Post by donalhunt »

oh_sigh wrote: post #39
jiveturkey wrote: post #16

Earlier quoted context omitted.

I don't see it that way at all. Those egregious egress charges still apply while you are actively using GCP, encouraging you to put everything in GCP, and eschew multicloud. This seems to me more of a "try us out for free" play. Bring your big data here, if you end up not liking it, we won't penalize you for taking your data out. Given that GCP is running at a very distant 3rd, they need to make plays like this.

It could also be a method to put pressure on AWS to get rid of their egress fees. If it doesn't work - GCP looks a little better compared to AWS If it does work, AWS users will have an easier time extricating themselves from the platform, and possibly going to GCP.

This. I see this as purely an attempt to influence AWS in lowering the barriers of migrating between clouds. But also makes sense for those who want the option to test the waters with no downside.

Re: Removing data transfer fees when moving off Google Cloud

#58

Post by NBJack »

mschuster91 wrote: post #50
blibble wrote: post #18

Earlier quoted context omitted.

I read through a couple of these responses to the CMA by MS, Google and AWS and their smaller competitors as expected the hyperscalers refuse to acknowledge that the free ingress and expensive egress is a lock-in mechanism, and their smaller competitors complain bitterly about this the hyperscalers say they have to charge egress fees to pay for the costs in building their networks, but for some reason doesn't apply t…

> the hyperscalers say they have to charge egress fees to pay for the costs in building their networks, but for some reason doesn't apply to ingress (which they're silent on) because ingress traffic volume is a fraction (in my experience, in website hosting of a well known household brand, barely 1%!) of egress traffic volume, and most peering connections are 1:1 in ingress/egress bandwidth so the egress bandwidth co…

This also holds true on thebflip side for most consumer internet speeds (at least in the US).

Many people have a x00 Mbps or even x Gbps downstream, but most have no more than x0 Mbps upstream. Literally their ability to pull traffic from websites is 50X in some cases than to push information out. Going beyond that (greater uploads) often costs significantly more.

Whether or not these two are actually related isn't clear to me, but it is interesting.

Re: Removing data transfer fees when moving off Google Cloud

#59

Post by amluto »

jeffbee wrote: post #41
dekhn wrote: post #38

Earlier quoted context omitted.

Blocking is a common concept in packet switched networks; for example, a packet switch with a full crossover can be called "non-blocking". A switch is either going to queue or discard packets, and at the rates we're discussing, there is not enough buffer space so typically if a switch gets overloaded it's going to drop low priority packets. Obviously many things have changed, there are ethernet pause frames and admis…

The whole word smacks of Bellhead thinking. With ethernet you put a frame on the wire and hope.

The term “non-blocking” may well originate with circuit switching, but Ethernet switches have referred to the behavior of supporting full line rate between any combination of inputs and outputs as “non-blocking” for a long time. (I wouldn’t call myself an expert on switching, but I learned IOS before there was a thing called iOS, and I think this usage predates me by a decent amount.)

> With ethernet you put a frame on the wire and hope.

This is not really true. With Ethernet, applications and network stacks (the usual kind — see below) ought to do their best to control congestion, and, subject to congestion control, they put frames on the wire and hope. But network operators read specs and choose and configure hardware to achieve a given level of performance, and they expect their hardware to perform as specified.

But increasingly you can get guaranteed performance on Ethernet even outside a fully non-blocking context or even performance exceeding merely “non-blocking”. You are fairly likely to have been on an airplane with controls over Ethernet. Well, at least something with a strong resemblance to Ethernet:

https://en.m.wikipedia.org/wiki/Avionics_Full-Duplex_Switche...

There are increasing efforts to operate safety critical industrial systems over Ethernet. I recall seeing a system to allow electrical stations to reliably open relays controlled over Ethernet. Those frames are not at all fire-and-hope — unless there is an actual failure, they arrive, and the networks are carefully arranged so that they will still arrive even if any single piece of hardware along the way fails completely.

Here’s a rather less safety critical example of better-than-transmit-and-hope performance over genuine Ethernet:

https://en.m.wikipedia.org/wiki/Audio_Video_Bridging

(Although I find AVB rather bizarre. Unless you need extremely tight latency control, Dirac seems just fine, and Dirac doesn’t need any of the fancy switch features that AVB wants. Audio has both low bandwidth and quite loose latency requirements compared to the speed of modern networks.)

Re: Removing data transfer fees when moving off Google Cloud

#60

Post by lokar »

toast0 wrote: post #30
blibble wrote: post #27

Earlier quoted context omitted.

I accept there's some level of cost, but the prices are so high it's hard to describe it as anything other than gouging to prevent competition

My personal feeling is they're moving costs around so that egress has a big margin and other items have a smaller or potentially negative margin. I've seen this at other providers. We did a competitive pricing exercise at my last company, and our overall cost went down, but the mechanism was per hosts costs went down significantly and egress costs went up significantly, and the per host cost decrease outweighed the e…

Many companies in many industries do this. It’s often simply not practical or sensible to price every SKU “fairly “ on some value or cost basis. Your margin varies from item to item (including negative) and the whole bundle works out.
Post reply on HN