DNS Disaster Recovery für SaaS: Der 28-minütige Ausfall, der 12.000 $ gekostet hätte

Geschrieben von Huifer, Solo-Entwickler und Maintainer von TanStack Ship. Im März 2026 nahm ein Ausfall des DNS-Anbieters tanstackship.com für 28 Minuten offline. Es war kein Cloudflare-Ausfall — das DNS-Managementsystem meines Registrars hatte während eines routinemäßigen Wartungsfensters einen kaskadierenden Fehler. Der Ausfall kostete schätzungsweise 2.400 $ an verlorenen Testanmeldungen, ausgehend von einem durchschnittlichen Trial-Conversion-Wert von 5 $ und 480 verlorenen Sitzungen. Wäre ich bei 100.000 $ MRR gewesen, hätte derselbe 28-minütige Ausfall 1.350 $ gekostet. Dieses Playbook dokumentiert, was ich nach diesem Vorfall aufgebaut habe, und die DNS-Failover-Architektur, die die RTO unter 15 Minuten hält.

Verifizierte Quellen: Cloudflare DNS documentation · AWS Route 53 health checks · SLA math Zuletzt aktualisiert: 18. September 2026 · Changelog

TL;DR: Single-Provider-DNS ist ein Single Point of Failure. Ein Multi-Provider-DNS-Setup mit Health Checks und automatischem Failover hält die RTO unter 15 Minuten. Die Architektur: primär Cloudflare, sekundär AWS Route 53, Health Check alle 30 Sekunden, Failover-TTL von 60 Sekunden. Monatliche Gesamtkosten: 0,50 $.

Die Kosten eines DNS-Ausfalls

Die Rechnung ist einfach:

Bei 100.000 $ MRR kostet ein 4-stündiger DNS-Ausfall mehr als die meisten jährlichen DNS-Budgets für SaaS. Die Lösung ist ein Multi-Provider-DNS-Setup mit automatischem Failover. Die Kosten liegen bei 0,50 $/Monat.

Die Architektur: Zwei Provider, Health Checks, automatischer Failover

[User] → [Cloudflare DNS (Primary)] → [Primary IP]
              ↓ failover
         [AWS Route 53 (Secondary)] → [Secondary IP]
              ↓ health checks
         [Health check: GET /health → 200 in 3s]

Das Setup:

1. Cloudflare: Primäres DNS, Proxying, CDN, DDoS-Schutz
2. AWS Route 53: Sekundäres DNS, Health-Check-Monitoring, automatischer Failover
3. Health Checks: Route 53 überwacht einen /health-Endpunkt alle 30 Sekunden
4. Failover-TTL: 60 Sekunden — der DNS-Cache läuft 1 Minute nach dem Failover ab

Schritt 1: Konfigurieren Sie den Health-Endpunkt

Erstellen Sie einen /health-Endpunkt auf Ihrem primären Server, der 200 zurückgibt, wenn er fehlerfrei ist, und non-200, wenn nicht:

// src/routes/health.ts
export const Route = createFileRoute('/health')({
  GET: async () => {
    const dbHealthy = await checkDatabaseConnection()
    const cacheHealthy = await checkCacheConnection()

    if (dbHealthy && cacheHealthy) {
      return new Response(JSON.stringify({ status: 'ok' }), {
        status: 200,
        headers: { 'Content-Type': 'application/json' },
      })
    }

    return new Response(JSON.stringify({ status: 'degraded' }), {
      status: 503,
      headers: { 'Content-Type': 'application/json' },
    })
  },
})

Der Health-Endpunkt muss die tatsächlichen Abhängigkeiten überprüfen — Datenbank, Cache, externe APIs. Ein Health Check, der immer 200 zurückgibt, ist nutzlos.

Schritt 2: Richten Sie AWS Route 53 als sekundäres DNS ein

AWS Route 53 Health Checks überwachen den Health-Endpunkt und aktualisieren das DNS automatisch, wenn der primäre Server ausfällt:

# Erstellen eines Health Checks
aws route53 create-health-check --caller-reference $(date +%s) \
  --health-check-config '{
    "Type": "HTTPS",
    "FullyQualifiedDomainName": "tanstackship.com",
    "Port": 443,
    "ResourcePath": "/health",
    "RequestInterval": 10,
    "FailureThreshold": 3
  }'

RequestInterval: 10 bedeutet, dass Route 53 alle 10 Sekunden prüft. FailureThreshold: 3 bedeutet, dass 3 aufeinanderfolgende Fehler einen Failover auslösen. Gesamte Failover-Zeit: 30 Sekunden + DNS-TTL-Verbreitung.

Schritt 3: Konfigurieren Sie die DNS-Failover-Record-Sets

Erstellen Sie in Route 53 zwei Record-Sets:

Primärer Record (Cloudflare-Ursprung):

Name: tanstackship.com
Type: A
TTL: 60
Value: [Cloudflare origin IP]
Health check: [Route 53 health check]
Failover: Primary

Sekundärer Record (direkter Ursprung):

Name: tanstackship.com
Type: A
TTL: 60
Value: [Direct origin IP]
Health check: None (always healthy — this is the fallback)
Failover: Secondary

