AWS, Azure & Google Cloud Have All Had Major Outages in Last 13 Months: Is Your Hosting Strategy Still ‘Set and Forget’?

Cloud hosting reliability just failed its biggest test in years. A single uptime percentage never saw it coming. AWS, Azure, and Google Cloud have each had incidents where failures crossed boundaries their own architecture was supposed to contain. The failure modes varied: DNS, identity, configuration errors, network capacity, and in one case, physical damage to the data center itself. For an enterprise running on any of the three, what matters isn’t which failure mode hits next. It’s whether your architecture notices when a shared dependency goes down, and whether the affected service can keep running, or recover fast, before it becomes a business problem.

What Recent Hyperscaler Outages Exposed About Cloud Hosting Reliability

Four incidents make the clearest case studies for what’s actually going wrong. More have followed since, in different forms.

Google Cloud, June 2025

On June 12, 2025, a policy update to Google’s Service Control system introduced a change with unintended blank fields, triggering a crash loop in Google’s API management and control-plane layer. This broke authorization checks across dozens of services, including IAM, Compute Engine, and BigQuery, for roughly three hours, and took down platforms such as Spotify and Discord along with it. Google’s incident report notes something else worth flagging: some customers’ own monitoring tools were affected too, which meant teams lost part of the visibility they’d normally lean on during an outage.

AWS, October 2025

AWS’s own DNS automation for DynamoDB’s regional endpoint in us-east-1 broke on October 19 and 20, 2025, and endpoint resolution failed as a result. DynamoDB isn’t just a database. Part of EC2’s own instance management runs through it too. That’s why a DNS failure turned into a 15-hour outage, pulling in Lambda, Network Load Balancer, and dozens of other services. AWS’s post-event summary describes three separate impact windows, not one continuous failure.

EC2 instances already running kept running throughout. What broke was the ability to launch, scale, or manage them, since that path ran through DynamoDB. A healthy data plane doesn’t mean an operational service if the control plane underneath it is down.

Azure Front Door, October 2025

On October 29, 2025, a configuration change slipped past Microsoft’s own validation checks and reached Azure Front Door’s global edge network. Edge nodes that couldn’t load the new config dropped out of the healthy pool, leaving the remaining nodes to handle redistributed traffic as latency and errors climbed. Recovery took roughly eight hours, via rollback to the last known-good configuration. Microsoft 365, Xbox Live, and third-party Azure customers, including airlines and retailers, felt the impact, according to Microsoft’s Preliminary Post Incident Review.

Azure Storage and Managed Identity, February 2026

According to Microsoft’s status history, a policy change affecting anonymous storage access ended up blocking legitimate public read access that VM extension packages need, breaking VM provisioning across regions on the night of February 2 into 3, 2026. The mitigation for that issue was followed by a separate overload on the Managed Identity platform in East US and West US, which Microsoft tracked as a second, related incident. Authentication and VM provisioning stayed degraded for close to ten hours between the two.

What stands out across these four incidents is that none of them started with a conventional infrastructure disaster. In each case, a change in a shared dependency, a policy update, a configuration tweak, an automated process, let the impact spread past the boundary the architecture assumed would contain it.

And the pattern hasn’t stopped. Google Cloud’s own service history shows further incidents affecting multiple products since, each hitting a different layer of the stack. The specifics change. The lesson doesn’t: a region, a zone, or a provider is only as resilient as the dependencies and recovery paths built around it.

Mapping the Failure Domain Behind Every Cloud Hosting Outage

When Azure Front Door went down, IT teams first had to work out which internal apps and SaaS tools actually ran on Azure underneath the surface. That gap survives even in mature cloud programs when application, infrastructure, and SaaS dependencies get documented separately instead of as one chain.

A Business Impact Analysis and a dependency map do different jobs. A BIA tells you which services need to recover first. Dependency mapping tells you what each of those services actually depends on underneath: application, database, compute, storage, network, identity, DNS, and any third-party API in between. Do only one of these, and a DR plan usually stops at documentation instead of becoming something IT can execute.

