RDS Multi-AZ: Hochverfügbarkeit, Failover und was es wirklich bringt

Ein Produktionsdatenbankausfall um 3 Uhr morgens ist der Moment, in dem man sich fragt, ob man Multi-AZ hätte aktivieren sollen. RDS Multi-AZ ist eine der meistgenutzten Funktionen für Amazon RDS Hochverfügbarkeit — aber in der Praxis herrscht oft Verwirrung darüber, was es tatsächlich liefert und was nicht.

TL;DR: RDS Multi-AZ auf einen Blick

Aspekt	Multi-AZ: Ja	Multi-AZ: Nein
Automatischer Failover	✅ Ja (typisch 60–120 Sek.)	❌ Manuell
Synchrone Replikation	✅ Ja	❌ Nein
Leseleistung (Read Scaling)	❌ Nein (Standby nicht lesbar)	❌ Nein
Schutz vor AZ-Ausfall	✅ Ja	❌ Nein
Zusatzkosten	Ca. 2× Instanzkosten	Basiskosten
Backup-Fenster-Impact	Reduziert (Backup vom Standby)	Kurze I/O-Unterbrechung möglich

Wie RDS Multi-AZ wirklich funktioniert

Multi-AZ ist kein Cluster im klassischen Sinne — es ist eine synchrone Spiegelung auf Speicherebene. AWS betreibt eine primäre Instanz in einer Availability Zone und eine Standby-Instanz in einer anderen AZ derselben Region. Schreiboperationen werden erst bestätigt, wenn beide Seiten persistiert haben. Das ist der Kern des Mechanismus: keine asynchrone Replikation mit Lag, sondern synchrones Commit.

Der DNS-Endpunkt der Datenbank zeigt immer auf die primäre Instanz. Bei einem Failover aktualisiert AWS den DNS-Eintrag, sodass er auf die Standby-Instanz zeigt, die dann zur neuen Primärinstanz wird. Anwendungen müssen dafür keine eigene Failover-Logik implementieren — aber sie müssen DNS-TTL-Caching korrekt handhaben, sonst verbinden sie sich nach dem Failover weiterhin mit der alten IP.

Multi-AZ verhält sich wie ein stiller Schatten: immer synchron, nie direkt ansprechbar — bis der Primärknoten ausfällt und der Schatten übernimmt.

