Amazon SAA-C03: Hochverfügbarkeit, Fehlertoleranz & Notfallwiederherstellung — Lernleitfaden

By Laurynas Brazys · 17 July 2026 · #amazon #saa-c03 #certification #exam-prep #study-guide

Teil des AWS SAA-C03 — Vollständiger Lernleitfaden. Üben Sie mit verifizierten Antworten im Amazon-Prüfungscenter, oder absolvieren Sie zeitlich begrenzte Übungstests auf ExamRoll.io.

Multi-AZ-Bereitstellungen und Replikation

Multi-AZ-Architekturen adressieren den Ausfall eines einzelnen Rechenzentrums oder einer Availability Zone – nicht mehr. Diese Unterscheidung ist der am häufigsten missverstandene Punkt im Hochverfügbarkeitsdesign. Eine Multi-AZ-Bereitstellung toleriert den Verlust einer AZ innerhalb einer Region; sie toleriert nicht einen regionenweiten Ausfall, eine Beeinträchtigung eines regionalen Dienstes oder das versehentliche Löschen einer Ressource, das die Löschung sofort auf den Standby repliziert. Die Replikation propagiert fehlerhafte Daten – logische Korruption, Schemafehler, Ransomware-Schreibvorgänge – originalgetreu, weshalb Replikation und Backup sich ergänzen und keine Substitute sind.

Bei Amazon RDS stellt Multi-AZ eine synchrone Standby-Replik in einer anderen AZ bereit. Schreibvorgänge werden auf beiden Instanzen bestätigt (Commit), bevor eine Bestätigung erfolgt, was einen RPO von praktisch null und einen RTO von typischerweise 60–120 Sekunden bei einem automatischen Failover ermöglicht. Bei der klassischen Multi-AZ-Instanz-Bereitstellung ist der Standby nicht lesbar – er dient ausschließlich der Langlebigkeit und dem Failover. Multi-AZ-Cluster-Bereitstellungen (zwei lesbare Standbys) reduzieren die Failover-Zeit weiter und bieten eine gewisse Leseskalierung, beschränken sich aber immer noch auf eine Region.

Für die Leseskalierung fügen Sie Read Replicas hinzu. Read Replicas verwenden asynchrone Replikation und dienen dazu, Reporting-, Analyse- und Dashboard-Abfragen auszulagern. Eine Read Replica als HA-Failover-Mechanismus zu behandeln, ist aus drei Gründen falsch: Die Replikation ist asynchron (Datenverlust bei der Heraufstufung), die Heraufstufung ist manuell oder skriptbasiert (nicht automatisch) und der primäre Endpunkt wird nicht beibehalten. Wenn eine wachsende Arbeitslast mehr Lesekapazität ohne neue Komplexität benötigt, fügen Sie eine Read Replica hinzu; wenn die Anforderung ein automatisches Failover ohne Datenverlust ist, verwenden Sie Multi-AZ. Wenn RPO/RTO einen Regionsausfall für eine relationale Engine überstehen müssen, bietet Aurora Global Database eine regionsübergreifende Replikationslatenz von unter einer Sekunde und ein verwaltetes Failover-RTO von unter einer Minute.

Amazon ElastiCache folgt demselben Muster mit Replikationsgruppen. Eine Redis-Replikationsgruppe mit aktiviertem Multi-AZ unterhält eine primäre und eine oder mehrere Repliken über AZs hinweg; wenn die primäre Instanz ausfällt, stuft ElastiCache eine Replik herauf und aktualisiert den primären Endpunkt. Für die horizontale Skalierung partitioniert Redis (mit aktiviertem Cluster-Modus) Daten über Shards, wobei jeder Shard seine eigene Replikationsgruppe ist. Memcached hingegen repliziert nicht – ein Knotenausfall bedeutet Datenverlust für diese Partition.

Amazon FSx bietet Multi-AZ-Bereitstellungstypen für FSx for Windows File Server und FSx for ONTAP, die synchrone Replikation zwischen einem bevorzugten und einem Standby-Dateiserver verwenden. FSx for Lustre ist im Allgemeinen Single-AZ (Scratch oder Persistent); die Langlebigkeit für Lustre ergibt sich aus Verknüpfungen mit S3-Daten-Repositorys, nicht aus der AZ-Replikation.

