AWS Outages in 2025: Why Neo Clouds Are the Future of AI Infrastructure

The October 2025 AWS outage cost global businesses around $75 million per hour and pulled down Snapchat, Roblox, Coinbase, Reddit, parts of the UK government, and over 1,000 other services. If you ran AI workloads on AWS that morning, you were idle. If you ran them anywhere else, you weren't. The gap matters more every year, and it's why a growing share of AI teams now keep their training and inference on specialized GPU clouds instead of hyperscaler infrastructure.

TL;DR: Why AWS's 2025 Outages Are Pushing AI Workloads to Neo Clouds

• Duration: AWS's October 19-20, 2025 Northern Virginia region outage lasted about 14.5 hours, triggered by a DynamoDB DNS race condition.
• Cost: That October 2025 outage cost businesses roughly $75 million per hour; Snapchat alone lost about $611,986 per hour.
• Not AWS-only: Google Cloud (June 12, 2025) and Azure Front Door (October 9, 2025) also had multi-hour outages in 2025.
• Price gap: Spheron's A100 80GB rental runs $1.43/hr on-demand against AWS p4's roughly $2.30/hr, as of 30 Oct 2026.
• Fix: Running AI compute on a separate GPU cloud removes the single point of failure between the app stack and model serving.

The October 2025 Outage in Numbers

The outage started at 3:11 AM ET on October 20, 2025, in US-EAST-1 (Northern Virginia). Within two hours, Downdetector logged over a million reports from the US alone and 400,000 more from the UK. By the time the dust settled, total reports hit 17 million across 60 countries.

The dollar damage by company, per hour of downtime:

• Snapchat: $611,986
• Zoom: $532,580
• Roblox: $411,187
• Fortnite: $399,543
• Canva: $342,466
• Slack: $194,064
• Reddit: $148,402

Amazon's own retail platform, warehouse systems (Anytime Pay), and Seller Central went down too. Warehouse staff were told to wait in break rooms while the systems they depend on came back.

Those figures are hourly rates, and the outage didn't last an hour. AWS's own post-incident report puts the event at 11:48 PM PDT on October 19 through 2:20 PM PDT on October 20, about 14.5 hours end to end, caused by a race condition in DynamoDB's DNS automation that briefly wiped the regional endpoint's DNS record and took down every service that resolves DynamoDB by name along with it. Run the hourly figures above across that full window and Snapchat's $611,986/hour becomes roughly $8.9 million, Zoom's $532,580/hour becomes about $7.7 million, and Roblox's $411,187/hour becomes close to $6 million, assuming (generously, for most of these companies) that the disruption hit them for the entire 14.5 hours rather than a few hours in the middle of it.

What AWS Says It Fixed, and What That Doesn't Fix

AWS's own post-incident report names the mechanism precisely: a race condition between two of the DynamoDB DNS Enactors, the processes that apply the plans a separate Planner produces on a periodic schedule. One Enactor fell behind applying an older plan while a second Enactor applied a newer plan and deleted the first, leaving an empty, incorrect DNS record for the regional endpoint and wiping out every IP address DynamoDB needed to resolve. AWS says it has already disabled that DNS automation worldwide and won't turn it back on until the race condition itself is fixed and new safeguards are in place to catch a bad DNS plan before it ships.

That's a real fix for this specific bug. It isn't a fix for the structural problem underneath it. The same pattern, a background automation process quietly updating shared control-plane state, exists everywhere inside a hyperscaler, which is exactly why Kinesis in 2020, Azure Front Door in 2025, and Google's Service Control in 2025 each broke for completely unrelated reasons but took down the same breadth of dependent services. Patching the DynamoDB DNS bug prevents a repeat of October's exact failure. It does nothing about the next one, in a different subsystem, with the same blast radius, because the blast radius was never the bug, it's the architecture of concentrating a region's control plane in one place.

Why This Keeps Happening

AWS holds about 30% of global cloud market share. Azure has 20%. GCP has 13%. Combined, the three of them control 63% of the world's cloud infrastructure. That concentration is the systemic risk. When AWS US-EAST-1 fails, a meaningful fraction of the internet fails with it, including the AI workloads that depend on AWS GPUs.

The outage also exposes a quieter problem for AI teams specifically: most teams run their training and inference on the same provider as their application stack. If your app and your H100 cluster both sit in US-EAST-1, one regional issue takes you down twice.

Three More Outages, Same Root-Cause Shape

October 2025 wasn't AWS's only turn at this, and it wasn't an AWS-only problem. Three other incidents, spanning three different providers and five years, follow the same shape: a routine internal change nobody expected to matter cascades into an outage that has nothing to do with the service that actually broke.

