Fehlertoleranz

Überprüft, ob Ihre Application Load Balancer so konfiguriert sind, dass sie mehr als eine Availability Zone (AZ) verwenden. Eine Availability Zone ist ein eigenständiger Standort, der vor Ausfällen in anderen Zonen geschützt ist. Konfigurieren Sie Ihren Load Balancer in mehreren AZs in derselben Region, um die Verfügbarkeit Ihrer Workloads zu verbessern.

c1dfprch08

Gelb: ALB befindet sich in einer einzigen AZ.

Grün: ALB hat zwei oder mehr AZs.

Stellen Sie sicher, dass Ihr Load Balancer mit mindestens zwei Availability Zones konfiguriert ist.

Weitere Informationen finden Sie unter Availability Zones für Ihren Application Load Balancer.

Weitere Informationen finden Sie in der folgenden Dokumentation:

Prüft, ob für einen Amazon-Aurora-MySQL-Cluster die Rückverfolgung aktiviert ist.

Amazon-Aurora-MySQL-Cluster-Rückverfolgung ist eine Funktion, mit der Sie einen Aurora-DB-Cluster auf einen früheren Zeitpunkt zurücksetzen können, ohne einen neuen Cluster zu erstellen. Sie können Ihre Datenbank innerhalb eines Aufbewahrungszeitraums auf einen bestimmten Zeitpunkt zurücksetzen, ohne dass eine Wiederherstellung aus einem Snapshot notwendig ist.

Sie können das Backtracking-Zeitfenster (Stunden) im BacktrackWindowInHours Parameter der AWS Config Regeln anpassen.

Weitere Informationen finden Sie unter Rückverfolgen eines Aurora-DB-Clusters.

c18d2gz131

AWS Config Managed Rule: aurora-mysql-backtracking-enabled

Gelb: Die Amazon-Aurora-MySQL-Cluster-Rückverfolgung ist nicht aktiviert.

Aktivieren Sie die Rückverfolgung für Ihren Amazon-Aurora-MySQL-Cluster.

Weitere Informationen finden Sie unter Rückverfolgen eines Aurora-DB-Clusters.

Rückverfolgen eines Aurora-DB-Clusters

Prüft auf Fälle, in denen ein Amazon Aurora DB-Cluster sowohl private als auch öffentliche Instances hat.

Wenn Ihre primäre Instance ausfällt, kann ein Replikat zu einer primären Instance befördert werden. Wenn diese Replik privat ist, können Benutzer, die nur öffentlichen Zugriff haben, nach dem Failover keine Verbindung mehr zur Datenbank herstellen. Wir empfehlen, dass alle DB-Instances in einem Cluster die gleiche Zugänglichkeit haben.

xuy7H1avtl

Gelb: Die Instances in einem Aurora-DB-Cluster sind auf unterschiedliche Weise zugänglich (eine Mischung aus öffentlich und privat).

Ändern Sie die Publicly Accessible-Einstellung der Instances im DB-Cluster, sodass sie alle entweder öffentlich oder privat sind. Weitere Informationen finden Sie in den Anweisungen für MySQL-Instances unter Ändern einer DB-Instance mit ausgeführter MySQL-Datenbank-Engine.

Fehlertoleranz für einen Aurora-DB-Cluster

Überprüft, ob eine Ursprungsgruppe für Distributionen konfiguriert ist, die zwei Ursprünge in Amazon enthalten. CloudFront

Weitere Informationen finden Sie unter Optimieren der Hochverfügbarkeit mit CloudFront Origin-Failover.

c18d2gz112

AWS Config Managed Rule: cloudfront-origin-failover-enabled

Gelb: Amazon CloudFront Origin Failover ist nicht aktiviert.

Stellen Sie sicher, dass Sie die Origin-Failover-Funktion für Ihre CloudFront Distributionen aktivieren, um eine hohe Verfügbarkeit Ihrer Inhalte für Endbenutzer sicherzustellen. Wenn Sie diese Funktion aktivieren, wird der Datenverkehr automatisch an den Backup-Ursprungsserver weitergeleitet, falls der primäre Ursprungsserver nicht verfügbar ist. Dadurch werden potenzielle Ausfallzeiten minimiert und die kontinuierliche Verfügbarkeit Ihrer Inhalte gewährleistet.

Überprüft die AWS Key Management Service (AWS KMS) -Schlüsselberechtigungen für einen Endpunkt, an dem das zugrunde liegende Modell mithilfe von vom Kunden verwalteten Schlüsseln verschlüsselt wurde. Wenn der kundenverwaltete Schlüssel deaktiviert ist, oder die Schlüsselrichtlinie geändert wurde, um die erlaubten Berechtigungen für Amazon Comprehend zu ändern, könnte die Verfügbarkeit des Endpunkts beeinträchtigt werden.

Cm24dfsM13

Rot: Der kundenverwaltete Schlüssel ist deaktiviert oder die Schlüsselrichtlinie wurde geändert, um die erlaubten Berechtigungen für den Zugriff auf Amazon Comprehend zu ändern.

Wenn der vom Kunden verwaltete Schlüssel deaktiviert wurde, empfehlen wir die Aktivierung. Weitere Informationen finden Sie unter Aktivieren von Schlüsseln. Wenn die Schlüsselrichtlinie geändert wurde und Sie den Endpunkt weiterhin verwenden möchten, empfehlen wir Ihnen, die AWS KMS Schlüsselrichtlinie zu aktualisieren. Weitere Informationen finden Sie unter Changing a key policy (Ändern einer Schlüsselrichtlinie).

AWS KMS Berechtigungen

Prüft, ob Amazon DocumentDB-Cluster als konfiguriert sind. Single-AZ

Die Ausführung von Amazon DocumentDB-Workloads in einer Single-AZ Architektur reicht für hochkritische Workloads nicht aus und die Wiederherstellung nach einem Komponentenausfall kann bis zu 10 Minuten dauern. Kunden sollten Replica-Instances in zusätzlichen Verfügbarkeitszonen bereitstellen, um die Verfügbarkeit bei Wartungsarbeiten, Instance-Ausfällen, Komponentenausfällen oder Verfügbarkeitszonenausfällen sicherzustellen.

c15vnddn2x

Gelb: Der Amazon DocumentDB-Cluster hat Instances in weniger als drei Verfügbarkeitszonen.

Grün: Der Amazon DocumentDB-Cluster hat Instances in drei Verfügbarkeitszonen.

Wenn Ihre Anwendung eine hohe Verfügbarkeit erfordert, ändern Sie Ihre DB-Instance, um die Multi-AZ Verwendung von Replikat-Instances zu ermöglichen. Siehe Amazon DocumentDB Hochverfügbarkeit und Replikation

Grundlegendes zur Amazon DocumentDB-Cluster-Fehlertoleranz

Regionen und Availability Zones

Prüft, ob die zeitpunktbezogene Wiederherstellung für Ihre Amazon-DynamoDB-Tabellen aktiviert ist.

Point-in Time Recovery schützt Ihre DynamoDB-Tabellen vor versehentlichen Schreib- oder Löschvorgängen. Mit Point-in-Time-Recovery müssen Sie sich keine Gedanken über die Erstellung, Wartung oder Planung von On-Demand-Backups machen. Point-in Time-Recovery stellt Tabellen zu einem beliebigen Zeitpunkt der letzten 35 Tage wieder her. DynamoDB verwaltet inkrementelle Backups Ihrer Tabelle.

Weitere Informationen finden Sie unter Point-in-time Wiederherstellung für DynamoDB.

c18d2gz138

AWS Config Managed Rule: dynamodb-pitr-enabled

Gelb: Die Point-in-time Wiederherstellung ist für Ihre DynamoDB-Tabellen nicht aktiviert.

Aktivieren Sie die zeitpunktbezogene Wiederherstellung in Amazon DynamoDB, um Ihre Tabellendaten kontinuierlich zu sichern.

Weitere Informationen finden Sie unter Point-in-time Wiederherstellung: So funktioniert sie.

Point-in-time Wiederherstellung für DynamoDB

Prüft, ob Amazon DynamoDB-Tabellen Teil eines AWS Backup Plans sind.

AWS Backup bietet inkrementelle Backups für DynamoDB-Tabellen, die Änderungen erfassen, die seit der letzten Sicherung vorgenommen wurden. Die Aufnahme von DynamoDB-Tabellen in einen AWS Backup Plan schützt Ihre Daten vor versehentlichen Datenverlust-Szenarien und automatisiert den Sicherungsvorgang. Dies bietet eine zuverlässige und skalierbare Backup-Lösung für Ihre DynamoDB-Tabellen und trägt dazu bei, dass Ihre wertvollen Daten geschützt sind und bei Bedarf wiederhergestellt werden können.

Weitere Informationen finden Sie unter Erstellen von Backups von DynamoDB-Tabellen mit AWS Backup

c18d2gz107

AWS Config Managed Rule: dynamodb-in-backup-plan

Gelb: Die Amazon DynamoDB-Tabelle ist nicht im AWS Backup Plan enthalten.

Stellen Sie sicher, dass Ihre Amazon DynamoDB-Tabellen Teil eines Plans sind. AWS Backup

Geplante Backups

Was ist? AWS Backup

Erstellen von Backup-Plänen mit der AWS-Backup-Konsole

Prüft, ob Amazon EBS-Volumes in Backup-Plänen für enthalten sind. AWS Backup

Nehmen Sie Amazon EBS-Volumes in einen AWS Backup Plan auf, um regelmäßige Backups der auf diesen Volumes gespeicherten Daten zu automatisieren. Dies schützt Sie vor einem möglichen Datenverlust, erleichtert die Datenverwaltung und ermöglicht bei Bedarf die Wiederherstellung von Daten. Ein Backup-Plan hilft sicherzustellen, dass Ihre Daten sicher sind und Sie in der Lage sind, die Zeit- und Punktziele für die Wiederherstellung (RTO/RPO) für Ihre Anwendung und Dienste einzuhalten.

Weitere Informationen finden Sie unter Erstellen eines Sicherungsplans.

c18d2gz106

AWS Config Managed Rule: ebs-in-backup-plan

Gelb: Das Amazon EBS-Volume ist nicht im AWS Backup Plan enthalten.

Stellen Sie sicher, dass Ihre Amazon EBS-Volumes Teil eines AWS Backup Plans sind.

Erstellen von Backup-Plänen mithilfe der Konsole AWS Backup

Was ist AWS Backup?

Erste Schritte, Schritt 3: Erstellen einer geplanten Sicherung

Überprüft das Alter der Snapshots für Ihre Amazon EBS-Volumes (entweder verfügbar oder in Verwendung). Fehler können auch dann auftreten, wenn Amazon EBS-Volumes repliziert werden. Snapshots werden auf Amazon S3 gespeichert, um eine dauerhafte Speicherung und zeitnahe Wiederherstellung zu gewährleisten.

H7IgTzjTYb

Erstellen Sie wöchentliche oder monatliche Schnappschüsse Ihrer Volumes. Weitere Informationen finden Sie unter Erstellen von Amazon-EBS-Snapshots.

Um die Erstellung von EBS-Snapshots zu automatisieren, können Sie die Verwendung AWS Backup von Amazon Data Lifecycle Manager in Betracht ziehen. https://docs.aws.amazon.com/prescriptive-guidance/latest/backup-recovery/new-ebs-volume-backups.html#amazon-dlm

Amazon Elastic Block Store (Amazon EBS)

Amazon-EBS-Snapshots

AWS Backup

Amazon Data Lifecycle Manager

Prüft, ob Ihre Amazon-EC2-Auto-Scaling-Gruppen, die einem Classic Load Balancer zugeordnet sind, Elastic-Load-Balancing-Zustandsprüfungen verwenden. Die Standardzustandsprüfungen für eine Auto-Scaling-Gruppe sind ausschließlich Amazon-EC2-Zustandsprüfungen. Wenn eine Instance diese Zustandsprüfungen nicht besteht, wird sie als fehlerhaft markiert und beendet. Amazon EC2 Auto Scaling startet eine neue Ersatz-Instance. Die Elastic-Load-Balancing-Zustandsprüfung überwacht regelmäßig Amazon-EC2-Instances, um fehlerhafte Instances zu erkennen und zu beenden und dann neue Instances zu starten.

Weitere Informationen finden Sie unter Hinzufügen von Elastic Load Balancing-Zustandsprüfungen.

c18d2gz104

AWS Config Managed Rule: autoscaling-group-elb-healthcheck-required

Gelb: Amazon-EC2-Auto-Scaling-Gruppe ist an einen Classic Load Balancer angefügt, für den Elastic-Load-Balancing-Zustandsprüfungen nicht aktiviert sind.

Vergewissern Sie sich, dass Ihre Auto-Scaling-Gruppen, die einem Classic Load Balancer zugeordnet sind, Elastic-Load-Balancing-Zustandsprüfungen verwenden.

Elastic-Load-Balancing-Zustandsprüfungen melden, ob der Load Balancer fehlerfrei ist und für die Bearbeitung von Anfragen verfügbar ist. So wird eine Hochverfügbarkeit Ihrer Anwendung gewährleistet.