The table below shows why that mapping matters for cloud hosting resilience. Each layer of redundancy only protects against one specific scope of failure.

The AWS incident shows why this matters. EC2’s control plane depends on DynamoDB, so a DynamoDB failure crossed a boundary most architecture diagrams draw as separate. Multi-AZ redundancy did its job. It just wasn’t built to survive a control-plane failure outside those zones.

High Availability Isn’t the Same as Provider Independence

High availability in cloud hosting tells you how much redundancy exists within a defined failure domain. Provider independence asks a different question: what happens once the provider itself becomes the failure domain? A workload can hit a 99.99% availability target inside a single provider and still go down the moment that provider’s shared platform layer fails, which is exactly what happened in most of the incidents above.

An SLA is a contractual availability promise for the provider’s own service, not a disaster-recovery architecture. Even where a service credit applies, it doesn’t recover lost transactions, lost productivity, or the exposure your business carries to its own customers.

What Decides Whether You Need a Second Cloud Provider

A multi-cloud strategy can lower provider concentration risk and strengthen cloud hosting resilience. But there’s a catch: the recovery environment has to be genuinely independent. If both clouds share the same DNS registrar, certificate authority, or identity provider, the second cloud isn’t really independent. It’s just a second address for the same dependency. It also costs real effort: doubled networking, IAM, monitoring, and skills.

So how do you actually decide, workload by workload, whether that cost is worth carrying? Four factors tend to settle it:

1. Business criticality
   
   Revenue, safety, or a regulatory obligation on the line makes a stronger case. A few hours nobody outside IT notices usually doesn’t.
   
   
2. Recovery requirement
   
   An RTO in minutes leaves no room for a single-provider outage to run its course. One measured in hours gives strong single-cloud DR enough time to work.
3. Dependency Independence
   
   The factor most teams skip. If the backup environment still shares DNS or identity with production, multi-cloud hasn’t bought independence, just a second bill.
   
   
4. Operational Capacity
   
   Two clouds mean two sets of skills and incident procedures. A team stretched thin on one cloud rarely runs a second one well.

A workload that scores high across these factors is a stronger candidate for the added complexity of multi-cloud or provider-independent recovery. Most internal tools don’t score that way. Tools like AWS Elastic Disaster Recovery and Azure Site Recovery can orchestrate cross-environment failover for the ones that qualify, though identity, DNS, and certificates still need a separate design decision.

Failover Isn’t Finished When the Servers Come Back

Cloud failover only works if it recovers the whole dependency chain, not just the workload. Where does the application run, and where does the database become authoritative? How does DNS redirect traffic without waiting out a long TTL, and how does the app authenticate users once identity moves with it? And once everything’s back up, who actually checks that transactions are going through, not just that the servers are responding? A plan that only covers the initial recovery step often leaves teams figuring out the rest during the outage.

Two numbers decide whether a cloud disaster recovery plan actually holds up. RTO is how long the business can tolerate downtime. RPO, or Recovery Point Objective, is how much data it can afford to lose if systems roll back to the last backup. Those numbers should shape the recovery architecture from the start, not get written down after the fact.

Cloud backup and recovery tooling is only as good as its last full restore test, not its last successful backup job. Those are two different things. Testing once a year might work for some workloads. It’s not enough for ones with tight recovery windows or environments that change constantly. The right test cadence follows the workload, not the calendar.

The Four Layers Cloud Infrastructure Monitoring Needs

A server can report as healthy while the business service running on it is unavailable to users. Infrastructure-only monitoring usually misses this. A provider-side failure rarely announces itself as a server going offline. It shows up first as an authentication error or a latency spike. As the Google Cloud incident earlier showed, this gap gets worse when the outage takes out your own monitoring tools too.

Watching only the first layer is how a dashboard shows green while customers are stuck, and it’s exactly the gap that gives cloud hosting reliability a more useful definition than uptime alone.

