Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà. # Riferimento agli scenari Gli scenari inclusi nella libreria degli scenari sono progettati per utilizzare [ tag ](https://docs.aws.amazon.com/whitepapers/latest/tagging-best-practices/what-are-tags.html) laddove possibile e ogni scenario descrive i tag richiesti nelle ** sezioni ** Prerequisiti ** e ** Come funziona della descrizione dello scenario. Puoi etichettare le tue risorse con quei tag predefiniti oppure puoi impostare i tuoi tag utilizzando l'esperienza condivisa di modifica dei parametri (vedi[Utilizzo di uno scenario](scenario-library.md#using-a-scenario)). Questo riferimento descrive gli scenari comuni nella libreria di scenari AWS FIS. Puoi anche elencare gli scenari supportati utilizzando la console AWS FIS. Per ulteriori informazioni, consulta [Lavorare con AWS FIS libreria di scenari](scenario-library.md). AWS FIS supporta i seguenti scenari Amazon EC2. Questi scenari prendono di mira le istanze utilizzando tag. [https://docs.aws.amazon.com/whitepapers/latest/tagging-best-practices/what-are-tags.html](https://docs.aws.amazon.com/whitepapers/latest/tagging-best-practices/what-are-tags.html) È possibile utilizzare tag personalizzati o utilizzare i tag predefiniti inclusi nello scenario. Alcuni di questi scenari [ utilizzano documenti ](https://docs.aws.amazon.com/fis/latest/userguide/actions-ssm-agent.html) SSM. + **Stress EC2: instance failure**: esplora l'effetto del fallimento dell'istanza arrestando una o più istanze EC2. Individua le istanze nella regione corrente a cui è associato un tag specifico. In questo scenario interromperemo tali istanze e le riavvieremo al termine della durata dell'azione, per impostazione predefinita 5 minuti. + **Stress EC2: Disco**: scopri l'impatto del maggiore utilizzo del disco sull'applicazione basata su EC2. In questo scenario, prenderemo di mira le istanze EC2 nella regione corrente a cui è associato un tag specifico. In questo scenario è possibile personalizzare l'utilizzo crescente del disco iniettato sulle istanze EC2 mirate per la durata dell'azione, di default 5 minuti per ogni azione di stress del disco. + **Stress EC2: CPU**: esplora l'impatto dell'aumento della CPU sull'applicazione basata su EC2. In questo scenario, prenderemo di mira le istanze EC2 nella regione corrente a cui è associato un tag specifico. In questo scenario è possibile personalizzare una quantità crescente di stress della CPU iniettato sulle istanze EC2 mirate per la durata dell'azione, di default 5 minuti per ogni azione di stress della CPU. + **Stress EC2: memoria**: scopri l'impatto di un maggiore utilizzo della memoria sull'applicazione basata su EC2. In questo scenario, prenderemo di mira le istanze EC2 nella regione corrente a cui è associato un tag specifico. In questo scenario è possibile personalizzare una quantità crescente di stress di memoria iniettato sulle istanze EC2 mirate per la durata dell'azione, per impostazione predefinita 5 minuti per ogni azione di stress della memoria. + **Stress EC2: latenza di rete**: scopri l'impatto dell'aumento della latenza di rete sull'applicazione basata su EC2. In questo scenario, prenderemo di mira le istanze EC2 nella regione corrente a cui è associato un tag specifico. In questo scenario è possibile personalizzare una quantità crescente di latenza di rete iniettata sulle istanze EC2 mirate per la durata dell'azione, di default 5 minuti per ogni azione di latenza. AWS FIS supporta i seguenti scenari Amazon EKS. Questi scenari sono destinati ai pod EKS utilizzando le etichette di un'applicazione Kubernetes. È possibile utilizzare le proprie etichette o utilizzare le etichette predefinite incluse nello scenario. Per ulteriori informazioni su EKS con FIS, vedere[Azioni EKS Pod](eks-pod-actions.md). + **EKS stress: Pod Delete ** - Esplorate l'effetto del fallimento del pod EKS eliminando uno o più pod. In questo scenario prenderemo di mira i pod nella regione corrente associati a un'etichetta dell'applicazione. In questo scenario termineremo tutti i pod abbinati. Re-creation i pod saranno controllati dalla configurazione di Kubernetes. + **Stress EKS: CPU**: scopri l'impatto dell'aumento della CPU sull'applicazione basata su EKS. In questo scenario prenderemo di mira i pod nella regione corrente associati a un'etichetta dell'applicazione. In questo scenario è possibile personalizzare una quantità crescente di stress della CPU iniettato sui pod EKS mirati per la durata dell'azione, di default 5 minuti per ogni azione di stress della CPU. + **Stress da EKS: disco**: scopri l'impatto di un maggiore utilizzo del disco sull'applicazione basata su EKS. In questo scenario prenderemo di mira i pod nella regione corrente associati a un'etichetta dell'applicazione. In questo scenario è possibile personalizzare una quantità crescente di stress sul disco iniettato sui pod EKS mirati per la durata dell'azione, di default 5 minuti per ogni azione di stress della CPU. + **Stress da EKS: memoria**: esplorate l'impatto di un maggiore utilizzo della memoria sull'applicazione basata su EKS. In questo scenario prenderemo di mira i pod nella regione corrente associati a un'etichetta dell'applicazione. In questo scenario è possibile personalizzare una quantità crescente di stress di memoria iniettato sui pod EKS mirati per la durata dell'azione, di default 5 minuti per ogni azione di stress della memoria. + **Stress da EKS: latenza di rete**: scoprite l'impatto di una maggiore latenza di rete sull'applicazione basata su EKS. In questo scenario prenderemo di mira i pod nella regione corrente associati a un'etichetta dell'applicazione. In questo scenario è possibile personalizzare una quantità crescente di latenza di rete iniettata sui pod EKS mirati per la durata dell'azione, di default 5 minuti per ogni azione di latenza. AWS FIS supporta i seguenti scenari per applicazioni Single-AZ, Multi-AZ e multi-region. Questi scenari si rivolgono a più tipi di risorse. + **AZ Availability: Power Interruption**- Iniettare i sintomi previsti di un'interruzione completa dell'alimentazione in una zona di disponibilità (AZ). Ulteriori informazioni su [Disponibilità AZ: interruzione dell'alimentazione](az-availability-scenario.md). + **AZ: Application Slowdown**- Aggiungi latenza tra le risorse all'interno di una singola zona di disponibilità (AZ) per rallentare un'applicazione. Ulteriori informazioni su [AZ: Rallentamento dell'applicazione](az-application-slowdown-scenario.md). + **Cross-AZ: Traffic Slowdown**- Inietta la perdita di pacchetti per interrompere e rallentare il traffico tra le zone di disponibilità (AZ). Ulteriori informazioni su [Cross-AZ: rallentamento del traffico](cross-az-traffic-slowdown-scenario.md). + **Cross-Region: Connectivity**- Blocca il traffico di rete delle applicazioni dalla regione dell'esperimento alla regione di destinazione e sospendi la replica dei dati tra regioni. Scopri di più sull'utilizzo di. [Cross-Region: Connettività](cross-region-scenario.md) AWS FIS supporta i seguenti scenari per i volumi Amazon EBS. Questi scenari sono indirizzati ai volumi utilizzando tag. È possibile utilizzare tag personalizzati o utilizzare i tag predefiniti inclusi nello scenario. I volumi di destinazione devono trovarsi nella stessa zona di disponibilità. Per ulteriori informazioni, [ Fault testing su Amazon EBS. ](https://docs.aws.amazon.com/ebs/latest/userguide/ebs-fis.html) + **EBS: Sustained Latency**— Esplora l'impatto della I/O latenza persistente sulla tua applicazione. In questo scenario, prenderemo di mira i volumi nell'attuale zona di disponibilità a cui è associato un tag specifico. Questo scenario inietta una latenza costante di 500 ms sul 50% delle operazioni di lettura e sul 100% delle operazioni di scrittura per un volume, utilizzando una singola azione di latenza nell'arco di 15 minuti. In questo scenario, è possibile personalizzare la quantità di latenza iniettata, la percentuale di I/O iniezione e la durata dell'azione. + **EBS: Increasing Latency**— Esplorate l'impatto dell'aumento della I/O latenza sulla vostra applicazione. In questo scenario, prenderemo di mira i volumi nell'attuale zona di disponibilità a cui è associato un tag specifico. Questo scenario prevede una latenza crescente di 50 ms, 200 ms, 700 ms, 1 secondo e 15 secondi sul 10% delle operazioni di lettura e sul 25% delle operazioni di scrittura per un volume utilizzando cinque azioni di latenza in un periodo di 15 minuti. In questo scenario, è possibile personalizzare la quantità di latenza iniettata, la percentuale di latenza iniettata e la durata dell' I/O azione per ciascuna azione di latenza. + **EBS: Intermittent Latency**— Esplorate l'impatto dei picchi di latenza intermittenti I/O sulla vostra applicazione. In questo scenario, prenderemo come target i volumi nell'attuale zona di disponibilità a cui è allegato un tag specifico. Questo scenario inietta tre forti picchi di latenza intermittenti di 30 secondi, 10 secondi e 20 secondi sullo 0,1% delle I/O operazioni di lettura e scrittura di un volume, utilizzando tre azioni di latenza, con intervalli di ripristino tra ogni picco nell'arco di 15 minuti. In questo scenario, è possibile personalizzare la quantità di latenza iniettata, la percentuale di latenza iniettata e la durata dell'azione per ciascuna azione di I/O latenza. + **EBS: Decreasing Latency**— Esplorate l'impatto della riduzione della latenza I/O sull'applicazione. In questo scenario, prenderemo di mira i volumi nell'attuale zona di disponibilità a cui è allegato un tag specifico. Questo scenario prevede una latenza decrescente di 20 secondi, 5 secondi, 900 ms, 300 ms e 40 ms nel 10% delle operazioni di lettura e scrittura di un volume, utilizzando cinque azioni di latenza in un periodo di 15 minuti. In questo scenario, è possibile personalizzare la quantità di latenza iniettata, la percentuale di latenza iniettata e la durata dell' I/O azione per ciascuna azione di latenza.