| ▲ | dangoodmanUT 2 hours ago |
| It has been 0 days since GCP has taken down a startup (again). You see this at least once a year. Never heard of this from AWS or Azure. In all seriousness, this is why we don't use them. They have the most ergonomic cloud of the big three, then absolutely murder it by having this kind of reputation. |
|
| ▲ | somewhatgoated an hour ago | parent | next [-] |
| On the other hand i can’t remember when there was a serious outage on GCP, unlike AWS/Azure who seem to go down catastrophically a couple of times per year. |
| |
| ▲ | adamtaylor_13 a minute ago | parent | next [-] | | Perhaps you don't notice GCP outages because so few companies rely on them? | |
| ▲ | plandis 31 minutes ago | parent | prev | next [-] | | GCP has had outages. From a quick search it looks like they had a global outage less than a year ago: https://status.cloud.google.com/incidents/ow5i3PPK96RduMcb1S... | |
| ▲ | abofh 26 minutes ago | parent | prev | next [-] | | I've been in AWS for almost twenty years at this point. It's been a long time since I've seen a global outage of the data plane on anything. The control plane, especially the US-east-1 services? Yes - but if you're off of east-1, your outages are measured in missile strikes, not botched deployments. | |
| ▲ | pixl97 33 minutes ago | parent | prev | next [-] | | GCP never goes down because they banned all their customers. | |
| ▲ | JoRyGu an hour ago | parent | prev | next [-] | | AWS goes down catastrophically but are back up in minutes/hours most of the time (as long as they aren't down because Iran blew up their data center). That's obviously REALLY bad for certain industries, but I suspect for the vast majority of their customers it's not a big deal. We've been able to isolate the damage almost every time just by having AZ failover in place and avoiding us-east-1 where we can. | |
| ▲ | blobbers 15 minutes ago | parent | prev | next [-] | | Unfortunately, if everyone goes down people are understanding. If just _you_ go down, then its oddly less forgiveable. | |
| ▲ | corpoposter an hour ago | parent | prev | next [-] | | IIRC the Paris datacenter flood took down a whole “region” and some data was permanently unrecoverable. | |
| ▲ | danesparza 9 minutes ago | parent | prev | next [-] | | You can read the parent post, right? | |
| ▲ | Izikiel43 5 minutes ago | parent | prev | next [-] | | I still remember the one where they nuked all the storage of I think an Australian insurance company I think, luckily the it department had done a multi cloud setup for backups | |
| ▲ | devmor 31 minutes ago | parent | prev [-] | | There was a pretty bad one last summer - their IAM system got a bad update and it broke almost all GCP services for an hour or so, since every authenticated API call reaches out to IAM. It had lasting effects for us for a little over 3 hours. |
|
|
| ▲ | overfeed an hour ago | parent | prev | next [-] |
| > Never heard of this from AWS or Azure. AWS does it more efficiently; it takes down many startups at a time when us-east-1 goes down. |
| |
| ▲ | stingraycharles 43 minutes ago | parent [-] | | That’s an entirely different type of problem, and avoidable by just using us-east-2 (I still don’t understand why people default to us-east-1 unless they require some highly specific services). | | |
| ▲ | aloha2436 6 minutes ago | parent | next [-] | | Is it that easily avoidable? A lot of AWS's control plane seems to have dependencies on us-east-1, or at least that's what it's looked like as a non-us-east-1 user during recent outages. | |
| ▲ | MattGaiser 7 minutes ago | parent | prev [-] | | Sympathy. Railway is going to have numerous people blaming them for this outage. When us-east-1 fails, it is headline news, so you are not to blame. |
|
|
|
| ▲ | abrookewood 2 hours ago | parent | prev | next [-] |
| Yep, agree 100%. Such a stupid move on their behalf. |
|
| ▲ | rozap an hour ago | parent | prev | next [-] |
| Yep, we also don't touch them for this same reason. |
|
| ▲ | busterarm 11 minutes ago | parent | prev | next [-] |
| Hetzner and OVH also do this all the time. It's AWS and Azure that are the outliers and tend not to care too much what their customers do with their infrastructure. AWS is perfectly fine with allowing me to run copies of 15 year old vulnerable AMIs copied from AMIs they've long since deprecated and removed. Even for removed features like NAT AMIs. |
|
| ▲ | jameson an hour ago | parent | prev | next [-] |
| What was the reason GCP took down a startup previously? |
| |
|
| ▲ | tjpnz 2 hours ago | parent | prev [-] |
| AWS normally contacts you first. |
| |
| ▲ | kevin_nisbet an hour ago | parent | next [-] | | Do they? The only anecdotal thing I've seen is we hired a vendor to do a pentest a few years ago, and they setup some stuff in an AWS account and that account got totally yeeted out of existence by AWS if memory serves. | | |
| ▲ | dannyw an hour ago | parent | next [-] | | You should not be conducting unauthorized penetration tests against third party infrastructure providers without permission. They have processes and systems and usually just wants a heads up of what you plan to test and t the duration / timestamps. Cuz otherwise you look like a threat actor. That’s assuming your vendor was pentesting AWS systems. If you meant you hired a vendor to pentest your own systems on AWS, that’s of course a totally different matter. | | |
| ▲ | kevin_nisbet 44 minutes ago | parent [-] | | >That’s assuming your vendor was pentesting AWS systems. If you meant you hired a vendor to pentest your own systems on AWS, that’s of course a totally different matter. Sorry for being unclear, the vendor was attacking our organization only, and any other company was expressly forbidden in the contract. As I recall it was a fake SSO sign-in page to collect credentials that they would try and social engineer our employees with. |
| |
| ▲ | alchemism an hour ago | parent | prev | next [-] | | I’m fairly certain you are supposed to contact any vendor before attempting to penetrate hosts with authorization, not the other way around. | | |
| ▲ | coredog64 an hour ago | parent [-] | | Having done this for both Azure and AWS, there's a specific ticket that needs to be filed with each provider that documents the scope of your pen test, where you're coming from, and a time frame over which you're doing it (which ISTR was "not more than 24 hours") |
| |
| ▲ | mixdup an hour ago | parent | prev | next [-] | | Responding to an unknown security tester like that is a selling point, not a cautionary tale | | |
| ▲ | kevin_nisbet 38 minutes ago | parent [-] | | Yup, I thought it was great. Although one concern I always had in the back of my mind was where is the line drawn. Such as if an adversary gains access to one of my orgs accounts and does something similar, do we get 100% taken out. |
| |
| ▲ | 29 minutes ago | parent | prev [-] | | [deleted] |
| |
| ▲ | cherioo 2 hours ago | parent | prev [-] | | They better do. What is google doing? | | |
|