graph TD App["Anwendung"] -->|'DNS-Endpunkt'| Primary["Primäre Instanz
AZ-A"] Primary -->|'Synchrone Replikation'| Standby["Standby-Instanz
AZ-B"] Primary -->|'Ausfall'| Failover{"Failover-Trigger"} Failover -->|'DNS-Update'| NewPrimary["Neue Primärinstanz
ehem. Standby AZ-B"] App -->|'Reconnect via DNS'| NewPrimary style Primary fill:#2ecc71,color:#fff style Standby fill:#95a5a6,color:#fff style NewPrimary fill:#e67e22,color:#fff style Failover fill:#e74c3c,color:#fff

1. Primäre Instanz (AZ-A): Empfängt alle Lese- und Schreibanfragen über den RDS-Endpunkt.
2. Synchrone Replikation: Jede Schreiboperation wird synchron auf die Standby-Instanz in AZ-B übertragen, bevor ein Commit bestätigt wird.
3. Standby-Instanz (AZ-B): Empfängt keine direkten Anfragen — sie ist nicht lesbar und nicht direkt adressierbar.
4. Failover-Trigger: Bei Ausfall der primären Instanz (Hardware, AZ-Ausfall, Patching) aktualisiert AWS den DNS-Eintrag automatisch.
5. Neue Primärinstanz: Die ehemalige Standby-Instanz übernimmt — Anwendungen reconnecten über denselben Endpunkt.

Was Multi-AZ konkret bringt — und was nicht

Hochverfügbarkeit und automatischer Failover

Das ist der eigentliche Zweck. Multi-AZ schützt vor AZ-Ausfällen, Hardware-Fehlern und geplanten Wartungsfenstern. AWS führt Patches und Minor-Version-Upgrades auf der Standby-Instanz durch, schwenkt dann über, und patcht die ehemalige Primärinstanz — das reduziert die Downtime auf die Failover-Zeit statt auf die gesamte Patch-Dauer.

Wichtig: Multi-AZ schützt nicht vor logischen Fehlern. Wenn eine Anwendung versehentlich Daten löscht, ist dieser Fehler synchron auf die Standby-Instanz repliziert. Dafür sind Point-in-Time Recovery und Snapshots zuständig.

Kein Performance-Boost für Leseanfragen

Das ist der häufigste Irrtum in der Praxis. Die Standby-Instanz ist nicht lesbar — sie nimmt keine Verbindungen entgegen. Wer Lese-Skalierung benötigt, braucht RDS Read Replicas, nicht Multi-AZ. Multi-AZ und Read Replicas lösen unterschiedliche Probleme und können kombiniert werden.

Reduzierter I/O-Impact bei Backups

Bei aktiviertem Multi-AZ führt RDS automatisierte Backups von der Standby-Instanz durch. Das bedeutet: kein I/O-Einbruch auf der primären Instanz während des Backup-Fensters — ein operativer Vorteil, der in der Dokumentation oft untergeht, aber in I/O-intensiven Workloads spürbar ist.

Schreiblatenz: minimaler Overhead

Synchrone Replikation bedeutet, dass jedes Commit auf beide AZs warten muss. In der Praxis ist dieser Overhead messbar, aber für die meisten Workloads vernachlässigbar — AWS betreibt AZs innerhalb einer Region mit sehr niedrigen Inter-AZ-Latenzen. Wenn Schreiblatenz ein kritischer Faktor ist, sollte man das mit eigenem Benchmarking verifizieren, nicht auf Basis von Annahmen.

graph LR subgraph MultiAZ["Multi-AZ: Hochverfügbarkeit"] P["Primär
Lesen + Schreiben"] -->|'Synchron'| S["Standby
Nicht lesbar"] end subgraph ReadReplica["Read Replica: Lese-Skalierung"] M["Primär
Schreiben"] -->|'Asynchron'| R1["Replica 1
Nur lesen"] M -->|'Asynchron'| R2["Replica 2
Nur lesen"] end style P fill:#2ecc71,color:#fff style S fill:#95a5a6,color:#fff style M fill:#2ecc71,color:#fff style R1 fill:#3498db,color:#fff style R2 fill:#3498db,color:#fff

1. Multi-AZ (Hochverfügbarkeit): Synchrone Replikation, automatischer Failover, Standby nicht lesbar.
2. Read Replica (Lese-Skalierung): Asynchrone Replikation, lesbar, kein automatischer Failover als primäre Instanz (außer bei Promotion).
3. Kombination: Read Replicas können in einer anderen AZ oder Region betrieben werden — das kombiniert Lese-Skalierung mit geografischer Redundanz, ersetzt aber nicht Multi-AZ-Failover.

RDS Multi-AZ aktivieren — CLI-Beispiele

Multi-AZ bei einer bestehenden Instanz aktivieren

aws rds modify-db-instance \
  --db-instance-identifier meine-produktions-db \
  --multi-az \
  --apply-immediately

Ohne --apply-immediately wird die Änderung beim nächsten Wartungsfenster angewendet. In Produktionsumgebungen ist es sinnvoll, den Zeitpunkt kontrolliert zu wählen, da die Konvertierung einen kurzen Neustart auslösen kann.

Multi-AZ-Status einer Instanz prüfen

aws rds describe-db-instances \
  --db-instance-identifier meine-produktions-db \
  --query 'DBInstances[0].{MultiAZ:MultiAZ,Status:DBInstanceStatus,Endpoint:Endpoint.Address}'

Neue Instanz direkt mit Multi-AZ erstellen

aws rds create-db-instance \
  --db-instance-identifier neue-produktions-db \
  --db-instance-class db.t3.medium \
  --engine mysql \
  --master-username adminuser \
  --master-user-password 'SicheresPasswort123!' \
  --allocated-storage 100 \
  --multi-az \
  --backup-retention-period 7 \
  --storage-type gp3

Failover-Ereignisse in CloudWatch Logs / Events prüfen

aws rds describe-events \
  --source-identifier meine-produktions-db \
  --source-type db-instance \
  --duration 1440

Die Ausgabe enthält Ereignisse wie 'Multi-AZ instance failover started' und 'DB instance restarted' — nützlich für Post-Incident-Analysen.

IAM-Berechtigungen für Multi-AZ-Verwaltung

🔽 IAM-Policy anzeigen (Least Privilege für Multi-AZ-Operationen)

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "RDSMultiAZManagement",
      "Effect": "Allow",
      "Action": [
        "rds:ModifyDBInstance",
        "rds:DescribeDBInstances",
        "rds:DescribeEvents",
        "rds:RebootDBInstance"
      ],
      "Resource": "arn:aws:rds:us-east-1:123456789012:db:meine-produktions-db"
    },
    {
      "Sid": "RDSDescribeGlobal",
      "Effect": "Allow",
      "Action": [
        "rds:DescribeDBEngineVersions",
        "rds:DescribeOrderableDBInstanceOptions"
      ],
      "Resource": "*"
    }
  ]
}

Typisches Fehlerbild aus der Praxis: DNS-Caching nach Failover

Ein häufiges Muster: Multi-AZ ist aktiviert, der Failover läuft erfolgreich durch — aber die Anwendung verbindet sich noch Minuten danach mit der alten IP. Der Datenbankendpunkt hat sich geändert, aber der Anwendungsserver cached die DNS-Auflösung aggressiv.