Weitere Informationen finden Sie unter Hinzufügen von Zustandsprüfungen für Elastic Load Balancing zu einer Auto-Scaling-Gruppe.

Prüft, ob der Kapazitätsausgleich für Amazon-EC2-Auto-Scaling-Gruppen aktiviert ist, die mehrere Instance-Typen verwenden.

Durch die Konfiguration von Amazon-EC2-Auto-Scaling-Gruppen mit Kapazitätsausgleich wird sichergestellt, dass Amazon-EC2-Instances unabhängig von Instance-Typen und Kaufoptionen gleichmäßig auf die Availability Zones verteilt werden. Dazu wird eine der Gruppe zugeordnete Ziel-Nachverfolgungsrichtlinie verwendet, z. B. für die CPU-Nutzung oder den Netzwerkdatenverkehr.

Weitere Informationen finden Sie unter Auto-Scaling-Gruppen mit mehreren Instance-Typen und Kaufoptionen.

AWS Config c18d2gz103

AWS Config Verwaltete Regel: Autoscaling-Capacity-Rebalancing

Gelb: Für die Amazon-EC2-Auto-Scaling-Gruppe ist der Kapazitätsausgleich nicht aktiviert.

Stellen Sie sicher, dass der Kapazitätsausgleich für Amazon-EC2-Auto-Scaling-Gruppen aktiviert ist, die mehrere Instance-Typen verwenden.

Weitere Informationen finden Sie unter Aktivitieren des Kapazitätsausgleichs (Konsole).

Prüft, ob die Amazon-EC2-Auto-Scaling-Gruppe in mehreren Availability Zones bereitgestellt wird oder ob die angegebene Mindestanzahl von Availability Zones eingehalten wird. Stellen Sie Amazon-EC2-Instances in mehreren Availability Zones bereit, um Hochverfügbarkeit sicherzustellen.

Sie können die Mindestanzahl an Availability Zones mithilfe des AvailibilityZones Parameters min in Ihren AWS Config Regeln anpassen.

Weitere Informationen finden Sie unter Auto-Scaling-Gruppen mit mehreren Instance-Typen und Kaufoptionen.

c18d2gz101

AWS Config Managed Rule: autoscaling-multiple-az

Rot: Für die Amazon-EC2-Auto-Scaling-Gruppe sind nicht mehrere Availability Zones konfiguriert oder sie erfüllt nicht die angegebene Mindestanzahl an Availability Zones.

Stellen Sie sicher, dass Ihre Amazon-EC2-Auto-Scaling-Gruppe mit mehreren Availability Zones konfiguriert ist. Stellen Sie Amazon-EC2-Instances in mehreren Availability Zones bereit, um Hochverfügbarkeit sicherzustellen.

Erstellen einer Auto-Scaling-Gruppe mithilfe einer Startvorlage

Erstellen einer Auto-Scaling-Gruppe mithilfe einer Startkonfiguration

Prüft die Verteilung von Amazon Elastic Compute Cloud (Amazon EC2) Instances über Availability Zones in einer Region.

Availability Zones sind eigenständige Standorte, die von Ausfällen in anderen Availability Zones isoliert sind. Dies ermöglicht eine kostengünstige Netzwerkkonnektivität mit geringer Latenz zwischen Availability Zones in derselben Region. Indem Sie Instances in mehreren Availability Zones in derselben Region starten, können Sie Ihre Anwendungen vor einem einzelnen Ausfallpunkt schützen.

wuy7G1zxql

Verteilen Sie Ihre Amazon-EC2-Instances gleichmäßig auf mehrere Availability Zones. Sie können dies tun, indem Sie Instances manuell oder automatisch mit Auto Scaling starten. Weitere Informationen finden Sie unter Starten Ihrer Instance und Load Balance Your Auto Scaling Group (Load Balancing Ihrer Auto-Scaling-Gruppe).

Prüft, ob für Ihre Amazon-EC2-Instances eine detaillierte Überwachung aktiviert ist.

Die detaillierte Überwachung von Amazon EC2 bietet häufigere Metriken, die in Intervallen von einer Minute veröffentlicht werden, statt den Fünf-Minuten-Intervallen, die in der Amazon-EC2-Basisüberwachung verwendet werden. Durch das Aktvieren einer detaillierten Überwachung für Amazon EC2 können Sie Ihre Amazon-EC2-Ressourcen besser verwalten, damit Sie Trends finden und schneller Maßnahmen ergreifen können.

Weitere Informationen finden Sie unter Grundlegende Überwachung und detaillierte Überwachung.

AWS Config c18d2gz144

AWS Config Verwaltete Regel: ec2-instance-detailed-monitoring-enabled

Gelb: Die detaillierte Überwachung ist für Amazon-EC2-Instances nicht aktiviert.

Aktivieren Sie die detaillierte Überwachung Ihrer Amazon EC2-Instances, um die Häufigkeit zu erhöhen, mit der Amazon EC2-Metrikdaten auf Amazon veröffentlicht werden CloudWatch (von Intervallen von 5 Minuten auf 1 Minute).

Sucht nach Amazon ECS-Aufgabendefinitionen, die aktiv von der Ausführung von Aufgaben verwendet werden oder zu den 5 neuesten Revisionen pro Aufgabendefinitionsfamilie gehören und mit dem AWS Logging-Treiber im Blockmodus konfiguriert sind. Ein im Sperrmodus konfigurierter Treiber gefährdet die Systemverfügbarkeit.

Bei dieser Prüfung werden die Treiberkonfigurationseinstellungen auf Kontoebene nicht berücksichtigt.

c1dvkm4z6b

Gelb: Der Konfigurationsparametermodus für die AWSlogs-Treiberprotokollierung ist auf Blockieren eingestellt.

Grün: Die Amazon ECS-Aufgabendefinition verwendet den Awslogs-Treiber nicht oder der Awslogs-Treiber ist im nicht blockierenden Modus konfiguriert.

Um das Verfügbarkeitsrisiko zu minimieren, sollten Sie erwägen, die Konfiguration des AWS Logs-Treibers für die Aufgabendefinition von blockierend auf nicht blockierend zu ändern. Im nicht blockierenden Modus müssen Sie einen Wert für den Parameter max-buffer-size festlegen. Weitere Informationen und Anleitungen zu Konfigurationsparametern finden Sie im Protokolltreiber für den Logs-Container unter Verhindern von Protokollverlusten im nicht blockierenden Modus. AWS

Verwenden des AWS Protokolltreibers

Wählen Sie Optionen für die Container-Protokollierung, um Gegendruck zu vermeiden

Verhinderung von Protokollverlusten durch den nicht blockierenden Modus im Protokolltreiber für den AWS Logs-Container

Prüft, ob Ihre Servicekonfiguration eine einzige Availability Zone (AZ) verwendet.

Eine Availability Zone ist ein eigenständiger Standort, der vor Ausfällen in anderen Zonen geschützt ist. Dies unterstützt kostengünstige Netzwerkkonnektivität mit geringer Latenz zwischen Availability Zones in derselben AWS-Region. Indem Sie Instances in mehreren Availability Zones in derselben Region starten, können Sie Ihre Anwendungen vor einem einzelnen Ausfallpunkt schützen.

c1z7dfpz01

Erstellen Sie mindestens eine weitere Aufgabe für den Service in einer anderen AZ.

Kapazität und Verfügbarkeit von Amazon ECS

Überprüft, ob Ihr Amazon-ECS-Service die auf der Availability Zone (AZ) basierende Spread-Platzierungsstrategie verwendet. Diese Strategie verteilt Aufgaben auf dieselbe Weise auf alle Availability Zones AWS-Region und kann dazu beitragen, Ihre Anwendungen vor einem einzigen Ausfall zu schützen.

Für Aufgaben, die als Teil eines Amazon-ECS-Service ausgeführt werden, ist „Spread“ die Standard-Aufgabenplatzierungsstrategie.

Mit dieser Prüfung wird auch überprüft, ob Spread die erste oder die einzige Strategie in Ihrer Liste der aktivierten Platzierungsstrategien ist.

c1z7dfpz02

Aktivieren Sie die Spread-Aufgabenplatzierungsstrategie, um Aufgaben auf mehrere AZs zu verteilen. Stellen Sie sicher, dass die Verteilung (Spread) nach Availability Zone die erste Strategie für alle aktivierten Aufgabenplatzierungsstrategien oder die einzige verwendete Strategie ist. Wenn Sie sich dafür entscheiden, die AZ-Platzierung zu verwalten, können Sie einen gespiegelten Service in einer anderen Availability Zone verwenden, um diese Risiken zu minimieren.

Strategien für die Platzierung von Aufgaben in Amazon ECS

Prüft, ob Mount-Ziele in mehreren Availability Zones für ein Amazon-EFS-Dateisystem vorhanden sind.

Eine Availability Zone ist ein eigenständiger Standort, der vor Ausfällen in anderen Zonen geschützt ist. Durch die Erstellung von Mount-Zielen in mehreren geografisch getrennten Availability Zones innerhalb einer AWS-Region können Sie ein Höchstmaß an Verfügbarkeit und Beständigkeit für Ihre Amazon-EFS-Dateisysteme erreichen.

c1dfprch01

Für EFS-Dateisysteme, die One-Zone-Speicherklassen verwenden, empfehlen wir, neue Dateisysteme zu erstellen, die Standardspeicherklassen verwenden, indem eine Sicherung in einem neuen Dateisystem wiederhergestellt wird. Erstellen Sie dann Mount-Ziele in mehreren Availability Zones.

Für EFS-Dateisysteme, die Standardspeicherklassen verwenden, empfehlen wir, Mount-Ziele in mehreren Availability Zones zu erstellen.

Prüft, ob Amazon EFS-Dateisysteme in Backup-Plänen mit enthalten sind AWS Backup.

AWS Backup ist ein einheitlicher Backup-Service, der die Erstellung, Migration, Wiederherstellung und Löschung von Backups vereinfacht und gleichzeitig eine verbesserte Berichterstattung und Prüfung bietet.

Weitere Informationen finden Sie unter Sichern Ihrer Amazon-EFS-Dateisysteme.

c18d2gz117

AWS Config Managed Rule: EFS_IN_BACKUP_PLAN

Rot: Amazon EFS-Dateisysteme sind nicht im AWS Backup Plan enthalten.

Stellen Sie sicher, dass Ihre Amazon EFS-Dateisysteme in Ihrem AWS Backup Plan enthalten sind, um sich vor versehentlichem Datenverlust oder Datenbeschädigung zu schützen.

Sichern Ihrer Amazon-EFS-Dateisysteme

Amazon EFS-Backup und -Wiederherstellung mit AWS Backup.

Sucht nach ElastiCache Clustern, die in einer einzigen Availability Zone (AZ) bereitgestellt werden. Diese Prüfung warnt Sie, wenn sie in einem Cluster inaktiv Multi-AZ ist.

Bereitstellungen in mehreren AZs verbessern die ElastiCache Cluster-Verfügbarkeit, indem sie asynchron auf schreibgeschützte Replikate in einer anderen AZ replizieren. Wenn eine geplante Cluster-Wartung stattfindet oder ein Primärknoten nicht verfügbar ist, stuft ElastiCache ein Replikat automatisch zum Primärknoten herauf. Dieses Failover ermöglicht die Wiederaufnahme von Cluster-Schreibvorgängen, ohne dass ein Administrator eingreifen muss.

ECHdfsQ402

Erstellen Sie mindestens ein Replikat pro Shard in einer AZ, die sich von der primären unterscheidet.

Weitere Informationen finden Sie unter Minimierung von Ausfallzeiten in ElastiCache (Redis OSS) mit. Multi-AZ

Überprüft, ob für die Amazon ElastiCache (Redis OSS) -Cluster die automatische Sicherung aktiviert ist und ob der Snapshot-Aufbewahrungszeitraum über dem angegebenen oder dem Standardlimit von 15 Tagen liegt. Wenn automatische Backups aktiviert sind, ElastiCache erstellt täglich ein Backup des Clusters.

Sie können das gewünschte Aufbewahrungslimit für Snapshots mithilfe der RetentionPeriod Snapshot-Parameter Ihrer AWS Config Regeln angeben.

Weitere Informationen finden Sie unter Sichern und Wiederherstellen für ElastiCache (Redis OSS).

c18d2gz178

AWS Config Managed Rule: elasticache-redis-cluster-automatic-backup-check

Rot: Bei Amazon ElastiCache (Redis OSS) -Clustern ist das automatische Backup nicht aktiviert oder der Aufbewahrungszeitraum für Snapshots liegt unter dem Limit.

Stellen Sie sicher, dass bei Amazon ElastiCache (Redis OSS) -Clustern die automatische Sicherung aktiviert ist und die Snapshot-Aufbewahrungsdauer über dem angegebenen oder dem Standardlimit von 15 Tagen liegt. Automatische Backups schützen vor Datenverlust. Bei einem Ausfall können Sie einen neuen Cluster erstellen, indem Sie Ihre Daten aus der aktuellen Sicherung wiederherstellen.

