Native Replikation
Nutzen Sie den Replikationspfad eines Dienstes für unterstützte Zustände. Beispiele: neue ECR-Images, S3-Objektreplikation oder ein genehmigtes Datenbank-Replikat.
Muster ansehen →Wiederherstellungsstrategien
Der passende Wiederherstellungspfad.
Für jede AWS-Komponente.
Erfahren Sie, wie Images, Zertifikate, Netzwerksteuerungen, Secrets, Daten und Infrastruktur zusammenspielen. Diese Diagramme zeigen das Dockfield-Wiederherstellungsdesign; jede Kundenimplementierung wird separat abgegrenzt und getestet.
Nach Service und Wiederherstellungsziel auswählen
Sieben Familien, ein Wiederherstellungs-Blueprint.
Ein Workload kann mehrere Strategiefamilien kombinieren. Ein Containerdienst benötigt gleichzeitig sein Image, Netzwerk, seine Identität, Secrets und Daten. Die Wiederherstellung der Konfiguration und der Anwendungsdaten beruhen auf getrennten Nachweisen und Zeitangaben.
Ereignisgesteuerte Spiegelung
Erfassen Sie Änderungsereignisse, prüfen Sie die aktuelle Konfiguration und gleichen Sie zugeordnete Entsprechungen in DR ab. SGs und NACLs benötigen einen eigenen Abgleichsdienst.
Muster ansehen →Deklarativer Neuaufbau
Stellen Sie unterstützte Infrastruktur anhand des Recovery-Blueprints in Abhängigkeitsreihenfolge wieder her. Beispiele: VPC, Load Balancer, ECS und EKS.
Muster ansehen →Backup und Point-in-Time-Wiederherstellung
Stellen Sie den Zustand über einen genehmigten Wiederherstellungspunkt und native Backup-Pfade des Dienstes wieder her. Beispiele: RDS, Aurora und unterstützte AWS-Backup-Ressourcen.
Muster ansehen →Erneut ausstellen oder neu erstellen
Erstellen Sie eine gültige Zielressource und ordnen Sie ihre neue Identität zu. Beispiel: ACM-Zertifikate für Zielkonto und Zielregion.
Muster ansehen →Gemeinsame Recovery-Steuerungsebene
Koordinieren Sie Routing-Entscheidungen über die geschützten Umgebungen hinweg. ARC-Routing-Steuerungen wirken auf Route-53-Healthchecks.
Muster ansehen →Organisations-Governance
Verwalten Sie geltende Kontrollen zentral mit delegierter Administration und dienstspezifischen Regionseinstellungen.
Muster ansehen →Images · Erstbefüllung + fortlaufende native Replikation
ECR: Image schützen, dann den Dienst neu aufbauen.
Vorhandene Images und künftige Pushes folgen unterschiedlichen Pfaden. Das Ziel-Image muss verfügbar sein, bevor ECS oder EKS die wiederhergestellte Workload startet.
Ziel vorbereiten
Konfigurieren Sie native Replikationsregeln und Berechtigungen für die Ziel-Registry. Vorhandene Inhalte benötigen einen eigenen Kopierpfad; prüfen Sie den Ziel-Digest und die genehmigte Version.
Repository-Kontrollen müssen geprüft werden
Verschlüsselung, Tag-Unveränderlichkeit, Berechtigungen und Lebenszyklusregeln benötigen eine Zielkonfiguration oder geeignete Erstellungs-Templates. Native Image-Replikation überträgt keine Quelllöschungen.
AWS-Referenzen: ECR-Replikation
Zertifikate · erneute Ausstellung / Reimport
ACM: neues Zielzertifikat, ARN zugeordnet.
Erfassen Sie Zweck und Anforderungen des Zertifikats: Namen, Typ, Validierungsmethode und Workload-Zuordnung. Beantragen oder importieren Sie ein Zertifikat im Zielkonto und in der Zielregion und ordnen Sie dessen ARN dem wiederhergestellten Listener zu.
Die Region der Identität zählt
Ein Quell-ACM-ARN ist kein Zielzertifikat. Bereiten Sie Ausstellung und DNS-Validierung vor einer Recovery-Übung vor; prüfen Sie die Zuordnung am Ziel-Listener.
Private Schlüssel bleiben geschützt
Für die Ermittlung werden keine privaten Schlüssel benötigt. Jeder Import nutzt einen genehmigten sicheren Schlüsselpfad. CloudFront-Zertifikate verwenden us-east-1, auch wenn die Anwendung anderswo läuft.
AWS-Referenzen: ACM-Regionen und Nutzung · Zertifikate importieren
Netzwerkkontrollen · abgleichen + riskante Änderungen zurückhalten
Security Groups und NACLs: die Absicht sicher spiegeln.
Diese Dienste bieten keine native kontoübergreifende SG-/NACL-Replikation. Ein Dockfield-Abgleichprozess nutzt Änderungsereignisse als Signale, liest die aktuelle Konfiguration, ordnet Referenzen zu und wendet genehmigte Zielregeln an. Ein regelmäßiger Abgleich erfasst verpasste oder verzögerte Ereignisse.
| Kontrolle | Security Group | Netzwerk-ACL |
|---|---|---|
| Platzierung | Ressource / Netzwerkschnittstelle | Subnetzzuordnung |
| Datenverkehrsverhalten | Zustandsbehaftet; erlaubte Antworten werden nachverfolgt | Zustandslos; erforderlichen Rückweg zulassen |
| Regelmodell | Zulassungsregeln; referenzierte SG-IDs zuordnen | Geordnete Zulassungs- / Ablehnungsregeln; Regelnummers beibehalten |
| Zielzuordnung | Ziel-VPC, SG-Referenzen und genehmigte CIDRs | Ziel-Subnetzzuordnungen, CIDRs sowie eingehende / ausgehende Regeln |
Ereignisse sind Signale, nicht der vollständige Zustand
Verwenden Sie unterstützte CloudTrail-Schreibereignisse und einen aktivierten Trail. Lesen Sie die maßgebliche Konfiguration erneut ein, behandeln Sie Wiederholungen idempotent und erfassen Sie Abgleichnachweise.
Auch eine widerrufene Berechtigung kann riskant sein
Die Richtlinienprüfung umfasst geänderte Zugriffe und Zuordnungen ebenso wie die vollständige Ressourcenlöschung. Ein zurückgehaltener Änderungsantrag erfordert eine Prüfung; beibehaltene Zugriffe sind eine bewusste Übergangsentscheidung.
AWS-Referenzen: EventBridge über CloudTrail · Verhalten von Netzwerk-ACLs
Sensibler Zustand · getrennt von der Ermittlung
Secrets Manager: Werte gehören nicht in den Blueprint.
Die Ermittlung erfasst Secret-Metadaten und Abhängigkeiten, ohne GetSecretValue aufzurufen. Der operative Schutz von Secrets folgt einem separaten autorisierten Pfad für verschlüsselte Werte, KMS-Berechtigungen, Rotation und Zielendpunkte.
Ein Konto, mehrere Regionen
Native regionale Replikate übertragen Secret-Updates und Rotationen. Verwenden Sie einen passenden KMS-Schlüssel der Zielregion und prüfen Sie, ob die Verbindungseinstellungen auf den vorgesehenen wiederhergestellten Dienst zeigen.
Ein separates Konto erfordert ein eigenes Design
Native Regionsreplikation ist keine kontoübergreifende Replikation. Wählen Sie einen kontrollierten Synchronisierungspfad oder autorisierten gemeinsamen Zugriff; gemeinsamer Zugriff allein erzeugt keine isolierte Kopie. Kontoübergreifender Zugriff benötigt Ressourcen-, Identitäts- und kundenseitig verwaltete KMS-Berechtigungen.
AWS-Referenzen: Regionale Replikate · Kontoübergreifender Zugriff
Wiederherstellung zustandsbehafteter Daten · Replikat / Backup / PITR
Stellen Sie Daten auf einen vertrauenswürdigen Stand wieder her.
Wählen Sie den Datenpfad getrennt vom Infrastruktur-Blueprint. RDS und Aurora verwenden passende Wiederherstellungs- oder Replikationsmuster; DynamoDB, EBS, EFS und FSx benötigen jeweils eigene unterstützte Schutzpfade. Auswahl des Wiederherstellungspunkts, Zielzugriff und Aufbewahrung werden ausdrücklich getestet.
RTO und RPO werden gemessen
Das Erfassungsintervall der Infrastruktur ist nicht das RPO der Anwendungsdaten. Wiederherstellungsdauer, Replikationsverzögerung, aufbewahrte Wiederherstellungspunkte und die getestete Workload bestimmen die tatsächlichen Recovery-Nachweise.
Weitere zustandsbehaftete Dienste
Vorhandene S3-Objekte können zusätzlich zur Replikation neuer Objekte eine separate Batch-Replikation benötigen. EFS, FSx und Volume-Snapshots nutzen die unterstützten Mechanismen für den gewählten Dienst, das Konto und die Region.
AWS-Referenzen: RDS-Wiederherstellung zu einem Zeitpunkt · Umfang der S3-Replikation
Deklarative Wiederherstellung · Abhängigkeitsreihenfolge
Bauen Sie den verbundenen Dienst wieder auf.
Der Blueprint beschreibt unterstützte Konfigurationen und Zielzuordnungen. Der native Zustandsschutz liefert Images und Daten; Infrastrukturautomatisierung baut den umgebenden Dienst in Abhängigkeitsreihenfolge wieder auf.
Zielidentitäten auflösen
Quellkonto-IDs, Regionen, Zertifikat-ARNs, KMS-Schlüssel, Image-Speicherorte und Endpunktreferenzen benötigen Zielzuordnungen.
Der Sollzustand der Plattform zählt
Stellen Sie bei Kubernetes Workload-Spezifikationen und persistente Daten statt kurzlebiger Pod-IDs wieder her. Der Dienst braucht echte Anwendungstests zusätzlich zum gesunden Steuerungskontrollraum.
Dockfield-Entwurfsmuster: Abdeckung unterstützter Dienste und Abhängigkeitszuordnungen werden während der Bewertung festgelegt.
Datenverkehr · bereit → genehmigt → Routingaktion
ARC-Steuerungen leiten den Verkehr, wenn die Wiederherstellung bereit ist.
Routing-Steuerungen beeinflussen Route-53-Healthchecks und DNS-Verkehr. Das menschliche Freigabe- und Validierungstor von Dockfield ist eine Anwendungskontrolle; konfigurierte ARC-Sicherheitsregeln ergänzen sie. Die Recovery-Engine baut die Workload auf, bevor eine Routingaktion infrage kommt.
Bereitschaft ist kein Live-Failover
Ein genehmigter UI-Status belegt nicht, dass Routing-Steuerungen geändert wurden. Erfassen Sie die Steuerungsaktion und bestätigen Sie das Verhalten des wiederhergestellten Dienstes und von DNS.
Sicherheit und Rollback
Konfigurieren Sie geeignete Sicherheitsregeln, üben Sie den genehmigten Wechsel und Rollback und berücksichtigen Sie DNS-Caching und Clientverhalten.
AWS-Referenzen: ARC-Routing-Steuerung · ARC-Sicherheitsregeln
Organisationskontrollen · zentrale Konfiguration
Einmal regeln. Jede Recovery-Grenze prüfen.
Control Tower, AWS Config, Security Hub und GuardDuty haben unterschiedliche Organisations- und Region-Konfigurationsmodelle. Verwenden Sie das passende zentrale Administrationsmuster und prüfen Sie dann Abdeckung, Aggregation und Berechtigungen in jedem DR-Konto und jeder Region. IAM-Vertrauen und KMS-Zugriff bleiben ausdrückliche Abhängigkeiten.
Dienstspezifische Abdeckung
Ein zentraler Administrator bedeutet nicht automatisch, dass jedes Ziel abgedeckt ist. Erfassen Sie erforderliche aktivierte Regionen, Mitgliedskonten und Nachweisquellen.
Ein Blueprint ist ein Recovery-Vertrag
Erfassen Sie für jede Ressource Strategie, Zielzuordnung, Eigentümer, Genehmigungsregel, Schutznachweise und den letzten erfolgreichen Wiederherstellungstest.
Was sollte der Recovery-Blueprint dokumentieren?
- Quelldienst und Abhängigkeitsbeziehungen
- Zielkonten und -regionen, zugeordnete Identitäten und Endpunkte
- Schutzstrategie, Voraussetzungen und letzter Abgleich
- Richtlinie für Wiederherstellungspunkte, gemessene RTO / RPO und Validierungsnachweise
- Umgang mit destruktiven Änderungen, Genehmigungsverantwortliche und Rollback-Pfad
Kostenlose Erstberatung
Welche Recovery-Pfade passen zu Ihrer AWS-Umgebung?
Beginnen Sie mit einer kritischen Workload, ihren Abhängigkeiten und einem messbaren Recovery-Ziel.