Three different hyperscalers, three different root causes, and the same takeaway each time: nobody caught the defect in testing, and once it reached production, the blast radius was every customer in the affected region, not just the team that shipped the change.

What Downtime Actually Costs

The headline numbers ($75 million per hour for the global economy) understate what hits any single company. The per-org figures are worse:

• Oxford Economics: $9,000 per minute, $540,000 per hour average
• Uptime Institute (2022): >$300,000 per hour for 91% of medium-to-large enterprises
• 44% of mid-size and large enterprises lose over $1 million per hour of downtime
• IDC: Fortune 1000 companies lose up to $1 million per hour
• Banking, government, healthcare, manufacturing, media, and retail: >$5 million per hour

Run the Oxford Economics average against the actual length of October's outage rather than a single hour, and the number stops looking abstract: $540,000/hour across 14.5 hours is about $7.83 million for one mid-size enterprise, not a hypothetical, for the time AWS itself reports the event ran. A company at the Uptime Institute's $300,000/hour floor still clears $4.35 million for the same window.

The financial damage isn't even the worst part. Customers blame the brand they're using, not AWS. Oxford Economics found companies spend an average of $14 million on brand trust campaigns after a major outage. Manufacturers report that an hour of unplanned downtime costs 50% more than it did two years ago, and Fortune Global 500 industrial firms now lose nearly $1.5 trillion a year to unplanned downtime, up 65% in two years.

What to Do Instead

Five practical moves, ordered by impact.

1. Move AI workloads off the same provider as your app

This is the cheapest fix and the highest impact. If your training and inference live on a specialized GPU cloud, an AWS outage stops your customer app but not your model serving. You can rent GPUs on Spheron on per-minute billing with no AWS quota required. For provider comparisons, see the top 10 cloud GPU providers guide.

2. Run a hybrid setup for critical paths

Keep AWS for whatever genuinely needs it (managed services, FedRAMP workloads, S3 archives) and put the rest somewhere else. Warm standbys on a separate GPU cloud let inference scale up the moment AWS goes sideways. For architectural patterns, see the production GPU cloud architecture guide and the AWS, GCP, and Azure migration guide.

3. Test your escape plan, regularly

Most "multi-cloud" strategies fall apart at the first real test. Pick a Saturday, simulate a US-EAST-1 failure, and watch what breaks. If your workloads can't switch providers under load, you don't actually have a multi-cloud strategy.

4. Stop optimizing for vendor loyalty

Volume discounts and reserved instance commitments lock you in, which is exactly what hyperscalers want. The teams hit hardest by the October outage were the ones with the deepest AWS integrations. Specialized GPU clouds offer transparent pricing, no contracts, and 60%+ cost savings on the same NVIDIA hardware.

5. Know what standby capacity actually costs while it's idle

A warm standby is only cheap if you understand each provider's idle-billing rules, and they're not consistent across providers. AWS bills a running EC2 instance by the second, with a one-minute minimum, from the moment it enters the running state, so a GPU instance sitting idle still meters the whole time it's running. Stop it and you're not charged for compute or data transfer, only for the attached EBS volume, but every restart opens a fresh one-minute-minimum billing window, and anything on instance store is gone. Azure draws a sharper line: a VM in the "Stopped" state is still allocated on a host and billed, and only "Deallocated" actually releases the hardware lease and stops the meter, so picking the wrong one defeats the point of stopping it. Runpod's own docs confirm a stopped pod still bills for volume disk storage, even though the container disk clears and the GPU is released. Google Cloud removes the choice entirely for this use case: instances with a GPU or TPU attached, or more than 208 GB of memory, can't be suspended at all, so a standby GPU box on GCP either runs at full price around the clock or gets torn down and rebuilt when you need it. Spheron's own Stop control avoids that tradeoff: GPU billing drops to the disk rate while the data stays put, covered in Spheron's Park feature.

Worked Example: Pricing Out a Redundant Standby

Take a team running inference on a single AWS p5 instance that wants a second GPU warmed up and ready to take traffic the moment US-EAST-1 goes down. Here's what the two most common ways to do that actually cost, run against a 30-day month.

Keep a second p5 instance running, idle, in a different AWS region. At roughly $6.88/hr, billed by the second with a one-minute minimum from the moment it enters the running state, a month of idle standby runs about $4,954, whether it ever serves a single request or not. Stop it between tests to save money and you're no longer protected: a stopped instance can't take traffic, and getting it back to "running" opens a fresh one-minute-minimum billing window right when you need it fastest.

Keep a Spheron H100 SXM5 spot instance warm instead. Spot ran about $2.94/hr per GPU when this was priced on 7 Oct 2026 (check current spot pricing, since marketplace rates move by the hour). At that rate, the same 30 days of standby costs around $2,117, roughly 57% less than keeping a second AWS p5 running the whole month, and billing is per-minute rather than AWS's per-second-with-a-one-minute-minimum meter that only stops once the instance is fully stopped, not merely idle.

