Latest / The Cloud Business Podcast with Fexingo: AWS, Azure, GCP, and Enterprise Infrastructure / Why Cloud Outages Hit Harder in a Multi-Cloud World
Transcript
- Lucas: So back in February, AWS had an outage in the Sydney region that took down a bunch of stuff — EC2, RDS, the works. What was interesting is that companies using only AWS got hit, obviously, but so did companies that thought they were 'multi-cloud' — teams running part of their stack on Azure or GCP. Luna: Right, because everyone assumes multi-cloud means no single point of failure. But that outage proved otherwise. Lucas: Exactly. And that's what we're digging into today — why cloud outages actually hit harder in a multi-cloud world. Because the problem isn't the compute or storage. It's the shared dependencies you don't think about until they break. Lucas: Speaking of dependencies — this episode is brought to you by nothing. No sponsor, no ad read. We keep this show free of commercials because we think that makes for a better conversation. If you find value in that and want to support it, the link is buy me a coffee dot com slash fexingo. That's buy me a coffee dot com slash fexingo. Luna: Yeah, and it's genuinely appreciated. It's what lets us focus on the stuff that matters rather than reading ad copy. Lucas: So back to Sydney. The root cause was a misconfiguration in AWS's DNS service — Route 53. That took down internal service discovery, which cascaded into EC2 and RDS being unreachable. But here's the multi-cloud kicker: many enterprises use Route 53 as their DNS backbone even for workloads running on Azure or GCP. Luna: Because it's stable, it's fast, it's integrated. Until it isn't. Lucas: Right. So when Route 53 went down, services on Azure that relied on DNS resolution to talk to other services — even if those services were also on Azure — couldn't find each other. Same for GCP. So the multi-cloud architecture actually amplified the blast radius. Luna: I remember reading a postmortem from one fintech company that said their entire transaction processing pipeline went dark for 47 minutes. And they thought they had redundancy because they were spread across all three major clouds. Lucas: That's the painful irony. The very strategy meant to increase resilience introduced a hidden single point of failure. And it's not just DNS. Identity federation is another one. Most enterprises use a single identity provider — Azure AD or Okta — to authenticate users across all their clouds. Luna: So if that IdP goes down, nobody can log into any cloud console, any CI/CD pipeline, any dashboard. Lucas: Exactly. There was a survey by — I think it was Gartner, actually — that said seventy-eight percent of enterprises experienced a multi cloud related outage in the past eighteen months. And the common thread wasn't a compute failure. It was a shared service failure. Luna: So what do you do? The obvious answer is 'don't share dependencies,' but that's easier said than done. Lucas: Yeah, and it's also not practical in many cases. DNS is a great example — you could run your own BIND servers, but then you're trading a cloud outage for an operational burden. The more realistic approach is to design for chaos engineering intentionally. Luna: Meaning you proactively break things in production to see what happens? Lucas: Within limits, yeah. Netflix popularized this with Chaos Monkey — killing instances randomly to test resilience. The idea now is to extend that to shared services. For example, simulate a Route 53 outage for non-critical traffic and observe how your multi-cloud architecture actually behaves. Luna: But most companies don't do that. They build for the happy path and assume redundancy. Lucas: Right. And that assumption is dangerous. Another mitigation is what some call 'blast radius isolation' — making sure that a failure in one cloud can't cascade into another. That means avoiding cross-cloud service discovery that relies on a single DNS provider, or running separate identity federation per cloud with a fallback. Luna: That adds cost and complexity. But maybe less than a 47-minute outage for a fintech company. Lucas: Exactly. And there's a growing trend toward what people call 'active-active' multi-cloud — not just having workloads in two clouds but having them fully independent, each with its own DNS, its own IdP, its own CI/CD. If one cloud goes down, the other carries on without missing a beat. Luna: That's a pretty serious architectural choice. You're essentially running two separate infrastructure stacks. Lucas: It is. But some enterprises are doing it for their most critical workloads. And the interesting thing is that the hyperscalers are starting to offer tools to make it easier. AWS has its 'multi-region' patterns, Azure has 'Azure Arc' to manage across clouds, GCP has 'Anthos.' They're all trying to help you manage this complexity. Luna: Though, as we've seen, those tools themselves can become dependencies. Lucas: Yeah, that's the paradox. The tools that help you manage multi-cloud are often provided by one of the clouds. So you're back to the same problem. The real solution is to think in terms of failure domains — and to ensure that a failure in one domain doesn't propagate. Luna: So what's a concrete step an infrastructure team could take this week? Lucas: I'd say map your dependencies. Actually draw the graph of every shared service — DNS, identity, monitoring, logging, CI/CD. Then for each one, ask: if this goes down, what breaks in each cloud? You'll find surprises. Then prioritize the ones with the widest blast radius. Luna: And then what? Duplicate them? Lucas: Either duplicate or create a fallback. For DNS, you could run a secondary DNS provider — like Cloudflare or Neustar — and configure failover. For identity, you could have a backup IdP with read-only access that kicks in during an outage. It's not perfect, but it's better than being completely blind. Luna: I've also seen some teams run 'game days' — scheduled chaos exercises where they deliberately fail a shared service and practice the response. Lucas: That's a great practice. And it doesn't have to be expensive. You can start small — fail a DNS lookup for a test environment, see what breaks, document it. The key is to build muscle memory before a real outage hits. Luna: So the takeaway isn't 'multi-cloud is bad.' It's 'multi-cloud without explicit dependency management is risky.' Lucas: Exactly. And that's the message that a lot of enterprises are waking up to. The Sydney outage was a wake-up call. But it won't be the last. The question is whether your team learns the lesson in a game day or in a postmortem. Luna: And ideally you want to learn it before you're explaining to your CEO why the entire platform went dark. Lucas: Right. So if you're running multi-cloud, take an afternoon this week to map those dependencies. It might save you a lot of pain down the road. Luna: Good advice. That's it for this episode of The Cloud Business Podcast. We'll be back next week with another deep dive into enterprise infrastructure.