Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich. # Referenz zu den Szenarien In der Szenariobibliothek enthaltene Szenarien sind so konzipiert, dass sie nach Möglichkeit [Tags](https://docs.aws.amazon.com/whitepapers/latest/tagging-best-practices/what-are-tags.html) verwenden. Jedes Szenario beschreibt die erforderlichen Tags in den Abschnitten **Voraussetzungen** und **Funktionsweise** der Szenariobeschreibung. Sie können Ihre Ressourcen mit diesen vordefinierten Tags kennzeichnen oder Sie können mithilfe der gemeinsamen Parameterbearbeitung Ihre eigenen Tags festlegen (siehe[Anhand eines Szenarios](scenario-library.md#using-a-scenario)). In dieser Referenz werden die gängigen Szenarien in der AWS FIS-Szenariobibliothek beschrieben. Sie können die unterstützten Szenarien auch mithilfe der AWS FIS-Konsole auflisten. Weitere Informationen finden Sie unter [Arbeiten mit der AWS FIS Szenario-Bibliothek](scenario-library.md). AWS FIS unterstützt die folgenden Amazon EC2-Szenarien. [Diese Szenarien zielen auf Instances ab, die Tags verwenden.](https://docs.aws.amazon.com/whitepapers/latest/tagging-best-practices/what-are-tags.html) Sie können Ihre eigenen Tags oder die im Szenario enthaltenen Standard-Tags verwenden. In einigen dieser Szenarien werden [SSM-Dokumente verwendet](https://docs.aws.amazon.com//fis/latest/userguide/actions-ssm-agent.html). + **EC2-Stress: Instance-Ausfall — Untersuchen** Sie die Auswirkungen eines Instance-Ausfalls, indem Sie eine oder mehrere EC2-Instances stoppen. Ziel-Instances in der aktuellen Region, denen ein bestimmtes Tag zugeordnet ist. In diesem Szenario stoppen wir diese Instances und starten sie am Ende der Aktionsdauer neu, standardmäßig 5 Minuten. + **EC2-Stress: Disk** — Erkunden Sie die Auswirkungen einer erhöhten Festplattenauslastung auf Ihre EC2-basierte Anwendung. In diesem Szenario zielen wir auf EC2-Instances in der aktuellen Region ab, denen ein bestimmtes Tag zugewiesen ist. In diesem Szenario können Sie für die Aktionsdauer eine zunehmende Festplattenauslastung festlegen, die in die Ziel-Instances von EC2 injiziert wird, standardmäßig 5 Minuten für jede Festplattenbelastungsaktion. + **EC2-Stress: CPU** — Erkunden Sie die Auswirkungen einer erhöhten CPU-Auslastung auf Ihre EC2-basierte Anwendung. In diesem Szenario zielen wir auf EC2-Instances in der aktuellen Region ab, denen ein bestimmtes Tag zugewiesen ist. In diesem Szenario können Sie eine zunehmende Menge an CPU-Stress, der auf bestimmte EC2-Instances injiziert wird, für die Aktionsdauer anpassen, standardmäßig 5 Minuten für jede CPU-Belastungsaktion. + **EC2-Stress: Arbeitsspeicher** — Erkunden Sie die Auswirkungen einer erhöhten Speicherauslastung auf Ihre EC2-basierte Anwendung. In diesem Szenario zielen wir auf EC2-Instances in der aktuellen Region ab, denen ein bestimmtes Tag zugewiesen ist. In diesem Szenario können Sie eine zunehmende Menge an Speicherbelastung, die auf gezielte EC2-Instances injiziert wird, für die Aktionsdauer anpassen, standardmäßig 5 Minuten für jede Speicherbelastungsaktion. + **EC2-Stress: Netzwerklatenz** — Erkunden Sie die Auswirkungen einer erhöhten Netzwerklatenz auf Ihre EC2-basierte Anwendung. In diesem Szenario zielen wir auf EC2-Instances in der aktuellen Region ab, denen ein bestimmtes Tag zugewiesen ist. In diesem Szenario können Sie eine zunehmende Menge an Netzwerklatenz, die bestimmten EC2-Instances zugewiesen wird, für die Aktionsdauer anpassen, standardmäßig 5 Minuten für jede Latenzaktion. AWS FIS unterstützt die folgenden Amazon EKS-Szenarien. Diese Szenarien zielen auf EKS-Pods ab, die Labels einer Kubernetes-Anwendung verwenden. Sie können Ihre eigenen Labels oder die im Szenario enthaltenen Standardlabels verwenden. Weitere Informationen zu EKS mit FIS finden Sie unter[EKS-Pod-Aktionen](eks-pod-actions.md). + **EKS-Stress: Pod Delete** — Erkunden Sie die Auswirkungen eines EKS-Pod-Ausfalls, indem Sie einen oder mehrere Pods löschen. In diesem Szenario zielen wir auf Pods in der aktuellen Region ab, die einem Anwendungslabel zugeordnet sind. In diesem Szenario werden wir alle übereinstimmenden Pods beenden. Die Neuerstellung von Pods wird durch die Kubernetes-Konfiguration gesteuert. + **EKS-Stress: CPU** — Erkunden Sie die Auswirkungen einer erhöhten CPU-Auslastung auf Ihre EKS-basierte Anwendung. In diesem Szenario zielen wir auf Pods in der aktuellen Region ab, die einem Anwendungslabel zugeordnet sind. In diesem Szenario können Sie für die Aktionsdauer eine zunehmende Menge an CPU-Belastung, die auf gezielte EKS-Pods injiziert wird, anpassen, standardmäßig 5 Minuten für jede CPU-Stressaktion. + **EKS-Stress: Disk** — Erkunden Sie die Auswirkungen einer erhöhten Festplattenauslastung auf Ihre EKS-basierte Anwendung. In diesem Szenario zielen wir auf Pods in der aktuellen Region ab, die einem Anwendungslabel zugeordnet sind. In diesem Szenario können Sie für die Aktionsdauer eine zunehmende Menge an Festplattenbelastung anpassen, die auf gezielte EKS-Pods injiziert wird, standardmäßig 5 Minuten für jede CPU-Belastungsaktion. + **EKS-Stress: Arbeitsspeicher** — Erkunden Sie die Auswirkungen einer erhöhten Speicherauslastung auf Ihre EKS-basierte Anwendung. In diesem Szenario zielen wir auf Pods in der aktuellen Region ab, die einem Anwendungslabel zugeordnet sind. In diesem Szenario können Sie eine zunehmende Menge an Speicherstress, der auf gezielte EKS-Pods injiziert wird, für die Aktionsdauer anpassen, standardmäßig 5 Minuten für jede Speicherstressaktion. + **EKS-Stress: Netzwerklatenz** — Erkunden Sie die Auswirkungen einer erhöhten Netzwerklatenz auf Ihre EKS-basierte Anwendung. In diesem Szenario zielen wir auf Pods in der aktuellen Region ab, die einem Anwendungslabel zugeordnet sind. In diesem Szenario können Sie eine zunehmende Menge an Netzwerklatenz, die auf gezielte EKS-Pods übertragen wird, für die Aktionsdauer anpassen, standardmäßig 5 Minuten für jede Latenzaktion. AWS FIS unterstützt die folgenden Szenarien für Single-AZ-, Multi-AZ- und Multi-Region-Anwendungen. Diese Szenarien zielen auf mehrere Ressourcentypen ab. + **AZ Availability: Power Interruption**- Injizieren Sie die zu erwartenden Symptome einer vollständigen Stromunterbrechung in einer Availability Zone (AZ). Weitere Informationen zu [AZ Availability: Power Interruption](az-availability-scenario.md). + **AZ: Application Slowdown**- Erhöhen Sie die Latenz zwischen Ressourcen innerhalb einer einzigen Availability Zone (AZ), um eine Anwendung zu verlangsamen. Weitere Informationen zu [AZ: Application Slowdown](az-application-slowdown-scenario.md). + **Cross-AZ: Traffic Slowdown**— Fügen Sie Paketverlust ein, um den Verkehr zwischen Availability Zones () AZs zu unterbrechen und zu verlangsamen. Weitere Informationen zu [Cross-AZ: Traffic Slowdown](cross-az-traffic-slowdown-scenario.md). + **Cross-Region: Connectivity**- Blockieren Sie den Netzwerkverkehr der Anwendung von der Versuchsregion zur Zielregion und unterbrechen Sie die regionsübergreifende Datenreplikation. Erfahren Sie mehr über die Verwendung von[Cross-Region: Connectivity](cross-region-scenario.md). AWS FIS unterstützt die folgenden Szenarien für Amazon EBS-Volumes. Diese Szenarien zielen mithilfe von Tags auf Volumes ab. Sie können Ihre eigenen Tags oder die im Szenario enthaltenen Standardtags verwenden. Die Zielvolumes müssen sich in derselben Availability Zone befinden. Weitere Informationen finden Sie unter [Fehlertests auf Amazon EBS.](https://docs.aws.amazon.com/ebs/latest/userguide/ebs-fis.html) + **EBS: Sustained Latency**— Untersuchen Sie die Auswirkungen anhaltender I/O Latenz auf Ihre Anwendung. In diesem Szenario zielen wir auf Volumes in der aktuellen Availability Zone ab, denen ein bestimmtes Tag zugewiesen ist. In diesem Szenario wird eine konstante Latenz von 500 ms bei 50 Prozent der Lese- und 100 Prozent der Schreibvorgänge für ein Volume erreicht, wobei eine einzige Latenzaktion über einen Zeitraum von 15 Minuten verwendet wird. In diesem Szenario können Sie die Höhe der eingespeisten Latenz, den Prozentsatz der I/O injizierten Latenz und die Dauer der Aktion anpassen. + **EBS: Increasing Latency**— Untersuchen Sie, wie sich die Erhöhung der I/O Latenz auf Ihre Anwendung auswirkt. In diesem Szenario zielen wir auf Volumes in der aktuellen Availability Zone ab, denen ein bestimmtes Tag zugewiesen ist. In diesem Szenario wird bei 10 Prozent der Lese- und 25 Prozent der Schreibvorgänge für ein Volume mit fünf Latenzaktionen über einen Zeitraum von 15 Minuten eine zunehmende Latenz von 50 ms, 200 ms, 700 ms, 1 Sekunde und 15 Sekunden erreicht. In diesem Szenario können Sie für jede Latenzaktion die Menge der injizierten Latenz, den Prozentsatz der I/O injizierten Latenz und die Aktionsdauer anpassen. + **EBS: Intermittent Latency**— Untersuchen Sie die Auswirkungen intermittierender I/O Latenzspitzen auf Ihre Anwendung. In diesem Szenario zielen wir auf Volumes in der aktuellen Availability Zone ab, denen ein bestimmtes Tag zugewiesen ist. In diesem Szenario werden bei 0,1 Prozent der Lese- und I/O Schreibvorgänge für ein Volume drei starke, intermittierende Latenzspitzen von 30 Sekunden, 10 Sekunden und 20 Sekunden ausgelöst. Dabei werden drei Latenzaktionen verwendet, wobei zwischen jedem Anstieg über einen Zeitraum von 15 Minuten Wiederherstellungsintervalle liegen. In diesem Szenario können Sie für jede Latenzaktion den Umfang der injizierten Latenz, den Prozentsatz der I/O injizierten Latenz und die Aktionsdauer anpassen. + **EBS: Decreasing Latency**— Untersuchen Sie die Auswirkungen abnehmender I/O Latenz auf Ihre Anwendung. In diesem Szenario zielen wir auf Volumes in der aktuellen Availability Zone ab, denen ein bestimmtes Tag zugewiesen ist. In diesem Szenario wird bei 10 Prozent der Lese- und Schreibvorgänge für ein Volume eine verringerte Latenz von 20 Sekunden, 5 Sekunden, 900 ms, 300 ms und 40 ms erreicht, wobei fünf Latenzaktionen über einen Zeitraum von 15 Minuten verwendet werden. In diesem Szenario können Sie für jede Latenzaktion den Umfang der zugeführten Latenz, den Prozentsatz der I/O injizierten Latenz und die Aktionsdauer anpassen. # AZ Availability: Power Interruption Sie können das AZ Availability: Power Interruption Szenario verwenden, um die erwarteten Symptome einer vollständigen Stromunterbrechung in einer Availability Zone (AZ) auszulösen. Dieses Szenario kann verwendet werden, um zu demonstrieren, dass Multi-AZ-Anwendungen während einer einzigen, vollständigen AZ-Stromunterbrechung erwartungsgemäß funktionieren. Dazu gehören der Verlust von zonaler Rechenleistung (Amazon EC2, EKS und ECS), keine erneute Skalierung der Rechenleistung in der AZ, Verlust der Subnetzkonnektivität, RDS-Failover, ElastiCache Failover, eingeschränkter Zugriff auf S3 Express One Zone-Verzeichnisbuckets und nicht reagierende EBS-Volumes. Standardmäßig werden Aktionen, für die keine Ziele gefunden wurden, übersprungen. ## Aktionen Zusammen führen die folgenden Aktionen zu vielen der zu erwartenden Symptome einer vollständigen Stromunterbrechung in einer einzigen AZ. AZ-Verfügbarkeit: Die Stromunterbrechung wirkt sich nur auf Dienste aus, bei denen davon ausgegangen wird, dass sie während einer einzigen AZ-Stromunterbrechung beeinträchtigt werden. Standardmäßig werden in diesem Szenario 30 Minuten lang Symptome einer Stromunterbrechung und dann weitere 30 Minuten lang Symptome auftreten, die während der Wiederherstellung auftreten können. ### Stopp-Instanzen Während einer AZ-Stromunterbrechung werden die EC2-Instances in der betroffenen AZ heruntergefahren. Nach der Wiederherstellung der Stromversorgung werden die Instances neu gestartet. AZ Availability: Power Interruptionbeinhaltet [aws:ec2:stop-instances, um alle Instances](https://docs.aws.amazon.com/fis/latest/userguide/fis-actions-reference.html#stop-instances) in der betroffenen AZ für die Dauer der Unterbrechung zu stoppen. Nach Ablauf der Dauer werden die Instanzen neu gestartet. Das Stoppen von EC2-Instances, die von Amazon EKS verwaltet werden, führt dazu, dass abhängige EKS-Pods gelöscht werden. Das Stoppen von EC2-Instances, die von Amazon ECS verwaltet werden, führt dazu, dass abhängige ECS-Aufgaben gestoppt werden. Diese Aktion zielt auf EC2-Instances ab, die in der betroffenen AZ ausgeführt werden. Standardmäßig zielt sie auf Instances ab, deren Tag `AzImpairmentPower` den Wert hat. `StopInstances` Sie können dieses Tag zu Ihren Instanzen hinzufügen oder das Standard-Tag in der Experimentvorlage durch Ihr eigenes Tag ersetzen. Wenn keine gültigen Instanzen gefunden werden, wird diese Aktion standardmäßig übersprungen. ### Stop-ASG-Instanzen Während einer AZ-Stromunterbrechung werden EC2-Instances, die von einer Auto Scaling Scaling-Gruppe in der betroffenen AZ verwaltet werden, heruntergefahren. Nach der Wiederherstellung der Stromversorgung werden die Instances neu gestartet. AZ Availability: Power Interruptionbeinhaltet [aws:ec2:stop-instances, um alle Instances](https://docs.aws.amazon.com/fis/latest/userguide/fis-actions-reference.html#stop-instances), einschließlich der von Auto Scaling verwalteten, in der betroffenen AZ für die Dauer der Unterbrechung zu stoppen. Nach Ablauf der Dauer werden die Instances neu gestartet. Diese Aktion zielt auf EC2-Instances ab, die in der betroffenen AZ ausgeführt werden. Standardmäßig zielt sie auf Instances ab, deren Tag `AzImpairmentPower` den Wert hat. `IceAsg` Sie können dieses Tag zu Ihren Instanzen hinzufügen oder das Standard-Tag in der Experimentvorlage durch Ihr eigenes Tag ersetzen. Wenn keine gültigen Instanzen gefunden werden, wird diese Aktion standardmäßig übersprungen. ### Instanzstarts pausieren Während einer AZ-Stromunterbrechung schlagen EC2-API-Aufrufe zur Bereitstellung von Kapazität in der AZ fehl. Insbesondere APIs wird Folgendes betroffen sein: `ec2:StartInstances``ec2:CreateFleet`, und. `ec2:RunInstances` AZ Availability: Power Interruption includesbeinhaltet [aws:ec2: api-insufficient-instance-capacity -error](https://docs.aws.amazon.com/fis/latest/userguide/fis-actions-reference.html#api-ice), um zu verhindern, dass neue Instanzen in der betroffenen AZ bereitgestellt werden. Diese Aktion zielt auf IAM-Rollen ab, die zur Bereitstellung von Instanzen verwendet werden. Diese müssen mit einem ARN gezielt werden. Wenn keine gültigen IAM-Rollen gefunden werden, wird diese Aktion standardmäßig übersprungen. ### Unterbrechen Sie die ASG-Skalierung Während einer AZ-Stromunterbrechung schlagen EC2-API-Aufrufe der Auto Scaling-Steuerebene zur Wiederherstellung verlorener Kapazität in der AZ fehl. Insbesondere APIs wird Folgendes betroffen sein: `ec2:StartInstances``ec2:CreateFleet`, und. `ec2:RunInstances` AZ Availability: Power Interruptionbeinhaltet [aws:ec2: asg-insufficient-instance-capacity -error](https://docs.aws.amazon.com/fis/latest/userguide/fis-actions-reference.html#asg-ice), um zu verhindern, dass neue Instanzen in der betroffenen AZ bereitgestellt werden. Dadurch wird auch verhindert, dass Amazon EKS und Amazon ECS in der betroffenen AZ skaliert werden. Diese Aktion zielt auf Auto Scaling Scaling-Gruppen ab. Standardmäßig zielt es auf Auto Scaling Scaling-Gruppen ab, `AzImpairmentPower` deren Tag den Wert hat`IceAsg`. Sie können dieses Tag zu Ihren Auto Scaling Scaling-Gruppen hinzufügen oder das Standard-Tag in der Experimentvorlage durch Ihr eigenes Tag ersetzen. Wenn keine gültigen Auto Scaling Scaling-Gruppen gefunden werden, wird diese Aktion standardmäßig übersprungen. ### Netzwerkkonnektivität unterbrechen Während einer Stromunterbrechung ist das Netzwerk in der AZ nicht verfügbar. In diesem Fall kann es bei einigen AWS-Services bis zu ein paar Minuten dauern, bis das DNS aktualisiert wird, um widerzuspiegeln, dass private Endpunkte in der betroffenen AZ nicht verfügbar sind. Während dieser Zeit können DNS-Abfragen IP-Adressen zurückgeben, auf die nicht zugegriffen werden kann. AZ Availability: Power Interruptionbeinhaltet [aws:network:disrupt-connectivity, um die gesamte Netzwerkkonnektivität](https://docs.aws.amazon.com/fis/latest/userguide/fis-actions-reference.html#network-actions-reference) für alle Subnetze in der betroffenen AZ für 2 Minuten zu blockieren. Dadurch werden Timeouts und DNS-Aktualisierungen für die meisten Anwendungen erzwungen. Wenn die Aktion nach 2 Minuten beendet wird, kann das DNS des regionalen Dienstes anschließend wiederhergestellt werden, solange die AZ weiterhin nicht verfügbar ist. Diese Aktion zielt auf Subnetze ab. Standardmäßig zielt sie auf Cluster ab, deren Tag `AzImpairmentPower` den Wert hat. `DisruptSubnet` Sie können dieses Tag zu Ihren Subnetzen hinzufügen oder das Standard-Tag in der Experimentvorlage durch Ihr eigenes Tag ersetzen. Wenn keine gültigen Subnetze gefunden werden, wird diese Aktion standardmäßig übersprungen. ### Failover RDS Während einer AZ-Stromunterbrechung werden die RDS-Knoten in der betroffenen AZ heruntergefahren. Einzelne AZ-RDS-Knoten in der betroffenen AZ werden vollständig nicht verfügbar sein. Bei Multi-AZ-Clustern führt der Writer-Knoten ein Failover in eine nicht betroffene AZ durch und Leseknoten in der betroffenen AZ sind nicht verfügbar. Bei Multi-AZ-Clustern AZ Availability: Power Interruption umfasst dies [aws:rds:](https://docs.aws.amazon.com/fis/latest/userguide/fis-actions-reference.html#failover-db-cluster) für ein Failover, wenn failover-db-cluster sich der Writer in der betroffenen AZ befindet. Diese Aktion zielt auf RDS-Cluster ab. Standardmäßig zielt sie auf Cluster ab, deren Tag `AzImpairmentPower` den Wert hat`DisruptRds`. Sie können dieses Tag zu Ihren Clustern hinzufügen oder das Standard-Tag in der Experimentvorlage durch Ihr eigenes Tag ersetzen. Wenn keine gültigen Cluster gefunden werden, wird diese Aktion standardmäßig übersprungen. ### ElastiCache Replizierungsgruppe anhalten Während einer AZ-Stromunterbrechung sind die ElastiCache Knoten in der AZ nicht verfügbar. AZ Availability: Power Interruptionbeinhaltet [aws:elasticache:](https://docs.aws.amazon.com/fis/latest/userguide/fis-actions-reference.html#interrupt-elasticache), replicationgroup-interrupt-az-power um ElastiCache Knoten in der betroffenen AZ zu beenden. Für die Dauer der Unterbrechung werden keine neuen Instances in der betroffenen AZ bereitgestellt, sodass die Kapazität der Replikationsgruppe weiterhin reduziert bleibt. Diese Aktion zielt auf ElastiCache Replikationsgruppen ab. Standardmäßig zielt sie auf Replikationsgruppen ab, `AzImpairmentPower` deren Tag den Wert hat`ElasticacheImpact`. Sie können dieses Tag zu Ihren Replikationsgruppen hinzufügen oder das Standard-Tag in der Experimentvorlage durch Ihr eigenes Tag ersetzen. Wenn keine gültigen Replikationsgruppen gefunden werden, wird diese Aktion standardmäßig übersprungen. Beachten Sie, dass nur Replikationsgruppen mit Knoten in der betroffenen AZ als gültige Ziele betrachtet werden. ### Starten Sie ARC Zonal Autoshift Fünf Minuten nach Beginn der AZ-Stromunterbrechung verlagert die Wiederherstellungsaktion den Ressourcenverkehr für die verbleibenden 25 Minuten der Stromunterbrechung `aws:arc:start-zonal-autoshift` automatisch von der angegebenen AZ weg. Nach Ablauf dieser Dauer wird der Verkehr wieder auf die ursprüngliche AZ umgestellt. Beachten Sie, dass bei einer realen AZ-Stromunterbrechung die Beeinträchtigung erkannt und der Ressourcenverkehr verlagert AWS wird, sofern Autoshift aktiviert ist. Der Zeitpunkt dieser Schicht ist zwar unterschiedlich, es wird jedoch geschätzt, dass sie fünf Minuten nach Beginn der Beeinträchtigung eintritt. Diese Aktion zielt auf Autoshift-fähige Ressourcen des Amazon Application Recovery Controller (ARC) ab. Standardmäßig zielt sie auf Ressourcen mit dem Tag key `AzImpairmentPower` und value ab. `RecoverAutoshiftResources` Sie können dieses Tag zu Ihren Ressourcen hinzufügen oder das Standard-Tag in der Experimentvorlage durch Ihr eigenes Tag ersetzen. Möglicherweise möchten Sie beispielsweise ein anwendungsspezifisches Tag verwenden. Wenn keine gültigen Ressourcen gefunden werden, wird diese Aktion standardmäßig übersprungen. ### EBS-I/O anhalten Nach einer AZ-Stromunterbrechung kann es bei einem sehr kleinen Prozentsatz der Instances vorkommen, dass EBS-Volumes nicht mehr reagieren, sobald die Stromversorgung wiederhergestellt ist. AZ Availability: Power Interruptionbeinhaltet [aws:ebs:pause-io](https://docs.aws.amazon.com/fis/latest/userguide/fis-actions-reference.html#ebs-actions-reference), sodass ein EBS-Volume nicht mehr reagiert. Standardmäßig werden nur Volumes als Ziel ausgewählt, die so eingestellt sind, dass sie auch nach dem Beenden der Instance bestehen bleiben. Diese Aktion zielt auf Volumes ab, `AzImpairmentPower` deren Tag den Wert hat. `APIPauseVolume` Sie können dieses Tag zu Ihren Bänden hinzufügen oder das Standard-Tag in der Experimentvorlage durch Ihr eigenes Tag ersetzen. Wenn keine gültigen Volumen gefunden werden, wird diese Aktion standardmäßig übersprungen. ### Unterbrechen Sie die Konnektivität zu S3 Express One Zone-Verzeichnis-Buckets Während einer AZ-Stromunterbrechung ist kein Zugriff auf Daten möglich, die in den S3 Express One Zone-Verzeichnisbuckets in der AZ gespeichert sind. AZ-Verfügbarkeit: Die Stromunterbrechung umfasst [aws:network:disrupt-connectivity, um die Konnektivität](https://docs.aws.amazon.com/fis/latest/userguide/fis-actions-reference.html#network-actions-reference) zwischen Subnetzen und One Zone-Verzeichnis-Buckets in der betroffenen AZ für die Dauer des Experiments zu unterbrechen, was zu Timeouts bei API-Vorgängen auf der Datenebene auf zonaler Endpunkt-Datenebene führt. Verwenden Sie diese Aktion, um Störungen zu testen, wenn Rechenleistung und Speicher in einer AZ gemeinsam genutzt werden. Diese Aktion zielt auf Subnetze ab. Standardmäßig zielt sie auf Subnetze ab, deren Tag `AzImpairmentPower` den Wert hat. `DisruptSubnet` Sie können dieses Tag zu Ihren Subnetzen hinzufügen oder das Standard-Tag in der Experimentvorlage durch Ihr eigenes Tag ersetzen. Wenn keine gültigen Subnetze gefunden werden, wird diese Aktion standardmäßig übersprungen. ## Einschränkungen + Dieses Szenario beinhaltet keine [Stoppbedingungen](https://docs.aws.amazon.com/fis/latest/userguide/stop-conditions.html). Die richtigen Stoppbedingungen für Ihre Anwendung sollten der Versuchsvorlage hinzugefügt werden. + In der Ziel-AZ werden Amazon EKS-Pods, die auf EC2 laufen, mit EC2-Worker-Knoten beendet und das Starten neuer EC2-Knoten wird blockiert. Amazon EKS-Pods, die auf AWS Fargate ausgeführt werden, werden jedoch nicht unterstützt. + In der Ziel-AZ werden Amazon ECS-Aufgaben, die auf EC2 ausgeführt werden, mit EC2-Worker-Knoten beendet und das Starten neuer EC2-Knoten wird blockiert. Amazon ECS-Aufgaben, die auf AWS Fargate ausgeführt werden, werden jedoch nicht unterstützt. + [Amazon RDS Multi-AZ](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/multi-az-db-clusters-concepts.html#multi-az-db-clusters-migrating-to-with-read-replica) mit zwei lesbaren Standby-DB-Instances wird nicht unterstützt. In diesem Fall werden die Instances beendet, ein RDS-Failover durchgeführt und die Kapazität wird sofort wieder in der betroffenen AZ bereitgestellt. Der lesbare Standby-Modus in der betroffenen AZ bleibt verfügbar. ## Voraussetzungen + Fügen Sie der AWS FIS [Experimentrolle](https://docs.aws.amazon.com/fis/latest/userguide/getting-started-iam-service-role.html) die erforderliche Berechtigung hinzu. + Ressourcen-Tags müssen auf Ressourcen angewendet werden, auf die das Experiment abzielen soll. Diese können Ihre eigene Tagging-Konvention oder die im Szenario definierten Standard-Tags verwenden. ## Berechtigungen ARC Zonal Autoshift verwendet eine mit dem IAM-Dienst verknüpfte Rolle, `AWSServiceRoleForZonalAutoshiftPracticeRun` um Zonal Shift in Ihrem Namen durchzuführen. Diese Rolle verwendet die von IAM verwaltete Richtlinie. [https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSZonalAutoshiftPracticeRunSLRPolicy.html](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSZonalAutoshiftPracticeRunSLRPolicy.html) Sie müssen die Rolle nicht manuell erstellen. Wenn Sie eine Versuchsvorlage aus dem Szenario AZ Power Interruption im AWS-Managementkonsole, dem oder einem AWS SDK erstellen AWS CLI, erstellt ARC die serviceverknüpfte Rolle für Sie. Weitere Informationen finden Sie unter [Verwenden der serviceverknüpften Rolle für zonales Autoshift](https://docs.aws.amazon.com/r53recovery/latest/dg/using-service-linked-roles-zonal-autoshift.html) in ARC. Die folgende Richtlinie gewährt AWS FIS die erforderlichen Berechtigungen, um ein Experiment mit dem AZ Availability: Power Interruption Szenario durchzuführen. Diese Richtlinie muss der [Rolle des Experiments](https://docs.aws.amazon.com/fis/latest/userguide/getting-started-iam-service-role.html) zugeordnet werden. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "AllowFISExperimentLoggingActionsCloudwatch", "Effect": "Allow", "Action": [ "logs:CreateLogDelivery", "logs:PutResourcePolicy", "logs:DescribeResourcePolicies", "logs:DescribeLogGroups" ], "Resource": "*" }, { "Effect": "Allow", "Action": "ec2:CreateTags", "Resource": "arn:aws:ec2:*:*:network-acl/*", "Condition": { "StringEquals": { "ec2:CreateAction": "CreateNetworkAcl", "aws:RequestTag/managedByFIS": "true" } } }, { "Effect": "Allow", "Action": "ec2:CreateNetworkAcl", "Resource": "arn:aws:ec2:*:*:network-acl/*", "Condition": { "StringEquals": { "aws:RequestTag/managedByFIS": "true" } } }, { "Effect": "Allow", "Action": [ "ec2:CreateNetworkAclEntry", "ec2:DeleteNetworkAcl" ], "Resource": [ "arn:aws:ec2:*:*:network-acl/*", "arn:aws:ec2:*:*:vpc/*" ], "Condition": { "StringEquals": { "ec2:ResourceTag/managedByFIS": "true" } } }, { "Effect": "Allow", "Action": "ec2:CreateNetworkAcl", "Resource": "arn:aws:ec2:*:*:vpc/*" }, { "Effect": "Allow", "Action": [ "ec2:DescribeVpcs", "ec2:DescribeManagedPrefixLists", "ec2:DescribeSubnets", "ec2:DescribeNetworkAcls" ], "Resource": "*" }, { "Effect": "Allow", "Action": "ec2:ReplaceNetworkAclAssociation", "Resource": [ "arn:aws:ec2:*:*:subnet/*", "arn:aws:ec2:*:*:network-acl/*" ] }, { "Effect": "Allow", "Action": [ "rds:FailoverDBCluster" ], "Resource": [ "arn:aws:rds:*:*:cluster:*" ] }, { "Effect": "Allow", "Action": [ "rds:RebootDBInstance" ], "Resource": [ "arn:aws:rds:*:*:db:*" ] }, { "Effect": "Allow", "Action": [ "elasticache:DescribeReplicationGroups", "elasticache:InterruptClusterAzPower" ], "Resource": [ "arn:aws:elasticache:*:*:replicationgroup:*" ] }, { "Sid": "TargetResolutionByTags", "Effect": "Allow", "Action": [ "tag:GetResources" ], "Resource": "*" }, { "Effect": "Allow", "Action": [ "ec2:StartInstances", "ec2:StopInstances" ], "Resource": "arn:aws:ec2:*:*:instance/*" }, { "Effect": "Allow", "Action": [ "ec2:DescribeInstances" ], "Resource": "*" }, { "Effect": "Allow", "Action": [ "kms:CreateGrant" ], "Resource": [ "arn:aws:kms:*:*:key/*" ], "Condition": { "StringLike": { "kms:ViaService": "ec2.*.amazonaws.com" }, "Bool": { "kms:GrantIsForAWSResource": "true" } } }, { "Effect": "Allow", "Action": [ "ec2:DescribeVolumes" ], "Resource": "*" }, { "Effect": "Allow", "Action": [ "ec2:PauseVolumeIO" ], "Resource": "arn:aws:ec2:*:*:volume/*" }, { "Sid": "AllowInjectAPI", "Effect": "Allow", "Action": [ "ec2:InjectApiError" ], "Resource": [ "*" ], "Condition": { "ForAnyValue:StringEquals": { "ec2:FisActionId": [ "aws:ec2:api-insufficient-instance-capacity-error", "aws:ec2:asg-insufficient-instance-capacity-error" ] } } }, { "Sid": "DescribeAsg", "Effect": "Allow", "Action": [ "autoscaling:DescribeAutoScalingGroups" ], "Resource": [ "*" ] } ] } ``` ------ ## Inhalt des Szenarios Der folgende Inhalt definiert das Szenario. Diese JSON-Datei kann gespeichert und verwendet werden, um mithilfe des [create-experiment-template](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/fis/create-experiment-template.html)Befehls von der AWS-Befehlszeilenschnittstelle (AWS CLI) eine [Versuchsvorlage](https://docs.aws.amazon.com/fis/latest/userguide/experiment-templates.html) zu erstellen. Die neueste Version des Szenarios finden Sie in der Szenariobibliothek in der FIS-Konsole. ``` { "targets": { "IAM-role": { "resourceType": "aws:iam:role", "resourceArns": [], "selectionMode": "ALL" }, "EBS-Volumes": { "resourceType": "aws:ec2:ebs-volume", "resourceTags": { "AzImpairmentPower": "ApiPauseVolume" }, "selectionMode": "COUNT(1)", "parameters": { "availabilityZoneIdentifier": "us-east-1a" }, "filters": [ { "path": "Attachments.DeleteOnTermination", "values": [ "false" ] } ] }, "EC2-Instances": { "resourceType": "aws:ec2:instance", "resourceTags": { "AzImpairmentPower": "StopInstances" }, "filters": [ { "path": "State.Name", "values": [ "running" ] }, { "path": "Placement.AvailabilityZone", "values": [ "us-east-1a" ] } ], "selectionMode": "ALL" }, "ASG": { "resourceType": "aws:ec2:autoscaling-group", "resourceTags": { "AzImpairmentPower": "IceAsg" }, "selectionMode": "ALL" }, "ASG-EC2-Instances": { "resourceType": "aws:ec2:instance", "resourceTags": { "AzImpairmentPower": "IceAsg" }, "filters": [ { "path": "State.Name", "values": [ "running" ] }, { "path": "Placement.AvailabilityZone", "values": [ "us-east-1a" ] } ], "selectionMode": "ALL" }, "Subnet": { "resourceType": "aws:ec2:subnet", "resourceTags": { "AzImpairmentPower": "DisruptSubnet" }, "filters": [ { "path": "AvailabilityZone", "values": [ "us-east-1a" ] } ], "selectionMode": "ALL", "parameters": {} }, "RDS-Cluster": { "resourceType": "aws:rds:cluster", "resourceTags": { "AzImpairmentPower": "DisruptRds" }, "selectionMode": "ALL", "parameters": { "writerAvailabilityZoneIdentifiers": "us-east-1a" } }, "ElastiCache-Cluster": { "resourceType": "aws:elasticache:replicationgroup", "resourceTags": { "AzImpairmentPower": "DisruptElasticache" }, "selectionMode": "ALL", "parameters": { "availabilityZoneIdentifier": "us-east-1a" } } }, "actions": { "Pause-Instance-Launches": { "actionId": "aws:ec2:api-insufficient-instance-capacity-error", "parameters": { "availabilityZoneIdentifiers": "us-east-1a", "duration": "PT30M", "percentage": "100" }, "targets": { "Roles": "IAM-role" } }, "Pause-EBS-IO": { "actionId": "aws:ebs:pause-volume-io", "parameters": { "duration": "PT30M" }, "targets": { "Volumes": "EBS-Volumes" }, "startAfter": [ "Stop-Instances", "Stop-ASG-Instances" ] }, "Stop-Instances": { "actionId": "aws:ec2:stop-instances", "parameters": { "completeIfInstancesTerminated": "true", "startInstancesAfterDuration": "PT30M" }, "targets": { "Instances": "EC2-Instances" } }, "Pause-ASG-Scaling": { "actionId": "aws:ec2:asg-insufficient-instance-capacity-error", "parameters": { "availabilityZoneIdentifiers": "us-east-1a", "duration": "PT30M", "percentage": "100" }, "targets": { "AutoScalingGroups": "ASG" } }, "Stop-ASG-Instances": { "actionId": "aws:ec2:stop-instances", "parameters": { "completeIfInstancesTerminated": "true", "startInstancesAfterDuration": "PT30M" }, "targets": { "Instances": "ASG-EC2-Instances" } }, "Pause-network-connectivity": { "actionId": "aws:network:disrupt-connectivity", "parameters": { "duration": "PT2M", "scope": "all" }, "targets": { "Subnets": "Subnet" } }, "Failover-RDS": { "actionId": "aws:rds:failover-db-cluster", "parameters": {}, "targets": { "Clusters": "RDS-Cluster" } }, "Pause-ElastiCache": { "actionId": "aws:elasticache:replicationgroup-interrupt-az-power", "parameters": { "duration": "PT30M" }, "targets": { "ReplicationGroups": "ElastiCache-Cluster" } } }, "stopConditions": [ { "source": "aws:cloudwatch:alarm", "value": "" } ], "roleArn": "", "tags": { "Name": "AZ Impairment: Power Interruption" }, "logConfiguration": { "logSchemaVersion": 2 }, "experimentOptions": { "accountTargeting": "single-account", "emptyTargetResolutionMode": "skip" }, "description": "Affect multiple resource types in a single AZ, targeting by tags and explicit ARNs, to approximate power interruption in one AZ." } ``` # AZ: Application Slowdown Sie können das Szenario AZ: Application Slowdown verwenden, um zusätzliche Latenz zwischen Ressourcen innerhalb einer einzigen Availability Zone (AZ) einzuführen. Diese Latenz führt zu vielen Symptomen einer Anwendungsverlangsamung, einer teilweisen Unterbrechung, die manchmal auch als grauer Ausfall bezeichnet wird. Sie erhöht die Latenz der Netzwerkflüsse zwischen den Zielressourcen. Netzwerkflüsse stellen den Verkehr zwischen Rechenressourcen dar — Datenpakete, die Anfragen, Antworten und andere Kommunikationswege zwischen Ihren Servern, Containern und Diensten übertragen. Das Szenario kann dabei helfen, Beobachtbarkeitseinstellungen zu validieren, Alarmschwellenwerte zu optimieren, die Empfindlichkeit von Anwendungen gegenüber Verlangsamungen zu ermitteln und wichtige betriebliche Entscheidungen wie die Evakuierung von AZ zu treffen. Standardmäßig erhöht das Szenario für eine Dauer von 30 Minuten eine Latenz von 200 ms auf 100% der Netzwerkflüsse zwischen Zielressourcen innerhalb der ausgewählten AZ. Sie können das Dialogfeld **Gemeinsame Parameter bearbeiten** in der AWS FIS-Konsole verwenden, um die folgenden Parameter auf Szenarioebene anzupassen, die dann für die zugrunde liegenden Aktionen gelten: + Availability Zone — Sie können die AZ auswählen, die im Szenario beeinträchtigt werden soll. + Latenz in Millisekunden (ms) — passen Sie diese an die Empfindlichkeit und die Bedürfnisse Ihrer Anwendung an. Sie können die Latenz für empfindlichere Anwendungen niedriger oder höher einstellen, um beispielsweise die Behandlung von Timeouts zu testen. Erwägen Sie, ein Vielfaches Ihrer aktuellen Anwendungslatenz als Ausgangswert zu verwenden. + Prozentsatz der Datenflüsse — reduzieren Sie, um einen Teil des Datenverkehrs zu beeinträchtigen. Für noch subtilere Tests können Sie beispielsweise eine Latenz von 200 ms hinzufügen, was 25% der Netzwerkflüsse betrifft. + Dauer — legen Sie fest, wie lange das Experiment läuft. Sie können die Dauer für schnellere Tests verkürzen oder längere Dauertests ausführen. Legen Sie die Dauer beispielsweise auf 2 Stunden fest, um Ihre Wiederherstellungsmechanismen unter eingeschränkten Bedingungen zu testen. + Ressourcenausrichtung — Sie können Zielressourcen für das Gesamtszenario mithilfe von Tags (für EC2-Instances oder ECS-Aufgaben auf EC2 oder Fargate) oder Labels (für EKS-Pods auf EC2) definieren. Sie können Ihre eigenen Tags und Labels angeben oder die im Szenario bereitgestellten Standardwerte verwenden. Wenn Sie keine Tags oder Labels verwenden möchten, können Sie die Aktion so bearbeiten, dass sie auf Ressourcen abzielt, indem Sie andere Parameter angeben. + Anpassung — Wenn Sie nicht auf EC2- oder ECS-Ressourcen abzielen möchten, können Sie die Aktionen mit Standard-Tags belassen. Im Experiment werden keine Ressourcen gefunden, auf die Sie abzielen könnten, und die Aktion wird übersprungen. Wenn Sie jedoch nicht auf EKS-Ressourcen abzielen möchten, sollten Sie die EKS-Aktion und das EKS-Ziel vollständig aus dem Szenario entfernen, da dafür eine EKS-Cluster-ID angegeben werden muss. Für eine noch detailliertere Anpassung können Sie einzelne Aktionen direkt in der Experimentvorlage ändern. ## Aktionen Zusammengenommen tragen die folgenden Aktionen dazu bei, viele der Symptome einer Anwendungsverlangsamung in einer einzigen AZ hervorzurufen, indem sie zu zusätzlicher Latenz bei den Netzwerkabläufen führen, die sich dann in der gesamten Anwendung ausbreiten. Diese Aktionen werden parallel ausgeführt, wobei jeweils standardmäßig eine Latenz von 200 ms für 30 Minuten hinzugefügt wird. Nach diesem Zeitraum kehrt die Latenz auf ein normales Niveau zurück. Für die Ausführung des Szenarios ist mindestens einer der folgenden Ressourcentypen erforderlich: EC2-Instance, ECS-Task oder EKS-Pod. ### ECS-Netzwerklatenz AZ: Application Slowdown beinhaltet [aws:ecs:](https://docs.aws.amazon.com/fis/latest/userguide/fis-actions-reference.html#task-network-latency), task-network-latency um Latenz für ECS-Aufgaben einzuführen. Die Aktion zielt auf Aufgaben in der ausgewählten AZ ab. Standardmäßig zielt sie auf Aufgaben ab, [deren Tag](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs-using-tags.html) `AZApplicationSlowdown` den Wert hat`LatencyForECS`. Sie können das Standard-Tag durch Ihr eigenes ersetzen oder das Szenario-Tag zu Ihren Aufgaben hinzufügen. Wenn keine gültigen Aufgaben gefunden werden, wird diese Aktion übersprungen. Bevor Sie ein Experiment auf ECS durchführen, sollten Sie die [Einrichtungsschritte für ECS-Aufgabenaktionen](https://docs.aws.amazon.com/fis/latest/userguide/ecs-task-actions.html) befolgen. ### EKS-Netzwerklatenz AZ: Application Slowdown beinhaltet [aws:eks:](https://docs.aws.amazon.com/fis/latest/userguide/fis-actions-reference.html#pod-network-latency), pod-network-latency um Latenz für EKS-Pods einzuführen. Die Aktion zielt auf Pods in der ausgewählten AZ ab. Standardmäßig zielt sie auf Pods innerhalb eines Clusters ab, die Labels im Format key=value haben. Das bereitgestellte Standardlabel ist. `AZApplicationSlowdown=LatencyForEKS` Sie können das Standardlabel durch Ihr eigenes ersetzen oder dieses Label zu Ihren Pods hinzufügen. Wenn keine gültigen Pods gefunden werden, wird diese Aktion übersprungen. Bevor Sie ein Experiment mit EKS durchführen, sollten Sie die [Einrichtungsschritte für EKS-Pod-Aktionen](https://docs.aws.amazon.com/fis/latest/userguide/eks-pod-actions.html) befolgen. ### EC2-Netzwerklatenz [AZ: Application Slowdown verwendet die Aktion [aws:ssm:send-command](https://docs.aws.amazon.com/fis/latest/userguide/fis-actions-reference.html#ssm-send-command), um das Dokument -Network-Latency-SOURCES auszuführen, um Latenz für EC2-Instances einzuführenAWSFIS-Run.](https://docs.aws.amazon.com/fis/latest/userguide/actions-ssm-agent.html#awsfis-run-network-latency-sources) Die Aktion zielt auf Instances in der ausgewählten AZ ab. Standardmäßig zielt sie auf Instances ab, `AZApplicationSlowdown` deren [Tag](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html) den Wert hat`LatencyForEC2`. Sie können das Standard-Tag durch Ihr eigenes ersetzen oder dieses Tag zu Ihren Instances hinzufügen. Wenn keine gültigen Instanzen gefunden werden, wird diese Aktion übersprungen. Bevor Sie mit SSM ein Experiment auf EC2 ausführen, sollten Sie [den AWS Systems Manager Manager-Agenten konfigurieren](https://docs.aws.amazon.com/fis/latest/userguide/actions-ssm-agent.html). ## Einschränkungen + Dieses Szenario beinhaltet keine [Stoppbedingungen](https://docs.aws.amazon.com/fis/latest/userguide/stop-conditions.html). Die richtigen Stoppbedingungen für Ihre Anwendung sollten der Versuchsvorlage hinzugefügt werden. ## Voraussetzungen + Fügen Sie der AWS [FIS-Experimentrolle](https://docs.aws.amazon.com/fis/latest/userguide/getting-started-iam-service-role.html) die erforderlichen Berechtigungen hinzu. + Sie müssen innerhalb der ausgewählten AZ auf eine oder mehrere Ressourcen aus einem der folgenden drei Typen abzielen: EC2-Instances, ECS-Aufgaben oder EKS-Pods. + Alle Ziele des Szenarios müssen sich in derselben VPC befinden. ## Berechtigungen Um dieses Szenario auszuführen, benötigen Sie eine IAM-Rolle mit einer Vertrauensrichtlinie, die es FIS ermöglicht, die Rolle und die verwalteten Richtlinien für die Ressourcentypen zu übernehmen, auf die Sie im Experiment abzielen: EC2, ECS und EKS. Wenn Sie eine Versuchsvorlage aus dem Szenario AZ: Application Slowdown erstellen, erstellt FIS die Rolle für Sie mit der Vertrauensrichtlinie und den folgenden von AWS verwalteten Richtlinien: + [AWSFaultInjectionSimulatorEC2Access](https://docs.aws.amazon.com/fis/latest/userguide/security-iam-awsmanpol.html#AWSFaultInjectionSimulatorEC2Access) + [AWSFaultInjectionSimulatorECSAccess](https://docs.aws.amazon.com/fis/latest/userguide/security-iam-awsmanpol.html#AWSFaultInjectionSimulatorECSAccess) + [AWSFaultInjectionSimulatorEKSAccess](https://docs.aws.amazon.com/fis/latest/userguide/security-iam-awsmanpol.html#AWSFaultInjectionSimulatorEKSAccess) Wenn Sie eine bestehende [IAM-Rolle](https://docs.aws.amazon.com/fis/latest/userguide/getting-started-iam-service-role.html) verwenden, um das AZ: Application Slowdown-Szenario auszuführen, können Sie die folgende Richtlinie anhängen, um AWS FIS die erforderlichen Berechtigungen zu gewähren: ``` { "Version": "2012-10-17", "Statement": [ { "Sid": "DescribeTasks", "Effect": "Allow", "Action": "ecs:DescribeTasks", "Resource": "*" }, { "Sid": "DescribeContainerInstances", "Effect": "Allow", "Action": "ecs:DescribeContainerInstances", "Resource": "arn:aws:ecs:*:*:container-instance/*/*" }, { "Sid": "DescribeInstances", "Effect": "Allow", "Action": "ec2:DescribeInstances", "Resource": "*" }, { "Sid": "DescribeSubnets", "Effect": "Allow", "Action": "ec2:DescribeSubnets", "Resource": "*" }, { "Sid": "DescribeCluster", "Effect": "Allow", "Action": "eks:DescribeCluster", "Resource": "arn:aws:eks:*:*:cluster/*" }, { "Sid": "TargetResolutionByTags", "Effect": "Allow", "Action": "tag:GetResources", "Resource": "*" }, { "Sid": "SendCommand", "Effect": "Allow", "Action": [ "ssm:SendCommand" ], "Resource": [ "arn:aws:ec2:*:*:instance/*", "arn:aws:ssm:*:*:managed-instance/*", "arn:aws:ssm:*:*:document/*" ] }, { "Sid": "ListCommands", "Effect": "Allow", "Action": [ "ssm:ListCommands" ], "Resource": "*" }, { "Sid": "CancelCommand", "Effect": "Allow", "Action": [ "ssm:CancelCommand" ], "Resource": "*" } ] } ``` ## Inhalt des Szenarios Der folgende Inhalt definiert das Szenario. Diese JSON-Datei kann gespeichert und verwendet werden, um mithilfe des [create-experiment-template](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/fis/create-experiment-template.html)Befehls von der AWS-Befehlszeilenschnittstelle (AWS CLI) eine [Versuchsvorlage](https://docs.aws.amazon.com/fis/latest/userguide/experiment-templates.html) zu erstellen. Die neueste Version des Szenarios finden Sie in der Szenario-Bibliothek in der FIS-Konsole und wechseln Sie zur Registerkarte **Inhalt**. ``` { "tags": { "Name": "AZ: Application Slowdown" }, "description": "Add latency between resources within a single AZ.", "actions": { "LatencyForEKS": { "actionId": "aws:eks:pod-network-latency", "parameters": { "delayMilliseconds": "200", "duration": "PT30M", "flowsPercent": "100", "interface": "DEFAULT", "kubernetesServiceAccount": "fis-service-account", "sources": "us-east-1a" }, "targets": { "Pods": "TargetsForEKS" } }, "LatencyForEC2": { "actionId": "aws:ssm:send-command", "parameters": { "duration": "PT30M", "documentArn": "arn:aws:ssm:us-east-1::document/AWSFIS-Run-Network-Latency-Sources", "documentParameters": "{\"DelayMilliseconds\":\"200\",\"Sources\":\"us-east-1a\",\"Interface\":\"DEFAULT\",\"TrafficType\":\"egress\",\"DurationSeconds\":\"1800\",\"FlowsPercent\":\"100\",\"InstallDependencies\":\"True\"}" }, "targets": { "Instances": "TargetsForEC2" } }, "LatencyForECS": { "actionId": "aws:ecs:task-network-latency", "parameters": { "delayMilliseconds": "200", "duration": "PT30M", "flowsPercent": "100", "installDependencies": "true", "sources": "us-east-1a", "useEcsFaultInjectionEndpoints": "true" }, "targets": { "Tasks": "TargetsForECS" }, "startAfter": [] } }, "targets": { "TargetsForEKS": { "parameters": { "availabilityZoneIdentifier": "us-east-1a", "clusterIdentifier": "", "namespace": "default", "selectorType": "labelSelector", "selectorValue": "AZApplicationSlowdown=LatencyForEKS" }, "resourceType": "aws:eks:pod", "selectionMode": "ALL" }, "TargetsForEC2": { "filters": [ { "path": "Placement.AvailabilityZone", "values": [ "us-east-1a" ] } ], "resourceTags": { "AZApplicationSlowdown": "LatencyForEC2" }, "resourceType": "aws:ec2:instance", "selectionMode": "ALL" }, "TargetsForECS": { "filters": [ { "path": "AvailabilityZone", "values": [ "us-east-1a" ] } ], "resourceTags": { "AZApplicationSlowdown": "LatencyForECS" }, "resourceType": "aws:ecs:task", "selectionMode": "ALL" } }, "experimentOptions": { "accountTargeting": "single-account", "emptyTargetResolutionMode": "skip" }, "stopConditions": [ { "source": "none" } ] } ``` # Cross-AZ: Traffic Slowdown Sie können das Szenario Cross-AZ: Traffic Slowdown verwenden, um den Datenverkehr zwischen Availability Zones () durch Paketverlust zu unterbrechen und zu verlangsamen. AZs Der Paketverlust beeinträchtigt die AZ-übergreifende Kommunikation, was zu einer teilweisen Unterbrechung führt, die manchmal auch als grauer Ausfall bezeichnet wird. Er führt zu Paketverlusten bei Netzwerkströmen zwischen Zielressourcen. Netzwerkflüsse stellen den Verkehr zwischen Rechenressourcen dar — Datenpakete, die Anfragen, Antworten und andere Kommunikationswege zwischen Ihren Servern, Containern und Diensten übertragen. Das Szenario kann dabei helfen, Beobachtbarkeitseinstellungen zu validieren, Alarmschwellenwerte zu optimieren, Anwendungsempfindlichkeiten und Abhängigkeiten bei der AZ-übergreifenden Kommunikation zu ermitteln und wichtige betriebliche Entscheidungen wie die Evakuierung von AZ zu treffen. Standardmäßig führt das Szenario für eine Dauer von 30 Minuten zu einem Paketverlust von 15% bei 100% der ausgehenden Netzwerkflüsse für Zielressourcen aus der ausgewählten AZ. Sie können das Dialogfeld **Gemeinsame Parameter bearbeiten** in der AWS FIS-Konsole verwenden, um die folgenden Parameter auf Szenarioebene anzupassen, die dann für die zugrunde liegenden Aktionen gelten: + Availability Zone — Sie können die AZ auswählen, die beeinträchtigt werden soll, und Paketverluste werden von dieser AZ zur anderen AZs innerhalb der Region übertragen. + Paketverlust — Passen Sie den Paketverlust für Tests auf subtile Unterbrechungen niedriger an, z. B. 5% oder höher, um schwerwiegende Kommunikationsbeeinträchtigungen und Wiederherstellungsmechanismen zu testen, z. B. 50% oder sogar 100%, um die gesamte Konnektivität zu beeinträchtigen. + Prozentsatz der Datenflüsse — reduzieren Sie, um einen Teil des Datenverkehrs zu beeinträchtigen. Für noch subtilere Tests können Sie beispielsweise einen Paketverlust von 15% einbauen, der 25% der Netzwerkflüsse betrifft. + Dauer — legen Sie fest, wie lange das Experiment läuft. Sie können die Dauer für schnellere Tests verkürzen oder längere Dauertests ausführen. Legen Sie die Dauer beispielsweise auf 2 Stunden fest, um die Wiederherstellungsmechanismen unter beeinträchtigten Bedingungen zu testen. + Ressourcenausrichtung — Sie können Zielressourcen für das Gesamtszenario mithilfe von Tags (für EC2-Instances oder ECS-Aufgaben auf EC2 oder Fargate) oder Labels (für EKS-Pods auf EC2) definieren. Sie können Ihre eigenen Tags und Labels angeben oder die im Szenario bereitgestellten Standardwerte verwenden. Wenn Sie keine Tags oder Labels verwenden möchten, können Sie die Aktion so bearbeiten, dass sie auf Ressourcen abzielt, indem Sie andere Parameter angeben. + Anpassung — Wenn Sie nicht auf EC2- oder ECS-Ressourcen abzielen möchten, können Sie die Aktionen mit Standard-Tags belassen. Im Experiment werden keine Ressourcen gefunden, auf die Sie abzielen könnten, und die Aktion wird übersprungen. Wenn Sie jedoch nicht auf EKS-Ressourcen abzielen möchten, sollten Sie die EKS-Aktion und das EKS-Ziel vollständig aus dem Szenario entfernen, da dafür eine EKS-Cluster-ID angegeben werden muss. Für eine noch detailliertere Anpassung können Sie einzelne Aktionen direkt in der Experimentvorlage ändern. ## Aktionen Zusammen tragen die folgenden Aktionen dazu bei, die Symptome einer Verlangsamung des Datenverkehrs zwischen AZs zu erzeugen, indem sie zu Paketverlusten bei der ausgehenden Kommunikation von der Ziel-AZ zu anderen AZs in der Region auf Netzwerkebene führen. Diese Aktionen werden parallel ausgeführt, wobei jede Aktion standardmäßig einen Paketverlust von 15% für 30 Minuten verursacht. Nach diesem Zeitraum kehrt die Kommunikation zur Normalität zurück. Für die Ausführung des Szenarios ist mindestens einer der folgenden Ressourcentypen in der ausgewählten AZ erforderlich: EC2-Instance, ECS-Task oder EKS-Pod. ### Verlust von ECS-Netzwerkpaketen Cross-AZ: Traffic Slowdown beinhaltet [aws:ecs:](https://docs.aws.amazon.com/fis/latest/userguide/fis-actions-reference.html#task-network-packet-loss), um Paketverlust bei ECS-Aufgaben task-network-packet-loss einzuschleusen. Die Aktion zielt auf Aufgaben in der ausgewählten AZ ab und beeinträchtigt deren ausgehende Kommunikation mit allen anderen in der Region. AZs Sie können den Umfang der Auswirkungen weiter anpassen, indem Sie die Aktion bearbeiten und dem Feld etwas hinzufügen oder AZs daraus entfernen. `Sources` Standardmäßig zielt es auf Aufgaben ab, [deren Tag](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs-using-tags.html) `CrossAZTrafficSlowdown` den Wert hat`PacketLossForECS`. Sie können das Standard-Tag durch Ihr eigenes ersetzen oder das Szenario-Tag zu Ihren Aufgaben hinzufügen. Wenn keine gültigen Aufgaben gefunden werden, wird diese Aktion übersprungen. Bevor Sie ein Experiment auf ECS durchführen, sollten Sie die [Einrichtungsschritte für ECS-Aufgabenaktionen](https://docs.aws.amazon.com/fis/latest/userguide/ecs-task-actions.html) befolgen. ### Verlust von EKS-Netzwerkpaketen Cross-AZ: Traffic Slowdown beinhaltet [aws:eks:](https://docs.aws.amazon.com/fis/latest/userguide/fis-actions-reference.html#pod-network-packet-loss), um Paketverlust für EKS-Pods pod-network-packet-loss zu verhindern. Die Aktion zielt auf Pods in der ausgewählten AZ ab und beeinträchtigt deren ausgehende Kommunikation mit allen anderen Pods in der Region. AZs Sie können den Umfang der Auswirkungen weiter anpassen, indem Sie die Aktion bearbeiten und dem Feld etwas hinzufügen oder AZs daraus entfernen. `Sources` Standardmäßig zielt es auf Pods innerhalb eines Clusters ab, die Labels im Format key=value haben. Das bereitgestellte Standardlabel ist. `CrossAZTraffic=PacketLossForEKS` Sie können das Standardlabel durch Ihr eigenes ersetzen oder dieses Label zu Ihren Pods hinzufügen. Wenn keine gültigen Pods gefunden werden, wird diese Aktion übersprungen. Bevor Sie ein Experiment mit EKS durchführen, sollten Sie die [Einrichtungsschritte für EKS-Pod-Aktionen](https://docs.aws.amazon.com/fis/latest/userguide/eks-pod-actions.html) befolgen. ### Verlust von EC2-Netzwerkpaketen Cross-AZ: Traffic Slowdown verwendet die Aktion [aws:ssm:send-command](https://docs.aws.amazon.com/fis/latest/userguide/fis-actions-reference.html#ssm-send-command), um das Dokument [AWSFIS-Run-Network-Packet-Loss-Sources auszuführen, um Paketverlust für EC2-Instances zu verursachen, und beeinträchtigt deren](https://docs.aws.amazon.com/fis/latest/userguide/actions-ssm-agent.html#awsfis-run-network-packet-loss-sources) ausgehende Kommunikation mit allen anderen in der Region. AZs Sie können den Umfang der Auswirkung weiter anpassen, indem Sie die Aktion bearbeiten und dem Feld etwas hinzufügen oder daraus entfernen. AZs `Sources` Die Aktion zielt auf Instanzen in der ausgewählten AZ ab. Standardmäßig zielt sie auf Instances ab, `CrossAZTrafficSlowdown` deren [Tag](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html) den Wert hat`PacketLossForEC2`. Sie können das Standard-Tag durch Ihr eigenes ersetzen oder dieses Tag zu Ihren Instances hinzufügen. Wenn keine gültigen Instanzen gefunden werden, wird diese Aktion übersprungen. Bevor Sie mit SSM ein Experiment auf EC2 ausführen, sollten Sie [den AWS Systems Manager Manager-Agenten konfigurieren](https://docs.aws.amazon.com/fis/latest/userguide/actions-ssm-agent.html). ## Einschränkungen + Dieses Szenario beinhaltet keine [Stoppbedingungen](https://docs.aws.amazon.com/fis/latest/userguide/stop-conditions.html). Die richtigen Stoppbedingungen für Ihre Anwendung sollten der Versuchsvorlage hinzugefügt werden. ## Voraussetzungen + Fügen Sie der AWS [FIS-Experimentrolle](https://docs.aws.amazon.com/fis/latest/userguide/getting-started-iam-service-role.html) die erforderlichen Berechtigungen hinzu. + Sie müssen innerhalb der ausgewählten AZ auf eine oder mehrere Ressourcen aus einem der folgenden drei Typen abzielen: EC2-Instances, ECS-Aufgaben oder EKS-Pods. + Alle Ziele des Szenarios müssen sich in derselben VPC befinden. ## Berechtigungen Um dieses Szenario auszuführen, benötigen Sie eine IAM-Rolle mit einer Vertrauensrichtlinie, die es FIS ermöglicht, die Rolle und die verwalteten Richtlinien für die Ressourcentypen zu übernehmen, auf die Sie im Experiment abzielen: EC2, ECS und EKS. Wenn Sie eine Versuchsvorlage aus dem Szenario Cross-AZ: Traffic Slowdown erstellen, erstellt FIS die Rolle für Sie mit der Vertrauensrichtlinie und den folgenden von AWS verwalteten Richtlinien: + [AWSFaultInjectionSimulatorEC2Access](https://docs.aws.amazon.com/fis/latest/userguide/security-iam-awsmanpol.html#AWSFaultInjectionSimulatorEC2Access) + [AWSFaultInjectionSimulatorECSAccess](https://docs.aws.amazon.com/fis/latest/userguide/security-iam-awsmanpol.html#AWSFaultInjectionSimulatorECSAccess) + [AWSFaultInjectionSimulatorEKSAccess](https://docs.aws.amazon.com/fis/latest/userguide/security-iam-awsmanpol.html#AWSFaultInjectionSimulatorEKSAccess) Wenn Sie eine bestehende [IAM-Rolle](https://docs.aws.amazon.com/fis/latest/userguide/getting-started-iam-service-role.html) verwenden, um das Szenario Cross-AZ: Traffic Slowdown auszuführen, können Sie die folgende Richtlinie anhängen, um AWS FIS die erforderlichen Berechtigungen zu gewähren: ``` { "Version": "2012-10-17", "Statement": [ { "Sid": "DescribeTasks", "Effect": "Allow", "Action": "ecs:DescribeTasks", "Resource": "*" }, { "Sid": "DescribeContainerInstances", "Effect": "Allow", "Action": "ecs:DescribeContainerInstances", "Resource": "arn:aws:ecs:*:*:container-instance/*/*" }, { "Sid": "DescribeInstances", "Effect": "Allow", "Action": "ec2:DescribeInstances", "Resource": "*" }, { "Sid": "DescribeSubnets", "Effect": "Allow", "Action": "ec2:DescribeSubnets", "Resource": "*" }, { "Sid": "DescribeCluster", "Effect": "Allow", "Action": "eks:DescribeCluster", "Resource": "arn:aws:eks:*:*:cluster/*" }, { "Sid": "TargetResolutionByTags", "Effect": "Allow", "Action": "tag:GetResources", "Resource": "*" }, { "Sid": "SendCommand", "Effect": "Allow", "Action": [ "ssm:SendCommand" ], "Resource": [ "arn:aws:ec2:*:*:instance/*", "arn:aws:ssm:*:*:managed-instance/*", "arn:aws:ssm:*:*:document/*" ] }, { "Sid": "ListCommands", "Effect": "Allow", "Action": [ "ssm:ListCommands" ], "Resource": "*" }, { "Sid": "CancelCommand", "Effect": "Allow", "Action": [ "ssm:CancelCommand" ], "Resource": "*" } ] } ``` ## Inhalt des Szenarios Der folgende Inhalt definiert das Szenario. Diese JSON-Datei kann gespeichert und verwendet werden, um mithilfe des [create-experiment-template](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/fis/create-experiment-template.html)Befehls von der AWS-Befehlszeilenschnittstelle (AWS CLI) eine [Versuchsvorlage](https://docs.aws.amazon.com/fis/latest/userguide/experiment-templates.html) zu erstellen. Die neueste Version des Szenarios finden Sie in der Szenario-Bibliothek in der FIS-Konsole und wechseln Sie zur Registerkarte **Inhalt**. ``` { "tags": { "Name": "Cross-AZ: Traffic Slowdown" }, "description": "Inject packet loss to disrupt and slow down traffic between AZs.", "actions": { "PacketLossForEC2": { "actionId": "aws:ssm:send-command", "parameters": { "duration": "PT30M", "documentArn": "arn:aws:ssm:us-east-1::document/AWSFIS-Run-Network-Packet-Loss-Sources", "documentParameters": "{\"Sources\":\"us-east-1b,us-east-1c,us-east-1d,us-east-1e,us-east-1f\",\"LossPercent\":\"15\",\"Interface\":\"DEFAULT\",\"TrafficType\":\"egress\",\"DurationSeconds\":\"1800\",\"FlowsPercent\":\"100\",\"InstallDependencies\":\"True\"}" }, "targets": { "Instances": "TargetsForEC2" } }, "PacketLossForECS": { "actionId": "aws:ecs:task-network-packet-loss", "parameters": { "sources": "us-east-1b,us-east-1c,us-east-1d,us-east-1e,us-east-1f", "lossPercent": "15", "duration": "PT30M", "flowsPercent": "100", "installDependencies": "true", "useEcsFaultInjectionEndpoints": "true" }, "targets": { "Tasks": "TargetsForECS" } }, "PacketLossForEKS": { "actionId": "aws:eks:pod-network-packet-loss", "parameters": { "sources": "us-east-1b,us-east-1c,us-east-1d,us-east-1e,us-east-1f", "lossPercent": "15", "duration": "PT30M", "flowsPercent": "100", "interface": "DEFAULT", "kubernetesServiceAccount": "fis-service-account" }, "targets": { "Pods": "TargetsForEKS" } } }, "targets": { "TargetsForEC2": { "filters": [ { "path": "Placement.AvailabilityZone", "values": [ "us-east-1a" ] } ], "resourceTags": { "CrossAZTrafficSlowdown": "PacketLossForEC2" }, "resourceType": "aws:ec2:instance", "selectionMode": "ALL" }, "TargetsForECS": { "filters": [ { "path": "AvailabilityZone", "values": [ "us-east-1a" ] } ], "resourceTags": { "CrossAZTrafficSlowdown": "PacketLossForECS" }, "resourceType": "aws:ecs:task", "selectionMode": "ALL" }, "TargetsForEKS": { "parameters": { "availabilityZoneIdentifier": "us-east-1a", "clusterIdentifier": "", "namespace": "default", "selectorType": "labelSelector", "selectorValue": "CrossAZTrafficSlowdown=PacketLossForEKS" }, "resourceType": "aws:eks:pod", "selectionMode": "ALL" } }, "experimentOptions": { "accountTargeting": "single-account", "emptyTargetResolutionMode": "skip" }, "stopConditions": [ { "source": "none" } ] } ``` # Cross-Region: Connectivity Sie können das Cross-Region: Connectivity Szenario verwenden, um den Netzwerkverkehr der Anwendung von der Versuchsregion zur Zielregion zu blockieren und die regionsübergreifende Replikation für globale Amazon S3- und Amazon DynamoDB-Tabellen mit mehreren Regionen anzuhalten. *Regionsübergreifend: Die Konnektivität wirkt sich auf den ausgehenden Anwendungsdatenverkehr aus der Region aus, in der Sie das Experiment ausführen (Versuchsregion).* Zustandsloser eingehender Verkehr aus der Region, die Sie von der *Versuchsregion isolieren möchten (*Zielregion**), wird möglicherweise nicht blockiert. Der Datenverkehr von AWS Managed Services darf nicht blockiert werden. Dieses Szenario kann verwendet werden, um zu demonstrieren, dass Anwendungen mit mehreren Regionen erwartungsgemäß funktionieren, wenn auf Ressourcen in der Zielregion von der Versuchsregion aus nicht zugegriffen werden kann. Es beinhaltet das Blockieren des Netzwerkverkehrs von der Versuchsregion zur Zielregion, indem auf Transit-Gateways und Routentabellen gezielt wird. Außerdem wird die regionsübergreifende Replikation für globale S3- und DynamoDB-Tabellen angehalten. Standardmäßig werden Aktionen, für die keine Ziele gefunden wurden, übersprungen. ## Aktionen Zusammen blockieren die folgenden Aktionen die regionsübergreifende Konnektivität für die enthaltenen AWS-Services. Die Aktionen werden parallel ausgeführt. Standardmäßig blockiert das Szenario den Verkehr für 3 Stunden, die Sie auf eine maximale Dauer von 12 Stunden erhöhen können. ### Unterbrechen Sie die Transit-Gateway-Konnektivität Cross Region: Connectivitybeinhaltet [aws:network: transit-gateway-disrupt-cross -region-connectivity](https://docs.aws.amazon.com/fis/latest/userguide/fis-actions-reference.html#network-actions-reference), um den regionsübergreifenden Netzwerkverkehr von VPCs der *Versuchsregion zur *Zielregion* zu blockieren, die durch* ein VPCs Transit-Gateway verbunden ist. *Dies hat keinen Einfluss auf den Zugriff auf VPC-Endpunkte innerhalb der *Versuchsregion*, blockiert jedoch den Datenverkehr aus der *Versuchsregion, der für einen VPC-Endpunkt in der Zielregion* bestimmt ist.* *Diese Aktion zielt auf Transit-Gateways ab, die die *Versuchsregion mit der Zielregion* verbinden.* Standardmäßig zielt sie auf Transit-Gateways ab, [deren Tag](https://docs.aws.amazon.com/vpc/latest/tgw/tgw-transit-gateways.html#tgw-tagging) `DisruptTransitGateway` den Wert hat. `Allowed` Sie können dieses Tag zu Ihren Transit-Gateways hinzufügen oder das Standard-Tag in der Experimentvorlage durch Ihr eigenes Tag ersetzen. Wenn keine gültigen Transit-Gateways gefunden werden, wird diese Aktion standardmäßig übersprungen. ### Unterbrechen Sie die Subnetzkonnektivität Cross Region: Connectivity*beinhaltet [aws:network: route-table-disrupt-cross -region-connectivity](https://docs.aws.amazon.com/fis/latest/userguide/fis-actions-reference.html#network-actions-reference), um regionsübergreifenden Netzwerkverkehr von der *Versuchsregion zu öffentlichen AWS-IP-Blöcken VPCs in der Zielregion* zu blockieren.* Zu diesen öffentlichen IP-Blöcken gehören AWS-Serviceendpunkte in der *Zielregion*, z. B. der regionale S3-Endpunkt, und AWS-IP-Blöcke für verwaltete Services, z. B. die IP-Adressen, die für Load Balancer und Amazon API Gateway verwendet werden. *Diese Aktion blockiert auch die Netzwerkkonnektivität über regionsübergreifende VPC-Peering-Verbindungen von der *Versuchsregion zur Zielregion*.* *Es wirkt sich nicht auf den Zugriff auf VPC-Endpunkte in der *Versuchsregion* aus, blockiert jedoch den Datenverkehr aus der *Versuchsregion, der für einen VPC-Endpunkt in der Zielregion* bestimmt ist.* Diese Aktion zielt auf Subnetze in der Versuchsregion ab. Standardmäßig zielt sie auf Subnetze ab, deren [Tag](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html) `DisruptSubnet` den Wert hat. `Allowed` Sie können dieses Tag zu Ihren Subnetzen hinzufügen oder das Standard-Tag in der Experimentvorlage durch Ihr eigenes Tag ersetzen. Wenn keine gültigen Subnetze gefunden werden, wird diese Aktion standardmäßig übersprungen. ### Unterbrechen Sie die VPC-Endpunktkonnektivität Cross Region: Connectivitybeinhaltet [aws:network: disrupt-vpc-endpoint](https://docs.aws.amazon.com/fis/latest/userguide/fis-actions-reference.html#network-actions-reference) unterbricht die Konnektivität zu einem Dienst, der den Ziel-VPC-Endpunkten zugeordnet ist. Wenn ein VPC-Endpunkt beispielsweise einen privaten Link zu com.amazonaws.us-east-1.ec2 erstellt, wird die Konnektivität zu diesem Service unterbrochen. Diese Aktion zielt VPC VPC-Endpunkte in der Versuchsregion ab. Standardmäßig zielt es auf Schnittstellen-VPC-Endpunkte mit einem [Tag](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html) ab, der mit einem Wert benannt DisruptVpcEndpoint ist. `Allowed` Sie können dieses Tag zu Ihren VPC-Endpunkten hinzufügen oder das Standard-Tag in der Experimentvorlage durch Ihr eigenes Tag ersetzen. Wenn keine gültigen VPC-Endpoints gefunden werden, wird diese Aktion standardmäßig übersprungen. ### S3-Replikation unterbrechen Cross Region: Connectivitybeinhaltet [aws:s3: bucket-pause-replication](https://docs.aws.amazon.com/fis/latest/userguide/fis-actions-reference.html#s3-actions-reference-fis), um die S3-Replikation von der *Versuchsregion zur Zielregion* *für die Ziel-Buckets* anzuhalten. Die Replikation von der *Zielregion* zur *Experimentregion bleibt davon unberührt*. Nach dem Ende des Szenarios wird die Bucket-Replikation an dem Punkt fortgesetzt, an dem sie angehalten wurde. Beachten Sie, dass die Zeit, die für die Replikation benötigt wird, um alle Objekte synchron zu halten, je nach Dauer des Experiments und der Geschwindigkeit, mit der Objekte in den Bucket hochgeladen werden, variiert. Diese Aktion zielt auf S3-Buckets in der Versuchsregion ab, wobei die [regionsübergreifende Replikation (CRR) für einen S3-Bucket in der Zielregion](https://docs.aws.amazon.com/AmazonS3/latest/userguide/replication.html) aktiviert ist. Standardmäßig zielt sie auf Buckets ab, deren [Tag](https://docs.aws.amazon.com/AmazonS3/latest/userguide/view-bucket-properties.html) den Wert hat`DisruptS3`. `Allowed` Sie können dieses Tag zu Ihren Buckets hinzufügen oder das Standard-Tag in der Experimentvorlage durch Ihr eigenes Tag ersetzen. Wenn keine gültigen Buckets gefunden werden, wird diese Aktion standardmäßig übersprungen. ### DynamoDB-Replikation anhalten Cross-Region: Connectivitybeinhaltet [aws:dynamodb:](https://docs.aws.amazon.com/fis/latest/userguide/fis-actions-reference.html#dynamodb-actions-reference), global-table-pause-replication um die Replikation zwischen der Versuchsregion und allen anderen Regionen, einschließlich der Zielregion, anzuhalten. Dies verhindert die Replikation in und aus der *Versuchsregion*, hat aber keinen Einfluss auf die Replikation zwischen anderen Regionen. Nach dem Ende des Szenarios wird die Tabellenreplikation an dem Punkt fortgesetzt, an dem sie angehalten wurde. Beachten Sie, dass die Zeit, die für die Replikation benötigt wird, um alle Daten synchron zu halten, von der Dauer des Experiments und der Geschwindigkeit der Änderungen an der Tabelle abhängt. Diese Aktion zielt sowohl stark auf mehrere Regionen von DynamoDB als auch auf konsistente globale Tabellen in der Versuchsregion ab. Standardmäßig zielt sie auf Tabellen ab, deren [Tag](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/Tagging.html) den Wert `DisruptDynamoDb` hat. `Allowed` Sie können dieses Tag zu Ihren Tabellen hinzufügen oder das Standard-Tag in der Experimentvorlage durch Ihr eigenes Tag ersetzen. Wenn keine gültigen globalen Tabellen gefunden werden, wird diese Aktion standardmäßig übersprungen. ### Halten Sie die MemoryDB-Replikation für mehrere Regionen an Cross-Region: Connectivitybeinhaltet [aws:memorydb: multi-region-cluster-pause -replication, um die Replikation](https://docs.aws.amazon.com/fis/latest/userguide/fis-actions-reference.html#memorydb-actions-reference) vom regionalen Mitgliedscluster in der Versuchsregion zu den übrigen Clustern im Zielcluster mit mehreren Regionen anzuhalten. Die Replikation zwischen anderen regionalen Mitgliedsclustern wird nicht beeinträchtigt. Nach dem Ende des Szenarios wird die Replikation an dem Punkt fortgesetzt, an dem sie angehalten wurde. Beachten Sie, dass die Zeit, bis die Replikation Daten zwischen den Mitgliedsclustern synchronisiert, je nach Dauer des Experiments und der Geschwindigkeit, mit der Daten in die Cluster geschrieben werden, variiert. Diese Aktion zielt auf MemoryDB-Cluster mit mehreren Regionen ab, bei denen sich ein regionales Mitglied in der Versuchsregion befindet. Standardmäßig zielt sie auf Cluster mit mehreren Regionen ab, deren [Tag](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/Tagging.html) den Wert hat`DisruptMemoryDB`. `Allowed` Sie können dieses Tag zu Ihren Clustern mit mehreren Regionen hinzufügen oder das Standard-Tag in der Experimentvorlage durch Ihr eigenes Tag ersetzen. Wenn keine gültigen Cluster gefunden werden, wird diese Aktion standardmäßig übersprungen. ## Einschränkungen + Dieses Szenario beinhaltet keine [Stoppbedingungen](https://docs.aws.amazon.com/fis/latest/userguide/stop-conditions.html). Die richtigen Stoppbedingungen für Ihre Anwendung sollten der Versuchsvorlage hinzugefügt werden. ## Voraussetzungen + Fügen Sie der AWS [FIS-Experimentrolle](https://docs.aws.amazon.com/fis/latest/userguide/getting-started-iam-service-role.html) die erforderliche Berechtigung hinzu. + Ressourcen-Tags müssen auf Ressourcen angewendet werden, auf die das Experiment abzielen soll. Diese können Ihre eigene Tagging-Konvention oder die im Szenario definierten Standard-Tags verwenden. ## Berechtigungen Die folgende Richtlinie gewährt AWS FIS die erforderlichen Berechtigungen, um ein Experiment mit dem Cross-Region: Connectivity Szenario durchzuführen. Diese Richtlinie muss der [Rolle des Experiments](https://docs.aws.amazon.com/fis/latest/userguide/getting-started-iam-service-role.html) zugeordnet werden. ``` { "Version": "2012-10-17", "Statement": [ { "Sid": "RouteTableDisruptConnectivity1", "Effect": "Allow", "Action": "ec2:CreateRouteTable", "Resource": "arn:aws:ec2:*:*:route-table/*", "Condition": { "StringEquals": { "aws:RequestTag/managedByFIS": "true" } } }, { "Sid": "RouteTableDisruptConnectivity2", "Effect": "Allow", "Action": "ec2:CreateRouteTable", "Resource": "arn:aws:ec2:*:*:vpc/*" }, { "Sid": "RouteTableDisruptConnectivity21", "Effect": "Allow", "Action": "ec2:CreateTags", "Resource": "arn:aws:ec2:*:*:route-table/*", "Condition": { "StringEquals": { "ec2:CreateAction": "CreateRouteTable", "aws:RequestTag/managedByFIS": "true" } } }, { "Sid": "RouteTableDisruptConnectivity3", "Effect": "Allow", "Action": "ec2:CreateTags", "Resource": "arn:aws:ec2:*:*:network-interface/*", "Condition": { "StringEquals": { "ec2:CreateAction": "CreateNetworkInterface", "aws:RequestTag/managedByFIS": "true" } } }, { "Sid": "RouteTableDisruptConnectivity4", "Effect": "Allow", "Action": "ec2:CreateTags", "Resource": "arn:aws:ec2:*:*:prefix-list/*", "Condition": { "StringEquals": { "ec2:CreateAction": "CreateManagedPrefixList", "aws:RequestTag/managedByFIS": "true" } } }, { "Sid": "RouteTableDisruptConnectivity5", "Effect": "Allow", "Action": "ec2:DeleteRouteTable", "Resource": [ "arn:aws:ec2:*:*:route-table/*", "arn:aws:ec2:*:*:vpc/*" ], "Condition": { "StringEquals": { "ec2:ResourceTag/managedByFIS": "true" } } }, { "Sid": "RouteTableDisruptConnectivity6", "Effect": "Allow", "Action": "ec2:CreateRoute", "Resource": "arn:aws:ec2:*:*:route-table/*", "Condition": { "StringEquals": { "ec2:ResourceTag/managedByFIS": "true" } } }, { "Sid": "RouteTableDisruptConnectivity7", "Effect": "Allow", "Action": "ec2:CreateNetworkInterface", "Resource": "arn:aws:ec2:*:*:network-interface/*", "Condition": { "StringEquals": { "aws:RequestTag/managedByFIS": "true" } } }, { "Sid": "RouteTableDisruptConnectivity8", "Effect": "Allow", "Action": "ec2:CreateNetworkInterface", "Resource": [ "arn:aws:ec2:*:*:subnet/*", "arn:aws:ec2:*:*:security-group/*" ] }, { "Sid": "RouteTableDisruptConnectivity9", "Effect": "Allow", "Action": "ec2:DeleteNetworkInterface", "Resource": "arn:aws:ec2:*:*:network-interface/*", "Condition": { "StringEquals": { "ec2:ResourceTag/managedByFIS": "true" } } }, { "Sid": "RouteTableDisruptConnectivity10", "Effect": "Allow", "Action": "ec2:CreateManagedPrefixList", "Resource": "arn:aws:ec2:*:*:prefix-list/*", "Condition": { "StringEquals": { "aws:RequestTag/managedByFIS": "true" } } }, { "Sid": "RouteTableDisruptConnectivity11", "Effect": "Allow", "Action": [ "ec2:DeleteManagedPrefixList", "ec2:ModifyManagedPrefixList" ], "Resource": "arn:aws:ec2:*:*:prefix-list/*", "Condition": { "StringEquals": { "aws:ResourceTag/managedByFIS": "true" } } }, { "Sid": "EC2DescribeResources", "Effect": "Allow", "Action": [ "ec2:DescribeNetworkInterfaces", "ec2:DescribeVpcs", "ec2:DescribeVpcPeeringConnections", "ec2:DescribeManagedPrefixLists", "ec2:DescribeSubnets", "ec2:DescribeRouteTables", "ec2:DescribeVpcEndpoints", "ec2:DescribeTransitGatewayPeeringAttachments", "ec2:DescribeTransitGatewayAttachments", "ec2:DescribeTransitGateways", "ec2:DescribeSecurityGroups" ], "Resource": "*" }, { "Sid": "RouteTableDisruptConnectivity14", "Effect": "Allow", "Action": "ec2:ReplaceRouteTableAssociation", "Resource": [ "arn:aws:ec2:*:*:subnet/*", "arn:aws:ec2:*:*:route-table/*" ] }, { "Sid": "RouteTableDisruptConnectivity15", "Effect": "Allow", "Action": "ec2:GetManagedPrefixListEntries", "Resource": "arn:aws:ec2:*:*:prefix-list/*" }, { "Sid": "RouteTableDisruptConnectivity16", "Effect": "Allow", "Action": "ec2:AssociateRouteTable", "Resource": [ "arn:aws:ec2:*:*:subnet/*", "arn:aws:ec2:*:*:route-table/*" ] }, { "Sid": "RouteTableDisruptConnectivity17", "Effect": "Allow", "Action": "ec2:DisassociateRouteTable", "Resource": "arn:aws:ec2:*:*:route-table/*", "Condition": { "StringEquals": { "ec2:ResourceTag/managedByFIS": "true" } } }, { "Sid": "RouteTableDisruptConnectivity18", "Effect": "Allow", "Action": "ec2:DisassociateRouteTable", "Resource": "arn:aws:ec2:*:*:subnet/*" }, { "Sid": "RouteTableDisruptConnectivity19", "Effect": "Allow", "Action": "ec2:ModifyVpcEndpoint", "Resource": "arn:aws:ec2:*:*:route-table/*", "Condition": { "StringEquals": { "ec2:ResourceTag/managedByFIS": "true" } } }, { "Sid": "TransitGatewayDisruptConnectivity1", "Effect": "Allow", "Action": [ "ec2:DisassociateTransitGatewayRouteTable", "ec2:AssociateTransitGatewayRouteTable" ], "Resource": [ "arn:aws:ec2:*:*:transit-gateway-route-table/*", "arn:aws:ec2:*:*:transit-gateway-attachment/*" ] }, { "Sid": "S3CrossRegion1", "Effect": "Allow", "Action": "s3:ListAllMyBuckets", "Resource": "*" }, { "Sid": "S3CrossRegion3", "Effect": "Allow", "Action": "s3:PauseReplication", "Resource": "arn:aws:s3:::*", "Condition": { "StringLike": { "s3:DestinationRegion": "*" } } }, { "Sid": "S3CrossRegion4", "Effect": "Allow", "Action": [ "s3:GetReplicationConfiguration", "s3:PutReplicationConfiguration" ], "Resource": "arn:aws:s3:::*", "Condition": { "BoolIfExists": { "s3:isReplicationPauseRequest": "true" } } }, { "Sid": "DynamoDbPauseReplication", "Effect": "Allow", "Action": [ "dynamodb:DescribeTable", "dynamodb:PutResourcePolicy", "dynamodb:GetResourcePolicy", "dynamodb:DeleteResourcePolicy" ], "Resource": [ "arn:aws:dynamodb:*:*:table/*" ] }, { "Sid": "DynamoDbMrscPauseReplication", "Effect": "Allow", "Action": [ "dynamodb:InjectError" ], "Resource": ["*"] }, { "Sid": "ResolveResourcesViaTags", "Effect": "Allow", "Action": "tag:GetResources", "Resource": "*" }, { "Sid": "MemDbCrossRegion", "Effect": "Allow", "Action": [ "memorydb:DescribeMultiRegionClusters", "memorydb:PauseMultiRegionClusterReplication" ], "Resource": [ "arn:aws:memorydb::*:multiregioncluster/*" ] }, { "Sid": "DisruptVPCE1", "Effect": "Allow", "Action": "ec2:CreateSecurityGroup", "Resource": [ "arn:aws:ec2:*:*:vpc/*", "arn:aws:ec2:*:*:security-group/*" ] }, { "Sid": "DisruptVPCE2", "Effect": "Allow", "Action": "ec2:CreateTags", "Resource": "arn:aws:ec2:*:*:security-group/*", "Condition": { "StringEquals": { "ec2:CreateAction": "CreateSecurityGroup", "aws:RequestTag/managedByFIS": "true" } } }, { "Sid": "DisruptVPCE3", "Effect": "Allow", "Action": [ "ec2:DeleteSecurityGroup", "ec2:RevokeSecurityGroupEgress" ], "Resource": "arn:aws:ec2:*:*:security-group/*", "Condition": { "StringEquals": { "aws:ResourceTag/managedByFIS": "true" } } }, { "Sid": "DisruptVPCE4", "Effect": "Allow", "Action": "vpce:AllowMultiRegion", "Resource": "arn:aws:ec2:*:*:vpc-endpoint/*" }, { "Sid": "ModifyVPCE", "Effect": "Allow", "Action": "ec2:ModifyVpcEndpoint", "Resource": [ "arn:aws:ec2:*:*:vpc-endpoint/*", "arn:aws:ec2:*:*:security-group/*" ] } ] } ``` ## Inhalt des Szenarios Der folgende Inhalt definiert das Szenario. Diese JSON-Datei kann gespeichert und verwendet werden, um mithilfe des [create-experiment-template](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/fis/create-experiment-template.html)Befehls von der AWS-Befehlszeilenschnittstelle (AWS CLI) eine [Versuchsvorlage](https://docs.aws.amazon.com/fis/latest/userguide/experiment-templates.html) zu erstellen. Die neueste Version des Szenarios finden Sie in der Szenariobibliothek in der FIS-Konsole. ``` { "targets": { "Transit-Gateway": { "resourceType": "aws:ec2:transit-gateway", "resourceTags": { "TgwTag": "TgwValue" }, "selectionMode": "ALL" }, "Subnet": { "resourceType": "aws:ec2:subnet", "resourceTags": { "SubnetKey": "SubnetValue" }, "selectionMode": "ALL", "parameters": {} }, "VPC-Endpoint": { "resourceType": "aws:ec2:vpc-endpoint", "resourceTags": { "DisruptPrivateLink": "Allowed" }, "selectionMode": "ALL" }, "S3-Bucket": { "resourceType": "aws:s3:bucket", "resourceTags": { "S3Impact": "Allowed" }, "selectionMode": "ALL" }, "DynamoDB-Global-Table": { "resourceType": "aws:dynamodb:global-table", "resourceTags": { "DisruptDynamoDb": "Allowed" }, "selectionMode": "ALL" }, "MemoryDB-Multi-Region-Cluster": { "resourceType": "aws:memorydb:multi-region-cluster", "resourceTags": { "DisruptMemoryDb": "Allowed" }, "selectionMode": "ALL" } }, "actions": { "Disrupt-Transit-Gateway-Connectivity": { "actionId": "aws:network:transit-gateway-disrupt-cross-region-connectivity", "parameters": { "duration": "PT3H", "region": "eu-west-1" }, "targets": { "TransitGateways": "Transit-Gateway" } }, "Disrupt-Subnet-Connectivity": { "actionId": "aws:network:route-table-disrupt-cross-region-connectivity", "parameters": { "duration": "PT3H", "region": "eu-west-1" }, "targets": { "Subnets": "Subnet" } }, "Disrupt-Vpc-Endpoint": { "actionId": "aws:network:disrupt-vpc-endpoint", "parameters": { "duration": "PT3H" }, "targets": { "VPCEndpoints": "VPC-Endpoint" } }, "Pause-S3-Replication": { "actionId": "aws:s3:bucket-pause-replication", "parameters": { "duration": "PT3H", "region": "eu-west-1" }, "targets": { "Buckets": "S3-Bucket" } }, "Pause-DynamoDB-Replication": { "actionId": "aws:dynamodb:global-table-pause-replication", "parameters": { "duration": "PT3H" }, "targets": { "Tables": "DynamoDB-Global-Table" } }, "Pause-MemoryDB-Multi-Region-Cluster-Replication": { "actionId": "aws:memorydb:multi-region-cluster-pause-replication", "parameters": { "duration": "PT3H", "region": "eu-west-1" }, "targets": { "MultiRegionClusters": "MemoryDB-Multi-Region-Cluster" } } }, "stopConditions": [ { "source": "none" } ], "roleArn": "", "logConfiguration": { "logSchemaVersion": 2 }, "tags": { "Name": "Cross-Region: Connectivity" }, "experimentOptions": { "accountTargeting": "single-account", "emptyTargetResolutionMode": "skip" }, "description": "Block application network traffic from experiment Region to target Region and pause cross-Region replication" } ```