This image is licensed by CC BY 4.0.
On November 18th, 2025, a Cloudflare outage temporarily brought down Canva, X (the social network we now know as Twitter), ChatGPT, and many other sites that rely on Cloudflare. Cloudflare also protects web services that many of us rely upon everyday. A Cloudflare representative said the likely cause of the outage was an automatically generated configuration file that “grew beyond an expected size of entries and triggered a crash in the software system that handles traffic for a number of Cloudflare's services.”
Not long after, on December 5th, 2025, there was another Cloudflare outage. But this time, Cloudflare was able to quickly recover and get back online after about a half an hour. Many enterprises could still benefit from Cloudflare and how to deal with an outage.
Here’s the Problem
When Cloudflare DDoS protection goes down, the effect is just like a DDoS attack. It is kind of ironic, eh? Cloudflare’s services are worth keeping even with the recent outages; there aren’t a lot of alternatives for cloud-based Distributed Denial-of-Service (DDoS) attack protections, except AWS Shield, but that is not the only service they offer. Enterprise customers often order multiple services from Cloudflare like serverless computing platform, defense from Gen AI bot scrapping, and VPN services. Regardless of the service you use you would want to prevent DDoS attacks that can cause your network services to go down.
Neither of these outages appear to be caused by any kind of cyber attack, they were technological malfunctions with no malicious intent. Accidents, but not happy accidents like what Bob Ross used to talk about.
When Cloudflare goes down, you can’t paint a happy little tree over it. Consider the frequency of DDoS attacks on the internet, how promiscuous they often are, and how threat actors are likely automating most of their buffer overflow attempts, which is the cause of most DDoS attacks, with Gen AI. If you take a long-term perspective in cost benefit analysis, keeping Cloudflare running will likely result in fewer downtime incidents than going without Cloudflare.
And when you know that there are ways to keep your web applications and cloud networks running even when Cloudflare goes down, the appeal of keeping Cloudflare becomes even more compelling.
The ultimate metric expected of network administrators, especially cloud network administrators, is to maintain maximum up time and minimum downtime. Depending on how your business uses your cloud network, downtime can mean unhappy customers and clientele, or other service downtime if your cloud network is in the supply chain of other companies’ networks.
Cloudflare has been excellent in maintaining open communication with their clients and the general public, and their Cloudflare System Status website is an example of that. So we understand the problem. Now let’s examine some solutions.
The Solution
Keeping your enterprise’s public cloud services running during a Cloudflare outage is doable with preparation. When Cloudflare goes down, it’s nice to have other security controls that may be able to mitigate DDoS attacks in its absence. In cybersecurity, we often talk about “defense in depth”. The idea is to have multiple technologies, tools, and procedures to prevent or mitigate incidents if one fails.
If AWS provides your infrastructure, AWS Shield can prevent DDoS attacks in a similar way to how Cloudflare does. It’s worth keeping both services ready, though. Amazon has more datacenter infrastructure globally than Cloudflare does, so they’re in a good situation to provide such a service. And of course, it does provide monitoring and has various measures for preventing DDoS attacks caused by a variety of techniques an attacker may use.
Don’t neglect your Web Application Firewall (WAF). Every major cloud provider has its own WAF services. There are also third party cloud-based WAF services you can look into, such as Sucuri’s WAF.
If a component of your network is on-premises, strongly consider getting a WAF that vendors like Cisco and Juniper Networks have for on-prem networks. In a hybrid cloud network, the cloud components and on-premises components are fully integrated. And a DDoS that targets your enterprise’s on-premises servers and networking devices will likely negatively impact the cloud components of your networks too.
If you’re a small or medium sized enterprise, you may need to have a Managed Security Services Provider (MSSP) manage your WAFs. Automation can also be helpful when designed and deployed well, and many cyber defense and monitoring tools, such as Security Information and Event Management (SIEM) or Extended Detection and Response (XDR), would be impossible to operate properly without automation. But make sure that automation is well designed and well configured. And never take any security controls for granted. Resources like CIS (Center for Internet Security) Benchmarks provide optimal security configuration recommendations and will be a big help when you review your configurations for operating systems and applications all throughout your enterprise network. You do review your configurations every so often, don’t you?
It’s said that real estate is all about “location, location, location”! Our mantra for maintaining network uptime and cyber resilience is “redundancy, redundancy, redundancy”!
How to Build Redundancy
So just as AWS Shield can be a redundant DDoS mitigation service, you should probably consider deploying a redundant instance of your enterprise’s publicly accessible cloud network as well. Here’s how it’s done.
Make sure your network has a secondary DNS provider. Ask any computer networking wiz, and they’ll tell you that DNS is a frequent source of issues! Even the AWS US-EAST-1 downtime last fall was ultimately a DNS issue! Fortunately, there are a lot of DNS services out there that are independent of each other.
Set up a new subdomain for your backup network. So if the main domain name for your publicly accessible production network is website.com, you could choose backup.website.com. Or name it whatever you want! Just please stick to ASCII characters. Your secondary DNS should have no connection to the Cloudflare implementation in your enterprise network. Because shared DNS will cause a domino effect of outages when it goes down, and it’s a massive headache for admins everywhere!
SSL should be configured for your backup network because encryption is essential. Make sure your backup subdomain is cut off from public search indexing! We do need to make the Deep Web any deeper! That backup network should use AWS Shield or an equivalent service on another cloud platform. Just make sure no Cloudflare resources are on the backup network, and no shared DNS servers either.
Be careful to not expose administrative interfaces on the backup domain! We would recommend having someone at your MSSP or your company’s network security specialist scan for exposed admin panels from an origin point external to your backup network. Vulnerability scanning of all kinds is permitted on cloud provider infrastructure without seeking permission from your cloud provider, unlike actual network pentesting. Blackhat Ethical Hacking has a wonderful tool for vulnerability scanning for exposed admin panels called AdminPBuster. When you’re sure no admin is exposed, remember to enable a WAF, rate limit at origin, and consider geo-blocking or implementing an IP whitelist, depending on what works best in your circumstances.
If everything is set up properly, when Cloudflare goes down in the future, and it inevitably will, users trying to access your public web applications should be redirected to your backup.
The cloud provides a lot of scalability, built in security tools, storage, and compute capacity. So the thing you’re trying to protect is also a resource to improve its protection!
Summary
- Use several different vendors for the same service to build redundancy in case of an outage.
- Use additional dedicated firewall devices, additional servers, and other hardware as an effective way to build redundancy for on-prem networks.
- Implement automated network security monitoring and incident response tools, such as SIEM and XDR. If you use an MSSP, network security monitoring and incident response is partly or completely their responsibility.
- Use a multi-cloud network (more than one cloud provider), or to use multiple geographic regions from the same cloud provider to build redundancy.
- Use redundant DNS services or a different subdomain to host your network in the event of DDoS protection services going down, or in the event of an actual DDoS attack!
- Implement rate limiting at origin, WAFs, geo-blocking, and IP whitelisting.
- When in doubt, reach out to your trusted Cloud Security Partner for a full review.
Stay in the loop.
Subscribe for the latest in AI, Security, Cloud, and more—straight to your inbox.
