To a lot of managers/startup execs this is something like "we won't ever need this". And I'd agree to some extent for not so important/rebuildable services. Depends on what you need. In startups, you don't have infinite time you can spend on stuff. But this makes a good case: if a geographical region only has one AWS region, don't keep data or run services that can't be easily rebuild somewhere else. In europe you can just pick two AWS regions and you stay in the same regions, UAE not so much.

There’s a reason literally every enterprise of any size in the early 00s not only had a DR site, but a DR plan they would test multiple times per year.

1. Just having a copy in two places doesn’t mean the copies are both good or that you can get DR online in any reasonable amount of time.

2. You quickly figure out all the things you thought “weren’t important” that prevent you from actually doing a successful DR test.

They amount of things that “cloud first” people just assume naturally takes care of itself because it’s in the cloud always amuses me.

You should have that for your main data, yes. I insist on that as well. Making backups, cold storage, and getting them back online. Yearly is not enough. My point was that not everything needs a backup or a DR. Spend your time wisely, we're talking startups, not enterprise. Can't talk more specifics obviously

The fact half the internet was down the last time US east was down tells me it’s not just startups that foolishly think they don’t need actively tested dr copies and plans when they move to the cloud.

I don't think this changes anything. It is always the same argument for me.

"How often do those happen?"

That was my point: now we have a very specific case we can argue. I always used the "what if a plane crashes into the data center" argument. Now I can say: in one of my engagements, we lost a datacenter completely because of a drone attack. That's a first for AWS as well, but we can draw from reality, not hypotheticals.