The Operating Model Behind Every Disaster Recovery Plan

Architecture only decides what can fail independently. Whether anyone notices and reacts before that turns into a business problem is a different question entirely, an operational one. Somebody has to watch the primary and recovery environments every day. Somebody has to track each dependency in the chain, confirm backups actually restore, and decide in real time whether a degraded service needs a full failover or just a quick fix. Who holds that authority, declares the failover, and confirms the recovered service works, is as much a resilience gap as any missing redundant region.

For enterprises running hybrid or multi-cloud environments, Remote Infrastructure Management and Monitoring (RIMM) provides one team to monitor and manage the entire IT estate, rather than monitoring each cloud environment separately.

Before the next outage hits, a few plain questions are worth asking. Do you actually know the biggest failure domain your most critical workload depends on, or are you assuming it? Have you mapped which services share a provider, a region, or an identity layer? If that shared dependency failed today, what would keep running? Has anyone proven your RTO and RPO with a real recovery test in the last year, not just checked that a backup exists? And is there one named person with the authority to call a failover and confirm it actually worked?

From “Set and Forget” to “Set and Operate”: What Comes Next

None of this argues for moving away from cloud infrastructure. The outages above didn’t happen because AWS, Azure, and Google Cloud are unreliable. They happened because redundancy inside one environment isn’t the same as resilience across the dependencies an enterprise actually runs on. The better question for most enterprises is how to build cloud hosting reliability and independence from a single failure domain without taking on more complexity than the workload’s downtime tolerance requires. With cloud outages taking new forms every few months, it’s a question enterprises need to address now.

Getting there takes a few things working together: a dependency map that’s actually current, failover that’s been tested rather than just documented, RTO and RPO validated at the workload level, and one team accountable for watching all of it, instead of several teams each watching their own slice. That’s the gap Progression’s managed cloud hosting, RIMM, and disaster recovery model is built to close, bringing dependency mapping, failover readiness, and recovery testing together as one operating model instead of separate projects. If your team hasn’t mapped application dependencies, validated workload-level RTO and RPO, or tested failover for a critical application, start there.

FAQs

1. What happens to my business if AWS, Azure, or Google Cloud goes down?
   
   It depends on what actually sits on that provider, underneath your applications and SaaS tools. That’s not always obvious. A vendor’s homepage won’t tell you which cloud it runs on, so an outage there can still knock out your email, your files, or a tool your team uses every day, even if nobody on your side ever logs into AWS, Azure, or Google Cloud.
   
   
2. Does our SLA protect our business during a cloud outage?
   
   An SLA mainly covers the provider’s service availability and may offer service credits if the agreed uptime isn’t met. It doesn’t cover the revenue you lose, missed transactions, or the impact on your customers when an outage affects your business.
   
   
3. Should we move to a multi-cloud strategy after these outages?
   
   Only where the cost of downtime is high enough to justify the extra complexity. Cloud hosting resilience genuinely depends on staying independent from one provider for some workloads, not all of them. Running two clouds well means doubling identity, networking, and monitoring. That’s worth it for revenue-critical or regulated systems. For most other things, it isn’t.
   
   
4. How do we find out which applications depend on a specific cloud provider?
   
   Start with a dependency audit. Trace each critical application through its compute, storage, network, identity, and DNS layers, then include any SaaS tool it connects to. The exercise often uncovers dependencies nobody documented, usually through a SaaS tool nobody flagged as cloud-dependent. Progression builds this map as the first step of any managed hosting or DR engagement.
   
   
5. How often should a cloud disaster recovery plan be tested?
   
   Testing once a year is common. It’s often not enough for a short RTO or a fast-changing environment. The right cadence follows the workload’s recovery needs and how often its architecture changes, not a fixed calendar. A test should validate the full recovery path, app, database, DNS, and identity together, since that’s what turns a documented plan into a capability IT can rely on.