Is self-hosting less reliable? DDoS, uptime and failover — honestly

TL;DR. For DDoS, you’re often stronger off the hyperscalers, for free — OVH and Hetzner include serious network-level scrubbing that AWS charges $3,000/month for (Shield Advanced). For raw uptime, a single self-hosted box is weaker than AWS multi-AZ — but that’s the wrong setup. With a static-IP datacenter primary, a second DNS provider, and health-check failover, you can credibly reach 99.9% without any hyperscaler. The honest wins of leaving aren’t “more nines” — they’re predictable cost, data you control, and not going down because one giant vendor did.

“Will I be less reliable than on AWS?”

It depends entirely on how you set it up, so let me separate the real answer from the myth.

• A single box at home or in one shop, on a dynamic IP: yes, less reliable — realistically ~99–99.5% (a few days a year), bounded by consumer power and one internet line, with no automatic failover. Fine for a demo; not a production promise. Don’t build the business on that.
• A proper distributed setup (a cheap datacenter box as the anchor, with owned sites as cache/failover): ~99.9% is very achievable — and it has a property AWS can’t give you: it doesn’t share a fate with one hyperscaler’s bad day.

I’ll always quote you the honest number for your design, not a marketing one. Matching AWS’s headline 99.99% (multi-AZ) as a small operator is possible but takes genuinely independent sites and tested failover — so I quote 99.9%, and tell you what the last nine would cost.

DDoS — are you weaker off the cloud?

No — for the common attacks, you’re better protected, at no cost. This surprises people.

• OVH runs one of the world’s largest anti-DDoS systems (multi-terabit scrubbing), included free on every server — they built it because they were a constant target. Hetzner includes automatic protection too.
• AWS gives only basic protection free; its real defense, Shield Advanced, costs $3,000/month plus data fees. So OVH’s free scrubbing is roughly what AWS sells for $36k/year.
• Where the gap is: application-layer (L7) floods — clever HTTP requests that look real. Network scrubbing stops the big volumetric attacks but not L7. And a single location isn’t a global anycast network that disperses an attack across hundreds of cities.
• The fix is free and standard: put your origin behind Cloudflare’s free tier (anycast + L7 protection
  • a WAF + caching, all $0), with OVH/Hetzner’s free scrubbing protecting the origin underneath. That stack gives hyperscaler-grade DDoS defense for $0/month. (More on the honest trade-off of leaning on Cloudflare below.)

Are DDoS attacks permanent? No — the large majority are short bursts (minutes to a couple of hours; many under ten minutes). Mitigation is automatic: the attack is scrubbed for its duration, then traffic returns to normal. Sustained extortion or hacktivist campaigns can run for days, but the same automatic scrubbing rides them out. The risk is downtime during an unmitigated attack — which the setup above is built to prevent.

How reliable is a home/shop server, really — and how to estimate it

Your uptime is the product of every link in the chain, because if any one is down, the site is down:

uptime ≈ power × internet line × hardware × DNS × (1 − dynamic-IP gap)

  home/shop power        ~99.9%        (≈ 9 hours/year)
  consumer internet      ~99.5–99.9%   (≈ 9–44 hours/year)
  one server, no spare   ~99.9%
  one DNS provider        if it's down, everything is down
  dynamic-IP gap          every IP change → down for (update interval + DNS TTL)

Multiply those and a single home/shop node lands around 99–99.7%. To measure your real number, point a free external monitor at it (UptimeRobot, or self-hosted Uptime Kuma) for a few weeks and track each layer.

How to add failover and reach 99.9%

1. Move the primary off the house. A small datacenter box (OVH/Hetzner) with a static IP is ~99.9%+ on power and network and needs no dynamic DNS at all. Make that the anchor; make owned sites the cache/failover, not the foundation. This one change is most of the jump.
2. Use a second DNS provider. One DNS server is a single point of failure. A hidden primary plus free secondary DNS (Hurricane Electric, BuddyNS, deSEC, 1984) means DNS survives one provider failing.
3. Add health-checked failover so traffic moves automatically when the primary is down:
   • Simple managed: Cloudflare Load Balancing (~$5/month) — two origins + health checks.
   • Free / self-hosted: deSEC, or PowerDNS + dnsdist with health-check records.
   • Recovery time ≈ DNS TTL + check interval — so keep those records’ TTL low (30–60s).
4. Shrink the dynamic-IP gap anywhere you still use it (short update interval + low TTL) — or avoid it entirely by anchoring on the static-IP box.

Result: a static-IP datacenter primary + secondary DNS + automatic failover gives a credible 99.9% with no hyperscaler — and the owned sites become a resilience bonus, not a liability.

CDN — alternatives to Cloudflare

All of these undercut CloudFront’s $0.085/GB by a wide margin. A common low-cost stack: bunny.net for delivery + Cloudflare’s free tier out front for DNS and DDoS — they compose well.

On Cloudflare — useful, and an honest single point of failure

I use Cloudflare’s free tier where it genuinely earns its place — it’s the best free DDoS and anycast you can get. But I’ll say plainly what most consultants won’t: Cloudflare is one of the largest single points of failure on the internet. It sits in front of a big share of the web, and when it has a bad day, an enormous number of sites go down with it — through no fault of their own. Leaning on it is convenient and, for the reasons above, often the right call. Being dependent on it is the same centralization risk you’re trying to leave AWS to escape.

So I design for that: your origin works without Cloudflare, you can fail away from it, and nothing critical assumes it’s there. Cloudflare is a layer you benefit from, not a vendor you’re hostage to. That’s the whole point of the distributed, antifragile approach — the fewer giant shared dependencies your business shares a fate with, the more resilient you are when one of them stumbles.

(Where this is heading: as more independent businesses run their own infrastructure, the natural next step is for them to back each other up — a small, trusted mesh that reduces everyone’s dependence on any single big provider. That’s the direction. For now, the win is simpler: your own anchor, honest failover, and no shared fate with a single giant.)

Worried reliability is the reason you can’t leave the cloud? That’s the exact question a Cloud-Exit Assessment answers for your specific setup — with a real target uptime number and a failover design, not a slogan. Or send me your bill for a free 24-hour teardown.