GCP offering 200Gb free egress on their Standard Tier
We are writing to let you know that starting October 1, 2023, all existing and new Standard Tier Egress customers will avail their first 200 GB for free in every region that they choose to operate, after which Standard Tier will be billed at current rates.
What do you need to know? The 200 GB meter will reset every month. We’re introducing this offer to make it frictionless for customers to start using Standard Tier egress with their Virtual Machines.
Today, there is no free usage tier for Standard Tier Egress. With this MSA, we are introducing a free tier of egress to our Standard tier customers.
What do you need to do? No action is required on your part. However, if you currently consume Standard Tier Egress, you will notice a slight reduction in the billed amount starting October 1, 2023. You can also review our standard billing rates.
Thanks for choosing Standard Tier Egress
27 comments
[ 33.9 ms ] story [ 110 ms ] threadI work for a gcp customer, but we don't have anything deployed to europe-west9, so I don't have direct exposure. As I recall, we did see some difference in geodns routing on that day, but it was unclear if it was related or not.
[1] https://status.cloud.google.com/incidents/dS9ps52MUnxQfyDGPf...
europe-west9-a was clearly messed up, and for a long time; which I think is fairly reasonable if you have to toss out at least 58% of the hardware because of water and smoke damage. c'est la vie. That -b and -c were unavailable during the incident is not how availability zones are supposed to work, and it's bad; but you seem to be claiming that -b and -c were down for weeks afterward and I don't see that reflected in the links you shared.
If you demand a 3 availability zone system, and one availability zone had a disaster; the right thing to do is to move to another region which has three working azs (and hope that one is properly setup; or request an audit if you've got leverage). Cloudyness is supposed to make it easier to move infrastructure. But if likeminded customers are all moving infrastructure, there's going to be a capacity crunch. OTOH, GCP has several regions in europe-west, and there's a lot of interconnections in Europe in general, so unless you had a requirement to domicile data in France, lots of options.
Multiple Google Cloud services in the europe-west9 region are impacted.
'Water intrusion in a data center in europe-west9 caused a multi-cluster failure that led to a shutdown of multiple zones. We expect some unavailability in the europe-west9 region. There is no current ETA for full recovery of operations in the europe-west9 region at this time. We expected to see an extended outage for some services. Customers are advised to failover to other regions if they are impacted.'
can you please explain to me how water intrusion in a data center cause a region failure? there is only one reason. they lied. most likely overhyping the region resiliency. how after seing that can you trust them to host critical apps is beyond belief.
and if you look the resolution link I shared they kept hiding reality behind fuzzy language.
'After Regional Spanner, IAM and GCE/PD came back online for the region, almost all of the services in the region fully recovered soon after that. The following services either took longer to recover or had additional impact during the outage.
Google Cloud Storage, Google BigQuery, Cloud Bigtable, Cloud SQL, Cloud Pub/Sub, Google Cloud Dataflow Please log a case with our Support team if you would like to receive additional information regarding these services.'
please look the last sentence and I can tell you it was way more than a day for those services. try to get additional info on how long bigquery/bigtable were offline.
Clearly, they fucked up, and didn't distribute critical infrastructure adequately across the region. There's lots of ways this kind of thing happens. I've had 'redundant fiber' that was running in the same bundle and got severed by the same backhoe, for example. The easiest way to determine if there's a dependency on a particular building is to forcibly de-energize all the equipment in it. In this particular case, it seems like there was a mistake in allocation of instances for the regional Spanner database, resulting in that database becoming unavailable when the building was de-energized; and then lots of services depend on regional Spanner, because that's its intended use.
It sounds like they did an audit of regional Spanners after this incident, but who knows what other hidden dependencies there are there, or at any cloud provider. Having your critical apps available in multiple distributed datacenters is best practice; having that all in one city isn't really. In an ideal world, you're not dependent on any single entity you don't control; but egress charges make that difficult.
Re: Bigquery, there's a separate post for that [1] which seems to indicate "The issue with Google BigQuery has been resolved for all affected users as of Wednesday, 2023-04-26 17:05 US/Pacific." The incident began around "26 Apr 2023 06:25 PDT", so resolution was next-day (but that's about 35 hours). If you've got other data on BigQuery, that's fine; I'm not saying your experience is wrong, I'm saying it doesn't match the public record.
[1] https://status.cloud.google.com/incidents/TbcwMSkKy8MTmeeEiq...
https://thenewstack.io/paris-is-drowning-gcps-region-failure...
Honestly, it’s better than DO and Linode.
Didn't AWS had in the last year two or three large scale events that paralyzed the web?
Edit: here's a discussion over one of the times AWS's us-east-1 was down this year.
https://news.ycombinator.com/item?id=36315300
I don't think this is true at all. The cloud is just a fancy word for using someone else's computational resources, and the cloud's main selling points is not having to host or manage your hardware, and be able to scale on demand. A third less mentioned topic is being able to have global deployments.
None of these items imply a limit on how "big" are your computational needs. In fact, it's well established that once a company grows its cloud needs after a threshold, it becomes far more cost-effective and performance to just manage your own hardware and infrastructure.
Lastly, even AWS frames itself as the go-to solution to grow from zero to launch.
Today, is more important the time to market. You can use existing services to build your application, there are customers that don't have access to a pool of data scientist to run their own ML training for example. These would rather benefit from high level services that help them to deliver functionalities just by using APIs.
> it becomes far more cost-effective and performance to just manage your own hardware and infrastructure.
This is very wrong too. First of all managing hardware is not just buying a server and placing it in your room. There are plenty of other business functions needed to run an effective datacenter. Procurement, hardware eng, sys admin, security (net, app, etc) and the list goes on.
You can do that if you reach a critical mass or if you are able to attract the right talents for that.
Big enterprise customers will settle for a suboptimal usage of their resources with limited capabilities to expand further or settle for one size fits all. You need a DB? We bought 15mil on Oracle licenses sorry about that, your no SQL needs or your vector search would be better make it work there.
As I said earlier, eventually this affects the time to market. Which is a far more important measure than cost for business. Especially thanks to the agility. If it doesn't work they tear it down, you don't need to keep paying for it.
Also Cloudflare R2 for object storage - zero egress fees.