# RDS Multi-AZ with cross-Region read replica for DR
DBInstance:
  Type: AWS::RDS::DBInstance
  Properties:
    Engine: sqlserver-ee
    MultiAZ: true              # AZ-level HA (synchronous)
    BackupRetentionPeriod: 35
    CopyTagsToSnapshot: true
    DeletionProtection: true

Automatisierte RDS-Backups und Point-in-Time Recovery

Automatisierte RDS-Backups kombinieren einen täglichen Snapshot mit kontinuierlichen Uploads von Transaktionsprotokollen alle 5 Minuten nach S3 und ermöglichen so eine Point-in-Time Recovery (PITR) zu jeder beliebigen Sekunde innerhalb des Aufbewahrungszeitraums von 1–35 Tagen. Wenn Ihr RPO 2 Stunden beträgt, decken die nativen Backups von RDS dies bereits ab – es ist keine zusätzliche Snapshot-Planung erforderlich, und die zusätzliche Verwendung von AWS Backup ist redundant, es sei denn, Sie benötigen regionsübergreifende Kopien, kontoübergreifende Isolierung oder Vault Lock-Semantik, die über das hinausgeht, was die RDS-Snapshot-Kopie bietet. Das standardmäßige automatisierte Backup ist oft die günstigste korrekte Antwort auf moderate RPO-Anforderungen.

AWS Backup als zentrale Steuerungsebene

AWS Backup ist die richtliniengesteuerte Steuerungsebene für Backups über EBS, EC2 (als AMIs), RDS, Aurora, DynamoDB, EFS, FSx, Storage Gateway, S3 und mehr. Anstatt dienstspezifische Snapshot-Logik zu skripten, definieren Sie Sicherungspläne, die Regeln zu Häufigkeit, Backup-Fenster, Start-/Abschlussfenstern, Lebenszyklus-Übergängen in den Cold Storage, Aufbewahrung und Ziel-Tresoren gruppieren. Ressourcen werden durch Ressourcenzuweisungen nach Tag oder ARN registriert, sodass eine Tagging-Konvention wie Backup=Daily zum operativen Vertrag wird, der die Abdeckung regelt. Für Flotten von Hunderten von EC2-Instanzen ist die Tag-basierte Auswahl der Ansatz mit dem geringsten Aufwand – wenden Sie das Tag an und lassen Sie AWS Backup die Aufzählung durchführen, anstatt Zeitpläne pro Instanz zu erstellen.

Ein Backup-Tresor ist der mit KMS verschlüsselte Container, in dem sich die Wiederherstellungspunkte befinden. Der Zugriff wird durch Ressourcenrichtlinien auf dem Tresor gesteuert.

BackupPlan:
  BackupPlanName: tier1-daily
  Rules:
    - RuleName: daily-35day
      TargetBackupVault: vault-locked-compliance
      ScheduleExpression: cron(0 5 ? * * *)
      StartWindowMinutes: 60
      CompletionWindowMinutes: 180
      Lifecycle:
        MoveToColdStorageAfterDays: 30
        DeleteAfterDays: 365
      CopyActions:
        - DestinationBackupVaultArn: arn:aws:backup:us-west-2:111122223333:backup-vault:dr-vault
          Lifecycle: { DeleteAfterDays: 365 }

Regions- und kontoübergreifende Kopien

Der CopyActions-Block ist der Mechanismus für regionsübergreifende DR-Kopien. AWS Backup übernimmt die Snapshot-Kopie, verschlüsselt sie mit einem KMS-Schlüssel der Zielregion neu (der Ziel-Tresor muss auf einen Schlüssel in dieser Region verweisen) und wendet einen unabhängigen Lebenszyklus an. EBS- und RDS-Snapshots verbleiben standardmäßig in der Quellregion – wenn die gesamte Region beeinträchtigt ist, sind es auch die Snapshots. Jede regulatorische oder geschäftliche Anforderung, die regionale Ausfallsicherheit erwähnt, muss einen expliziten Schritt zum regionsübergreifenden Kopieren beinhalten, sei es durch AWS Backup-Kopieraktionen, die regionsübergreifende Kopierfunktion für automatisierte RDS-Snapshots oder DLM-Richtlinien mit regionsübergreifenden Zielen.