Either way, the standby is only worth what the failover test proves it's worth. The cheapest redundant GPU in the world is dead weight if nobody has actually cut production traffic over to it before the day it matters. Price the standby, provision it, then run the Saturday failover drill from step 3 against that specific instance, not a stand-in.

Pricing fluctuates based on GPU availability and region. The figures above are illustrative, captured on 7 Oct 2026; check Spheron's live pricing and the AWS EC2 pricing page for what either provider actually charges today.

Why Neo Clouds Are Growing 35% a Year

Neo clouds (specialized infrastructure providers focused on GPU compute) are growing at roughly 35% annually, faster than the hyperscalers. The GPU cloud infrastructure market was $3.2 billion in 2023 and is projected to hit $25.5 billion by 2030, a 34.8% CAGR. GenAI-specific services are growing 160-200% year over year in 2025. The neocloud financing model driving rapid neocloud expansion now carries its own risks, particularly for AI teams choosing where to anchor long-term compute commitments.

The cost gap is the main driver. Uptime Institute pricing analysis for NVIDIA DGX H100 nodes:

• Hyperscaler average: $98/hr per DGX H100 instance
• Neo cloud average: $34/hr for equivalent capacity

That's a 66% reduction. At thousands of GPU-hours per month, the savings cover the cost of the redundancy infrastructure that protects you from the next outage, and then some. For organizations running large GPU clusters for AI training, the math typically clears $1.2 million per year in annual savings versus AWS, with minimal operational changes.

How Spheron Fits In

Spheron is a GPU cloud platform that aggregates capacity from 5+ providers and exposes it on a single per-minute billed catalog. The architecture matters here: because workloads aren't tied to a single data center, you get multi-provider resilience built in. If one node or partner has issues, workloads can move.

What that looks like in practice:

• H100 SXM5 at $2.50/hr on-demand, $1.03/hr spot (vs. AWS p5 at $6.88/hr)
• A100 80GB at $1.07/hr on-demand, $0.60/hr spot (vs. AWS p4 at $2.30/hr)
• B300, B200, H200, L40S, RTX 5090, RTX 4090 in the same per-minute catalog
• Full VM access with root SSH on every instance; no managed sandbox limits
• Bare-metal performance with no hypervisor overhead, which typically runs 15-20% faster on compute and 35% faster on multi-node networking than virtualized hyperscaler instances
• Zero egress fees, which alone saves $5,000-$15,000 a year for teams moving meaningful data

Pricing fluctuates based on GPU availability and region. Spheron's rates above are current as of 30 Oct 2026; AWS and other hyperscaler figures reflect their most recently published list prices and may have moved since. Check Spheron's live pricing and the AWS EC2 pricing page before you commit to either side of this comparison.

For a full pricing comparison across major providers and every GPU model, see the GPU cloud pricing comparison 2026. For a direct AWS / GCP / Azure breakdown, see the hyperscaler alternative guide.

The ROI of Adding Redundancy

For enterprises with significant GPU spend, moving even 40% of compute to a neo cloud while keeping AWS for the rest pays back the redundancy investment in 12-18 months through cost savings alone. Once you factor in the avoided risk of a multi-hour outage ($10M-$100M+ for large enterprises), the ROI gets dramatic.

SLA credits don't close that gap, even on specialized GPU clouds. CoreWeave's own SLA commits to 99.9% monthly uptime on its AI Object Storage product, measured as 100% minus the average error rate across five-minute intervals for the billing month. At 99.9%, the entire monthly allowance is about 43 minutes of downtime before a provider is outside its own SLA. The October 2025 AWS incident ran roughly 14.5 hours, more than 20 times that allowance in a single event, and the credit a provider issues for breaching an SLA is a percentage of that month's bill, not a reimbursement for what the outage actually cost the business running on top of it. The redundancy pays for itself; the SLA credit was never going to.

Bottom Line

The October 2025 outage isn't an outlier. AWS has had multi-hour US-EAST-1 incidents in 2017, 2020, 2021, and 2023. The pattern is regular enough that planning for it is no longer optional. The teams that came through October without major incident were the ones that had already split critical workloads across providers, often with the GPU side already running on a specialized cloud.

The numbers say the same thing the outage did. Hyperscaler concentration is a systemic risk, and the cost of fixing that risk is now negative: you save money on compute and gain resilience at the same time.

Don't wait for the next outage. Spheron's H100, A100, B200, and B300 instances run 60-75% below hyperscaler rates with zero egress fees and per-minute billing.

H100 GPU pricing → | View all GPU pricing →