71–80 of 113 posts
The cynical might wonder if this is a precursor to Google closing down its cloud. They can't really shut Google Cloud down and still be charging people to exit. And if they had suddenly seen the light on egress fees then surely they would have cut egress fees everywhere..... the fact that it's only on account closure is kinda suspicious.
The fine print: https://cloud.google.com/exit-cloud * Free data transfers related to Google Cloud Exit are available on Premium Tier Network Service Tier * Only data residing in Google Cloud data storage and data management products are covered * You must report any changes to your migration timeline set out in your request form to the Google Cloud Support team * You must submit your free data transfer request prior…
Is requiring a Google committee review/application process a new trend with Google products? I recently was denied on another application through Google for API access to get one businesses GMB reviews, and it's frustrating because there's no recourse. Google is so opaque now.
Earlier quoted context omitted.
> to even delete it would cost thousands in API calls raises eyebrow It's a well-known trick (proposed by AWS Support as well) to set S3 lifecycle rules to empty buckets with too many objects to cycle through via List calls. Doesn't cost anything.
There's still a cost for transitions even if it's not list calls. That might be cheaper I haven't looked in a while.
I bet there's some new regulation being implemented here that they just happened to forget to mention in the post.
This is a smart play that costs them basically nothing. Remember that egressing data costs customers at worst 3x the monthly cost of storing it. Nobody is avoiding leaving because of the egress fee.
What this does do is assuage the “lock-in” fear common in cloud-reluctant customers, while presents them as being forward thinking.
I’ve never heard of a cloud migration where the data egress wasn’t at least an order of magnitude less than the engineering cost of the migration itself.
> Certain legacy providers leverage their on-premises software monopolies to create cloud monopolies, using restrictive licensing practices that lock in customers and warp competition. I like to see them publicly call out Microsoft and Oracle.
Google should have made the same announcement without the snarky mean-spirited bitterness.
Earlier quoted context omitted.
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…
> With Ethernet, applications and network stacks (the usual kind — see below) ought to do their best to control congestion Exactly. Network endpoints infer things about how to behave optimally. Then they put their frame on the wire and hope. The things that make it possible to use those networks at high load ratios are in the smart endpoints: pacing, entropy, flow rate control, etc. It has nothing at all to do with t…
A ratio has a numerator and a denominator. I can run some fancy software and get (data rate / nominal network bandwidth) to be some value. But the denominator is a function of the network. I can get a few tens of 10Gbps links all connected together with a non-gold-plated nonblocking switch that’s fairly inexpensive (and even cheaper in the secondary market!), and each node can get, say, 50% of 10Gbps out as long as no node gets more than, say, 50% of 10Gbps in. That’s the load ratio.
Or I can build a non-gold-plated network where each rack is like this and each rack has a 100Gbps uplink to a rather more expensive big switch for the whole pile of racks, and it works until I run out of ports on that big switch, as long as each rack doesn’t try to exceed the load ratio times 100Gbps in aggregate. Maybe this is okay for some use case, but maybe not. Netflix would certainly not be happy with this for their content streaming nodes.
But this all starts to break down a bit with really large networks, because no one makes switches with enough ports. So you can build a gold plated network that actually gets each node its full 10Gbps, or you can choose not to. Regardless, this isn’t cheap at AWS scale. (But it may well be cheap at AWS scale, amortized per node.)
And my point is that egress does not add meaningful cost here. A 10Gbps egress link costs exactly as much, in internal network terms, as a compute or object storage node with a 10Gbps link. For an egress node, it costs whatever 10Gbps of egress transit or peering costs plus the amortized internal network cost, and a compute node costs whatever the cost of the node, space, power, cooling, maintenance etc costs, plus that internal network link.
So I think there is no legitimate justification for charging drastically more for egress than for internal bandwidth, especially if the cost is blamed on the network cost within the cloud. And the costs of actual egress in a non-hyperscaler facility aren’t particularly secret, and they are vastly less than what the major clouds charge.
Hi. I fix AWS bills for a living and also shitpost a lot. This is a smart play that costs them basically nothing. Remember that egressing data costs customers at worst 3x the monthly cost of storing it. Nobody is avoiding leaving because of the egress fee. What this does do is assuage the “lock-in” fear common in cloud-reluctant customers, while presents them as being forward thinking. I’ve never heard of a cloud mig…