A Fire, Then a Forced Shutdown
Cloud outages usually trace back to software: a botched config push, a bad deployment, a cascading failure in control planes. The disruption that hit Google Cloud's India region was older and more physical. A fire at a third party data center in Delhi forced an emergency power shutdown beginning June 9, knocking out networking equipment that serves the asia-south2 region. The result was intermittent latency spikes and possible packet loss for users across Delhi, Chennai, Mumbai, and surrounding areas, the kind of degradation that does not take a service fully offline but quietly erodes everything running on it.
Google acknowledged the disruption on its service health dashboard, noting reduced network capacity in the region and rerouting affected traffic to alternate facilities. The company was careful to characterize the impact as intermittent rather than a full outage. That distinction is technically fair and strategically convenient. For an enterprise running latency sensitive workloads in Mumbai, intermittent packet loss across an entire metro is not a footnote. It is a reliability event that shows up in their own dashboards, their own customer complaints, and their own incident reviews.
What Actually Broke
The technical detail Google offered is worth parsing, because it reveals how modern cloud regions are wired. The fire did not take down compute. It isolated what Google describes as a non-compute local point of presence, a networking node that routes traffic efficiently into and across the region. The servers customers pay for stayed online. The problem was getting traffic to them cleanly. When a point of presence drops out, packets take longer or less reliable paths, and the symptoms users feel are latency and loss rather than hard errors.
This is an important nuance for capacity planners. A region is not a monolith. It is a mesh of compute zones, network fabric, and edge nodes, and the failure of any one layer produces a different blast radius. Here, the compute layer was resilient and the networking edge was not. That asymmetry is exactly why single region architectures remain fragile even when the headline compute capacity is healthy. The plumbing that connects users to that capacity can fail on its own, and a fire at one facility was enough to expose it.
The Third Party Dependency Problem
The most uncomfortable fact is that the failure originated in a facility Google does not own. Hyperscalers project an image of total control over their infrastructure, but in many markets they lease space, power, and interconnection from local data center operators. India is one of those markets, where rapid demand has outpaced the buildout of fully owned hyperscale campuses. That dependency means a hyperscaler's reliability is only as strong as the third party's fire suppression, power redundancy, and operational discipline.
We have argued that cloud concentration shifts risk in ways enterprises underappreciate, and this incident is a clean illustration. Customers chose Google Cloud in part to outsource infrastructure risk. But the risk did not disappear; it moved one layer down, into a colocation provider most of those customers have never heard of. When that layer fails, the hyperscaler's brand absorbs the blame while the customer absorbs the downtime. Procurement teams should be asking their providers harder questions about which regions rely on leased third party facilities and what redundancy exists when one burns.
India's Resilience Question, Again
The outage reignited a debate that recurs in India with every major disruption: is the country's digital infrastructure resilient enough for the load it now carries. India runs an enormous share of its public services, payments, and commerce on a handful of cloud regions, and asia-south2 is a critical node. A single facility fire that degrades connectivity across multiple metros is precisely the concentration risk regulators worry about. Local commentators framed the event as a stress test that the system passed narrowly rather than comfortably.
For Indian enterprises, the lesson is not to abandon the cloud but to architect for its failure modes. That means multi region designs within India where data residency rules allow, clear runbooks for traffic rerouting, and contractual clarity on what a provider owes when a leased facility fails. The broader policy conversation, about whether critical national workloads should tolerate this degree of single region dependency, is one that will outlast this particular fire. The infrastructure is growing faster than the resilience practices around it.
Lessons for Cloud Buyers Everywhere
Strip away the geography and this is a universal cautionary tale. Every enterprise that has consolidated onto a single cloud region for cost or simplicity carries the same latent risk. The mitigation is not exotic. Distribute critical workloads across availability zones and, where the stakes justify it, across regions. Test failover regularly rather than trusting that it works. And treat the network edge, not just compute, as a failure domain that deserves its own redundancy planning.
Google's response, rerouting traffic and keeping compute online, shows the architecture working roughly as designed. The systems degraded rather than collapsed, which is the goal of resilient design. But resilient degradation is still degradation, and customers felt it. The honest takeaway is that hyperscale clouds are extraordinarily reliable and still not infallible, and the points where they fail are often the unglamorous physical dependencies beneath the abstraction. Enterprises that internalize that, and plan for it, will be the ones who treat the next fire as an inconvenience rather than a crisis.