Erste Reaktion: 'Multi-AZ hat nicht funktioniert.' Tatsächliche Ursache: Der JDBC-Connection-Pool oder der OS-DNS-Cache hält die alte IP-Adresse fest. Multi-AZ hat korrekt funktioniert — der DNS-Eintrag wurde aktualisiert, aber die Anwendung hat ihn nicht neu aufgelöst.

Die Lösung liegt nicht in Multi-AZ, sondern in der Anwendungskonfiguration: DNS-TTL respektieren, Connection-Pool mit Reconnect-Logik konfigurieren, und bei JDBC-Treibern die Option zur automatischen Reconnection aktivieren. Wer das nicht beachtet, erlebt nach jedem Failover manuelle Neustarts — obwohl Multi-AZ korrekt arbeitet.

Multi-AZ ist kein Ersatz für robuste Reconnect-Logik in der Anwendungsschicht. Der Failover dauert Sekunden — aber eine Anwendung ohne Reconnect-Mechanismus bleibt trotzdem hängen.

Multi-AZ vs. Read Replicas: Entscheidungshilfe

graph TD Start(["Datenbankbedarf analysieren"]) --> Q1{"Automatischer Failover
bei AZ-Ausfall nötig?"} Q1 -->|'Ja'| MultiAZ["Multi-AZ aktivieren"] Q1 -->|'Nein'| Q2{"Lese-Skalierung
nötig?"} Q2 -->|'Ja'| ReadReplica["Read Replica erstellen"] Q2 -->|'Nein'| Single["Single-AZ genügt"] MultiAZ --> Q3{"Zusätzlich
Lese-Skalierung?"} Q3 -->|'Ja'| Both["Multi-AZ + Read Replica"] Q3 -->|'Nein'| MultiAZOnly["Multi-AZ allein"] style MultiAZ fill:#2ecc71,color:#fff style Both fill:#e67e22,color:#fff style ReadReplica fill:#3498db,color:#fff style Single fill:#95a5a6,color:#fff

Kosten und operativer Aufwand

Multi-AZ verdoppelt näherungsweise die Instanz- und Speicherkosten, da AWS eine vollständige Standby-Instanz betreibt. Genaue Preise variieren je nach Region, Instanztyp und Speicherkonfiguration — aktuelle Werte immer in der offiziellen AWS-Preisübersicht prüfen.

Operativ reduziert Multi-AZ den Wartungsaufwand: Patches werden mit minimalem Downtime-Fenster durchgeführt, und Hardware-Ausfälle erfordern keine manuelle Intervention. Für Produktionsdatenbanken ist das in der Regel die richtige Abwägung.

Fazit: RDS Multi-AZ richtig einsetzen

RDS Multi-AZ ist ein Hochverfügbarkeitsmechanismus — kein Performance-Feature. Es schützt vor AZ-Ausfällen und Hardware-Fehlern mit automatischem Failover, reduziert den I/O-Impact von Backups, und vereinfacht Wartungsfenster. Wer Lese-Skalierung benötigt, kombiniert Multi-AZ mit Read Replicas. Wer nach dem Aktivieren von Multi-AZ Verbindungsprobleme nach einem Failover sieht, prüft zuerst DNS-Caching und Connection-Pool-Konfiguration — nicht Multi-AZ selbst.

Für Produktionsdatenbanken, die mehr als minimale Downtime tolerieren können, ist Multi-AZ keine optionale Funktion — es ist die Baseline.

Weiterführende Ressourcen & nächste Schritte

• AWS Dokumentation: RDS Multi-AZ Deployments
• AWS Dokumentation: RDS Read Replicas
• Nächster Schritt: Failover-Verhalten mit aws rds reboot-db-instance --force-failover in einer Nicht-Produktionsumgebung testen
• Connection-Pool-Konfiguration und DNS-TTL-Handling in der Anwendung validieren

Glossar

Begriff	Bedeutung
Multi-AZ	Synchrone Replikation einer RDS-Instanz in eine zweite Availability Zone für automatischen Failover
Standby-Instanz	Die passive Replikationsinstanz in Multi-AZ — nicht lesbar, übernimmt bei Failover
Read Replica	Asynchrone Lesekopie einer RDS-Instanz zur Skalierung von Leseanfragen
Failover	Automatischer Wechsel von der primären zur Standby-Instanz bei einem Ausfall
DNS-TTL	Time-to-Live des DNS-Eintrags — bestimmt, wie lange Clients eine IP-Adresse cachen, bevor sie neu auflösen

Related Posts

• 📄 RDS aus einem Snapshot wiederherstellen: Neuer Endpunkt oder Überschreiben?