Für kontoübergreifende Kopien delegiert AWS Organizations ein Administratorkonto für AWS Backup; die Richtlinie des Quell-Tresors erlaubt den Zugriff durch das Zielkonto, und der Ziel-Tresor erlaubt Kopien von der Quelle. Dies ist die kosteneffiziente Methode zur Zentralisierung von DR: Ein Verwaltungskonto hält Wiederherstellungspunkte von vielen Workload-Konten und kann in beiden Regionen wiederherstellen. Für EC2 ermöglicht eine AMI-Kopie in eine zweite Region plus Snapshot-Freigabe das Starten von Instanzen dort ohne warme Infrastruktur. Verschlüsselte Snapshots erfordern die Freigabe des CMK – das Zielkonto oder die Zielregion benötigt kms:CreateGrant und Zugriff auf den Schlüssel. Das Fehlen dieser Berechtigung ist der Grund, warum kontoübergreifende Wiederherstellungen ohne Fehlermeldung scheitern.

Ein RPO von 24 Stunden wird kostengünstig durch einen täglich erstellten, regionsübergreifend kopierten automatisierten Snapshot erfüllt – weitaus kostengünstiger als eine regionsübergreifende Read Replica oder ein warmer Standby-Cluster. Wechseln Sie erst dann zu kontinuierlicher Replikation, wenn der RPO unter das fällt, was die Snapshot-Frequenz liefern kann.

AMI-Lebenszyklus und EC2-Backups

Zwei Mechanismen automatisieren EC2-Backups: Data Lifecycle Manager (DLM) und AWS Backup. DLM ist älter als AWS Backup und erstellt richtliniengesteuert EBS-Snapshots oder AMIs nach einem Zeitplan, mit regions- und kontoübergreifenden Kopieraktionen. AWS Backup umfasst diese Funktionalität und fügt zentrale Richtlinien, Vault Lock und einen dienstübergreifenden Geltungsbereich hinzu. Bevorzugen Sie AWS Backup, wenn Sie es bereits für andere Dienste einsetzen; verwenden Sie DLM für reine EBS/AMI-Szenarien, in denen Sie keine Vault-Funktionen benötigen.

Für zustandslose (stateless) Web-Tiers hinter einer Auto Scaling-Gruppe ohne persistente lokale Daten ist das Sichern laufender EC2-Instanzen eine Verschwendung. Die korrekte Vorgehensweise ist, ein gehärtetes AMI zu erstellen (zu „backen“, via EC2 Image Builder oder einer CI-Pipeline), es in der Startvorlage (Launch Template) zu referenzieren und die ASG den Austausch von Instanzen übernehmen zu lassen. Der Backup-Aufwand konzentriert sich auf die zustandsbehafteten (stateful) Tiers, deren native automatisierte Backups die RPO erfüllen.

Unveränderbarkeit (Immutability): Vault Lock und Object Lock

Ein einfacher Snapshot in Ihrem Konto kann von jedem mit der richtigen IAM-Berechtigung gelöscht werden – Snapshots allein erfüllen nicht die Anforderungen an die Unveränderbarkeit. Regulatorische Rahmenbedingungen (SEC 17a-4, FINRA, HIPAA, DSGVO) fordern häufig eine Write-Once-Read-Many (WORM)-Aufbewahrung, die selbst Administratoren nicht umgehen können. Zwei AWS-Mechanismen bieten dies.

AWS Backup Vault Lock erzwingt WORM für einen Backup-Tresor (Vault):