Weitere Informationen finden Sie unter Sichern und Wiederherstellen für ElastiCache (Redis OSS).

Weitere Informationen finden Sie unter Planen automatischer Sicherungen.

Prüft auf MemoryDB-Cluster, die in einer einzigen Availability Zone (AZ) bereitgestellt werden. Diese Prüfung warnt Sie, wenn sie in einem Multi-AZ Cluster inaktiv ist.

Bereitstellungen in mehreren AZs verbessern die MemoryDB-Clusterverfügbarkeit, indem sie asynchron auf schreibgeschützte Replikate in einer anderen AZ repliziert werden. Wenn eine geplante Cluster-Wartung stattfindet oder ein Primärknoten nicht verfügbar ist, stuft MemoryDB ein Replikat automatisch zum Primärknoten herauf. Dieses Failover ermöglicht die Wiederaufnahme von Cluster-Schreibvorgängen, ohne dass ein Administrator eingreifen muss.

MDBdfsQ401

Erstellen Sie mindestens ein Replikat pro Shard in einer AZ, die sich von der primären unterscheidet.

Weitere Informationen finden Sie unter Minimierung von Ausfallzeiten in MemoryDB mit. Multi-AZ

Überprüft, ob den Brokern eines MSK-Clusters (Managed Streaming for Kafka) nicht mehr als die empfohlene Anzahl von Partitionen zugewiesen wurde.

Cmsvnj8vf1

Folgen Sie den von MSK empfohlenen bewährten Methoden, um Ihren MSK-Cluster zu skalieren oder ungenutzte Partitionen zu löschen.

Überprüft die Anzahl der Availability Zones (AZs) für Ihren von Amazon MSK bereitgestellten Cluster. Der Amazon MSK-Cluster besteht aus mehreren Brokern, die zusammenarbeiten und die Daten und die Last verteilen. Bei Wartungsarbeiten oder Brokerproblemen in einem 2-AZ-Cluster kann es zu Produktionsunterbrechungen kommen.

90046ff5b5

Um die Verfügbarkeit des Clusters zu erhöhen, können Sie einen weiteren Cluster in einem 3-AZS-Setup erstellen. Migrieren Sie dann den vorhandenen Cluster zu dem neuen Cluster, den Sie erstellt haben. Sie können die Amazon MSK-Replikation für diese Migration verwenden.

Hohe Verfügbarkeit von Amazon MSK

Amazon MSK-Migration

Überprüft, ob Amazon OpenSearch Service-Domänen mit mindestens drei Datenknoten konfiguriert sind. ZoneAwarenessEnabled Der Wert ist wahr. ZoneAwarenessEnabled Wenn diese Option aktiviert ist, stellt Amazon OpenSearch Service sicher, dass jeder primäre Shard und das entsprechende Replikat verschiedenen Availability Zones zugewiesen sind.

Weitere Informationen finden Sie unter Konfiguration einer Multi-AZ-Domain in Amazon Service. OpenSearch

c18d2gz183

AWS Config Managed Rule: opensearch-data-node-fault-tolerance

Gelb: Amazon OpenSearch Service-Domains sind mit weniger als drei Datenknoten konfiguriert.

Stellen Sie sicher, dass Amazon OpenSearch Service-Domains mit mindestens drei Datenknoten konfiguriert sind. Konfigurieren Sie eine Multi-AZ-Domain, um die Verfügbarkeit des Amazon OpenSearch Service-Clusters zu verbessern, indem Sie Knoten zuweisen und Daten über drei Availability Zones innerhalb derselben Region replizieren. Dies verhindert Datenverluste und minimiert Ausfallzeiten im Falle eines Knoten- und Rechenzentrumsausfalls.

Weitere Informationen finden Sie unter Erhöhen Sie die Verfügbarkeit von Amazon OpenSearch Service durch Bereitstellung in drei Availability Zones.

Prüft auf automatische Backups von Amazon RDS DB-Instances.

Standardmäßig sind Backups mit einer Aufbewahrungsfrist von einem Tag aktiviert. Backups verringern das Risiko eines unerwarteten Datenverlusts und ermöglichen eine zeitnahe Wiederherstellung.

opQPADkZvH

Rot: Die Aufbewahrungsfrist für Backups einer DB-Instance ist auf 0 Tage festgelegt.

Legen Sie den Aufbewahrungszeitraum für das automatische DB-Instance-Backup entsprechend den Anforderungen Ihrer Anwendung auf 1 bis 35 Tage fest. Weitere Informationen finden Sie unter Arbeiten mit automatischen Sicherungen.

Erste Schritte mit Amazon RDS

Prüft, ob eine Amazon RDS-Instance mit automatisierten Backups mithilfe von Amazon RDS oder mit kontinuierlichen Backups von aktiviert ist AWS Backup. Kontinuierliche Backups reduzieren das Risiko eines unerwarteten Datenverlusts und ermöglichen eine Wiederherstellung zu einem bestimmten Zeitpunkt.

44fde09ab5

Stellen Sie sicher, dass für Amazon RDS-Instances automatische Backups konfiguriert sind, indem Sie entweder in Amazon RDS einen Aufbewahrungszeitraum von mehr als 0 festlegen oder indem Sie einen Plan für kontinuierliche Backups mithilfe von verwenden AWS Backup.

Fügen Sie dem DB-Cluster mindestens eine weitere DB-Instance hinzu, um Verfügbarkeit und Leistung zu verbessern.

c1qf5bt011

Gelb: DB-Cluster haben nur eine DB-Instance.

Fügen Sie dem DB-Cluster eine Reader-DB-Instance hinzu.

In der aktuellen Konfiguration wird eine DB-Instance sowohl für Lese- als auch für Schreibvorgänge verwendet. Sie können eine weitere DB-Instance hinzufügen, um eine Leseverteilung und eine Failover-Option zu ermöglichen.

Weitere Informationen finden Sie unter Hochverfügbarkeit für Amazon Aurora.

Die DB-Cluster befinden sich derzeit in einer einzigen Availability Zone. Verwenden Sie mehrere Availability Zones, um die Verfügbarkeit zu verbessern.

c1qf5bt007

Gelb: Bei DB-Clustern befinden sich alle Instances in derselben Availability Zone.

Fügen Sie die DB-Instances mehreren Availability Zones in Ihrem DB-Cluster hinzu.

Wir empfehlen, die DB-Instances mehreren Availability Zones in einem DB-Cluster hinzuzufügen. Das Hinzufügen von DB-Instances zu mehreren Availability Zones verbessert die Verfügbarkeit Ihres DB-Clusters.

Weitere Informationen finden Sie unter Hochverfügbarkeit für Amazon Aurora.

Ihr DB-Cluster hat alle DB-Instances in derselben Availability Zone. Wir empfehlen, dass Sie die Reader-Instances auf mehrere Availability Zones in Ihrem DB-Cluster verteilen.

Die Verteilung erhöht die Verfügbarkeit der Datenbank und verbessert die Reaktionszeit, indem die Netzwerklatenz zwischen Clients und der Datenbank reduziert wird.

c1qf5bt018

Rot: Bei DB-Clustern befinden sich die Reader-Instances in derselben Availability Zone.

Verteilen Sie die Reader-Instances auf mehrere Availability Zones.

Availability Zones (AZs) sind Standorte, die sich voneinander unterscheiden, um bei Ausfällen innerhalb der einzelnen AWS Regionen eine Isolierung zu gewährleisten. Wir empfehlen Ihnen, die primäre Instance und die Reader-Instances in Ihrem DB-Cluster über mehrere Availability Zones zu verteilen, um die Verfügbarkeit Ihres DB-Clusters zu verbessern. Sie können einen Multi-AZ Cluster mithilfe der AWS-Managementkonsole AWS CLI, oder Amazon RDS-API erstellen, wenn Sie den Cluster erstellen. Sie können den vorhandenen Aurora-Cluster in einen Multi-AZ Cluster ändern, indem Sie eine neue Reader-Instance hinzufügen und eine andere AZ angeben.

Weitere Informationen finden Sie unter Hochverfügbarkeit für Amazon Aurora.

Prüft, ob für Ihre Amazon-RDS-DB-Instances die erweiterte Überwachung aktiviert wurde.

Die erweiterte Überwachung für Amazon RDS stellt Metriken in Echtzeit für das Betriebssystem (BS) bereit, unter dem Ihre DB-Instance ausgeführt wird. Alle Systemmetriken und Prozessinformationen für Ihre Amazon-RDS-DB-Instances können in der Konsole angezeigt werden. Und Sie können das Dashboard anpassen. Mit erweiterter Überwachung haben Sie nahezu in Echtzeit Einblick in den Betriebsstatus Ihrer Amazon-RDS-Instance, sodass Sie schneller auf betriebliche Probleme reagieren können.

Sie können das gewünschte Überwachungsintervall mithilfe des MonitoringInterval-Parameters Ihrer Regeln angeben. AWS Config

Weitere Informationen finden Sie unter Übersicht über „Erweiterte Überwachung“ und Betriebssystemmetriken in „Erweiterte Überwachung“.

c18d2gz158

AWS Config Managed Rule: rds-enhanced-monitoring-enabled

Gelb: Für Ihre Amazon-RDS-DB-Instances ist „Erweiterte Überwachung“ nicht aktiviert oder sie sind nicht mit dem gewünschten Intervall konfiguriert.

Aktivieren Sie „Erweiterte Überwachung“ für Ihre Amazon-RDS-DB-Instances, um die Sichtbarkeit des Betriebsstatus Ihrer Amazon-RDS-Instance zu verbessern.

Weitere Informationen finden Sie unter Überwachen von Betriebssystem-Metriken mithilfe von „Erweitere Überwachung“.

Betriebssystemmetriken in „Erweiterte Überwachung“

Die automatische Skalierung von Amazon RDS-Speicher ist für Ihre DB-Instance nicht aktiviert. Wenn die Datenbank-Arbeitslast zunimmt, skaliert RDS Storage Autoscaling automatisch die Speicherkapazität ohne Ausfallzeiten.

c1qf5bt013

Rot: Bei DB-Instances ist die automatische Speicherskalierung nicht aktiviert.

Schalten Sie Amazon RDS-Speicher-Autoscaling mit einem angegebenen maximalen Speicherschwellenwert ein.

Die automatische Amazon RDS-Speicherskalierung skaliert die Speicherkapazität automatisch und ohne Ausfallzeiten, wenn die Datenbank-Arbeitslast zunimmt. Storage Autoscaling überwacht die Speichernutzung und skaliert die Kapazität automatisch, wenn die Nutzung in der Nähe der bereitgestellten Speicherkapazität liegt. Sie können eine Höchstgrenze für den Speicher angeben, den Amazon RDS der DB-Instance zuweisen kann. Für die automatische Speicherskalierung fallen keine zusätzlichen Kosten an. Sie zahlen nur für die Amazon RDS-Ressourcen, die Ihrer DB-Instance zugewiesen sind. Wir empfehlen, dass Sie Amazon RDS-Speicher-Autoscaling aktivieren.

Weitere Informationen finden Sie unter Managing capacity automatically with Amazon RDS storage autoscaling (Automatische Kapazitätsverwaltung mit Speicher-Autoscaling).

Wir empfehlen, dass Sie Multi-AZ Deployment verwenden. Die Multi-AZ Bereitstellungen verbessern die Verfügbarkeit und Haltbarkeit der DB-Instance.

c1qf5bt019

Gelb: DB-Instances verwenden kein Multi-AZ Deployment.

Multi-AZ Für die betroffenen DB-Instances eingerichtet.

In einer Amazon Multi-AZ RDS-Bereitstellung erstellt Amazon RDS automatisch eine primäre Datenbank-Instance und repliziert die Daten auf eine Instance in einer anderen Availability Zone. Wenn Amazon RDS einen Ausfall erkennt, wechselt es automatisch zu einer Standby-Instance, ohne dass ein manuelles Eingreifen erforderlich ist.

Weitere Informationen finden Sie unter  – Preise.

Überprüft, ob die CloudWatch Metrik DiskQueueDepth zeigt, dass die Anzahl der Schreibvorgänge in den Datenbankspeicher der RDS-Instance in der Warteschlange so groß ist, dass eine operative Untersuchung vorgeschlagen werden sollte.

Cmsvnj8db3

Erwägen Sie den Umstieg auf Instances und Speichervolumes, die diese read/write Merkmale unterstützen.

Überprüft, ob die FreeStorageSpace CloudWatch Metrik für eine RDS-Datenbank-Instance unter einen betrieblich vertretbaren Schwellenwert gefallen ist.

Cmsvnj8db2

Skalieren Sie mithilfe der Amazon RDS Management Console, der Amazon RDS-API oder der AWS-Befehlszeilenschnittstelle den Speicherplatz für die RDS-Datenbank-Instance, deren freier Speicherplatz knapp wird.

