The Cloud Is Still Just a Network

I've spent enough time around network operator meetups and mailing lists to have developed an allergy to one specific sentence. Someone describes an outage, a slow failover, a routing mess, and someone else replies: "yeah, that's why we moved everything to the cloud." The conversation ends there, as if the phrase itself were a fire extinguisher. I want to push back on that reflex. The infrastructure itself is often fine. The reflex is the problem, because it substitutes a brand name for an actual risk assessment.

Start with the physical layer, because everyone forgets it exists. A hyperscale data center still needs power, still needs cooling, still needs fiber running through conduit that some backhoe operator hasn't heard of yet. Traffic between regions still travels over undersea cables, long-haul terrestrial routes, and peering points that a surprising number of internet users couldn't locate on a map. The company running the data center doesn't change what a backhoe can do to a buried cable, or what a fishing trawler's anchor can do to a subsea line. None of that risk went away. It just got a nicer dashboard sitting on top of it.

Redundancy is real, and also oversold

To be fair, large providers genuinely invest in redundancy in ways most individual companies never could on their own. Multiple availability zones, diverse peering arrangements, staffed network operations centers around the clock, engineers who think about routing anomalies before breakfast. That's not nothing. A small company running its own rack in one facility with a single uplink is worse off in almost every measurable way, and I wouldn't argue otherwise.

But redundancy inside one provider's network doesn't protect you from that provider's control plane, and control planes are exactly where a lot of the largest recent outages tend to live. A misconfigured update or a routing change pushed to the wrong region: these are software and process failures, and one provider's software and process now sits underneath an enormous share of the sites and apps people actually use every day. When it goes sideways, it doesn't take down one company's product. It takes down chat apps, banking portals, smart locks, and half the "is it down" checker sites people use to confirm it's actually down, all within the same few minutes, because they all quietly depend on the same handful of substrates.

That's the part the "just move to the cloud" narrative tends to skip over. Concentrating traffic behind a small number of providers doesn't eliminate fragility, it relocates and concentrates it. Before, you had thousands of independently operated networks, each capable of failing on its own schedule, mostly uncorrelated with one another. Now a meaningful fraction of daily internet traffic shares a blast radius with a handful of companies' internal tooling decisions. That's a different risk profile, and arguably a scarier one, because the failures get rarer and much wider at the same time. You've traded frequent, isolated incidents for infrequent, correlated ones.

Self-hosting isn't some golden alternative here, and I'd be lying if I said the old world of everyone running their own iron was a reliability paradise either. It mostly wasn't. Plenty of the NOG war stories I've heard involve homegrown infrastructure falling over in dumber ways than anything a major provider has done in public. What I'm arguing against is treating "we're in the cloud" as an answer to a resilience question, when it's really just a description of whose infrastructure you now depend on.

A better question, one I wish came up more in these conversations, is what happens to you when that provider has a bad day. Do you have a real fallback, or just an assumption that the bad day won't land on you specifically? Are you multi-region within a single provider, which helps with some failure modes and does nothing for others? Have you tested what breaks when DNS, identity, or the control plane goes sideways, or is your disaster recovery plan a paragraph nobody has opened since the day it was written?

Ask that question honestly and the usual answer sits somewhere between "we haven't fully thought about it" and "we assumed the provider had it handled." Both are reasonable starting points. Neither is a finished answer, and treating it as one is how a rare event turns into a very bad afternoon.