You can keep a SaaS app up through a cloud outage without paying for every region twice.
I recorded this video in October 2025, the day Amazon Web Services had a major outage. Apps people use every day went dark, and so did parts of AWS itself. It got me thinking as a SaaS founder about one thing: what it would take for my own app to stay up through a day like that.
The business case
Any cloud provider can go down. I said that up front in the video and I still mean it. The real question is whether you can soften an outage in a way you can afford. You can always copy your whole setup into a second region. The problem is the bill.
My answer was to spread the parts of the app that matter most across Cloudflare's network, without moving everything. The goal is an app that degrades during an outage instead of going fully offline. As a founder, that difference shows up in trust and churn.
I have no inside knowledge of how AWS runs, or how any of the affected SaaS companies run. This is a general framework built from what I read and how I understand these services.
The single-region stack
If you're like most startups on AWS, you're probably running DynamoDB for data, Lambda functions, S3 for files and Route 53 for DNS. Most of that sits in one region, because a multi-region setup is expensive. So most teams put their data in one place and hope for the best.
Your own region isn't the only risk. Services you depend on, like Auth0, Stripe or OpenAI, can also feel the ripple when a big region has trouble.
What broke in Virginia
In the video I gave my reading of the reports that day. The US East region in Northern Virginia is a big hub for AWS, so a lot of traffic and DNS lookups lean on it. Then DynamoDB in that region hit a DNS problem, and services there couldn't reach the database.
AWS later published its own post-event summary. It says the trigger was a latent race condition in DynamoDB's automated DNS management, which left an empty DNS record for the service's regional endpoint in us-east-1. Other AWS services that depend on DynamoDB, including Lambda, saw errors as well. That matches the shape I described. Your data and your DNS path all leaned on one place.
The usual fix costs double
The traditional answer is a second copy. You run your database and services in another region, say US West, replicate data between the two and put global DNS in front. When one region fails, DNS sends traffic to the other.
It works, but you pay for both. If one region costs you $100, the second costs you another $100. On top of that, someone has to keep both copies identical, watch the replication and sort out routing problems, which costs a small team time as well as money.
Jump to
- 0:00 AWS went down: could your app survive?
- 1:21 The single-region startup stack
- 2:42 What went wrong in US East
- 5:07 The usual fix: a second region at double the cost
- 6:27 Cloudflare's anycast DNS and edge network
- 8:06 Workers, KV caching and Queues
- 10:27 D1 for edge data and graceful degradation
- 12:39 Why outages cost you trust
I sketch the whole architecture on screen in the full video on my channel: Surviving an AWS outage with Cloudflare on YouTube.
Anycast DNS first
Cloudflare's network is built differently. In the video I said Cloudflare runs in north of 320 locations. Its network page now lists 348 cities.
Its DNS is a global anycast system. A lookup can be answered from many locations at once, so there's no single central point of failure. Someone would have to take down the whole network before your DNS stopped resolving.
Workers in place of Lambda
Next, run your code on Cloudflare Workers instead of Lambda functions in one region. Workers run at the edge, across many locations. A request comes in, gets routed to a nearby location and runs there. If several locations have trouble, the others still answer.
A cache in front
At some point your code needs data, and if your main database lives in one region, you still have to go back to it. This is where Workers KV helps. The Worker checks KV first. On a miss, it reads from your database and saves the result, so the next request hits the cache.
Plan for one limit. KV is eventually consistent, so a change can take a little while to show up everywhere. Cache the critical paths where slightly stale data won't hurt the user or any decision they need to make.
Queues hold the writes
For writes, I'd add Cloudflare Queues. The request lands in the queue first, and the queue passes it on to your backend in AWS. During an outage, those writes wait. Whether the database is gone for two hours or three, the queue holds them until the backend comes back.
D1 for edge data
Cloudflare also has D1, a serverless database with SQLite's SQL semantics. It's relational, while DynamoDB is NoSQL, so I wouldn't swap one for the other wholesale.
What you can do is move certain workloads to the edge. Settings, per-user configuration and authentication config are good candidates. If your core backend fails, those pieces can still load, and the user gets a reduced app with some features missing. That beats a full outage and a pile of unhappy customers.
What customers care about
As I said in the video, no customer cares that AWS had an outage. You can tell them, but it means nothing to them. They gave you money for a service, and that service is down.
In the video I argued this setup can cost significantly less than what many teams pay AWS. I didn't put numbers on it, so treat that as my view. I'm also not telling you to move everything to Cloudflare tomorrow. Cloudflare has outages too, and I'm not a spokesperson for them. Disclosure: in April 2026 I said Cloudflare gave me a $25,000 credit as sponsorship. No affiliate links. There are trade-offs on every platform. Pick based on your stage, the services you need and how much outage risk you can live with.
If you want to build this way, take my free Cloudflare course. For more on how I run a business on the platform, read building a business on Cloudflare and Cloudflare for non-technical founders.
About Dwain
I'm Dwain Browne, Founder of LeadScore AI and SnapSuite. I'm a Toronto-based software architect with 25+ years across software, sales, operations and entrepreneurship. SnapSuite helps contractors and trades teams get paid faster, and LeadScore AI shows you which leads deserve your next call. I also run Vibe Code to Profit, a community helping people build software with AI.