An AWS incident exposed how dependent we are on a small number of hyperscale clouds. Soon after, a Cloudflare outage generated error messages “across the internet” and took major services offline. Different providers, different layers – same business impact.
Taken together, they highlight a hard truth: we’ve centralised so much of our digital world into a few platforms that when one of them stumbles, everyone feels it.
Different providers, similar dependency problem
AWS is a hyperscale cloud platform. When something goes wrong there, it hits the compute, storage and databases that thousands of companies quietly rely on.
Cloudflare sits at the edge: CDN, DNS and security services. When Cloudflare has an issue, your servers might be fine – but the “front door” your users use to reach them is not.
Different layers, same outcome for users:
- Apps become unreachable
- Transactions fail
- Error pages suddenly become the “face” of your brand
For many organisations, these outages were the first time they realised how many critical services – their own and their suppliers’ – sit behind AWS and Cloudflare.
What these incidents have in common
Across both events, a few patterns emerge that should worry every CISO and CTO:
Single points of platform failure
Even highly redundant cloud and edge networks can suffer from misconfigurations or software issues that ripple globally.
Hidden fourth‑party risk
You may not buy from AWS or Cloudflare directly, but your SaaS, payment provider, CRM, HR system, or security tools do.
Operational blind spots
Many organisations discovered they had no quick answers to basic questions:
- Which critical services are affected?
- What can we safely fail over, and to where?
- Who owns the decision to degrade functionality vs. go fully offline?
Communication gaps
Internal and customer communication often lagged the outage itself, even when provider status pages were already publishing updates.
Key differences – and why they matter
While both events caused disruption, they highlight different dimensions of risk:
AWS outage – core compute & data
- Impacted back‑end systems, applications and data‑processing pipelines
- Exposed how few organisations have realistic multi‑cloud or cross‑region failover for stateful workloads
- Raised questions about how “cloud‑native” many architectures really are
Cloudflare outage – edge & accessibility
- Impacted DNS, routing, caching and security controls at the perimeter
- Showed how a single edge provider can become a choke point for availability
- Demonstrated that security and performance services themselves can be a source of systemic risk
Understanding which category a dependency sits in (core vs edge vs “both”) should directly influence how you design for failure.
What resilient organisations will do differently
If we treat these outages as free training exercises, a few priorities become clear:
Map your critical dependency chain
- List business‑critical services and the providers behind them (including your SaaS and their underlying cloud/CDN).
- Identify where AWS, Cloudflare and similar linchpins sit in that chain.
Design for graceful degradation, not perfection
- Ask: “If this provider disappears for 4–8 hours, what minimal functionality must we keep alive?”
- Build modes where you can serve limited content, queue transactions, or fall back to “offline” workflows instead of failing hard.
Treat DNS, CDN and identity as Tier‑0
- Protect and monitor them as aggressively as you do your core application stack.
- Avoid putting every domain, every region and every control behind a single provider without a contingency.
Rehearse third‑party outage playbooks
- Run tabletop exercises for large cloud/CDN outages, just as you would for ransomware or data breaches.
- Include comms, legal, customer‑facing teams and key suppliers – not just ops and security.
Re‑think “multi‑cloud” in practical terms
- For most organisations, full active‑active multi‑cloud is unrealistic.
- But having some critical functions (status pages, support portals, basic authentication, emergency comms) on a separate stack can dramatically improve your options during an outage.
Questions to take to your next leadership meeting
If you want to turn these incidents into action:
- Which of our truly critical services would fail if AWS had a regional or control‑plane problem?
- Which of our public‑facing capabilities fully depend on Cloudflare (or another single CDN/DNS/security provider)?
- Do we have a simple business‑level view of these dependencies (not just a CMDB)?
- How fast could we publish a clear, accurate message to customers if our main providers went down?
- What small investments in architecture or contracts (e.g. secondary DNS, separate status site, minimal backup stack) would give us a disproportionate resilience boost?
AWS and Cloudflare are not “the problem”. They are doing what we asked them to do: scale the internet for us. But these outages are reminders that resilience is a shared responsibility. Relying on a handful of platforms for everything might be convenient, but it isn’t free of risk.
The real test isn’t whether your providers will ever fail. It’s whether, when they do, your organisation is surprised – or prepared.