Im Compliance-Modus kann kein Benutzer – einschließlich des Root-Kontos – die Aufbewahrungsfrist verkürzen, Wiederherstellungspunkte vor Ablauf löschen oder die Sperre selbst entfernen, sobald die Abkühlphase abgelaufen ist. Dies verhindert sowohl die Löschung durch Insider als auch durch einen Ransomware-Angreifer, der das Konto vollständig kompromittiert hat.

aws backup put-backup-vault-lock-configuration \
  --backup-vault-name ComplianceVault \
  --changeable-for-days 3 \
  --min-retention-days 2555 \
  --max-retention-days 2920

S3 Object Lock bietet WORM auf Objektebene im Governance-Modus (privilegierte Benutzer mit s3:BypassGovernanceRetention können die Sperre umgehen) oder im Compliance-Modus (niemand, einschließlich Root, kann die Aufbewahrung löschen oder verkürzen). Legal Hold ist unabhängig von den Aufbewahrungsfristen. Object Lock erfordert Versioning und muss bei der Erstellung des Buckets aktiviert werden, um vollen Schutz zu gewährleisten.

Kapazitätsreservierungen für die Failover-Region

Ein DR-Plan, der davon ausgeht, dass in der Failover-Region am Tag eines großen Ausfalls EC2-Kapazität verfügbar sein wird, ist kein Plan. Wenn eine Region ausfällt, führen alle gleichzeitig ein Failover durch, und Instanztypen – insbesondere große, GPU- oder spezialisierte Formen – können erschöpft sein. On-Demand Capacity Reservations (ODCRs) in der Zielregion garantieren Kapazität für einen bestimmten Instanztyp, eine Plattform und eine AZ und werden in Rechnung gestellt, unabhängig davon, ob sie genutzt werden oder nicht. Kombinieren Sie sie mit einem Savings Plan, um die Kosten zu kompensieren. Für langfristige GPU/ML-Verpflichtungen kommen Capacity Blocks zum Einsatz; für Flexibilität bei der Instanzfamilie deckt eine Capacity Reservation Fleet mehrere Instanzfamilien ab. Das Prinzip lautet: Wenn das Geschäft garantierte Rechenleistung in der DR-Region erfordert, reservieren Sie sie – verlassen Sie sich nicht auf die Best-Effort-Verfügbarkeit von On-Demand.

Auswahl der DR-Strategie

AWS kanonisiert vier DR-Stufen (Tiers), jede mit einem eigenen Kompromiss zwischen Kosten und Wiederherstellungszeit:

Die richtige Stufe wird durch die RPO und RTO des Unternehmens vorgegeben – nicht durch architektonische Vorlieben. Eine RPO von 24 Stunden toleriert tägliche regionsübergreifende Snapshot-Kopien (Backup & Restore). Eine RPO von Sekunden erfordert kontinuierliche Replikation – regionsübergreifende Read Replicas, Aurora Global Database, DynamoDB Global Tables oder S3 Cross-Region Replication. Der Versuch, eine 5-Minuten-RPO mit nächtlichen Snapshots zu erreichen, ist architektonisch unmöglich, unabhängig vom Budget. Umgekehrt ist die standardmäßige Verwendung von Active-Active für jeden Workload ein Kosten-Antipattern: Es erfordert global konsistente Daten (DynamoDB Global Tables oder Aurora Global mit Write-Forwarding), duplizierte Rechenleistung im vollen Umfang und komplexe Traffic-Steuerung über Route 53 oder Global Accelerator. Wählen Sie das günstigste Muster, das die angegebene RPO/RTO erfüllt – für eine 2-Stunden-RPO reichen Backup-and-Restore oder Pilot Light in der Regel aus, und Warm Standby ist Over-Engineering.

Löschschutz und mehrschichtige Sicherheitsvorkehrungen

Resilienz bedeutet nicht nur „Haben wir Backups?“ – sondern „Kann ein einzelner Akteur, Fehler oder Angriff sie löschen?“. Mehrschichtige Kontrollen verhindern die Katastrophe durch einen einzigen falschen Klick:

