Cloud Hosting Provider Outages: How AWS, GCP, and Azure Failures Cascade
Cloud providers offer unprecedented operational scale, but their shared infrastructure model creates correlated failure risk — when a control plane, networking fabric, or IAM service fails, thousands of customer services fail simultaneously across an entire region.
Traditional server downtime affects one customer’s service. Cloud provider outages affect thousands of services simultaneously because they share the same underlying infrastructure: physical network switches, control plane APIs, IAM authentication services, and DNS resolvers. A single misconfigured route advertisement, a control plane bug triggered by a routine deployment, or a power event in a critical data center cascades to every customer in the same region within minutes.
How Cloud Infrastructure Is Organized (Regions, AZs, Control Planes)
Cloud providers organize infrastructure into a three-tier hierarchy: geographic regions → availability zones (AZs) within regions → individual data centers within AZs. This hierarchy is designed to isolate failures: a power failure in one AZ should not affect other AZs in the same region. In practice, the shared components that span tiers — regional network fabric, control plane APIs, DNS resolvers, IAM services — create failure propagation paths that the physical isolation cannot prevent.
The critical distinction between the data plane and the control plane: the data plane is the running infrastructure serving live traffic (EC2 instances processing requests, RDS serving database queries, S3 serving objects). The control plane is the management API layer that creates, modifies, and monitors resources. Data plane and control plane failures have very different symptoms. A control plane failure means deployments fail, auto-scaling stops, health checks cannot update routing, and DNS changes do not propagate — but existing running instances may continue serving traffic normally. A data plane failure means running services stop responding.
This distinction matters for incident diagnosis. During the December 2021 AWS us-east-1 outage, AWS’s internal tooling for monitoring and responding to the outage was itself affected by the same control plane failure — engineers could not easily deploy fixes because the deployment infrastructure was down. This is a meta-failure property of cloud outages: the tools used to fix the outage run on the same infrastructure that is failing.
Why Cloud Outages Affect Thousands of Sites Simultaneously
The shared infrastructure model that makes cloud computing economically viable is the same property that makes cloud outages uniquely broad in impact. When AWS rents an EC2 instance to customer A and another to customer B, both instances run on the same physical network switches, use the same regional DNS resolvers, authenticate through the same IAM API, and are managed through the same control plane. When any of these shared components fails, both customers fail simultaneously — along with every other customer sharing the same component.
Root cause event
A network configuration change is deployed to the regional core router fabric. A bug in the change causes BGP route withdrawals for internal service discovery prefixes. Or: a routine EC2 control plane deployment has a memory leak that exhausts API server capacity under load. Or: a power event in a critical data center causes unexpected failover behavior that the automation mishandles.
Shared component fails
The affected shared component (network fabric, IAM API, DNS, EC2 control plane) becomes unavailable or degraded. Every service that depends on it begins to fail. Because the component is shared, this is not a single customer’s server going down — it is infrastructure that all customers in the region depend on.
Dependent services fail in sequence
Services that depend on the failed component begin failing: auto-scaling cannot launch new instances (EC2 API down), load balancers cannot update their target health status (health check API down), CDN cannot retrieve configuration (S3 API down), applications cannot authenticate users (IAM API down). Each failure reduces the system’s capacity to absorb further load, accelerating the cascade.
Customer-facing services become unavailable
Thousands of customer applications simultaneously return 5xx errors, connection timeouts, or authentication failures. DownCheck and other monitoring services detect probe failures across a broad cross-section of sites hosted on the affected provider simultaneously — the correlated failure signature that distinguishes a provider outage from isolated individual failures.
Recovery is non-linear
Mitigation requires rolling back or patching the root cause change, then waiting for the shared infrastructure to stabilize, then waiting for dependent services to reconnect and re-authenticate, then waiting for DNS caches to propagate updated routing. Recovery time is measured in hours because each step must complete before the next begins, and some steps (DNS TTL propagation) cannot be accelerated.
AWS Outage Patterns — us-east-1 and the Control Plane Problem
AWS us-east-1 (Northern Virginia) experiences disproportionate outage frequency and impact for two structural reasons: it is the largest AWS region by capacity and the location of several globally-scoped AWS control plane services. When us-east-1’s IAM, CloudFront’s control plane, Route 53 health checks, or Cognito fail, the impact extends beyond us-east-1 customers to affect global services — even customers in ap-southeast-1 or eu-west-1 may experience IAM authentication failures because IAM’s global service is anchored in us-east-1.
AWS Kinesis failure cascades to IAM, Cognito, Lambda, and monitoring tooling
A capacity increase in AWS Kinesis triggered a threading issue in the Kinesis front-end fleet. Because Kinesis Data Streams is used internally by AWS’s own IAM, Cognito, CloudWatch, and Lambda services for event processing, the Kinesis failure cascaded into these services. IAM credential vending was impacted, preventing new AWS API calls from authenticating. Lambda invocations failed. CloudWatch metrics stopped updating — meaning AWS’s own monitoring was blind during the incident. Amazon, Disney+, Netflix (which uses AWS), and thousands of other services were affected.
→ Lesson: Dependencies between AWS services are opaque to customers. An AWS internal service (Kinesis) you may not use directly can fail services you do depend on.EBS outage takes down Netflix, Reddit, Foursquare — multi-AZ alone insufficient
A network configuration change caused a packet storm in us-east-1’s network fabric. Elastic Block Store (EBS) volumes in multiple AZs simultaneously lost connectivity, as the network storm affected the intra-region networking that EBS depends on. Services that were multi-AZ but still in us-east-1 experienced outages. This incident established that multi-AZ ≠ region-failure-proof: a regional network event can bridge AZ isolation.
→ Lesson: Multi-AZ protects against AZ-level failures but not region-level network failures. Multi-region is required for region failure tolerance.Kinesis + Lambda failure: Adobe, Roku, IMDb, 1Password affected
A capacity addition to Kinesis created an internal meta-data issue affecting the Kinesis front-end fleet. Lambda, which uses Kinesis internally, experienced intermittent failures. The failure impacted event-driven architectures relying on Lambda triggers from Kinesis, S3, DynamoDB Streams, and SNS — many services that appeared unrelated to Kinesis were affected through hidden dependencies.
→ Lesson: Serverless architectures with event-driven triggers inherit AWS’s internal service dependencies invisibly.Google Cloud Outage Patterns — Networking and IAM Failures
GCP’s most significant outage patterns involve IAM authentication failures and global networking disruptions, both of which cascade broadly because every GCP service requires IAM for authentication and all inter-service communication routes through GCP’s global network fabric. When GCP IAM fails, no GCP API calls can authenticate — the control plane effectively becomes inaccessible for every customer simultaneously.
GCP global networking outage: Cloudflare, Shopify, Discord, Snapchat affected
A configuration change to Google’s network control plane software triggered a cascade that reduced network capacity to the East Coast US and parts of Europe. Traffic was rerouted to remaining capacity, which became overwhelmed, causing packet loss across GCP regions. Google’s own services (YouTube, Google Drive, Gmail, Google Search) were impacted. The outage affected any service routing through Google’s network infrastructure, including Cloudflare (which peers with Google) and sites served by Google’s CDN.
→ Lesson: Network peering relationships mean GCP outages can affect services not hosted on GCP — Cloudflare’s degradation during this incident surprised customers not using GCP directly.Google Cloud IAM outage takes down all GCP console access and API authentication
A quota configuration change to Google’s IAM service caused the IAM API to return errors for all requests. Because every GCP service uses IAM for authentication, the GCP console became inaccessible, all GCP SDK API calls failed, and automated processes (CI/CD pipelines, auto-scaling, health checks) that authenticate with service account credentials stopped functioning. Existing running workloads continued operating, but any operation requiring API authentication failed.
→ Lesson: IAM is the single most critical shared dependency in any cloud platform — its failure is functionally a complete control plane failure.Azure Outage Patterns — Cascading AAD and Fabric Failures
Azure’s most impactful outage patterns involve Azure Active Directory (now Microsoft Entra ID) authentication failures, which cascade broadly because virtually every Azure service and Microsoft 365 product authenticates through AAD. A failed AAD deployment or configuration change can simultaneously take down Azure Portal access, Microsoft 365 (Teams, Outlook, SharePoint), Azure DevOps, and any enterprise application using AAD for identity — the broadest possible blast radius of any single service failure.
Azure WAN routing update takes down Azure, Microsoft 365, Teams, Xbox globally
A change to Azure’s Wide Area Network (WAN) routing configuration caused incorrect BGP route advertisements that moved traffic from Azure’s expected network paths to paths that could not support the load. Teams, Outlook, SharePoint, Xbox, and Azure services globally experienced failures. Microsoft spent hours rolling back the WAN configuration while traffic took unintended paths through congested network links. The incident affected millions of enterprise users at the start of the business day in Europe.
→ Lesson: BGP misconfiguration can take down global infrastructure in minutes. Canary deployments of network changes with automated rollback are essential at this scale.Azure Active Directory outage: all Microsoft 365, Azure, and enterprise apps inaccessible
A change to Azure Active Directory token validation caused authentication failures across all services using AAD — Azure Portal, Teams, Outlook, SharePoint, Dynamics 365, and thousands of enterprise SaaS applications using AAD federation. Unlike an individual service outage, an AAD failure is a meta-failure: the authentication system that grants access to all other systems is down, making all management and mitigation actions via the portal impossible. Resolution required identifying and rolling back the specific AAD change, with no user-facing workaround available.
→ Lesson: Identity infrastructure (AAD, IAM, Okta) is uniquely high-consequence because its failure prevents access to everything else — including incident response tooling.Provider status pages are often late and understated. Cloud providers’ own status pages typically acknowledge incidents 20–60 minutes after they begin, and often initially describe the impact as “some customers may be experiencing issues” before escalating to acknowledge the full scope. DownCheck’s independent probes detect provider failures within 5 minutes of onset — before the status page acknowledges them — because the probes are not dependent on the provider’s own infrastructure to report the failure.
How to Architect for Cloud Provider Resilience (Multi-AZ, Multi-Region)
Cloud resilience architecture is a spectrum from single-AZ (maximum simplicity, maximum risk) to multi-cloud active-active (maximum resilience, maximum complexity and cost). The right level depends on your RTO (Recovery Time Objective — how long can you be down?) and RPO (Recovery Point Objective — how much data loss is acceptable?). Most production systems warrant multi-AZ minimum; high-availability systems warrant multi-region; systems with zero-downtime SLAs require multi-region active-active.
| Architecture | Protects Against | RTO | Additional Cost |
|---|---|---|---|
| Single AZ, single region | Hardware failure (single server) | Minutes–hours | Baseline |
| Multi-AZ, single region | AZ-level hardware, power, cooling failures | < 1 minute | ~2–3× (duplicate capacity) |
| Multi-AZ + CDN | AZ failures; static content survives regional outages | < 1 minute | ~2–3× + CDN cost |
| Multi-region active-passive | Full regional failures; control plane failures | 5–15 minutes | ~4–6× (standby region) |
| Multi-region active-active | Full regional failures with zero downtime | Seconds | ~6–10× (full duplicate) |
| Multi-cloud active-active | Full cloud provider failures (AWS + GCP simultaneously) | Seconds | >10× (extreme complexity) |
Multi-AZ deployment for every stateful service
Deploy application servers, databases, and load balancers across at least 2 AZs. Use managed multi-AZ services: RDS Multi-AZ, ElastiCache with Multi-AZ, ELB (automatically multi-AZ). This is the baseline requirement for production workloads — single-AZ deployments have no provider SLA and frequent failure.
Serve all static assets via CDN independent of your cloud region
Place static content (HTML, CSS, JS, images) on Cloudflare, CloudFront, or Fastly. During a cloud provider outage, users can still access cached static content from CDN PoPs, reducing perceived downtime for read-heavy workloads. Configure CDN with a generous TTL and stale-while-revalidate headers so CDN serves cached content even when the origin is unreachable.
Pre-stage passive infrastructure in a second region
Maintain a “warm standby” in a second region: a scaled-down but ready deployment that can receive traffic within minutes. Use Route 53 health checks with DNS failover to automatically redirect traffic to the secondary region when primary region health checks fail. Test failover quarterly by intentionally failing the primary region in a game day exercise.
Use global DNS with health check-based routing
Route 53 Latency Routing + Health Checks, or Cloudflare Load Balancing, routes traffic to the nearest healthy region automatically. When the primary region fails health checks, DNS automatically shifts traffic to the secondary region within 60 seconds (1 TTL at the 60s health check interval). This is the lowest-cost multi-region failover mechanism available.
Decouple from cloud provider’s control plane for critical operations
Do not require the cloud provider’s control plane (EC2 API, IAM API) for your application to serve traffic. Applications should start without needing to call AWS APIs at runtime. Use IAM instance profiles loaded at startup, not API calls at request time. Avoid architectures where every request requires an IAM API call for authorization.
How to Monitor Cloud Provider Health (Status Pages, DownCheck)
Effective cloud provider health monitoring requires multiple independent data sources because provider-operated status pages have documented latency in acknowledging incidents and often understate the impact scope in initial notifications. Cross-referencing provider status pages with independent probe data provides earlier incident detection and more accurate impact assessment.
📄 Official Status Pages
AWS: status.aws.amazon.com (subscribe to RSS or email for service-specific alerts per region)
GCP: status.cloud.google.com (JSON API available for programmatic monitoring)
Azure: status.azure.com and Azure Service Health in Azure Portal (more detailed, account-specific)
Limitation: Status pages typically acknowledge incidents 20–60 minutes after onset and initial impact descriptions often understate the severity and customer count affected.
🔴 DownCheck Service Dashboard
DownCheck monitors 55+ services including AWS S3, EC2 endpoints, CloudFront, GCP Cloud Storage, Azure Blob Storage, GitHub, Stripe, and major SaaS platforms with 5-minute independent probes.
When an AWS outage occurs, DownCheck’s probes detect simultaneous failures across AWS-hosted services within one probe interval (5 minutes) — before AWS’s status page acknowledges the incident. The correlated failure pattern across multiple services is the signature of a provider-level incident vs isolated service failures.
Use DownCheck to detect provider incidents early and correlate your own site’s downtime with a known provider incident.
💡 AWS Personal Health Dashboard
AWS Personal Health Dashboard (now AWS Health) provides account-specific notifications about AWS events affecting your specific resources — unlike the public status page, which is generic. Available in AWS Console → AWS Health or via the AWS Health API.
Subscribe to AWS Health events via EventBridge to route incident notifications to your monitoring system, PagerDuty, or Slack. This gives you AWS-sourced incident data specific to your account’s services and regions.
Limitation: Still dependent on AWS infrastructure to deliver notifications — during severe outages, Personal Health Dashboard alerts may themselves be delayed.
🌍 Third-Party Downtime Trackers
Downdetector, IsItDownRightNow, and similar crowd-sourced platforms aggregate user-reported outages in real time. During major cloud provider events, these show spikes in user reports for affected services within minutes of the incident beginning — often faster than official acknowledgment.
While not technically precise, these platforms confirm that an outage is user-impacting and widespread, helping distinguish a provider incident from a configuration issue in your own infrastructure.
Limitation: No geographic or service-level granularity. Cannot distinguish AWS EC2 failures from RDS failures from IAM failures.
The incident response workflow: (1) Your monitor alerts → (2) Run DownCheck check: are other sites on the same provider also down? → (3) Check DownCheck’s service dashboard for provider status → (4) Check official status page → (5) If confirmed provider incident: update your status page, communicate to users, set up recovery alert — do not debug your own code, the problem is upstream → (6) When provider recovers: verify your own service recovery, document MTTR and impact, update post-mortem with provider RCA when published (usually within 1–2 weeks).
Frequently Asked Questions
Is it your code or your cloud provider?
DownCheck monitors AWS, GCP, Azure, and Cloudflare with independent probes. When your site goes down, know in 30 seconds whether the problem is yours or upstream.
Check provider status →