Wenn log_output auf TABLE gesetzt ist, wird mehr Speicherplatz verwendet als wenn log_output auf FILE gesetzt ist. Wir empfehlen, den Parameter auf FILE zu setzen, um zu verhindern, dass die Speichergrößenbeschränkung erreicht wird.

c1qf5bt023

Gelb: Für DB-Parametergruppen ist der Parameter log_output auf TABLE gesetzt.

Setzen Sie den Log_Output-Parameterwert in Ihren DB-Parametergruppen auf FILE.

Weitere Informationen finden Sie unter MySQL-Datenbank-Logdateien.

Ihre DB-Instance hat ein bekanntes Problem: Auf eine Tabelle, die in einer MySQL-Version unter 8.0.26 erstellt wurde und bei der row_format auf COMPACT oder REDUNDANT gesetzt ist, kann nicht zugegriffen werden und sie kann nicht wiederhergestellt werden, wenn der Index 767 Byte überschreitet.

Wir empfehlen, den Parameterwert innodb_default_row_format auf DYNAMIC zu setzen.

c1qf5bt036

Rot: DB-Parametergruppen haben eine unsichere Einstellung für den Parameter innodb_default_row_format.

Setzen Sie den Parameter innodb_default_row_format auf DYNAMIC.

Wenn eine Tabelle mit einer MySQL-Version unter 8.0.26 erstellt wird und row_format auf COMPACT oder REDUNDANT gesetzt ist, wird die Erstellung von Indizes mit einem Schlüsselpräfix, das kürzer als 767 Byte ist, nicht erzwungen. Nach dem Neustart der Datenbank kann auf diese Tabellen nicht zugegriffen oder sie wiederhergestellt werden.

Weitere Informationen finden Sie unter Änderungen in MySQL 8.0.26 (20.07.2021, Allgemeine Verfügbarkeit) n auf der MySQL-Dokumentationswebsite.

Der Wert des Parameters innodb_flush_log_at_trx_commit Ihrer DB-Instance ist kein sicherer Wert. Dieser Parameter steuert die Persistenz von Commit-Operationen auf der Festplatte.

Wir empfehlen, den Parameter innodb_flush_log_at_trx_commit auf 1 zu setzen.

c1qf5bt030

Gelb: Für DB-Parametergruppen ist innodb_flush_log_at_trx_commit auf einen anderen Wert als 1 gesetzt.

Setzen Sie den Parameterwert innodb_flush_log_at_trx_commit auf 1

Die Datenbanktransaktion ist dauerhaft, wenn der Log-Puffer im dauerhaften Speicher gespeichert wird. Das Speichern auf der Festplatte beeinträchtigt jedoch die Leistung. Abhängig vom Wert, der für den Parameter innodb_flush_log_at_trx_commit festgelegt ist, kann das Verhalten, wie Protokolle geschrieben und auf der Festplatte gespeichert werden, variieren.

Weitere Informationen finden Sie unter Best practices for configuring parameters for Amazon RDS für MySQL, part 1: Parameters related to performance.

Ihre DB-Instance hat einen niedrigen Wert für die maximale Anzahl gleichzeitiger Verbindungen für jedes Datenbankkonto.

Wir empfehlen, den Parameter max_user_connections auf eine Zahl größer als 5 einzustellen.

c1qf5bt034

Gelb: Bei DB-Parametergruppen ist max_user_connections falsch konfiguriert.

Erhöhen Sie den Wert des Parameters max_user_connections auf eine Zahl größer als 5.

Die Einstellung max_user_connections steuert die maximale Anzahl gleichzeitiger Verbindungen, die für ein MySQL-Benutzerkonto zulässig sind. Das Erreichen dieses Verbindungslimits führt zu Fehlern bei den Verwaltungsvorgängen der Amazon RDS-Instance, z. B. bei Backups, Patches und Parameteränderungen.

Weitere Informationen finden Sie auf der MySQL-Dokumentationswebsite unter Setting Account Resource Limits.

Prüft auf DB-Instances, die in einer einzigen Availability Zone (AZ) eingesetzt werden.

Multi-AZ Bereitstellungen verbessern die Datenbankverfügbarkeit, indem sie synchron auf eine Standby-Instance in einer anderen Availability Zone replizieren. Bei geplanter Datenbankwartung oder dem Ausfall einer DB-Instance oder Availability Zone wechselt Amazon RDS automatisch zum Standby. Dieses Failover ermöglicht eine schnelle Wiederaufnahme des Datenbankbetriebs ohne administrative Eingriffe. Da Amazon RDS die Multi-AZ Bereitstellung für Microsoft SQL Server nicht unterstützt, werden bei dieser Prüfung keine SQL Server-Instanzen untersucht.

f2iK5R6Dep

Gelb: Eine DB-Instance wird in einer einzelnen Availability Zone bereitgestellt.

Wenn Ihre Anwendung eine hohe Verfügbarkeit erfordert, ändern Sie Ihre DB-Instance, um die Multi-AZ Bereitstellung zu ermöglichen. Siehe Hochverfügbarkeit (Multi-AZ).

Regionen und Availability Zones

Überprüft, ob Ihre Amazon-RDS-DB-Instances in einem Backup-Plan in AWS Backup enthalten sind.

AWS Backup ist ein vollständig verwalteter Backup-Service, der es einfach macht, die Sicherung von Daten über mehrere AWS Dienste hinweg zu zentralisieren und zu automatisieren.

Die Aufnahme Ihrer Amazon-RDS-DB-Instance in einen Backup-Plan ist wichtig für die Einhaltung gesetzlicher Vorschriften, die Notfallwiederherstellung, die Unternehmensrichtlinien für den Datenschutz und die Ziele der Geschäftskontinuität.

Weitere Informationen finden Sie unter Was ist AWS Backup?.

c18d2gz159

AWS Config Managed Rule: rds-in-backup-plan

Gelb: Eine Amazon RDS-DB-Instance ist nicht in einem Backup-Plan mit enthalten AWS Backup.

Nehmen Sie Ihre Amazon RDS-DB-Instances in einen Backup-Plan mit auf AWS Backup.

Weitere Informationen finden Sie unter Amazon-RDS-Backup und -Wiederherstellung mit AWS Backup.

Zuweisen von Ressourcen zu einem Sicherungsplan

Ihre DB-Instance verfügt über ein Lesereplikat im beschreibbaren Modus, das Aktualisierungen von Clients ermöglicht.

Wir empfehlen, den Parameter read_only auf einzustellen, TrueIfReplica damit sich die Read Replicas nicht im schreibbaren Modus befinden.

c1qf5bt035

Gelb: DB-Parametergruppen aktivieren den schreibbaren Modus für die Read Replicas.

Stellen Sie den Parameterwert read_only auf ein. TrueIfReplica

Der Parameter read_only steuert die Schreibberechtigung der Clients für eine Datenbankinstanz. Der Standardwert für diesen Parameter ist TrueIfReplica. TrueIfReplicaSetzt für eine Replikatinstanz den Wert read_only auf ON (1) und deaktiviert jegliche Schreibaktivitäten der Clients. TrueIfReplicaSetzt den Wert für eine master/writer Instanz auf OFF (0) und aktiviert die Schreibaktivität der Clients für die Instanz. Wenn das Lesereplikat im schreibbaren Modus geöffnet wird, können die in dieser Instanz gespeicherten Daten von der primären Instanz abweichen, was zu Replikationsfehlern führt.

Weitere Informationen finden Sie unter Bewährte Methoden für die Konfiguration von Parametern für Amazon RDS for MySQL, Teil 2: Parameter im Zusammenhang mit der Replikation auf der MySQL-Dokumentationswebsite.

Automatische Backups sind auf Ihren DB-Ressourcen deaktiviert. Automatisierte Sicherungen ermöglichen eine zeitpunktbezogene Backup Ihrer DB-Instance.

c1qf5bt001

Rot: Für Amazon RDS-Ressourcen sind automatische Backups nicht aktiviert

Aktivieren Sie automatisierte Backups mit einer Aufbewahrungsfrist von bis zu 14 Tagen.

Automatisierte Backups ermöglichen die Wiederherstellung Ihrer DB-Instances zu einem bestimmten Zeitpunkt. Wir empfehlen, automatische Backups zu aktivieren. Wenn Sie automatische Backups für eine DB-Instance aktivieren, führt Amazon RDS in Ihrem bevorzugten Backup-Fenster täglich automatisch eine vollständige Sicherung Ihrer Daten durch. Das Backup erfasst Transaktionsprotokolle, wenn Ihre DB-Instance aktualisiert wird. Sie erhalten Backup-Speicher bis zur Speichergröße Ihrer DB-Instance ohne zusätzliche Kosten.

Weitere Informationen finden Sie in den folgenden Ressourcen:

Die Synchronisation des Binärprotokolls mit der Festplatte wird erst erzwungen, wenn Transaktions-Commits in Ihrer DB-Instance bestätigt wurden.

Wir empfehlen, den Parameterwert sync_binlog auf 1 zu setzen.

c1qf5bt031

Gelb: Für DB-Parametergruppen ist die synchrone Binärprotokollierung deaktiviert.

Setzen Sie den Parameter sync_binlog auf 1.

Der Parameter sync_binlog steuert, wie MySQL das Binärlog auf die Festplatte überträgt. Wenn der Wert dieses Parameters auf 1 gesetzt ist, wird die Binärprotokollsynchronisierung mit der Festplatte aktiviert, bevor Transaktionen festgeschrieben werden. Wenn der Wert dieses Parameters auf 0 gesetzt ist, wird die Binärprotokollsynchronisierung mit der Festplatte deaktiviert. Normalerweise hängt der MySQL-Server vom Betriebssystem ab, um das Binärprotokoll regelmäßig auf die Festplatte zu übertragen, ähnlich wie bei anderen Dateien. Der Wert des sync_binlog-Parameters, der auf 0 gesetzt ist, kann die Leistung verbessern. Bei einem Stromausfall oder einem Betriebssystemabsturz verliert der Server jedoch alle festgeschriebenen Transaktionen, die nicht mit den Binärprotokollen synchronisiert wurden.

Weitere Informationen finden Sie unter Bewährte Methoden für die Konfiguration von Parametern für Amazon RDS for MySQL, Teil 2: Parameter im Zusammenhang mit der Replikation.

Prüft, ob für Ihre Amazon RDS-DB-Cluster die Multi-AZ Replikation aktiviert ist.

Ein Multi-AZ DB-Cluster hat eine Writer-DB-Instance und zwei Reader-DB-Instances in drei separaten Availability Zones. Multi-AZ DB-Cluster bieten im Vergleich zu Multi-AZ Bereitstellungen eine hohe Verfügbarkeit, eine höhere Kapazität für Lese-Workloads und eine geringere Latenz.

Weitere Informationen finden Sie unter Multi-AZ DB-Cluster erstellen.

c18d2gz161

AWS Config Managed Rule: rds-cluster-multi-az-enabled

Gelb: Für Ihren Amazon RDS-DB-Cluster ist keine Multi-AZ Replikation konfiguriert

Schalten Sie die Multi-AZ DB-Cluster-Bereitstellung ein, wenn Sie einen Amazon RDS-DB-Cluster erstellen.

Weitere Informationen finden Sie unter Erstellen eines Multi-AZ DB-Clusters.

Multi-AZ DB-Cluster-Bereitstellungen

Prüft, ob für Ihre Amazon RDS-DB-Instances eine Multi-AZ Standby-Replica konfiguriert ist.

Amazon RDS Multi-AZ bietet hohe Verfügbarkeit und Haltbarkeit für Datenbank-Instances, indem Daten auf ein Standby-Replikat in einer anderen Availability Zone repliziert werden. Dies ermöglicht ein automatisches Failover und verbessert die Leistung und Beständigkeit der Daten. Bei einer Multi-AZ DB-Instance-Bereitstellung stellt Amazon RDS automatisch eine synchrone Standby-Replica in einer anderen Availability Zone bereit und verwaltet sie. Die primäre DB-Instance wird synchron über Availability Zones hinweg auf ein Standby-Replikat repliziert, um Datenredundanz bereitzustellen und Latenzspitzen während Systemsicherungen zu minimieren. Wenn Sie eine DB-Instance mit hoher Verfügbarkeit ausführen, verbessert dies die Verfügbarkeit bei geplanten Systemwartungen. Sie kann auch Ihre Datenbanken bei Ausfällen der DB-Instance und bei Nichtverfügbarkeit von Availability Zones schützen.

Weitere Informationen finden Sie unter Multi-AZ DB-Instance-Bereitstellungen.

c18d2gz156

AWS Config Managed Rule: rds-multi-az-support

Gelb: Für eine Amazon RDS-DB-Instance ist kein Multi-AZ Replikat konfiguriert.

Schalten Sie die Multi-AZ Bereitstellung ein, wenn Sie eine Amazon RDS-DB-Instance erstellen.

Diese Prüfung kann nicht von der Anzeige in der Trusted Advisor Konsole ausgeschlossen werden.

Multi-AZ Bereitstellungen von DB-Instances

Überprüft, ob die ReplicaLag CloudWatch Metrik für eine RDS-Datenbank-Instance in der letzten Woche einen betrieblich vertretbaren Schwellenwert überschritten hat.

