The recent Google Cloud incident in London is the kind of event that should force enterprises to rethink what cloud resilience really means. Google said the disruption was caused by a “power event” affecting London-based data centers in its europe-west2 region. The issue appeared early in the day and affected cloud services that many organizations depend on, either directly through their own deployments or indirectly through third-party platforms that run on Google Cloud.
What made this incident important was not simply that a cloud region had problems. Cloud infrastructure, like all infrastructure, can and will fail. The real issue was the scope of the dependency chain. Banks, delivery services, e-bike providers, budgeting apps, some appointment services through the National Health Service app, and court video-link systems were all caught in the disruption. These services may appear unrelated, but in reality, they can share the same underlying cloud providers, regional infrastructure, managed services, networks, identity systems, APIs, and operational dependencies.
Google later said services had recovered for most affected workloads, with only a small number of customers still impacted. However, the damage had already been done. The incident showed how much modern business depends on cloud platforms that are highly capable but not immune to failure. It also showed that resilience is not something enterprises automatically gain by moving to a hyperscaler. Resilient architecture must be designed, funded, tested, and owned.
Don’t assume resilience
Many enterprises still treat public cloud resiliency as a provider problem. They assume that because a workload runs on a major cloud platform, it is inherently resilient. That is a dangerous assumption. Public cloud providers do offer impressive resiliency capabilities. They provide multiple regions, availability zones, managed databases, replication tools, load balancing, object storage durability, backup services, monitoring, and automated recovery options. But these are building blocks. They are not a finished resilience strategy.
The provider is responsible for the reliability of the cloud platform. The enterprise is responsible for how its applications use that platform. This distinction is often misunderstood. If an application is deployed in a single region, depends on one managed database, uses one identity path, and has no tested failover process, the cloud provider cannot magically make that application resilient. The provider may recover the underlying infrastructure, but the business still owns the application architecture and operating model.
This is where many cloud programs fall short. Enterprises migrate applications to public cloud and assume the resiliency conversation is complete. In reality, they may have only moved the single point of failure from their own data center to someone else’s regional infrastructure. The platform is better, but the design may still be fragile.
A growing dependency chain
Cloud resiliency has become more difficult because enterprise systems are now deeply interconnected. A typical modern application is a collection of managed services, APIs, identity platforms, data stores, message queues, observability tools, deployment pipelines, security controls, and third-party integrations.
This creates hidden risk. An enterprise may think it has built a resilient application because compute runs across multiple zones. But the database may be regional. The identity provider may be unavailable. DNS may require manual intervention. A third-party payments API may fail. Logging and monitoring may go dark during the incident. The backup may exist but may not have been restored in months. The failover process may depend on a person who is unavailable.
This is the new cloud resilience problem. The failure is rarely just one server, one disk, or one network device. The failure is often a dependency chain. Enterprises need to understand not only where applications run, but what they depend on to operate. A true resilience program starts with mapping dependencies at a practical level. Which services are zonal, regional, or global? Which ones rely on a provider control plane? Which third-party services share the same cloud provider or region? Which workloads can continue in degraded mode? Which ones stop completely?
Without that map, enterprises are guessing.
Multicloud is not a shortcut
When public cloud outages happen, the reflexive response is often, “We need multicloud.” Sometimes that is true. Often, it is an expensive distraction.
Multicloud can reduce dependency on a single provider, but it can also introduce complexity that can make resilience worse. Running the same workload across two clouds requires duplicated architecture, data replication, consistent security policies, cross-cloud networking, staff expertise, governance, monitoring, deployment automation, and incident response processes. If those capabilities are not mature, multicloud becomes distributed fragility.
The better answer is workload-specific resilience. Not every system needs active-active deployment across providers. Some workloads need multiregion architecture within one provider. Others need active-passive failover. Some need strong backup and restore. Some can tolerate hours of downtime with minimal business impact.
Enterprises should classify applications by business criticality. Customer-facing systems, revenue platforms, payments, logistics, clinical operations, identity services, and regulatory workflows usually need stronger resilience. Internal reporting, development systems, and low-impact workloads may not justify the same investment.
Testing and more testing
A resilience plan that has not been tested is just a theory. Many enterprises have architecture diagrams showing failover paths that have never been exercised. They have backups that have never been restored. They have recovery runbooks that depend on outdated steps. They have escalation paths that look good in a document but fail during an actual incident.
Testing is where resilience becomes real. Enterprises should run controlled failure exercises. They should test regional failover. They should restore productionlike data from backup. They should simulate the loss of a managed service, an identity provider, a network path, or a third-party API. They should measure actual recovery time rather than relying on assumptions.
These tests often reveal that the weakest part of the system is the operating model, not the cloud platform. Teams may not know who can approve failover. Business leaders may not know what degraded mode looks like. Engineers may not have permission to execute emergency changes. Monitoring may not show the real customer impact. Communications teams may not have prepared language for customers or regulators.
Cloud resilience is both technical and organizational. The architecture matters, but so do decision rights, runbooks, staffing, communications, and practice.
Cost must be explicit
Better resilience costs money. Multiregion deployment, replicated databases, additional monitoring, traffic management, backup storage, testing environments, and skilled operations all increase cloud spend. That cost should not be hidden or treated as waste. Compare it with the cost of downtime. What does one hour of downtime cost? What happens if customers cannot access funds, complete purchases, schedule appointments, ship products, or use core services? What is the regulatory exposure? What is the reputational damage? What contractual penalties apply? What manual workarounds exist, and how long can they scale?
Once you answer those questions, resilience investments become easier to justify. Some systems will deserve expensive designs. Others will not. But at least the decision will be deliberate. The worst outcome is accidental underinvestment, where a business-critical system has low resilience simply because no one priced the risk.