Wenn Route 53 drei aufeinanderfolgende fehlgeschlagene Health Checks beim primären Server erkennt, hört es auf, Anfragen für den primären Record zu beantworten, und beginnt, den sekundären Record zurückzugeben. DNS-Resolver speichern die neue Antwort für 60 Sekunden (TTL) im Cache.

Schritt 4: Setzen Sie angemessene TTLs

Niedrige TTLs bedeuten einen schnelleren Failover, aber höhere Kosten für DNS-Anfragen:

60-Sekunden-TTLs bei A-Records bedeuten: Der Failover ist in insgesamt 60–90 Sekunden abgeschlossen (30 Sek. Health-Check-Erkennung + 60 Sek. TTL-Verbreitung). Dies ist das richtige Gleichgewicht für die meisten SaaS-Apps.

Schritt 5: Testen Sie den Failover

Vertrauen Sie niemals einem Failover-System, das Sie nicht getestet haben. Testen Sie es:

1. Verschlechtern Sie den Health-Endpunkt: Geben Sie für 5 Minuten 503 zurück und überprüfen Sie, ob Route 53 den Fehler erkennt.
2. Blockieren Sie die primäre IP: Verwenden Sie eine Firewall-Regel, um den ausgehenden Traffic für 1 Minute zu blockieren, und überprüfen Sie, ob das DNS umschaltet.
3. Simulieren Sie einen kompletten primären Ausfall: Fahren Sie den primären Server herunter und überprüfen Sie, ob der Failover ausgelöst wird.

Testen Sie vierteljährlich. Ein Failover, das noch nie getestet wurde, ist kein Failover-System — es ist nur ein Plan.

Die Incident-Response-Sequenz

Wenn der primäre Server ausfällt und Route 53 auf den sekundären Server umschaltet:

Minute 0–2: Alarm wird ausgelöst Ein PagerDuty/OpsGenie-Alarm wird ausgelöst, wenn der Health Check 3-mal fehlschlägt. Der On-Call-Ingenieur bestätigt dies.

Minute 2–5: Verifizieren Sie den Fehler Prüfung: Handelt es sich um einen echten Ausfall oder um ein False Positive beim Health Check? Überprüfen Sie den Health-Endpunkt direkt, checken Sie den Cloudflare-Status und prüfen Sie die Cloudflare-DNS-Auflösung.

Minute 5–10: Bewerten Sie die RTO Ist der primäre Server in unter 15 Minuten wiederherstellbar? Wenn ja, arbeiten Sie am primären Server. Wenn nicht, bestätigen Sie, dass der Route 53-Failover aktiv ist, und überwachen Sie dies.

Minute 10+: Kommunizieren Sie Aktualisierung der Statusseite alle 15 Minuten. Direkte Kundenkommunikation, falls der Ausfall 30 Minuten überschreitet.

Das Problem der TTL-Verbreitung

Das harte Limit für die Geschwindigkeit eines DNS-Failovers ist die TTL-Verbreitung. Selbst bei 60-Sekunden-TTLs speichern einige DNS-Resolver Records länger als die TTL im Cache. In der Praxis lösen 95 % der Nutzer die neue IP innerhalb von 90 Sekunden auf. Die restlichen 5 % können bis zu 4 Stunden lang eine veraltete Auflösung erleben.

Für wirklich kritischen Traffic sollten Sie das Cloudflare-eigene Load Balancing mit Health Checks verwenden — es führt einen Failover auf der Proxy-Schicht ohne DNS-Verbreitungsverzögerung durch. Aber das erfordert Cloudflare Pro+ (20 $/Monat) und eine andere Architektur.

Die Kosten von 0,50 $/Monat

AWS Route 53 Health Checks: 0,50 $/Monat pro Health Check (die ersten 50 sind im AWS Free Tier kostenlos enthalten). Für eine einzelne SaaS-App entspricht ein Health Check insgesamt 0,50 $/Monat.

Cloudflare ist für das DNS-Hosting kostenlos. Das primäre DNS kostet nichts.

Verwandte Artikel: Dns Disaster Recovery Saas · Saas Data Backup Disaster Recovery · Multilingual Seo Saas Strategy

Checkliste für den produktiven Einsatz

• Health-Endpunkt gibt korrekten Status zurück — überprüft alle Abhängigkeiten
• Route 53 Health Check ist konfiguriert — 10-Sekunden-Intervall, 3-Fehler-Schwellenwert
• Sekundärer DNS-Record ist erstellt — zeigt auf die direkte Ursprungs-IP
• TTL ist auf 60 Sekunden gesetzt — bei allen kritischen A-Records
• Failover wird vierteljährlich getestet — vertrauen Sie niemals einem ungetesteten Failover
• Incident Response ist dokumentiert — Alarm → verifizieren → bewerten → kommunizieren
• Statusseite ist konfiguriert — automatisierte Updates während des Failovers

TanStack Ship wird auf Cloudflare Workers mit Multi-Region-Redundanz bereitgestellt. Sehen Sie sich die Deployment-Dokumentation und die vollständige Feature-Liste an.