ReplicaLag Die Metrik misst die Anzahl der Sekunden, um die sich eine Read Replica hinter der primären Instance befindet. Eine Verzögerung bei der Replikation tritt auf, wenn die asynchronen Aktualisierungen des Lesereplikats nicht mit den Aktualisierungen in der primären Datenbank-Instance Schritt halten können. Bei einem Ausfall der primären Instance könnten Daten in der Read Replica fehlen, wenn der Wert über einem betriebswirtschaftlich vertretbaren Schwellenwert ReplicaLag liegt.

Cmsvnj8db1

Es gibt mehrere mögliche Ursachen dafür, dass der Anstieg über ReplicaLag die betriebssichersten Werte hinausgeht. Dies kann beispielsweise dadurch verursacht werden, dass kürzlich replaced/launched replizierte Instanzen aus älteren Backups erstellt wurden und diese Replikate viel Zeit benötigen, um die primäre Datenbankinstanz und Live-Transaktionen nachzuholen. Dies ReplicaLag kann im Laufe der Zeit abnehmen, wenn ein Aufholvorgang stattfindet. Ein anderes Beispiel könnte sein, dass die Transaktionsgeschwindigkeit, die in der primären Datenbank-Instance erreicht werden kann, höher ist als der Replikationsprozess oder die Replikatinfrastruktur. Dies ReplicaLag kann im Laufe der Zeit zunehmen, da die Replikation nicht mit der Leistung der primären Datenbank Schritt hält. Schließlich kann es vorkommen, dass die Arbeitslast in verschiedenen Perioden des day/month /etc.-Prozesses überlastet ist, was gelegentlich dazu führt, dass ReplicaLag sie ins Hintertreffen gerät. Ihr Team sollte untersuchen, welche mögliche Grundursache zu einem Ausfall der Datenbank beigetragen hat, und möglicherweise den Typ der Datenbankinstanz oder andere Merkmale der Arbeitslast ändern, um sicherzustellen, dass die Datenkontinuität auf dem Replikat Ihren Anforderungen entspricht. ReplicaLag

Wenn der Parameter synchronous_commit ausgeschaltet ist, können Daten bei einem Datenbankabsturz verloren gehen. Die Haltbarkeit der Datenbank ist gefährdet.

Wir empfehlen, den Parameter synchronous_commit zu aktivieren.

c1qf5bt026

Rot: Bei DB-Parametergruppen ist der Parameter synchronous_commit deaktiviert.

Schalten Sie den Parameter synchronous_commit in Ihren DB-Parametergruppen ein.

Der Parameter synchronous_commit definiert den Abschluss des Write-Ahead Logging-Prozesses (WAL), bevor der Datenbankserver eine erfolgreiche Benachrichtigung an den Client sendet. Dieses Commit wird als asynchrones Commit bezeichnet, da der Client das Commit bestätigt, bevor WAL die Transaktion auf der Festplatte speichert. Wenn der Parameter synchronous_commit ausgeschaltet ist, können die Transaktionen verloren gehen, die Haltbarkeit der DB-Instance kann beeinträchtigt werden und Daten können verloren gehen, wenn eine Datenbank abstürzt.

Weitere Informationen finden Sie unter MySQL-Datenbank-Logdateien.

Prüft, ob automatische Snapshots für Ihre Amazon-Redshift-Cluster aktiviert sind.

Amazon Redshift erstellt in regelmäßigen Abständen inkrementelle Snapshots und verfolgt so Änderungen am Cluster seit dem letzten automatisierten Snapshot nach. Automatisierte Snapshots speichern alle Daten, die erforderlich sind, um einen Cluster anhand eines Snapshots wiederherzustellen. Zum Deaktivieren von automatischen Snapshots setzen Sie den Wert für den Aufbewahrungszeitraum auf null. Sie können automatische Snapshots für RA3-Knotentypen nicht deaktivieren.

Sie können die gewünschte Mindest- und Höchstaufbewahrungsdauer mithilfe des MaxRetentionPeriod Parameters MinRetentionPeriod und Ihrer AWS Config Regeln angeben.

Amazon-Redshift-Snapshots und -Sicherungen

c18d2gz135

AWS Config Managed Rule: redshift-backup-enabled

Rot: Amazon Redshift hat keine automatisierten Snapshots, die innerhalb des gewünschten Aufbewahrungszeitraums konfiguriert wurden.

Stellen Sie sicher, dass automatische Snapshots für Ihre Amazon-Redshift-Cluster aktiviert sind.

Weitere Informationen finden Sie unter Verwalten von Snapshots mithilfe der Konsole.

Amazon-Redshift-Snapshots und -Sicherungen

Weitere Informationen finden Sie unter Arbeiten mit Sicherungen.

Prüft auf Ressourcendatensätzen, die mit gelöschten Zustandsprüfungen verbunden sind.

Route 53 hindert Sie nicht daran, eine Zustandsprüfung zu löschen, die mit einem oder mehreren Ressourceneintragsätzen verbunden ist. Wenn Sie eine Zustandsprüfung löschen, ohne die zugehörigen Ressourceneintragsätze zu aktualisieren, funktioniert die Weiterleitung von DNS-Anfragen für Ihre DNS-Failover-Konfiguration nicht wie vorgesehen.

Gehostete Zonen, die von AWS Diensten erstellt wurden, erscheinen nicht in Ihren Prüfergebnissen.

Cb877eB72b

Gelb: Ein Ressourcendatensatz ist mit einer Zustandsprüfung verknüpft, die gelöscht wurde.

Erstellen Sie eine neue Zustandsprüfung und ordnen Sie sie dem Ressourcendatensatz zu. Weitere Informationen finden Sie unter Erstellen, Aktualisieren und Löschen von Zustandsprüfungen und Hinzufügen von Zustandsprüfungen zu Ressourcendatensätzen.

Prüft auf Amazon Route 53 Failover-Ressourceneintragsätze, die eine Fehlkonfiguration aufweisen.

Wenn Amazon Route 53 Zustandsprüfungen feststellen, dass die primäre Ressource ungesund ist, antwortet Amazon Route 53 auf Anfragen mit einem sekundären Backup-Ressourceneintragsatz. Sie müssen korrekt konfigurierte primäre und sekundäre Ressourceneintragsätze erstellen, damit das Failover funktioniert.

Gehostete Zonen, die von AWS Diensten erstellt wurden, werden in Ihren Prüfergebnissen nicht angezeigt.

b73EEdD790

Wenn ein Failover-Ressourcensatz fehlt, erstellen Sie den entsprechenden Ressourcendatensatz. Weitere Informationen finden Sie unter Erstellen von Failover-Ressourcendatensätzen.

Wenn Ihre Ressourcendatensätze derselben Zustandsprüfung zugeordnet sind, erstellen Sie für jeden einzelnen eine separate Zustandsprüfung. Weitere Informationen finden Sie unter Erstellen, Aktualisieren und Löschen von Zustandsprüfungen.

Erstellen von Amazon-Route-53-Zustandsprüfungen und Konfigurieren des DNS-Failovers

Prüft auf Ressourcendatensätze, die von einem niedrigeren TTL-Wert (Gültigkeitsdauer) profitieren können.

TTL ist die Anzahl der Sekunden, die ein Ressourceneintragsatz von DNS-Auflösern zwischengespeichert wird. Wenn Sie eine lange TTL angeben, benötigen DNS-Resolver länger, um aktualisierte DNS-Einträge anzufordern, was zu unnötigen Verzögerungen bei der Umleitung des Datenverkehrs führen kann (z. B. wenn DNS-Failover einen Ausfall eines Ihrer Endpunkte erkennt und darauf reagiert). Bei dieser Prüfung werden nur Datensätze untersucht, für die die Failover-Richtlinie gilt, oder ob eine zugehörige Integritätsprüfung durchgeführt wurde.

Gehostete Zonen, die von AWS Diensten erstellt wurden, werden in Ihren Prüfergebnissen nicht angezeigt.

C056F80cR3

Geben Sie einen TTL-Wert von 60 Sekunden für die aufgelisteten Ressourcendatensätze ein. Weitere Informationen finden Sie unter Arbeiten mit Ressourcendatensätzen.

Erstellen von Amazon-Route-53-Zustandsprüfungen und Konfigurieren des DNS-Failovers

Prüft auf von Amazon Route 53 gehosteten Zonen, für die Ihr Domain-Registrar oder DNS nicht die richtigen Route 53-Namenserver verwendet.

Wenn Sie eine gehostete Zone erstellen, weist Route 53 einen Delegationssatz von vier Namenservern zu. Die Namen dieser Server lauten ns- ### .awsdns- ## .com, .net, .org und .co.uk, wobei ### und für gewöhnlich unterschiedliche Zahlen stehen. ## Bevor Route 53 DNS-Anfragen für Ihre Domain weiterleiten kann, müssen Sie die Nameserverkonfiguration Ihres Registrars aktualisieren, um die Nameserver zu entfernen, die der Registrar zugewiesen hat. Anschließend müssen Sie alle vier Nameserver in den Route 53-Delegationssatz aufnehmen. Um eine maximale Verfügbarkeit zu erreichen, müssen Sie alle vier Route 53-Namenserver hinzufügen.

Gehostete Zonen, die von AWS Diensten erstellt wurden, erscheinen nicht in Ihren Prüfergebnissen.

cF171Db240

Gelb: Eine gehostete Zone, für die die Domainvergabestelle nicht alle vier Route 53-Namenserver im Delegierungssatz verwendet.

Fügen Sie Nameserver-Datensätze bei Ihrer Vergabestelle oder mit dem aktuellen DNS-Service hinzu oder aktualisieren Sie sie, damit Ihre Domain alle vier Nameserver in Ihrem Route-53-Delegationssatz enthält. Informationen zu diesen Werten finden Sie unter Das Abrufen der Nameserver für eine öffentliche gehostete Zone. Hinweise zum Hinzufügen oder Aktualisieren von Nameserver-Datensätzen finden Sie unter Verwendung von Amazon Route 53 als DNS-Service für eine Subdomain ohne Migration der übergeordneten Domain.

Arbeiten mit gehosteten Zonen

Überprüft, ob in Ihrer Service-Konfiguration aus Redundanzgründen IP-Adressen in mindestens zwei Availability Zones (AZs) angegeben sind. Eine Availability Zone ist ein eigenständiger Standort, der vor Ausfällen in anderen Zonen geschützt ist. Indem Sie IP-Adressen in mehreren Availability Zones in derselben Region angeben, können Sie Ihre Anwendungen vor einem einzelnen Ausfallpunkt schützen.

Chrv231ch1

Geben Sie zu Redundanzzwecken IP-Adressen in mindestens zwei Availability Zones an.

Überprüft, ob in Ihren Amazon S3-Buckets Replikationsregeln für Cross-Region Replikation, Same-Region Replikation oder beides aktiviert sind.

Bei der Replikation handelt es sich um das automatische, asynchrone Kopieren von Objekten zwischen Buckets in derselben oder verschiedenen Regionen. AWS Sie kopiert neu erstellte Objekte und Objektaktualisierungen aus einem Quell-Bucket in einen Ziel-Bucket oder mehrere Ziel-Buckets. Verwenden Sie die Amazon-S3-Bucket-Replikation, um die Resilienz und Konformität Ihrer Anwendungen und Datenspeicher zu verbessern.

Weitere Informationen finden Sie unter Replizieren von Objekten.

c18d2gz119

AWS Config Managed Rule: s3-bucket-replication-enabled

Gelb: Die Amazon S3-Bucket-Replikationsregeln sind nicht für Cross-Region Replikation, Same-Region Replikation oder beides aktiviert.

Aktivieren Sie die Amazon-S3-Bucket-Replikationsregeln, um die Resilienz und Konformität Ihrer Anwendungen und Datenspeicher zu verbessern.

Weitere Informationen finden Sie unter Anzeigen Ihrer Backup-Jobs und Wiederherstellungspunkte und Einrichten der Replikation.

Anleitungen: Beispiele zum Konfigurieren der Replikation

Prüft auf Amazon Simple Storage Service-Buckets, bei denen die Versioning nicht aktiviert ist oder die Versionierung ausgesetzt wurde.

Wenn die Versioning aktiviert ist, können Sie sowohl unbeabsichtigte Benutzeraktionen als auch Anwendungsfehler problemlos beheben. Mit Versioning können Sie jede Version eines Objekts, das in einem Bucket gespeichert ist, aufbewahren, abrufen und wiederherstellen. Sie können Lebenszyklusregeln verwenden, um alle Versionen Ihrer Objekte sowie die damit verbundenen Kosten zu verwalten, indem Sie Objekte automatisch in der Speicherklasse Glacier archivieren. Die Regeln können auch so konfiguriert werden, dass Versionen Ihrer Objekte nach einem bestimmten Zeitraum entfernt werden. Sie können auch eine Multi-Faktor-Authentifizierung (MFA) für alle Objektlöschungen oder Konfigurationsänderungen an Ihren Buckets verlangen.