• RDS: DeletionProtection aktivieren und einen finalen Snapshot beim Löschen verlangen.
• EC2: DisableApiTermination und DisableApiStop für kritische Instanzen aktivieren.
• DynamoDB: Löschschutz und Point-in-Time Recovery aktivieren.
• S3: Versioning + MFA Delete + Object Lock für Unveränderbarkeit.
• CloudFormation: DeletionPolicy: Retain für zustandsbehaftete Ressourcen und Schutz vor Stack-Beendigung (Termination Protection).
• IAM SCPs: backup:DeleteRecoveryPoint, backup:DeleteBackupVault, rds:DeleteDBInstance und ec2:DeleteSnapshot außerhalb von Break-Glass-Rollen verweigern.

aws rds modify-db-instance \
  --db-instance-identifier prod-pg \
  --deletion-protection \
  --backup-retention-period 35 \
  --apply-immediately

In Kombination mit Vault Lock im Compliance-Modus ergeben diese eine tiefengestaffelte Verteidigung (Defense in Depth): Selbst kompromittierte Administrator-Anmeldeinformationen können die Wiederherstellungspunkte der letzten Verteidigungslinie nicht zerstören.

Häufige Fallstricke

Multi-AZ als DR behandeln. RDS Multi-AZ, ElastiCache Multi-AZ und FSx Multi-AZ befinden sich alle innerhalb einer einzigen Region. Ein regionaler API-Ausfall, ein versehentliches Löschen einer Tabelle oder eine falsch angewendete Schema-Migration betrifft beide Knoten. Jede Anforderung, die „eine andere Region“, „regionalen Ausfall“ oder „regionsübergreifendes RPO“ erwähnt, erfordert eine regionsübergreifende Replikation oder Kopie – Multi-AZ allein erfüllt diese Anforderung nicht.

Lesereplikas mit HA verwechseln. Lesereplikas sind asynchron, werden manuell hochgestuft (promote) und ändern ihre Endpunkte. Sie lösen die Skalierung von Lesezugriffen, nicht das automatische Failover.

Annahme, dass Snapshots Compliance gewährleisten. Snapshots ohne Vault Lock (Compliance-Modus) oder Object Lock können von jedem Principal mit der entsprechenden IAM-Berechtigung und vom Root-Konto gelöscht werden. Die regulatorische WORM-Aufbewahrung erfordert eine explizite Konfiguration der Unveränderlichkeit (Immutability), bei der eine gesperrte Bedenkzeit (Cooling-off Period) abgelaufen ist.

Nur lokale Snapshots für ein regionales RPO. EBS- und RDS-Snapshots werden standardmäßig in der Quellregion gespeichert. Regionale Ausfallsicherheit erfordert eine explizite, regionsübergreifende Kopieraktion.

Backups ohne getestete Wiederherstellungen oder reservierte Kapazität. Ein Snapshot, den Sie noch nie wiederhergestellt haben, ist eine Hypothese, kein Backup. Wiederherstellungsübungen decken fehlende IAM-Rollen, Probleme beim Zugriff auf KMS-Schlüssel in der Zielregion und im Zielkonto sowie nicht verfügbare Instanztypen auf. Ohne Capacity Reservations für kritische Workloads hat die DR-Region möglicherweise nicht die Kapazität, die Sie benötigen, wenn alle gleichzeitig ein Failover durchführen – und das RTO wird unbegrenzt.

Überdimensionierung zu Aktiv-Aktiv. Doppelte globale Rechenleistung, global konsistente Datenreplikation und komplexe Verkehrssteuerung sind teuer. Wenn RPO/RTO dies nicht rechtfertigen, ist eine Pilot-Light- oder Warm-Standby-Architektur die richtige Wahl.

Backups von zustandslosen Ebenen. Das Erstellen von Snapshots von flüchtigen Webservern hinter einer ASG verschwendet Geld und verkompliziert die Wiederherstellung. Erstellen Sie AMIs, referenzieren Sie diese in Launch Templates und konzentrieren Sie Ihre Backup-Investitionen auf zustandsbehaftete (stateful) Daten.

← Management · Alle Domänen

Diese Fragen üben → · Zeitlich begrenzte Übung auf ExamRoll.io →

Amazon durchsuchen →