On AWS/Cloudflare, web centralization, and pride

Published on May 2, 2026

This post will be just a complaint with no real solution, but it’s worth keeping as a record of how we perceive our times. Consider yourself warned.

In October 2025, the main AWS region went offline due to a DNS issue in DynamoDB. In November 2025, Cloudflare experienced an outage due to a change in query behavior combined with insufficient safeguards in code. In both cases, “the internet”, this metaphysical entity, suffered, with many services going offline or becoming unusable. Websites down, social media unavailable, apps not working… you know the drill.

And the general reaction was a big “meh, it happens.” The community perception is that this is part of the job. That the price to pay for the convenience these services provide is to accept this 0.01% of downtime and just wait it out when it happens.

That stance makes me sad.

The rationale

The practical argument is familiar: Your application was built for the cloud, so there’s not much you can do if “the cloud” is down. There’s also limited impact, because if ““the cloud”” is down, your customers probably are too, since they’re also in the “cloud”. Availability is within the contracted SLA, and you likely accounted for this in your contracts, so it’s fine. The system is down, but within acceptable limits. Just another day of using the “““cloud”””.

The financial argument is just as familiar. Multi-cloud is considered too expensive, so the default decision is to not have a fallback at all. The cost of doing so (and keeping everything in sync across regions or providers) is often prohibitive and can outweigh the financial return.

But this is a bitter and fragile place to be.

The fragility

If your cloud provider takes five days to recover, should you just wait those five days? If prices go up, do you simply absorb the hit and accept reduced margins? What alternatives does your “cloud-first” application have when things go wrong? And if I don’t have alternatives, it’s worth asking who this situation actually favors.

Also, is the cost efficiency of the cloud really that real? How do we measure it? If you use cloud services, your system’s final architecture will differ from what it would be on-premise (as expected), so how much of that “flexibility” is real, and how much is just reframing a different kind of dependency?

“But for high-traffic events in short bursts, the cloud’s infinite scalability is unbeatable.” You’re right. But you know what isn’t infinite? Your wallet. It’s often valuable to actually see and feel where your application bottlenecks are, so you can make informed decisions based on real constraints and real scenarios.

Or, if your application is like the average cloud app out there, your database will still be the bottleneck when the spike comes. You just don’t notice because your system hasn’t actually been forced to prove itself yet.

Where are we winning by putting everything in one place?

I’m not against building systems in the cloud. I’ve built and continue to build in the cloud across various scenarios, and I understand the benefits. I’m not against Cloudflare either. This very blog sits behind Cloudflare’s proxy, and I know it solves a real and important problem elegantly. But there are non-obvious costs involved in these choices, and pretending everything is fine doesn’t automatically make it so.

The internet today is far more centralized than it used to be, both in terms of the sites we visit and where we host our things.

And we treat that as a reasonable trade-off.