Die Versioning kann nicht mehr deaktiviert werden, nachdem sie aktiviert wurde. Sie kann jedoch ausgesetzt werden, so dass keine neuen Versionen von Objekten erstellt werden können. Die Verwendung der Versioning kann Ihre Kosten für Amazon S3 erhöhen, da Sie für die Speicherung mehrerer Versionen eines Objekts bezahlen.

R365s2Qddf

Aktivieren Sie das Bucket-Versioning für die meisten Buckets, um versehentliches Löschen oder Überschreiben zu verhindern. Weitere Informationen finden Sie unter Verwenden des Versioning und Aktivieren des Versioning für Buckets.

Wenn das Bucket-Versioning ausgesetzt ist, sollten Sie es erneut aktivieren. Informationen zum Arbeiten mit Objekten in einem Bucket, für den die Versionierung gesperrt ist, finden Sie unter Objekte in einem Bucket verwalten. Versioning-Suspended

Wenn das Versioning aktiviert oder ausgesetzt ist, können Sie Lebenszyklus-Konfigurationsregeln definieren, um bestimmte Objektversionen als abgelaufen zu kennzeichnen oder nicht benötigte Objektversionen dauerhaft zu entfernen. Weitere Informationen hierzu finden Sie im Abschnitt Objektlebenszyklusverwaltung.

MFA Delete erfordert zusätzliche Authentifizierung, wenn der Versioning-Status des Buckets geändert wird oder Versionen eines Objekts gelöscht werden. Der Benutzer muss Anmeldeinformationen und einen Code von einem zugelassenen Authentifizierungsgerät eingeben. Weitere Informationen finden Sie unter MFA Delete (MFA-Löschung).

Arbeiten mit Buckets

Prüft, ob Ihre Load Balancer (Application Load Balancer, Network Load Balancer und Gateway Load Balancer) mit Subnetzen in mehreren Availability Zones konfiguriert sind.

Sie können Ihre gewünschten Mindestverfügbarkeitszonen in den AvailabilityZones Hauptparametern Ihrer AWS Config Regeln angeben.

Weitere Informationen finden Sie unter Availability Zones für Ihren Application Load Balancer, Availability Zones – Network Load Balancer und Erstellen eines Gateway Load Balancers.

c18d2gz169

AWS Config Managed Rule: elbv2-multiple-az

Gelb: Application Load Balancer, Network Load Balancer und Gateway Load Balancer, die mit Subnetzen in weniger als zwei Availability Zones konfiguriert sind.

Konfigurieren Sie Ihre Application Load Balancer, Network Load Balancer und Gateway Load Balancer mit Subnetzen in mehreren Availability Zones.

Availability Zones für Ihren Application Load Balancer

Availability Zones (Elastic Load Balancing)

Erstellen eines Gateway Load Balancers

Prüft, ob genügend verfügbare IPs unter den angestrebten Subnets.Having IP-Adressen zur Verfügung stehen. Das hilft, wenn die Auto Scaling Group ihre maximale Größe erreicht hat und zusätzliche Instances starten muss.

Cjxm268ch1

Erhöhen Sie die Anzahl der verfügbaren IP-Adressen.

Untersucht die Konfiguration der Zustandsprüfung für Auto-Scaling-Gruppen.

Wenn Elastic Load Balancing für eine Auto-Scaling-Gruppe verwendet wird, wird empfohlen, eine Elastic Load Balancing-Zustandsprüfung zu aktivieren. Wenn keine Elastic Load Balancing-Zustandsprüfung verwendet wird, kann Auto-Scaling nur auf den Zustand der Amazon Elastic Compute Cloud (Amazon EC2)-Instance reagieren. Auto-Scaling wirkt sich nicht auf die Anwendung aus, die auf der Instance läuft.

CLOG40CDO8

Wenn der Auto-Scaling-Gruppe ein Load Balancer zugeordnet ist, die Zustandsprüfung für Elastic Load Balancing jedoch nicht aktiviert ist, finden Sie weitere Informationen unter Hinzufügen von Zustandsprüfungen für Elastic-Load-Balancing zu einer Auto-Scaling-Gruppe.

Wenn der Elastic Load Balancing Health Check aktiviert ist, der Auto Scaling-Gruppe aber kein Load Balancer zugeordnet ist, finden Sie weitere Informationen unter Eine Auto-Scaled Load-Balanced UND-Anwendung https://docs.aws.amazon.com/AutoScaling/latest/DeveloperGuide/as-register-lbs-with-asg.html einrichten.

Benutzerhandbuch für Amazon EC2 Auto Scaling

Überprüft die Verfügbarkeit von Ressourcen, die Ihren Startkonfigurationen, Startvorlagen und Ihren Auto Scaling-Gruppen zugeordnet sind.

Auto-Scaling-Gruppen, die auf nicht verfügbare Ressourcen verweisen, können keine neuen Amazon-Elastic-Compute-Cloud(Amazon EC2)-Instances starten. Bei richtiger Konfiguration bewirkt Auto-Scaling, dass die Anzahl der Amazon-EC2-Instances bei Bedarfsspitzen nahtlos erhöht und bei Bedarfstiefs automatisch verringert wird. Auto Scaling-Gruppen und configurations/launch Startvorlagen, die auf nicht verfügbare Ressourcen verweisen, funktionieren nicht wie vorgesehen.

8CNsSllI5v

Wenn der Load Balancer gelöscht wurde, erstellen Sie entweder einen neuen Load Balancer oder eine neue Zielgruppe und ordnen Sie sie dann der Auto Scaling-Gruppe zu. Oder erstellen Sie eine neue Auto Scaling-Gruppe ohne den Load Balancer. Informationen zum Erstellen einer neuen Auto Scaling-Gruppe mit einem neuen Load Balancer finden Sie unter Eine UND-Anwendung einrichten. Auto-Scaled Load-Balanced Informationen zum Erstellen einer neuen Auto-Scaling-Gruppe ohne Load Balancer finden Sie unter „Create Auto Scaling Group“ (Erstellen einer Auto-Scaling-Gruppe) in Getting Started With Auto Scaling Using the Console (Erste Schritte mit Auto Scaling mit der Konsole).

Wenn das AMI gelöscht wurde, erstellen Sie eine neue Startkonfiguration oder Startvorlagenversion mit einem gültigen AMI und ordnen Sie sie einer Auto Scaling-Gruppe zu. Informationen zum Erstellen einer neuen Startkonfiguration finden Sie unter Erstellen einer Startkonfiguration im Amazon EC2 Auto Scaling-Benutzerhandbuch. Informationen zum Erstellen einer Startvorlage finden Sie unter Erstellen einer Startvorlage für eine Auto Scaling-Gruppe im Amazon EC2 Auto Scaling-Benutzerhandbuch.

Wenn Ihre Startvorlagen einen AWS Systems Manager Parameter enthalten, der eine Amazon Machine Image (AMI) -ID enthält, überprüfen Sie die Startvorlage, um sicherzustellen, dass die Parameter auf eine gültige AMI-ID verweisen, oder nehmen Sie die entsprechenden Änderungen im AWS Systems Manager Parameterspeicher vor. Weitere Informationen finden Sie unter Verwenden von AWS Systems Manager Parametern anstelle von AMI-IDs im Amazon EC2 Auto Scaling-Benutzerhandbuch.

Überprüft Ihre Cluster, die HSM-Instances in einer einzigen Availability Zone (AZ) ausführen. Diese Prüfung warnt Sie, wenn bei Ihren Clustern das Risiko besteht, dass sie nicht über das neueste Backup verfügen.

hc0dfs7601

Erstellen Sie mindestens eine weitere Instance für den Cluster in einer anderen Availability Zone.

Bewährte Methoden für AWS CloudHSM

Überprüft die Stabilität des Geräts, das für die Verbindung zwischen Ihrem lokalen Gateway und jedem Direct Connect-Gateway oder Virtual Private Gateway Direct Connect verwendet wird.

Bei dieser Prüfung werden Sie gewarnt, wenn ein Direct Connect-Gateway oder Virtual Private Gateway nicht mit virtuellen Schnittstellen an mindestens zwei verschiedenen Direct Connect-Standorten konfiguriert ist. Ein Mangel an Ausfallsicherheit kann zu unerwarteten Ausfallzeiten während der Wartung, einem Glasfaserausfall, einem Geräteausfall oder einem kompletten Standortausfall führen.

c1dfpnchv2

Rot: Das Direct Connect-Gateway oder Virtual Private Gateway ist mit einer oder mehreren virtuellen Schnittstellen auf einem einzelnen Direct Connect-Gerät konfiguriert.

Gelb: Das Direct Connect-Gateway oder Virtual Private Gateway ist mit virtuellen Schnittstellen für mehrere Direct Connect-Geräte an einem einzigen Direct Connect-Standort konfiguriert.

Grün: Das Direct Connect-Gateway oder Virtual Private Gateway ist mit virtuellen Schnittstellen an zwei oder mehr verschiedenen Direct Connect-Standorten konfiguriert.

Um die Stabilität des Direct Connect-Standorts zu gewährleisten, können Sie das Direct Connect-Gateway oder das Virtual Private Gateway so konfigurieren, dass eine Verbindung zu mindestens zwei verschiedenen Direct Connect-Standorten hergestellt wird. Weitere Informationen finden Sie unter Direct Connect Resilienz-Empfehlung.

Direct Connect Empfehlungen zur Resilienz

Direct Connect Failover-Test

Prüft, ob eine AWS Lambda Funktion mit einer Warteschlange für unlesbare Buchstaben konfiguriert ist.

Eine Warteschlange mit unzustellbaren Briefen ist eine Funktion von AWS Lambda , mit der Sie fehlgeschlagene Ereignisse erfassen und analysieren können, sodass diese Ereignisse entsprechend behandelt werden können. Ihr Code kann eine Ausnahme oder eine Zeitüberschreitung auslösen oder bewirken, dass der Speicher knapp wird, was zu fehlgeschlagenen asynchronen Ausführungen Ihrer Lambda-Funktion führt. In einer Warteschlange für unzustellbare Nachrichten werden Nachrichten von fehlgeschlagenen Aufrufen gespeichert, sodass die Nachrichten verarbeitet und Fehler behoben werden können.

Mithilfe des DLQArns-Parameters in Ihren Regeln können Sie die Ressource für die Warteschlange ohne Anmeldung angeben, die Sie überprüfen möchten. AWS Config

Weitere Informationen finden Sie unter Warteschlangen. Dead-letter

c18d2gz182

AWS Config Managed Rule: lambda-dlq-check

Gelb: Für die AWS Lambda Funktion ist keine Warteschlange für unlesbare Buchstaben konfiguriert.

Stellen Sie sicher, dass für Ihre AWS Lambda Funktionen eine Warteschlange mit unlesbaren Buchstaben konfiguriert ist, um die Nachrichtenverarbeitung für alle fehlgeschlagenen asynchronen Aufrufe zu steuern.

Weitere Informationen finden Sie unter Warteschlangen. Dead-letter

Überprüft, ob für Lambda-Funktionen in Ihrem Konto ein Ereignisziel bei einem Ausfall oder eine Warteschlange für unzustellbare Nachrichten für asynchrone Aufrufe konfiguriert ist, sodass Datensätze von fehlgeschlagenen Aufrufen zur weiteren Untersuchung oder Verarbeitung an ein Ziel weitergeleitet werden können.

c1dfprch05

Richten Sie das Ereignisziel bei einem Ausfall oder eine Warteschlange für unzustellbare Nachrichten für Ihre Lambda-Funktionen ein, um fehlgeschlagene Aufrufe zusammen mit anderen Details an einen der verfügbaren AWS-Ziel-Services zur weiteren Fehlersuche oder Verarbeitung zu senden.

Überprüft die $LATEST-Version der VPC-enabled Lambda-Funktionen, die anfällig für Betriebsunterbrechungen in einer einzelnen Availability Zone sind. Es hat sich bewährt, VPC-enabled Funktionen mit mehreren Availability Zones zu verbinden, um eine hohe Verfügbarkeit zu gewährleisten.

L4dfs2Q4C6

Gelb: Die $LATEST-Version einer VPC-enabled Lambda-Funktion ist mit Subnetzen in einer einzigen Availability Zone verbunden.

Wählen Sie bei der Konfiguration von Funktionen für den Zugriff auf Ihre VPC Subnetze in mehreren Availability Zones aus, um eine hohe Verfügbarkeit sicherzustellen.

Überprüft das Gleichgewicht der Outposts Racks. Dabei wird bewertet, ob die Outposts-Instanzen eines Kunden in mehreren Outpost-Racks oder in einem einzelnen Outpost-Rack eingesetzt werden. Ein einzelnes Outposts-Rack bietet eine zentrale Fehlerquelle für Probleme, die ein einzelnes Rack betreffen (z. B. Umweltausfälle). Diese Szenarien können durch den Einsatz von Außenposten auf mehreren Racks abgemildert werden.

c243hjzrhn

Wenn Sie Produktions-Workloads ausführen AWS Outposts, empfiehlt es sich, die folgende robuste Architektur zu verwenden. Ein einzelnes AWS Outposts Rack erzeugt eine einzige Fehlerquelle. Erwägen Sie, an diesem Standort ein zweites AWS Outposts Rack mit ausreichender Kapazität für einen Failover-Fall hinzuzufügen und dann die Arbeitslasten auf die Racks zu verteilen.

Fehlermodus 4: Racks oder Rechenzentren

Überprüft, ob eine Anwendungskomponente (AppComponent) in Ihrer Anwendung nicht wiederhergestellt werden kann. Wenn eine im Falle einer Störung AppComponent nicht wiederhergestellt werden kann, kann es zu unbekanntem Datenverlust und Systemausfällen kommen.

RH23stmM04

Rot: AppComponent ist nicht wiederherstellbar.

Um sicherzustellen, dass Ihr System wiederherstellbar AppComponent ist, überprüfen und implementieren Sie die Resilienzempfehlungen und führen Sie dann eine neue Bewertung durch. Weitere Informationen zur Überprüfung der Resilienzempfehlungen finden Sie unter Zusätzliche Ressourcen.

Überprüfung der Empfehlungen zur Ausfallsicherheit

Konzepte von AWS Resilience Hub

AWS Resilience Hub Benutzerhandbuch

Sucht in Resilience Hub nach Anwendungen, die das Recovery Time Objective (RTO) und Recovery Point Objective (RPO) nicht erfüllen. Diese Prüfung warnt Sie, wenn Ihre Anwendung die RTO- und RPO-Ziele, die Sie für eine Anwendung in Resilience Hub festgelegt haben, nicht erfüllt.

RH23stmM02

Melden Sie sich bei der Resilience-Hub-Konsole an und überprüfen Sie die Empfehlungen, damit Ihre Anwendung die RTO- und RPO-Ziele erfüllt.

Resilience-Hub-Konzepte

Prüft, ob Sie eine Bewertung für Ihre Anwendungen in Resilience Hub durchgeführt haben. Diese Prüfung warnt Sie, wenn Ihre Resilienzwerte unter einem bestimmten Wert liegen.

RH23stmM01

Melden Sie sich bei der Resilience-Hub-Konsole an und führen Sie eine Bewertung für Ihre Anwendung durch. Lesen Sie die Empfehlungen zur Verbesserung des Resilienzwertes.

Resilience-Hub-Konzepte

Prüft, wie lange es her ist, dass Sie das letzte Mal eine Anwendungsbeurteilung durchgeführt haben. Bei dieser Prüfung werden Sie benachrichtigt, wenn Sie seit einer bestimmten Anzahl von Tagen keine Anwendungsbeurteilung durchgeführt haben.

RH23stmM03

Melden Sie sich bei der Resilience-Hub-Konsole an und führen Sie eine Bewertung für Ihre Anwendung durch.

Resilience-Hub-Konzepte

Überprüft die Anzahl der Tunnel, die für jeden Ihrer AWS Site-to-Site VPN s aktiv sind.

In einem VPN sollten immer zwei Tunnel konfiguriert sein. Dies bietet Redundanz im Falle eines Ausfalls oder einer geplanten Wartung der Geräte am AWS-Endpunkt. Bei einigen Geräten ist jeweils nur ein Tunnel aktiv. Wenn ein VPN keine aktiven Tunnel hat, können trotzdem Gebühren für das VPN anfallen.

Weitere Informationen finden Sie unter Was ist AWS Site-to-Site VPN?

c18d2gz123

AWS Config Managed Rule: vpc-vpn-2-tunnels-up

Gelb: Bei einem Site-to-Site VPN ist mindestens ein Tunnel NICHT VERFÜGBAR.

Stellen Sie sicher, dass zwei Tunnel für VPN-Verbindungen konfiguriert sind. Und wenn Ihre Hardware dies unterstützt, stellen Sie sicher, dass beide Tunnel aktiv sind. Wenn Sie eine VPN-Verbindung nicht mehr benötigen, löschen Sie sie, um Kosten zu vermeiden.

Weitere Informationen finden Sie unter Ihr Kunden-Gateway-Gerät und in den im AWS-Wissenscenter verfügbaren Inhalten.

Bei dieser Prüfung wird ein Ausfallrisiko festgestellt, wenn AWS Workloads regionsübergreifende Aufrufe an den globalen STS-Endpunkt in der Region USA Ost (Nord-Virginia) senden. AWS Workloads, die regionsübergreifende Anfragen an den globalen STS-Endpunkt in USA Ost (Nord-Virginia) stellen, können sich negativ auswirken, wenn die Konnektivität zum STS-Endpunkt USA Ost (Nord-Virginia) beeinträchtigt wird.

Im April 2025 wurde der globale Endpunkt dahingehend AWS erweitert, dass er automatisch die globalen STS-Endpunktanrufe in derselben Region bedient, in der Ihre Workloads ausgeführt werden AWS, und zwar für alle standardmäßig aktivierten. AWS-Regionen Einige Workloads, z. B. solche, die in Opt-in-Regionen ausgeführt werden, oder solche, die keine Amazon-DNS-Server verwenden, profitieren jedoch nicht von der reduzierten Latenz und Fehlerisolierung, die im Rahmen dieser Erweiterung angeboten werden. Für diese Workloads werden globale STS-Endpunktanfragen in der Region USA Ost (Nord-Virginia) bedient, was ein Ausfallrisiko für Ihre Anwendung darstellt und die Latenz von STS-Anfragen erhöht.

c15m0mgld3

Rot: Workloads senden regionsübergreifende Aufrufe an den AWS STS globalen Endpunkt in der Region USA Ost (Nord-Virginia).

Um die Stabilität und Leistung Ihrer Workloads zu verbessern, empfehlen wir Ihnen, vom globalen STS-Endpunkt zum regionalen STS-Endpunkt zu migrieren. Wenn Sie einen regionalen Endpunkt verwenden, können Sie ihn AWS STS in derselben Region wie Ihre Workloads verwenden.

Im Folgenden finden Sie eine Liste von AWS Identity and Access Management (IAM-) Principals, die regionsübergreifende Anrufe an den AWS STS globalen Endpunkt in der Region USA Ost (Nord-Virginia) tätigen. Wenn Sie die Schritte im Blogbeitrag So verwenden Sie regionale AWS STS Endpunkte befolgen, können Sie Ihre Workloads für die Verwendung des regionalen STS-Endpunkts neu konfigurieren.

Prüft auf Probleme mit hohem Risiko (HRI) für Ihre Workloads hinsichtlich der Zuverlässigkeit. Diese Prüfung basiert auf Ihren AWS-Well Architected-Beurteilungen. Ihre Prüfergebnisse hängen davon ab, ob Sie die Workload-Bewertung mit AWS Well-Architected durchgeführt haben.

Wxdfp4B1L4

AWS Well-Architected hat bei Ihrer Workload-Bewertung Probleme mit hohem Risiko festgestellt. Diese Probleme bieten Möglichkeiten, Risiken zu reduzieren und Geld zu sparen. Melden Sie sich beim AWS Well-Architected Tool an, um Ihre Antworten zu überprüfen und Maßnahmen zur Behebung Ihrer aktuellen Probleme zu ergreifen.

Prüft, ob der Classic Load Balancer mehrere Availability Zones (AZs) umfasst.

Ein Load Balancer verteilt eingehenden Anwendungsdatenverkehr auf mehrere Amazon-EC2-Instances in mehreren Availability Zones. Der Load Balancer verteilt den Datenverkehr standardmäßig gleichmäßig auf die Availability Zones, die Sie für Ihren Load Balancer aktivieren. Bei einem Ausfall einer Availability Zone leiten Load-Balancer-Knoten Anforderungen automatisch an die fehlerfreien registrierten Instances in einer oder mehreren Availability Zones weiter.

Sie können die Mindestanzahl an Availability Zones mithilfe des AvailabilityZones Parameters min in Ihren AWS Config Regeln anpassen

Weitere Informationen finden Sie unter Was ist Classic Load Balancer?.

c18d2gz154

AWS Config Managed Rule: clb-multiple-az

Gelb: Classic Load Balancer wurde nicht Multi-AZ konfiguriert oder erfüllt nicht die angegebene Mindestanzahl von AZs.

Stellen Sie sicher, dass für Ihre Classic Load Balancer mehrere Availability Zones (AZs) konfiguriert sind. Verteilen Sie Ihren Load Balancer auf mehrere AZs, um sicherzustellen, dass Ihre Anwendung hochverfügbar ist.

Weitere Informationen finden Sie unter Tutorial: Erstellen eines Classic Load Balancer.

Sucht nach klassischen Load Balancern, bei denen der Verbindungsabbau nicht aktiviert ist.

Wenn der Verbindungsabbau nicht aktiviert ist und Sie eine Amazon EC2-Instance von einem Classic Load Balancer abmelden, stoppt der Classic Load Balancer die Weiterleitung des Datenverkehrs zu dieser Instance und schließt die Verbindung. Wenn der Verbindungsabbau aktiviert ist, sendet der Classic Load Balancer keine neuen Anfragen mehr an die deregistrierte Instance, hält die Verbindung jedoch offen, um aktive Anfragen zu bearbeiten.

7qGXsKIUw

Aktivieren Sie den Verbindungsabbau für den Classic Load Balancer. Weitere Informationen finden Sie unter Connection Draining und Enable or Disable Connection Draining for Your Load Balancer (Aktivieren oder Deaktivieren von Connection Draining für Ihren Load Balancer).

Elastic Load Balancing Concepts (Konzepte für Elastic-Load-Balancing)

Überprüft die Zielverteilung der Zielgruppen auf die Availability Zones (AZs) für Application Load Balancer (ALB), Network Load Balancer (NLB) und Gateway Load Balancer (GWLB).

Diese Prüfung schließt Folgendes aus:

b92b83d667

Stellen Sie für eine bessere Widerstandsfähigkeit sicher, dass Ihre Zielgruppen in allen AZs die gleiche Anzahl von Zielen haben.

Zielgruppen für Ihre Application Load Balancer

Registrieren Sie Ziele bei Ihrer Application Load Balancer-Zielgruppe

Überprüft, ob Ihre Gateway Load Balancer (GWLB) -Endpunkte als Routenziel aus einer anderen Availability Zone (AZ) konfiguriert sind.

Gateway Load Balancer-Endpunkte leiten den Netzwerkverkehr zur Überprüfung an Firewall-Appliances hinter einem Gateway Load Balancer weiter. Jeder Gateway Load Balancer-Endpunkt arbeitet innerhalb einer bestimmten AZ und ist nur in dieser AZ mit Redundanz ausgestattet. Daher müssen alle Ressourcen in einer bestimmten AZ einen Gateway Load Balancer-Endpunkt in derselben AZ verwenden. Dadurch wird sichergestellt, dass sich ein potenzieller Ausfall eines Gateway Load Balancer-Endpunkts oder seiner AZ nicht auf Ihre Ressourcen in einer anderen AZ auswirkt.

528d6f5ee7

Überprüfen Sie die AZ Ihres Subnetzes und konfigurieren Sie die zugehörige Routing-Tabelle so, dass der Datenverkehr über einen Gateway Load Balancer-Endpunkt in derselben AZ weitergeleitet wird.

Wenn es in der AZ keinen Gateway Load Balancer-Endpunkt gibt, erstellen Sie einen neuen und leiten Sie dann Ihren Subnetzdatenverkehr durch ihn.

Wenn Sie dieselbe Routing-Tabelle über Subnetze in verschiedenen AZs hinweg verknüpft haben, verknüpfen Sie diese Routing-Tabelle weiterhin mit den Subnetzen, die sich in derselben AZ wie der Gateway Load Balancer-Endpunkt befinden. Für Subnetze in der anderen AZ können Sie dann eine separate Routing-Tabelle einer Route zu einem Gateway Load Balancer-Endpunkt in dieser AZ zuordnen.

Es hat sich bewährt, ein Wartungsfenster für Architekturänderungen in Ihrer Amazon VPC auszuwählen.

Prüft die Load Balancer-Konfiguration.

Um die Fehlertoleranz in Amazon Elastic Compute Cloud (Amazon EC2) bei der Verwendung von Elastic Load Balancing zu erhöhen, empfehlen wir, eine gleiche Anzahl von Instances über mehrere Availability Zones in einer Region zu betreiben. Ein konfigurierter Load Balancer ist kostenpflichtig, so dass es sich auch hier um eine Kostenoptimierungsprüfung handelt.

iqdCTZKCUp

Stellen Sie sicher, dass Ihr Load Balancer auf aktive und fehlerfreie Instances in mindestens zwei Availability Zones verweist. Weitere Informationen finden Sie unter Hinzufügen von Availability Zones.

Wenn Ihr Load Balancer für eine Availability Zone ohne fehlerfreie Instances konfiguriert ist oder wenn Instances in den Availability Zones ungleich verteilt sind, stellen Sie fest, ob alle Availability Zones erforderlich sind. Lassen Sie unnötige Availability Zones weg und stellen Sie sicher, dass die Instances gleichmäßig über die verbleibenden Availability Zones verteilt sind. Weitere Informationen finden Sie unter Entfernen von Availability Zones.

Überprüft, ob Ihre NAT-Gateways mit Availability Zone (AZ)-Unabhängigkeit konfiguriert sind.

Ein NAT-Gateway ermöglicht es Ressourcen in Ihrem privaten Subnetz, mithilfe der IP-Adressen des NAT-Gateways eine sichere Verbindung zu Services außerhalb des Subnetzes herzustellen, und verwirft jeglichen unaufgeforderten eingehenden Datenverkehr. Jedes NAT-Gateway arbeitet innerhalb einer ausgewiesenen Availability Zone (AZ) und ist nur in dieser AZ mit Redundanz aufgebaut. Daher sollten Ihre Ressourcen in einer bestimmten AZ ein NAT-Gateway in derselben AZ verwenden, damit sich ein potenzieller Ausfall eines NAT-Gateways oder seiner AZ nicht auf Ihre Ressourcen in einer anderen AZ auswirkt.

c1dfptbg10

Überprüfen Sie die AZ Ihres Subnetzes und leiten Sie den Datenverkehr über ein NAT-Gateway in derselben AZ weiter.

Wenn es in der AZ kein NATGW gibt, erstellen Sie eines und leiten Sie dann Ihren Subnetz-Datenverkehr durch dieses weiter.

Wenn Sie dieselbe Routing-Tabelle allen Subnetzen in verschiedenen AZs zugeordnet haben, behalten Sie die Zuordnung dieser Routing-Tabelle zu den Subnetzen bei, die sich in derselben AZ wie das NAT-Gateway befinden. Verknüpfen Sie für Subnetze in der anderen AZ eine separate Routing-Tabelle mit einer Route zu einem NAT-Gateway in dieser anderen AZ.

Wir empfehlen, ein Wartungsfenster für Architekturänderungen in Ihrer Amazon VPC auszuwählen.

Überprüft, ob Ihre AWS Network Firewall Endpunkte als Routenziel aus einer anderen Availability Zone (AZ) konfiguriert sind.

Netzwerk-Firewall-Endpunkte leiten den Netzwerkverkehr zur Überprüfung an eine Netzwerk-Firewall weiter. Jeder Netzwerk-Firewall-Endpunkt arbeitet innerhalb einer bestimmten AZ und ist nur in dieser AZ mit Redundanz ausgestattet. Ihre Ressourcen in einer bestimmten AZ sollten einen Netzwerk-Firewall-Endpunkt in derselben AZ verwenden. Dadurch wird sichergestellt, dass sich ein potenzieller Ausfall eines Netzwerk-Firewall-Endpunkts oder seiner AZ nicht auf Ihre Ressourcen in einer anderen AZ auswirkt. Für Netzwerkverkehr, der zur Überprüfung des Datenverkehrs aus einer anderen AZ stammt, fallen Gebühren für die AZ-übergreifende Datenübertragung an. Es hat sich bewährt, sicherzustellen, dass alle Ressourcen in einer bestimmten AZ eine Netzwerkfirewall in derselben AZ verwenden, um AZ-übergreifende Datengebühren zu vermeiden.

7040ea389a

Überprüfen Sie die AZ Ihres Subnetzes und leiten Sie den Datenverkehr über einen Netzwerk-Firewall-Endpunkt in derselben AZ weiter.

Wenn es in der AZ keinen Netzwerk-Firewall-Endpunkt gibt, erstellen Sie eine neue Netzwerk-Firewall und leiten Sie Ihren Subnetzdatenverkehr durch diese.

Wenn dieselbe Routing-Tabelle mehreren Subnetzen in verschiedenen AZs zugeordnet ist, verknüpfen Sie diese Routing-Tabelle weiterhin mit den Subnetzen, die sich in derselben AZ wie der Netzwerk-Firewall-Endpunkt befinden. Ordnen Sie für Subnetze in anderen AZs eine separate Routing-Tabelle einer Route zu einem Netzwerk-Firewall-Endpunkt in dieser AZ zu.

Es hat sich bewährt, ein Wartungsfenster für Architekturänderungen in Ihrer Amazon VPC auszuwählen.

Datenübertragung innerhalb derselben AWS-Region

Grundlegendes zu den Gebühren für die Datenübertragung

Verfügbarkeit Zone Independence

Allgemeine Schritte zur Implementierung einer Firewall

Eine Firewall erstellen

AWS Well-Architected Tool - Verwenden Sie Bulkhead-Architekturen, um den Umfang der Auswirkungen zu begrenzen

Überprüft, ob Ihre Netzwerk-Firewalls so konfiguriert sind, dass sie mehr als eine Availability Zone (AZ) für Firewall-Endpunkte verwenden.

Eine AZ ist ein eigener Standort, der vor Ausfällen in anderen Zonen geschützt ist. Wenn der Netzwerk-Firewall-Endpunkt nur in einer AZ bereitgestellt wird, kann es sich um eine einzelne Ausfallstelle handeln und Workloads anderer AZs beeinträchtigen, die die Netzwerk-Firewall zur Überprüfung des Datenverkehrs verwenden. Es hat sich bewährt, Ihre Netzwerk-Firewalls in mehreren AZs in derselben Region zu konfigurieren, um die Verfügbarkeit Ihrer Workloads zu verbessern.

c2vlfg0gqd

Stellen Sie sicher, dass Ihre Netzwerk-Firewall mit mindestens zwei AZs für Produktionsworkloads konfiguriert ist.

VPC-Subnetzkonfiguration für AWS Network Firewall

Eine Firewall erstellen

Availability Zone

AWS Well-Architected Tool - Stellen Sie die Arbeitslast an mehreren Standorten bereit

Appliance in einer VPC für gemeinsame Dienste

Prüft, ob zonenübergreifendes Load Balancing in Network Load Balancern aktiviert ist.

Cross-zone Load Balancing hilft dabei, eine gleichmäßige Verteilung des eingehenden Datenverkehrs auf Instances in verschiedenen Availability Zones aufrechtzuerhalten. Dadurch wird verhindert, dass der Load Balancer den gesamten Datenverkehr an Instances in derselben Availability Zone weiterleitet, was zu einer ungleichmäßigen Verteilung des Datenverkehrs und zu einer potenziellen Überlastung führen kann. Die Funktion erhöht auch die Anwendungszuverlässigkeit, weil der Datenverkehr bei einem Ausfall einer einzelnen Availability Zone automatisch an fehlerfreie Instances in anderen Availability Zones weitergeleitet wird.

Weitere Informationen finden Sie unter Cross-zone Load Balancing.

c18d2gz105

AWS Config Managed Rule: nlb-cross-zone-load-balancing-enabled

Stellen Sie sicher, dass zonenübergreifendes Load Balancing in den Network Load Balancern aktiviert ist.

Cross-zone Lastenausgleich (Network Load Balancer)

Prüft, ob ein Network Load Balancer (NLB) mit Internetanschluss mit einem privaten Subnetz konfiguriert ist. Ein Network Load Balancer (NLB) mit Internetanschluss muss in öffentlichen Subnetzen konfiguriert werden, um Datenverkehr empfangen zu können. Ein öffentliches Subnetz ist definiert als ein Subnetz, das eine direkte Route zu einem Internet-Gateway hat. https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Internet_Gateway.html Wenn das Subnetz als privat konfiguriert ist, empfängt die Availability Zone (AZ) keinen Datenverkehr, was zu Verfügbarkeitsproblemen führen kann.

c1dfpnchv4

Rot: NLB ist mit einem oder mehreren privaten Subnetzen konfiguriert

Grün: Für NLB mit Internetzugriff ist kein privates Subnetz konfiguriert

Vergewissern Sie sich, dass die in einem mit dem Internet verbundenen Load Balancer konfigurierten Subnetze öffentlich sind. Ein öffentliches Subnetz ist definiert als ein Subnetz, das eine direkte Route zu einem Internet-Gateway hat. https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Internet_Gateway.html Verwenden Sie eine der folgenden Optionen:

Überprüft, ob Ihre Network Load Balancer so konfiguriert sind, dass sie mehr als eine Availability Zone (AZ) verwenden. Eine Availability Zone ist ein eigenständiger Standort, der vor Ausfällen in anderen Zonen geschützt ist. Konfigurieren Sie Ihren Load Balancer in mehreren AZs in derselben Region, um die Verfügbarkeit Ihrer Workloads zu verbessern.

c1dfprch09

Gelb: NLB befindet sich in einer einzigen AZ.

Grün: NLB hat zwei oder mehr AZs.

Stellen Sie sicher, dass Ihr Load Balancer mit mindestens zwei Availability Zones konfiguriert ist.

Weitere Informationen finden Sie in der folgenden Dokumentation:

Überprüft, ob die Konfiguration eines Incident Manager-Replikationssets mehrere verwendet AWS-Region , um regionales Failover und Reaktion zu unterstützen. Bei Vorfällen, die durch CloudWatch Alarme oder EventBridge Ereignisse verursacht wurden, erstellt der Incident Manager einen Vorfall, der der Alarm- oder Ereignisregel entspricht AWS-Region . Wenn Incident Manager in dieser Region vorübergehend nicht verfügbar ist, versucht das System, einen Vorfall in einer anderen Region im Replikationssatz zu erstellen. Wenn der Replikationssatz nur eine Region umfasst, kann das System keinen Vorfallsdatensatz erstellen, solange Incident Manager nicht verfügbar ist.

cIdfp1js9r

Fügen Sie dem Replikationssatz mindestens eine weitere Region hinzu.

Weitere Informationen finden Sie unter Cross-region Vorfallmanagement.

Überprüft Netzwerkmuster dahingehend, ob Ihr ausgehender Netzwerkdatenverkehr über eine einzelne Availability Zone (AZ) geleitet wird.

Eine Availability Zone ist ein eigenständiger Standort, der vor allen Auswirkungen in anderen Zonen geschützt ist. Indem Sie Ihren Service auf mehrere AZs verteilen, begrenzen Sie den Wirkungsradius eines AZ-Ausfalls.

c1dfptbg11

Wenn Ihre Anwendung Hochverfügbarkeit erfordert, sollten Sie die Implementierung einer Multi-AZ-Architektur für eine höhere Verfügbarkeit in Betracht ziehen.

Überprüft, ob Ihre AWS PrivateLink VPC-Schnittstellenendpunkte so konfiguriert sind, dass sie mehr als eine Availability Zone (AZ) verwenden. Eine Availability Zone ist ein eigenständiger Standort, der vor Ausfällen in anderen Zonen geschützt ist. Dies unterstützt eine kostengünstige Netzwerkkonnektivität mit niedriger Latenz zwischen AZs in derselben Region. AWS Wählen Sie Subnetze in mehreren AZs aus, wenn Sie Schnittstellenendpunkte erstellen, um Ihre Anwendungen vor einem einzigen Ausfall zu schützen.

c1dfprch10

Gelb: Der VPC-Endpunkt befindet sich in einer einzigen AZ.

Grün: Der VPC-Endpunkt befindet sich in mindestens zwei AZs.

Stellen Sie sicher, dass Ihr VPC-Schnittstellenendpunkt mit mindestens zwei Availability Zones konfiguriert ist.

Weitere Informationen finden Sie in der folgenden Dokumentation:

Überprüft die Anzahl der Tunnel, die für jedes Ihrer Site-to-Site VPNs aktiv sind.

In einem VPN sollten immer zwei Tunnel konfiguriert sein. Dies bietet Redundanz im Falle eines Ausfalls oder einer geplanten Wartung der Geräte am AWS Endpunkt. Bei einigen Geräten ist jeweils nur ein Tunnel aktiv. Wenn ein VPN keine aktiven Tunnel hat, können trotzdem Gebühren für das VPN anfallen. Weitere Informationen finden Sie im AWS Site-to-Site VPN-Benutzerhandbuch.

S45wrEXrLz

Stellen Sie sicher, dass zwei Tunnel für Ihre VPN-Verbindung konfiguriert sind und dass beide aktiv sind, wenn Ihre Hardware dies unterstützt. Wenn Sie eine VPN-Verbindung nicht mehr benötigen, können Sie sie löschen, um Kosten zu vermeiden. Weitere Informationen finden Sie unter Ihr Kunden-Gateway-Gerät oder Löschen einer Site-to-Site VPN-Verbindung.

Überprüft, ob Amazon MQ für ActiveMQ-Broker für Hochverfügbarkeit mit einem active/standby Broker in mehreren Availability Zones konfiguriert sind.

c1t3k8mqv1

Erstellen Sie einen neuen Broker mit active/standby Bereitstellungsmodus.

Überprüft, ob Amazon-MQ-for-RabbitMQ-Broker für Hochverfügbarkeit mit Cluster-Instances in mehreren Availability Zones konfiguriert sind.

c1t3k8mqv2

Erstellen Sie einen neuen Broker mit dem Cluster-Bereitstellungsmodus.