# Gestione degli errori
**Topics**
+ [REL 9 In che modo esegui il backup dei dati?](w2aac19b9c11b5.md)
+ [REL 10 In che modo utilizzi l'isolamento dei guasti per proteggere il carico di lavoro?](w2aac19b9c11b7.md)
+ [REL 11 In che modo progetti il carico di lavoro affinché resista ai guasti dei componenti?](w2aac19b9c11b9.md)
+ [REL 12 In che modo testi l'affidabilità?](w2aac19b9c11c11.md)
+ [REL 13 Come pianifichi il disaster recovery (DR)?](w2aac19b9c11c13.md)
# REL 9 In che modo esegui il backup dei dati?
Esegui il backup dei dati, delle applicazioni e della configurazione per soddisfare i tuoi requisiti relativi agli obiettivi di tempo di ripristino (recovery time objective, RTO) e agli obiettivi di punto di ripristino (recovery point objective, RPO).
**Topics**
+ [REL09-BP01 Identificazione e backup di tutti i dati che richiedono un backup o riproduzione dei dati dalle origini](rel_backing_up_data_identified_backups_data.md)
+ [REL09-BP02 Protezione e codifica dei backup](rel_backing_up_data_secured_backups_data.md)
+ [REL09-BP03 Esecuzione del backup dei dati in automatico](rel_backing_up_data_automated_backups_data.md)
+ [REL09-BP04 Ripristino periodico dei dati per verificare l'integrità e i processi di backup:](rel_backing_up_data_periodic_recovery_testing_data.md)
# REL09-BP01 Identificazione e backup di tutti i dati che richiedono un backup o riproduzione dei dati dalle origini
Tutti i data store AWS offrono funzionalità di backup. Servizi come Amazon RDS e Amazon DynamoDB supportano inoltre il backup automatico che consente il ripristino point-in-time (PITR), grazie al quale è possibile ripristinare un backup in qualsiasi momento fino a cinque minuti o meno rispetto all'ora corrente. Molti servizi AWS offrono la possibilità di copiare i backup su un'altra Regione AWS. AWS Backup è uno strumento che consente di centralizzare e automatizzare la protezione dei dati tra i vari servizi AWS.
Amazon S3 può essere utilizzato come destinazione di backup per le origini dei dati gestite dal cliente e gestite da AWS. I servizi AWS come Amazon EBS, Amazon RDS e Amazon DynamoDB hanno funzionalità incorporate per creare i backup. È anche possibile utilizzare software di backup di terze parti.
È possibile eseguire il backup dei dati on-premise in Cloud AWS utilizzando [Gateway di archiviazione AWS](https://docs.aws.amazon.com/storagegateway/latest/vgw/WhatIsStorageGateway.html) oppure [AWS DataSync](https://docs.aws.amazon.com/datasync/latest/userguide/what-is-datasync.html). I bucket Amazon S3 possono essere utilizzati per archiviare questi dati su AWS. Amazon S3 offre più livelli di archiviazione, quali [Amazon Glacier oppure S3 Glacier Deep Archive](https://docs.aws.amazon.com/prescriptive-guidance/latest/backup-recovery/amazon-s3-glacier.html) per ridurre i costi di archiviazione dei dati.
Potresti essere in grado di soddisfare le esigenze di recupero dei dati riproducendo i dati da altre origini. Ad esempio, [I nodi di replica Amazon Elasticache](https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/Replication.Redis.Groups.html) oppure [Repliche di lettura RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ReadRepl.html) possono essere utilizzati per riprodurre i dati in caso di perdita dei dati primari. Nei casi in cui origini di questo tipo possono essere utilizzate per raggiungere [l'Obiettivo del punto di ripristino (RPO) e l'Obiettivo del tempo di ripristino (RTO),](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/disaster-recovery-dr-objectives.html)potrebbe non essere necessario un backup. Un altro esempio: se con Amazon EMR, potrebbe non essere necessario eseguire il backup del data store HDFS, [purché sia possibile riprodurre i dati in EMR da S3](https://aws.amazon.com/premiumsupport/knowledge-center/copy-s3-hdfs-emr/).
Quando scegli una strategia di backup, devi considerare il tempo necessario per il ripristino dei dati. Il tempo necessario per il ripristino dei dati dipende dal tipo di backup (nel caso di una strategia di backup) o dalla complessità del meccanismo di riproduzione dei dati. Questo tempo deve rientrare nell'RTO per il carico di lavoro.
**Risultato desiderato: **
le origini dei dati sono state identificate e classificate in base alla criticità. Quindi, stabilisci una strategia per il recupero dei dati in base all'RPO. Questa strategia prevede il backup di queste origini dei dati o la possibilità di riprodurre i dati da altre origini. In caso di perdita di dati, la strategia implementata consente il recupero o la riproduzione dei dati entro i termini RPO e RTO definiti.
**Fase di maturità del cloud:** Foundational
**Anti-pattern comuni:**
+ Mancata conoscenza di tutte le origini dei dati per il carico di lavoro e della loro criticità.
+ Non si eseguono backup delle origini dei dati critiche.
+ Esecuzione di backup solo di alcune origini dei dati senza utilizzare la criticità come criterio.
+ Non esiste un RPO definito o la frequenza di backup non può soddisfare l'RPO.
+ Nessuna valutazione della necessità di un backup o della possibilità di riprodurre i dati da altre origini.
**Vantaggi dell'adozione di questa best practice:** L'identificazione dei punti in cui sono necessari i backup e l'implementazione di un meccanismo per la creazione di backup, o la possibilità di riprodurre i dati da una fonte esterna, migliorano la capacità di ripristinare e recuperare i dati durante un'interruzione.
**Livello di rischio associato se questa best practice non fosse adottata:** Alta
## Guida all'implementazione
Scopri e utilizza le funzionalità di backup dei servizi e delle risorse AWS utilizzati dal carico di lavoro. La maggior parte dei servizi AWS offre funzionalità per eseguire il backup dei dati del carico di lavoro.
**Passaggi dell'implementazione**
1. **Identificazione di tutte le origini dei dati per il carico di lavoro**. I dati possono essere memorizzati su diverse risorse, come ad esempio [database](https://aws.amazon.com/products/databases/), [volumi](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-volume-types.html), [filesystem](https://docs.aws.amazon.com/efs/latest/ug/whatisefs.html), [sistemi di registrazione](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/WhatIsCloudWatchLogs.html)e [archiviazione di oggetti](https://docs.aws.amazon.com/AmazonS3/latest/userguide/Welcome.html). Consulta la sezione **Risorse** per trovare **Documenti correlati** ai diversi servizi AWS in cui vengono archiviati i dati e la capacità di backup che questi servizi offrono.
1. **Classificazione delle origini dei dati in base alla criticità**. I diversi set di dati avranno diversi livelli di criticità per un carico di lavoro e quindi diversi requisiti di resilienza. Ad esempio, alcuni dati possono essere critici e richiedere un RPO prossimo allo zero, mentre altri dati possono essere meno critici e tollerare un RPO più elevato e una certa perdita di dati. Allo stesso modo, anche i diversi set di dati possono avere requisiti RTO diversi.
1. **Utilizza i servizi AWS o di terze parti per creare i backup dei dati**. [AWS Backup](https://docs.aws.amazon.com/aws-backup/latest/devguide/whatisbackup.html) è un servizio gestito che permette di creare backup di varie origini dei dati su AWS. La maggior parte di questi servizi dispone anche di funzionalità native per la creazione di backup. Marketplace AWS ha molte soluzioni che offrono anche queste funzionalità. Consulta lo **Risorse** elencate di seguito per informazioni su come creare backup dei dati da vari servizi AWS.
1. **Per i dati non sottoposti a backup, stabilire un meccanismo di riproduzione dei dati**. Puoi decidere di non eseguire il backup di dati riproducibili da altre origini per vari motivi. Potrebbe essere più conveniente riprodurre i dati dalle origini, quando necessario, piuttosto che creare un backup, dato che l'archiviazione dei backup può comportare dei costi. Un altro esempio è quello in cui il ripristino da un backup richiede più tempo rispetto alla riproduzione dei dati dalle origini, con conseguente violazione dell'RTO. In queste situazioni, è necessario considerare i compromessi e stabilire un processo ben definito per la riproduzione dei dati da queste origini quando è necessario il ripristino dei dati. Ad esempio, se hai caricato dati da Amazon S3 su un data warehouse (come Amazon Redshift) o su un cluster MapReduce (come Amazon EMR) per compiere analisi, ottieni un esempio pratico di riproduzione dati da oltre origini. Finché i risultati di queste analisi vengono archiviati o sono riproducibili, non subirai una perdita di dati a causa di un guasto nel data warehouse o nel cluster MapReduce. Altri esempi che possono essere riprodotti dalle origini includono le cache (ad esempio Amazon ElastiCache) o le repliche di lettura RDS.
1. **Stabilisci una cadenza per il backup dei dati**. La creazione di backup delle origini dei dati è un processo periodico e la frequenza deve dipendere dall'RPO.
**Livello di impegno per il piano di implementazione:** Moderato
## Risorse
**Best practice correlate:**
[REL13-BP01 Definizione degli obiettivi di ripristino in caso di downtime e perdita di dati](rel_planning_for_recovery_objective_defined_recovery.md)
[REL13-BP02 Utilizzo di strategie di ripristino definite per conseguire gli obiettivi di ripristino](rel_planning_for_recovery_disaster_recovery.md)
**Documenti correlati:**
+ [Che cos'è AWS Backup?](https://docs.aws.amazon.com/aws-backup/latest/devguide/whatisbackup.html)
+ [What is AWS DataSync? (Che cos'è AWS DataSync?)](https://docs.aws.amazon.com/datasync/latest/userguide/what-is-datasync.html)
+ [What is Volume Gateway? (Che cos'è il Gateway di volumi?)](https://docs.aws.amazon.com/storagegateway/latest/vgw/WhatIsStorageGateway.html)
+ [Partner APN: partner per il backup](https://aws.amazon.com/partners/find/results/?keyword=Backup)
+ [Marketplace AWS: prodotti che possono essere utilizzati per il backup](https://aws.amazon.com/marketplace/search/results?searchTerms=Backup)
+ [Snapshot Amazon EBS](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSSnapshots.html)
+ [Backing Up Amazon EFS (Backup di Elastic File System)](https://docs.aws.amazon.com/efs/latest/ug/efs-backup-solutions.html)
+ [Backup di Amazon FSx per Windows File Server](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/using-backups.html)
+ [Backup e ripristino di ElastiCache for Redis](https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/backups.html)
+ [Creating a DB Cluster Snapshot in Neptune (Creazione di uno snapshot cluster DB in Neptune)](https://docs.aws.amazon.com/neptune/latest/userguide/backup-restore-create-snapshot.html)
+ [Creazione di uno snapshot DB](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_CreateSnapshot.html)
+ [Creating an EventBridge Rule That Triggers on a Schedule (Creazione di una regola EventBridge che viene eseguita in base a una pianificazione)](https://docs.aws.amazon.com/eventbridge/latest/userguide/create-eventbridge-scheduled-rule.html)
+ [Replica tra Regioni](https://docs.aws.amazon.com/AmazonS3/latest/dev/crr.html) con Amazon S3
+ [EFS-to-EFS AWS Backup (Backup da EFS a EFS)](https://aws.amazon.com/solutions/efs-to-efs-backup-solution/)
+ [Esportazione di dati di registro in Amazon S3](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/S3Export.html)
+ [Gestione del ciclo di vita dell'applicazione](https://docs.aws.amazon.com/AmazonS3/latest/dev/object-lifecycle-mgmt.html)
+ [Backup e ripristino on demand per DynamoDB](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/backuprestore_HowItWorks.html)
+ [Point-in-time recovery for DynamoDB (Ripristino point-in-time per DynamoDB)](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/PointInTimeRecovery.html)
+ [Gestione di snapshot degli indici Amazon OpenSearch Service](https://docs.aws.amazon.com/elasticsearch-service/latest/developerguide/es-managedomains-snapshots.html)
**Video correlati:**
+ [AWS re:Invent 2021 - Backup, disaster recovery, and ransomware protection with AWS (Backup, ripristino di emergenza e protezione ransomware con AWS)](https://www.youtube.com/watch?v=Ru4jxh9qazc)
+ [AWS Backup Demo: Cross-Account and Cross-Region Backup (Backup trasversale tra account e tra regioni)](https://www.youtube.com/watch?v=dCy7ixko3tE)
+ [AWS re:Invent 2019: Deep dive on AWS Backup(Approfondimento si AWS Backup), ft. Rackspace (STG341) ](https://youtu.be/av8DpL0uFjc)
**Esempi correlati:**
+ [Well-Architected lab: Implementing Bi-Directional Cross-Region Replication (CRR) for Amazon S3 (Laboratorio Well-Architected: Implementazione della replica bi-direzionale tra regioni (CRR) per Amazon S3) ](https://wellarchitectedlabs.com/reliability/200_labs/200_bidirectional_replication_for_s3/)
+ [Corso Well-Architected: Testing Backup and Restore of Data](https://wellarchitectedlabs.com/reliability/200_labs/200_testing_backup_and_restore_of_data/)
+ [Well-Architected lab: Backup and Restore with Failback for Analytics Workload (Laboratorio Well-Architected: Backup e ripristino con failback per il carico di lavoro analitico)](https://wellarchitectedlabs.com/reliability/200_labs/200_backup_restore_failback_analytics/)
+ [Well-Architected lab: Disaster Recovery - Backup and Restore (Laboratorio Well-Architected: Ripristino di emergenza – Backup e ripristino)](https://wellarchitectedlabs.com/reliability/disaster-recovery/workshop_1/)
# REL09-BP02 Protezione e codifica dei backup
Controlla e rileva l'accesso ai backup utilizzando l'autenticazione e l'autorizzazione, come ad esempio AWS IAM. Previeni e rileva se l'integrità dei dati dei backup è compromessa utilizzando la crittografia.
Amazon S3 supporta diversi metodi di crittografia dei dati archiviati. Utilizzando la crittografia lato server, Amazon S3 accetta anche dati non crittografati e li crittografa man mano che vengono memorizzati. Utilizzando la crittografia lato client, l'applicazione del carico di lavoro è responsabile della crittografia dei dati prima che vengano inviati a Amazon S3. Entrambi i metodi ti consentono di utilizzare AWS Key Management Service (AWS KMS) per creare ed archiviare la chiave di crittografia dei dati, oppure di utilizzarne una personalizzata (della quale sarai responsabile). Tramite AWS KMS puoi impostare delle policy utilizzando IAM per regolare l'accesso alle chiavi dei dati, oltre che ai dati privi di crittografia.
Per Amazon RDS, se hai scelto di crittografare i database, anche i backup verranno crittografati. I backup di DynamoDB sono sempre crittografati.
**Anti-pattern comuni:**
+ Disporre di un accesso identico sia per i backup e l'automazione del ripristino sia per i dati.
+ Non codificare i backup.
**Vantaggi dell'adozione di questa best practice:** La protezione dei backup previene la manomissione dei dati, mentre la crittografia dei dati impedisce l'accesso in caso di esposizione accidentale.
**Livello di rischio associato se questa best practice non fosse adottata:** Alta
## Guida all'implementazione
+ Utilizzo della crittografia su ciascuno dei datastore. Se i dati di origine sono crittografati, lo sarà anche il backup.
+ Abilitazione della crittografia in RDS. Puoi configurare la crittografia dei dati inattivi utilizzando AWS Key Management Service al momento della creazione di un'istanza RDS.
+ [Crittografia delle risorse Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Overview.Encryption.html)
+ Abilitazione della crittografia sui volumi EBS. Puoi configurare la crittografia predefinita o specificare una chiave univoca al momento della creazione del volume.
+ [Crittografia Amazon EBS](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSEncryption.html)
+ Utilizza la crittografia Amazon DynamoDB richiesta. DynamoDB crittografa tutti i dati a riposo. Puoi utilizzare una chiave AWS KMS di proprietà di AWS o una chiave KMS gestita da AWS specificando una chiave archiviata nel tuo account.
+ [Crittografia a riposo per DynamoDB](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/EncryptionAtRest.html)
+ [Gestione di tabelle crittografate](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/encryption.tutorial.html)
+ Codifica dei dati archiviati in Amazon EFS. Configura la crittografia al momento della creazione del file system.
+ [Crittografia dei dati e dei metadati in EFS](https://docs.aws.amazon.com/efs/latest/ug/encryption.html)
+ Configura la crittografia nelle regioni di origine e di destinazione. Puoi configurare la crittografia dei dati inattivi in Amazon S3 utilizzando le chiavi archiviate in KMS, ma le chiavi sono specifiche per regione. Puoi specificare le chiavi di destinazione quando configuri la replica.
+ [Configurazione aggiuntiva CRR: replica di oggetti creati con crittografia lato server (SSE) utilizzando le chiavi di crittografia archiviate in AWS KMS](https://docs.aws.amazon.com/AmazonS3/latest/dev/crr-replication-config-for-kms-objects.html)
+ Implementazione delle autorizzazioni con privilegi minimi per accedere ai backup. Segui le best practice per limitare l'accesso a backup, snapshot e repliche in conformità con le best practice di sicurezza.
+ [Pilastro della sicurezza – AWS Well-Architected](./wat.pillar.security.en.html)
## Risorse
**Documenti correlati:**
+ [Marketplace AWS: prodotti che possono essere utilizzati per il backup](https://aws.amazon.com/marketplace/search/results?searchTerms=Backup)
+ [Crittografia Amazon EBS](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSEncryption.html)
+ [Amazon S3: protezione dei dati tramite la crittografia](https://docs.aws.amazon.com/AmazonS3/latest/dev/UsingEncryption.html)
+ [Configurazione aggiuntiva CRR: replica di oggetti creati con crittografia lato server (SSE) utilizzando le chiavi di crittografia archiviate in AWS KMS](https://docs.aws.amazon.com/AmazonS3/latest/dev/crr-replication-config-for-kms-objects.html)
+ [Crittografia a riposo per DynamoDB](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/EncryptionAtRest.html)
+ [Crittografia delle risorse Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Overview.Encryption.html)
+ [Crittografia dei dati e dei metadati in EFS](https://docs.aws.amazon.com/efs/latest/ug/encryption.html)
+ [Encryption for Backups in AWS (Crittografia per i backup in AWS Backup)](https://docs.aws.amazon.com/aws-backup/latest/devguide/encryption.html)
+ [Gestione di tabelle crittografate](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/encryption.tutorial.html)
+ [Pilastro della sicurezza – AWS Well-Architected](./wat.pillar.security.en.html)
**Esempi correlati:**
+ [Well-Architected lab: Implementing Bi-Directional Cross-Region Replication (CRR) for Amazon S3 (Laboratorio Well-Architected: Implementazione della replica bi-direzionale tra regioni (CRR) per Amazon S3) ](https://wellarchitectedlabs.com/reliability/200_labs/200_bidirectional_replication_for_s3/)
# REL09-BP03 Esecuzione del backup dei dati in automatico
Configura i backup in modo che vengano eseguiti automaticamente in base a una pianificazione periodica informata dall'Obiettivo del punto di ripristino (RPO) o dalle modifiche apportate al set di dati. I set di dati critici con bassi requisiti di perdita di dati devono essere sottoposti a backup automatico su base frequente, mentre i dati meno critici, per i quali è accettabile una certa perdita, possono essere sottoposti a backup meno frequenti.
AWS Backup può essere utilizzato per creare backup automatici di varie origini dei dati AWS. Il backup delle istanze Amazon RDS può essere eseguito quasi ininterrottamente ogni cinque minuti e quello degli oggetti Amazon S3 quasi ininterrottamente ogni quindici minuti, consentendo il ripristino point-in-time (PITR) a un punto specifico della cronologia di backup. Per altre origini dei dati AWS, come volumi Amazon EBS, tabelle Amazon DynamoDB o file system Amazon FSx, AWS Backup può eseguire il backup automatico con una frequenza di un'ora. Questi servizi offrono anche funzionalità di backup nativo. I servizi AWS che offrono un backup automatizzato con ripristino point-in-time includono [Amazon DynamoDB](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/PointInTimeRecovery_Howitworks.html), [Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_PIT.html)e [Amazon Keyspaces (per Apache Cassandra)](https://docs.aws.amazon.com/keyspaces/latest/devguide/PointInTimeRecovery.html) ; questi possono essere ripristinati a un punto specifico della cronologia di backup. La maggior parte degli altri servizi di archiviazione di dati AWS offre la possibilità di programmare backup periodici, anche ogni ora.
Amazon RDS e Amazon DynamoDB offrono un backup continuo con ripristino point-in-time. Una volta abilitato, il controllo delle versioni Amazon S3 è automatico. [Amazon Data Lifecycle Manager](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/snapshot-lifecycle.html) può essere utilizzato per automatizzare la creazione, la copia e l'eliminazione degli snapshot Amazon EBS. Può anche automatizzare la creazione, la copia, la rimozione e la cancellazione di Amazon Machine Images (AMI) con backup Amazon EBS e dei relativi snapshot Amazon EBS sottostanti.
Per una visualizzazione centralizzata dell'automazione e della cronologia dei backup, AWS Backup fornisce una soluzione di backup completamente gestita basata su policy. Centralizza e automatizza il backup dei dati su più servizi AWS nel cloud e on-premise utilizzando Gateway di archiviazione AWS.
Oltre a quella di controllo delle versioni, Amazon S3 offre tutte le funzioni di replica. L'intero bucket S3 può essere replicato automaticamente in un altro bucket in una Regione AWS diversa.
**Risultato desiderato: **
un processo automatizzato che crea backup delle origini dei dati con una cadenza stabilita.
**Anti-pattern comuni:**
+ Eseguire i backup manualmente.
+ Utilizzare risorse che dispongono di funzionalità di backup, ma non includere il backup nell'automazione.
**Vantaggi dell'adozione di questa best practice:** L'automazione dei backup garantisce che vengano eseguiti regolarmente in base all'RPO e avvisa se non vengono eseguiti.
**Livello di rischio associato se questa best practice non fosse adottata:** Medium
## Guida all'implementazione
1. **Identifica le origini dei dati** al momento sottoposte a backup manuale. Consulta [REL09-BP01 Identificazione e backup di tutti i dati che richiedono un backup o riproduzione dei dati dalle origini](rel_backing_up_data_identified_backups_data.md) per avere una guida.
1. **Determina l'RPO** per il carico di lavoro. Consulta [REL13-BP01 Definizione degli obiettivi di ripristino in caso di downtime e perdita di dati](rel_planning_for_recovery_objective_defined_recovery.md) per avere una guida.
1. **Utilizza una soluzione di backup automatico o un servizio gestito**. AWS Backup è un servizio completamente gestito che semplifica [la centralizzazione e l'automazione della protezione dei dati tra i servizi AWS, nel cloud e on-premise](https://docs.aws.amazon.com/aws-backup/latest/devguide/creating-a-backup.html#creating-automatic-backups). I piani di backup sono una funzionalità di AWS Backup che consente di creare regole che definiscono le risorse da sottoporre a backup e la frequenza con cui questi backup devono essere creati. Questa frequenza deve essere informata dall'RPO stabilito al punto 2. [Questo laboratorio WA](https://wellarchitectedlabs.com/reliability/200_labs/200_testing_backup_and_restore_of_data/) fornisce una guida pratica su come creare backup automatizzati utilizzando AWS Backup. La maggior parte dei servizi AWS di archiviazione dei dati offre funzionalità di backup native. Ad esempio, RDS può essere sfruttato per backup automatici con ripristino point-in-time (PITR).
1. **Per le origini dei dati non supportate** da una soluzione di backup automatico o da un servizio gestito, come le origini dei dati on-premise o le code di messaggi, è consigliabile utilizzare una soluzione di terze parti affidabile per creare backup automatici. In alternativa, puoi creare un'automazione utilizzando la AWS CLI o gli SDK. Puoi utilizzare le funzioni AWS Lambda o AWS Step Functions per definire la logica di creazione di un backup dei dati e utilizzare Amazon EventBridge per eseguirlo con una frequenza basata sull'RPO (come stabilito nel passaggio 2).
**Livello di impegno per il piano di implementazione:** Bassa
## Risorse
**Documenti correlati:**
+ [Partner APN: partner per il backup](https://aws.amazon.com/partners/find/results/?keyword=Backup)
+ [Marketplace AWS: prodotti che possono essere utilizzati per il backup](https://aws.amazon.com/marketplace/search/results?searchTerms=Backup)
+ [Creating an EventBridge Rule That Triggers on a Schedule (Creazione di una regola EventBridge che viene eseguita in base a una pianificazione)](https://docs.aws.amazon.com/eventbridge/latest/userguide/create-eventbridge-scheduled-rule.html)
+ [Che cos'è AWS Backup?](https://docs.aws.amazon.com/aws-backup/latest/devguide/whatisbackup.html)
+ [Che cos'è AWS Step Functions?](https://docs.aws.amazon.com/step-functions/latest/dg/welcome.html)
**Video correlati:**
+ [AWS re:Invent 2019: Deep dive on AWS Backup(Approfondimento si AWS Backup), ft. Rackspace (STG341)](https://youtu.be/av8DpL0uFjc)
**Esempi correlati:**
+ [Corso Well-Architected: Testing Backup and Restore of Data](https://wellarchitectedlabs.com/reliability/200_labs/200_testing_backup_and_restore_of_data/)
# REL09-BP04 Ripristino periodico dei dati per verificare l'integrità e i processi di backup:
Esegui un test di ripristino per verificare che l'implementazione del processo di backup soddisfi gli obiettivi di tempo di ripristino (recovery time objective, RTO) e gli obiettivi di punto di ripristino (recovery point objective, RPO).
Con AWS, puoi creare un ambiente di test e ripristinare i backup per valutare le funzionalità RTO e RPO ed eseguire test sul contenuto e l'integrità dei dati.
Inoltre, Amazon RDS e Amazon DynamoDB consentono il ripristino point-in-time (PITR). Utilizzando il backup continuo, puoi ripristinare il set di dati allo stato in cui si trovava in una data e un'ora specificate.
**Risultato desiderato:** I dati dei backup vengono ripristinati periodicamente utilizzando meccanismi ben definiti per garantire che il ripristino sia possibile entro l'Obiettivo del tempo di ripristino (RTO) stabilito per il carico di lavoro. Verifica che il ripristino da un backup porti a una risorsa che contiene i dati originali senza che questi siano danneggiati o inaccessibili e con una perdita di dati entro l'Obiettivo del punto di ripristino (RPO).
**Anti-pattern comuni:**
+ Ripristinare un backup, senza però eseguire query o recuperare dati per garantire che il ripristino sia utilizzabile.
+ Presupporre l'esistenza di un backup.
+ Presupporre che il backup di un sistema sia pienamente operativo e che i dati possano essere recuperati da esso.
+ Presupporre che il tempo di ripristino o di recupero dei dati da un backup rientri nell'RTO del carico di lavoro.
+ Presupporre che i dati contenuti nel backup rientrino nell'RPO del carico di lavoro.
+ Ripristino ad hoc, senza l'utilizzo di un runbook o al di fuori di una procedura automatizzata consolidata.
**Vantaggi dell'adozione di questa best practice:** la verifica del ripristino dei backup assicura che i dati possano essere ripristinati quando necessario senza preoccuparsi che possano essere mancanti o danneggiati, che il ripristino e il recupero siano possibili entro l'RTO per il carico di lavoro e che qualsiasi perdita di dati rientri nell'RPO per il carico di lavoro.
**Livello di rischio associato se questa best practice non fosse adottata:** Medium
## Guida all'implementazione
La verifica delle capacità di backup e ripristino aumenta la fiducia nella capacità di eseguire queste azioni durante un'interruzione. Ripristina periodicamente i backup in una nuova posizione ed esegui test per verificare l'integrità dei dati. Alcuni test comuni da eseguire sono la verifica che
tutti i dati siano disponibili, non siano danneggiati, siano accessibili e che qualsiasi perdita di dati rientri nell'RPO del carico di lavoro. Questi test possono anche aiutare a verificare se i meccanismi di ripristino sono sufficientemente veloci per soddisfare l'RTO del carico di lavoro.
1. **Identifica le origini dei dati** di cui si sta eseguendo il backup e dove sono archiviati i backup. Consulta [REL09-BP01 Identificazione e backup di tutti i dati che richiedono un backup o riproduzione dei dati dalle origini](rel_backing_up_data_identified_backups_data.md) per una guida all'implementazione.
1. **Stabilisci i criteri per la convalida dei dati** per ogni origine dei dati. Tipi di dati differenti avranno proprietà diverse che potrebbero richiedere meccanismi di convalida diversi. Considera il modo in cui potrebbero essere convalidati questi dati prima di poterli utilizzare in produzione. Alcuni modi comuni per convalidare i dati sono l'uso delle loro proprietà dei dati e del backup, come il tipo di dati, il formato, la somma di controllo, la dimensione o la combinazione di questi elementi con una logica di convalida personalizzata. Ad esempio, può trattarsi di un confronto dei valori di checksum tra la risorsa ripristinata e l'origine dei dati al momento della creazione del backup.
1. **Stabilisci l'RTO e l'RPO** per il ripristino dei dati in base alla loro criticità. Consulta [REL13-BP01 Definizione degli obiettivi di ripristino in caso di downtime e perdita di dati](rel_planning_for_recovery_objective_defined_recovery.md) per una guida all'implementazione.
1. **Valuta la capacità di ripristino dei dati**. Rivedi la strategia di backup e ripristino per capire se è in grado di soddisfare RTO e RPO e modifica la strategia se necessario. Utilizzando [Hub di resilienza AWS](https://docs.aws.amazon.com/resilience-hub/latest/userguide/create-policy.html), puoi eseguire una valutazione del carico di lavoro. La valutazione esamina la configurazione dell'applicazione rispetto alle policy sulla resilienza e indica se gli obiettivi RTO e RPO possono essere raggiunti.
1. **Esegui un ripristino di prova** utilizzando i processi attualmente in uso in produzione per il ripristino dei dati. Questi processi dipendono dal modo in cui è stato eseguito il backup dell'origine dei dati iniziale, dal formato e dalla posizione di archiviazione del backup stesso o dalla riproduzione dei dati da altre fonti. Ad esempio, utilizzi un servizio gestito come [AWS Backup, questo potrebbe essere semplice come il ripristino del backup in una nuova risorsa](https://docs.aws.amazon.com/aws-backup/latest/devguide/restoring-a-backup.html). Se hai utilizzato il Ripristino di emergenza elastico AWS, puoi [avviare un'analisi di ripristino](https://docs.aws.amazon.com/drs/latest/userguide/failback-preparing.html).
1. **Convalida il ripristino dei dati** dalla risorsa ripristinata (dal passo precedente) in base ai criteri stabiliti in precedenza per la convalida dei dati al passo 2. I dati ripristinati e recuperati contengono il record/la voce più recente al momento del backup? Questi dati rientrano nell'RPO per il carico di lavoro?
1. **Misura il tempo richiesto** per il ripristino e il recupero e confrontalo con l'RTO stabilito in precedenza nel passaggio 3. Questo tempo deve rientrare nell'RTO per il carico di lavoro? Ad esempio, confronta i timestamp dell'inizio del processo di ripristino e del completamento della convalida del ripristino per calcolare la durata del processo. Tutte le chiamate API AWS hanno una datazione temporale e queste informazioni sono disponibili in [AWS CloudTrail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-user-guide.html). Sebbene queste informazioni possano fornire dettagli sull'inizio del processo di ripristino, la logica di convalida dovrebbe registrare il timestamp finale del completamento della convalida. Se utilizzi un processo automatizzato, puoi utilizzare servizi come [Amazon DynamoDB](https://aws.amazon.com/dynamodb/) per l'archiviazione di queste informazioni. Inoltre, molti servizi AWS offrono una cronologia degli eventi che fornisce informazioni con data e ora in cui si sono verificate determinate azioni. All'interno di AWS Backup, le azioni di backup e di ripristino sono denominate *processi*e questi processi contengono informazioni sulla data e l'ora come parte dei metadati che possono essere utilizzati per misurare il tempo necessario per il ripristino e il recupero.
1. **Invia notifica alle parti interessate (stakeholder)** se la convalida dei dati non riesce o se il tempo necessario per il ripristino e il recupero supera l'RTO stabilito per il carico di lavoro. Quando si implementa l'automazione per farlo, [come in questo laboratorio,](https://wellarchitectedlabs.com/reliability/200_labs/200_testing_backup_and_restore_of_data/)servizi come Amazon Simple Notification Service (Amazon SNS) possono essere utilizzati per inviare notifiche push, come e-mail o SMS, alle parti interessate. [Questi messaggi possono anche essere pubblicati su applicazioni di messaggistica come Amazon Chime, Slack o Microsoft Teams](https://aws.amazon.com/premiumsupport/knowledge-center/sns-lambda-webhooks-chime-slack-teams/) o utilizzati per [creare attività come OpsItem utilizzando OpsCenter di AWS Systems Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/OpsCenter-creating-OpsItems.html).
1. **Automatizzare questo processo per eseguirlo periodicamente**. Ad esempio, per automatizzare i processi di ripristino e recupero si possono utilizzare servizi come AWS Lambda o una State Machine in AWS Step Functions, mentre Amazon EventBridge può essere utilizzato per attivare periodicamente questo flusso di lavoro di automazione, come mostrato nel diagramma di architettura sottostante. Scopri come [automatizzare la convalida del ripristino dati con AWS Backup](https://aws.amazon.com/blogs/storage/automate-data-recovery-validation-with-aws-backup/). Inoltre, [questo laboratorio Well-Architected](https://wellarchitectedlabs.com/reliability/200_labs/200_testing_backup_and_restore_of_data/) fornisce un'esperienza pratica su come realizzare l'automazione di alcuni dei passaggi qui descritti.
![\[Diagramma che mostra un processo di backup e ripristino automatizzato\]](http://docs.aws.amazon.com/it_it/wellarchitected/2022-03-31/framework/images/automated-backup-restore-process.png)
**Livello di impegno per il piano di implementazione:** da moderato a elevato, a seconda della complessità dei criteri di convalida.
## Risorse
**Documenti correlati:**
+ [automatizzare la convalida del ripristino dati con AWS Backup](https://aws.amazon.com/blogs/storage/automate-data-recovery-validation-with-aws-backup/)
+ [Partner APN: partner per il backup](https://aws.amazon.com/partners/find/results/?keyword=Backup)
+ [Marketplace AWS: prodotti che possono essere utilizzati per il backup](https://aws.amazon.com/marketplace/search/results?searchTerms=Backup)
+ [Creating an EventBridge Rule That Triggers on a Schedule (Creazione di una regola EventBridge che viene eseguita in base a una pianificazione)](https://docs.aws.amazon.com/eventbridge/latest/userguide/create-eventbridge-scheduled-rule.html)
+ [Backup e ripristino on demand per DynamoDB](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/BackupRestore.html)
+ [Che cos'è AWS Backup?](https://docs.aws.amazon.com/aws-backup/latest/devguide/whatisbackup.html)
+ [Che cos'è AWS Step Functions?](https://docs.aws.amazon.com/step-functions/latest/dg/welcome.html)
+ [What is AWS Elastic Disaster Recovery (Che cos'è il ripristino di emergenza elastico AWS?)](https://docs.aws.amazon.com/drs/latest/userguide/what-is-drs.html)
+ [AWS Elastic Disaster Recovery (Ripristino di emergenza elastico AWS)](https://docs.aws.amazon.com/resilience-hub/latest/userguide/what-is.html)
**Esempi correlati:**
+ [Corso Well-Architected: Testing Backup and Restore of Data](https://wellarchitectedlabs.com/reliability/200_labs/200_testing_backup_and_restore_of_data/)
# REL 10 In che modo utilizzi l'isolamento dei guasti per proteggere il carico di lavoro?
Le barriere per l'isolamento dei guasti limitano l'effetto di un errore all'interno di un carico di lavoro a un numero limitato di componenti. I componenti al di fuori della barriera non subiscono gli effetti del guasto. Utilizzando più barriere per l'isolamento dei guasti, puoi limitare l'impatto sul carico di lavoro.
**Topics**
+ [REL10-BP01 Implementazione del carico di lavoro in diversi luoghi](rel_fault_isolation_multiaz_region_system.md)
+ [REL10-BP02 Selezione delle posizioni appropriate per la tua implementazione multiposizione](rel_fault_isolation_select_location.md)
+ [REL10-BP03 Ripristino automatico dei componenti vincolati a una singola posizione](rel_fault_isolation_single_az_system.md)
+ [REL10-BP04 Utilizzo di architetture a paratie per limitare la portata dell'impatto](rel_fault_isolation_use_bulkhead.md)
# REL10-BP01 Implementazione del carico di lavoro in diversi luoghi
Distribuisci i dati e le risorse del carico di lavoro su più zone di disponibilità o, se necessario, su diverse Regioni AWS. Questi luoghi possono essere diversi a seconda delle necessità.
Uno dei principi fondamentali per la progettazione di servizi su AWS è l'eliminazione di singoli punti di errore nell'infrastruttura fisica sottostante. Questo ci spinge a creare software e sistemi che utilizzano più zone di disponibilità e sono resistenti al fallimento di una singola zona. Allo stesso modo, i sistemi sono costruiti per resistere ai guasti di un singolo nodo di calcolo, singolo volume di archiviazione o singola istanza di un database. Quando si costruisce un sistema che si basa su componenti ridondanti, è importante garantire che i componenti funzionino in modo indipendente e, nel caso delle Regioni AWS, in modo autonomo. I vantaggi ottenuti dai calcoli di disponibilità teorica con componenti ridondanti sono validi solo se questo continua a essere vero.
**Zone di disponibilità (AZ)**
Le Regioni AWS sono composte da almeno due zone di disponibilità progettate per essere indipendenti. Ogni zona di disponibilità è separata da una distanza fisica significativa da altre zone per evitare scenari di guasto correlati, dovuti a rischi ambientali come incendi, inondazioni e tornado. Ogni zona di disponibilità ha anche un'infrastruttura fisica indipendente: connessioni dedicate di alimentazione di rete, fonti di alimentazione di backup autonome, servizi meccanici indipendenti e connettività di rete indipendente all'interno e all'esterno della zona di disponibilità. Questa struttura limita gli errori di uno qualsiasi di questi sistemi alla sola AZ interessata. Nonostante siano geograficamente separate, le zone di disponibilità sono situate nella stessa area regionale, il che consente una rete a velocità di trasmissione effettiva elevata e bassa latenza. L'intera Regione AWS (in tutte le zone di disponibilità, costituite da più data center fisicamente indipendenti) può essere trattata come un unico obiettivo logico di implementazione per il carico di lavoro, compresa la possibilità di replicare i dati in modo sincrono (ad esempio, tra i database). Ciò ti consente di utilizzare le zone di disponibilità in una configurazione attiva/attiva o attiva/standby.
Le zone di disponibilità sono indipendenti e pertanto la disponibilità del carico di lavoro aumenta quando il carico di lavoro è progettato per utilizzare più zone di disponibilità. Alcuni servizi AWS (tra cui il piano dati dell'istanza Amazon EC2) sono implementati come servizi strettamente zonali nei quali hanno un destino condiviso con la zona di disponibilità in cui si trovano. Le istanze Amazon EC2 nelle altre AZ non saranno, tuttavia, interessate e continueranno a funzionare. Allo stesso modo, se un errore in una zona di disponibilità causa l'errore di un database Amazon Aurora, un'istanza Aurora di lettura-replica in una AZ non interessata può essere automaticamente promossa a primaria. I servizi regionali AWS, ad esempio Amazon DynamoDB, utilizzano internamente più zone di disponibilità in una configurazione attiva/attiva per raggiungere gli obiettivi di progettazione della disponibilità per quel servizio, senza che sia necessario configurare il posizionamento delle AZ.
![\[Diagramma che mostra un'architettura multi-livello implementata su tre zone di disponibilità. Tieni presente che Amazon S3 e Amazon DynamoDB sono sempre Multi-AZ automaticamente. L'ELB viene inoltre distribuito in tutte e tre le zone.\]](http://docs.aws.amazon.com/it_it/wellarchitected/2022-03-31/framework/images/multi-tier-architecture.png)
Mentre i piani di controllo AWS in genere offrono la possibilità di gestire le risorse all'interno dell'intera Regione (più zone di disponibilità), alcuni piani di controllo (inclusi Amazon EC2 ed Amazon EBS) hanno la capacità di filtrare i risultati per una singola zona di disponibilità. Con questo approccio, la richiesta viene elaborata solo nella zona di disponibilità specificata, riducendo l'esposizione all'interruzione in altre zone di disponibilità. Questo esempio di AWS CLI illustra come ottenere informazioni su un'istanza Amazon EC2 dalla sola zona di disponibilità us-east-2c:
```
AWS ec2 describe-instances --filters Name=availability-zone,Values=us-east-2c
```
*Zone locali AWS*
Le Zone locali AWS agiscono in modo simile alle zone di disponibilità nella rispettiva Regione AWS, in quanto possono essere selezionate come ubicazione di posizionamento per le risorse AWS zonali come le sottoreti e le istanze EC2. Ciò che le rende speciali è che non si trovano nella Regione AWS associata, ma vicino a grandi popolazioni, settori e centri IT in cui al momento non esiste alcuna Regione AWS. Tuttavia, mantengono una connessione sicura e a larghezza di banda elevata tra i carichi di lavoro locali nella zona locale e quelli in esecuzione nella Regione AWS. È consigliabile utilizzare le Zone locali AWS per implementare i carichi di lavoro più vicini agli utenti per requisiti a bassa latenza.
**Amazon Global Edge Network**
Amazon Global Edge Network è costituito da posizioni edge in città di tutto il mondo. Amazon CloudFront utilizza questa rete per fornire contenuti agli utenti finali con una latenza inferiore. AWS Global Accelerator consente di creare gli endpoint del carico di lavoro in queste posizioni edge per fornire l'onboarding alla rete globale AWS vicino agli utenti. Amazon API Gateway permette agli endpoint API ottimizzati per l'edge che utilizzano una distribuzione CloudFront di facilitare l'accesso dei clienti attraverso la posizione edge più vicina.
*Regioni AWS*
Le Regioni AWS sono progettate per essere autonome; pertanto, per utilizzare un approccio multi-regione, puoi implementare copie dedicate dei servizi in ciascuna Regione.
Un approccio multi-regione è comune per *le strategie di ripristino di emergenza* per raggiungere gli obiettivi di ripristino quando si verificano eventi unici su larga scala. Consulta [https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/plan-for-disaster-recovery-dr.html](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/plan-for-disaster-recovery-dr.html) per ulteriori informazioni su queste strategie. Qui, tuttavia, si focalizza l'attenzione sulla *disponibilità*, che cerca di fornire un obiettivo medio di operatività nel tempo. Per gli obiettivi di alta disponibilità, un'architettura multi-regione sarà generalmente progettata per essere attiva/attiva, dove ogni copia del servizio (nelle rispettive Regioni) è attiva (serve le richieste).
**Consiglio**
Gli obiettivi di disponibilità per la maggior parte dei carichi di lavoro possono essere soddisfatti utilizzando una strategia multi-AZ all'interno di una singola Regione AWS. Considera le architetture multi-regione solo quando i carichi di lavoro hanno requisiti di disponibilità estremi o altri obiettivi aziendali che richiedono un'architettura multi-regione.
AWS offre ai clienti la possibilità di gestire servizi in più Regioni. Ad esempio, AWS fornisce una replica continua e asincrona dei dati utilizzando la replica Amazon Simple Storage Service (Amazon S3), le repliche di lettura Amazon RDS (incluse le repliche di lettura Aurora) e le tabelle globali Amazon DynamoDB. Con la replica continua, le versioni dei dati sono disponibili per un uso quasi immediato in ogni Regione attiva.
Utilizzando AWS CloudFormation, puoi definire l'infrastruttura e implementarla in modo coerente sugli Account AWS e sulle Regioni AWS. Invece, AWS CloudFormation StackSets estende questa funzionalità consentendo di creare, aggiornare o eliminare stack AWS CloudFormation su più account e regioni con un'unica operazione. Per le implementazioni di istanza Amazon EC2, si utilizza un'immagine AMI (Amazon Machine Image) per fornire informazioni quali la configurazione hardware e il software installato. È possibile implementare una pipeline di Amazon EC2 Image Builder che crea le AMI necessarie e le copia nelle regioni attive. Ciò garantisce che *le Golden AMI* abbiano tutto ciò che serve per implementare e dimensionare il carico di lavoro in ogni nuova regione.
Per instradare il traffico, sia Amazon Route 53 sia AWS Global Accelerator abilitano la definizione di criteri che determinano quali utenti indirizzare a ogni endpoint regionale attivo. Con Global Accelerator imposti un valore di traffico per controllare la percentuale di traffico diretta a ciascun endpoint dell'applicazione. Route 53 supporta questo approccio percentuale e anche diverse altre policy disponibili, tra cui quelle basate sulla geoprossimità e sulla latenza. Global Accelerator sfrutta automaticamente la vasta rete di server edge AWS per convogliare il traffico verso la dorsale di rete AWS il prima possibile, con conseguente riduzione delle latenze delle richieste.
Tutte queste capacità operano in modo da preservare l'autonomia di ogni Regione. Ci sono pochissime eccezioni a questo approccio, inclusi i nostri servizi che forniscono distribuzione edge globale (ad esempio Amazon CloudFront e Amazon Route 53), insieme al piano di controllo per il servizio AWS Identity and Access Management (IAM). La maggior parte dei servizi opera interamente all'interno di una singola Regione.
**Data center in locale**
Per i carichi di lavoro eseguiti in un data center on-premise, puoi progettare un'esperienza ibrida quando possibile. AWS Direct Connect fornisce una connessione di rete dedicata dalla tua sede ad AWS che consente l'esecuzione in entrambi.
Un'altra opzione è quella di eseguire l'infrastruttura AWS e i servizi on-premise utilizzando AWS Outposts. AWS Outposts è un servizio completamente gestito che estende l'infrastruttura AWS, i servizi AWS, le API e gli strumenti al tuo data center. La stessa infrastruttura hardware utilizzata nel Cloud AWS viene installata nel data center. AWS Outposts è, quindi, connesso alla Regione AWS più vicina. Puoi quindi utilizzare AWS Outposts per supportare i carichi di lavoro che hanno requisiti di bassa latenza o di elaborazione dei dati locali.
**Livello di rischio associato se questa best practice non fosse adottata:** Alta
## Guida all'implementazione
+ Utilizza zone di disponibilità multiple e Regioni AWS. Distribuisci i dati e le risorse del carico di lavoro su più zone di disponibilità o, se necessario, su diverse Regioni AWS. Questi luoghi possono essere diversi a seconda delle necessità.
+ I servizi regionali sono distribuiti intrinsecamente in zone di disponibilità.
+ Sono inclusi Amazon S3, Amazon DynamoDB e AWS Lambda (se non collegati a un VPC)
+ Distribuisci il tuo container, istanza e carichi di lavoro basati su funzioni in più zone di disponibilità. Utilizza datastore multi-zona, inclusi sistemi di cache. Utilizza le funzionalità di dimensionamento automatico EC2, posizionamento di attività ECS, configurazione della funzione AWS Lambda in esecuzione nel tuo VPC e i cluster ElastiCache.
+ Utilizza sottoreti che sono in zone di disponibilità separate nella distribuzione di gruppi Auto Scaling.
+ [Esempio: distribuzione di istanze in più zone di disponibilità](https://docs.aws.amazon.com/autoscaling/ec2/userguide/auto-scaling-benefits.html#arch-AutoScalingMultiAZ)
+ [Strategie di posizionamento dei processi di Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task-placement-strategies.html)
+ [Configurazione di una funzione AWS Lambda per accedere alle risorse in un Amazon VPC](https://docs.aws.amazon.com/lambda/latest/dg/vpc.html)
+ [Scelta di regioni e zone di disponibilità](https://docs.aws.amazon.com/AmazonElastiCache/latest/UserGuide/RegionsAndAZs.html)
+ Utilizza sottoreti in zone di disponibilità separate quando distribuisci gruppi Auto Scaling.
+ [Esempio: distribuzione di istanze in più zone di disponibilità](https://docs.aws.amazon.com/autoscaling/ec2/userguide/auto-scaling-benefits.html#arch-AutoScalingMultiAZ)
+ Utilizza parametri di posizionamento attività ECS, specificando i gruppi di sottorete DB.
+ [Strategie di posizionamento dei processi di Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task-placement-strategies.html)
+ Utilizza sottoreti in più zone di disponibilità quando configuri una funzione da eseguire nel tuo VPC.
+ [Configurazione di una funzione AWS Lambda per accedere alle risorse in un Amazon VPC](https://docs.aws.amazon.com/lambda/latest/dg/vpc.html)
+ Utilizza più zone di disponibilità con cluster ElastiCache.
+ [Scelta di regioni e zone di disponibilità](https://docs.aws.amazon.com/AmazonElastiCache/latest/UserGuide/RegionsAndAZs.html)
+ Se il carico di lavoro deve essere implementato in più Regioni, scegli una strategia multi-regione. La maggior parte delle esigenze di affidabilità può essere soddisfatta all'interno di una singola Regione AWS utilizzando una strategia a più zone di disponibilità. Quando necessario, utilizza una strategia multi-Regione per soddisfare le tue esigenze aziendali.
+ [AWS re:Invent 2018: Architecture Patterns for Multi-Region Active-Active Applications (Modelli architetturali per applicazioni attive-attive su più Regioni) (ARC209-R2)](https://youtu.be/2e29I3dA8o4)
+ Il backup in un'altra Regione AWS può garantire ulteriormente che i dati saranno disponibili quando necessario.
+ Alcuni carichi di lavoro hanno requisiti normativi che prevedono l'utilizzo di una strategia multi-regione.
+ Valuta AWS Outposts per il tuo carico di lavoro. Se il carico di lavoro richiede bassa latenza nel data center locale o ha requisiti di elaborazione dei dati locali. In tal caso esegui l'infrastruttura e i servizi AWS on-premise utilizzando AWS Outposts.
+ [Che cos'è AWS Outposts?](https://docs.aws.amazon.com/outposts/latest/userguide/what-is-outposts.html)
+ Stabilisci se le Zone locali AWS ti aiutano a fornire il servizio ai tuoi utenti. Se hai requisiti di bassa latenza, verifica se le Zone locali AWS si trovano vicino ai tuoi utenti. Se sì, utilizzale per implementare carichi di lavoro più vicini a tali utenti.
+ [Domande frequenti sulle Zone locali AWS](https://aws.amazon.com/about-aws/global-infrastructure/localzones/faqs/)
## Risorse
**Documenti correlati:**
+ [Infrastruttura globale di AWS](https://aws.amazon.com/about-aws/global-infrastructure)
+ [Domande frequenti sulle Zone locali AWS](https://aws.amazon.com/about-aws/global-infrastructure/localzones/faqs/)
+ [Strategie di posizionamento dei processi di Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task-placement-strategies.html)
+ [Scelta di regioni e zone di disponibilità](https://docs.aws.amazon.com/AmazonElastiCache/latest/UserGuide/RegionsAndAZs.html)
+ [Esempio: distribuzione di istanze in più zone di disponibilità](https://docs.aws.amazon.com/autoscaling/ec2/userguide/auto-scaling-benefits.html#arch-AutoScalingMultiAZ)
+ [Tabelle globali: replica multi-regione con DynamoDB](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/GlobalTables.html)
+ [Using Amazon Aurora global databases (Utilizzo di database Amazon Aurora globali)](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-global-database.html)
+ [Creating a Multi-Region Application with AWS Services blog series (Creazione di un'applicazione multi-regione con la serie di blog sui servizi AWS)](https://aws.amazon.com/blogs/architecture/tag/creating-a-multi-region-application-with-aws-services-series/)
+ [Che cos'è AWS Outposts?](https://docs.aws.amazon.com/outposts/latest/userguide/what-is-outposts.html)
**Video correlati:**
+ [AWS re:Invent 2018: Architecture Patterns for Multi-Region Active-Active Applications (Modelli architetturali per applicazioni attive-attive su più Regioni) (ARC209-R2)](https://youtu.be/2e29I3dA8o4)
+ [AWS re:Invent 2019: Innovation and operation of the AWS global network infrastructure (Innovazione e gestione dell'infrastruttura di rete globale AWS) (NET339)](https://youtu.be/UObQZ3R9_4c)
# REL10-BP02 Selezione delle posizioni appropriate per la tua implementazione multiposizione
## Risultato desiderato
Per ottenere un'elevata disponibilità, distribuisci sempre (quando possibile) i componenti del carico di lavoro in più zone di disponibilità (AZ), come illustrato nella Figura 10. Per i carichi di lavoro con requisiti di resilienza estremi, valuta attentamente le opzioni per un'architettura multiregione.
![\[Diagramma che mostra un'implementazione resiliente di database multi-AZ con backup in un'altra regione AWS\]](http://docs.aws.amazon.com/it_it/wellarchitected/2022-03-31/framework/images/multi-az-architecture.png)
## Anti-pattern comuni
+ Scelta di progettare un'architettura multi-regione quando un'architettura multi-AZ soddisferebbe i requisiti.
+ Non si tiene conto delle dipendenze tra i componenti dell'applicazione se i requisiti di resilienza e multi-sede differiscono tra questi componenti.
## Vantaggi dell'adozione di questa best practice
Per la resilienza, devi utilizzare un approccio che costruisca livelli di difesa. Un livello protegge dalle interruzioni più piccole e più comuni costruendo un'architettura ad alta disponibilità utilizzando più AZ. Un altro livello di difesa è destinato a proteggere da eventi rari come disastri naturali diffusi e interruzioni a livello regionale. Questo secondo livello implica l'architettura dell'applicazione in modo che si estenda su più Regioni AWS.
+ La differenza tra una disponibilità del 99,5% e una del 99,99% è di oltre 3,5 ore al mese. La disponibilità prevista di un carico di lavoro può raggiungere i "quattro nove" solo se si trova in più AZ.
+ Eseguendo il carico di lavoro in più AZ, puoi isolare gli errori di alimentazione, raffreddamento e rete e la maggior parte dei disastri naturali come incendi e inondazioni.
+ L'implementazione di una strategia multi-regione per il tuo carico di lavoro aiuta a proteggerlo da disastri naturali diffusi che colpiscono un'ampia regione geografica di un paese o da guasti tecnici di portata regionale. Tieni presente che l'implementazione di un'architettura multi-regione può essere molto complessa e di solito non è necessaria per la maggior parte dei carichi di lavoro.
**Livello di rischio associato se questa best practice non fosse adottata:** Alta
## Guida all'implementazione
Per un evento disastroso basato sull'interruzione o la perdita parziale di una zona di disponibilità, l'implementazione di un carico di lavoro a disponibilità elevata in più zone di disponibilità all'interno di una singola Regione AWS aiuta a mitigare i disastri naturali e tecnici. Ogni Regione AWS è composta da più zone di disponibilità, ciascuna isolata dagli errori nelle altre zone e separate da una distanza significativa. Tuttavia, per un evento di disastro che include il rischio di perdere più componenti della zona di disponibilità, che si trovano a una distanza significativa l'uno dall'altro, è necessario implementare opzioni di ripristino di emergenza per mitigare gli errori di portata regionale. Per i carichi di lavoro che richiedono un'estrema resilienza (infrastrutture critiche, applicazioni sanitarie, infrastrutture di sistemi finanziari e così via), può essere necessaria una strategia multi-regione.
## Passaggi dell'implementazione
1. Valutare il carico di lavoro e determinare se le esigenze di resilienza possono essere soddisfatte da un approccio multi-AZ (Regione AWS singola) o se richiedono un approccio multi-regione. L'implementazione di un'architettura multi-regione per soddisfare questi requisiti introdurrà un'ulteriore complessità, quindi considera attentamente il tuo caso d'uso e i suoi requisiti. I requisiti di resilienza possono quasi sempre essere soddisfatti utilizzando un singolo Regione AWS. Per stabilire se è necessario utilizzare più Regioni, considera i seguenti possibili requisiti:
1. **Ripristino di emergenza**: per un evento disastroso basato sull'interruzione o la perdita parziale di una zona di disponibilità, l'implementazione di un carico di lavoro a disponibilità elevata in più zone di disponibilità all'interno di una singola Regione AWS aiuta a mitigare i disastri naturali e tecnici. In caso di eventi disastrosi che comportano il rischio di perdere più componenti della zone di disponibilità, che si trovano a una distanza significativa l'uno dall'altro, è necessario implementare il ripristino di emergenza in più regioni per mitigare i disastri naturali o gli errori tecnici di portata regionale.
1. **Alta disponibilità**: è possibile utilizzare un'architettura multi-regione (utilizzando più AZ in ogni regione) per ottenere una disponibilità superiore a quattro 9 (> 99,99%).
1. **Localizzazione delle risorse**: quando si distribuisce un carico di lavoro a un pubblico globale, è possibile distribuire stack localizzati in diverse Regioni AWS per servire il pubblico di quelle regioni. La localizzazione può includere la lingua, la valuta e i tipi di dati memorizzati.
1. **Prossimità agli utenti:** quando si distribuisce un carico di lavoro a un pubblico globale, è possibile ridurre la latenza distribuendo gli stack alle regioni Regioni AWS in prossimità degli utenti finali.
1. **Posizione fisica dei dati**: alcuni carichi di lavoro sono soggetti a requisiti di residenza dei dati, in base ai quali i dati di determinati utenti devono rimanere all'interno dei confini di un determinato Paese. In base alla normativa in questione, è possibile scegliere di distribuire un intero stack o solo i dati nella Regione AWS all'interno di tali confini.
1. Ecco alcuni esempi di funzionalità multi-AZ fornite dai servizi AWS:
1. Per proteggere i carichi di lavoro che utilizzano EC2 o ECS, è necessario distribuire un Elastic Load Balancer davanti alle risorse di calcolo. Elastic Load Balancing quindi fornisce la soluzione per rilevare le istanze nelle zone non integre e instradare il traffico verso quelle integre.
1. [Nozioni di base su Application Load Balancers](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/application-load-balancer-getting-started.html)
1. [Nozioni di base su Network Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/network-load-balancer-getting-started.html)
1. Nel caso di istanze EC2 che eseguono software commerciale pronto all'uso e che non supportano il bilanciamento del carico, puoi ottenere una forma di tolleranza ai guasti implementando una metodologia di ripristino di emergenza multi-AZ.
1. [REL13-BP02 Utilizzo di strategie di ripristino definite per conseguire gli obiettivi di ripristino](rel_planning_for_recovery_disaster_recovery.md)
1. Per le attività Amazon ECS, distribuire il servizio in modo uniforme su tre AZ per ottenere un equilibrio tra disponibilità e costi.
1. [Amazon ECS availability best practices \$1 Containers (Best practice di disponibilità ECS \$1 Container)](https://aws.amazon.com/blogs/containers/amazon-ecs-availability-best-practices/)
1. Per non Aurora Amazon RDS, puoi scegliere multi-AZ come opzione di configurazione. In caso di errore dell'istanza del database primario, Amazon RDS promuove automaticamente un database standby per ricevere il traffico in un'altra zona di disponibilità. Puoi inoltre creare repliche di lettura multi-regione per migliorare la resilienza.
1. [Implementazioni Multi-AZ Amazon RDS](https://aws.amazon.com/rds/features/multi-az/)
1. [Creazione di una replica di lettura in un'altra Regione AWS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ReadRepl.XRgn.html)
1. Ecco alcuni esempi di funzionalità multi-AZ fornite dai servizi AWS:
1. Per i carichi di lavoro Amazon S3 in cui la disponibilità multi-AZ è fornita automaticamente dal servizio, considera i punti di accesso multi-regione se è necessaria un'implementazione multi-regione.
1. [Punti di accesso multi-regione in Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/MultiRegionAccessPoints.html)
1. Per le tabelle DynamoDB in cui la disponibilità multi-AZ è fornita automaticamente dal servizio, è possibile convertire facilmente le tabelle esistenti in tabelle globali per sfruttare più regioni.
1. [Convert Your Single-Region Amazon DynamoDB Tables to Global Tables (Convertire le tabelle Amazon DynamoDB di una singola regione in tabelle globali)](https://aws.amazon.com/blogs/aws/new-convert-your-single-region-amazon-dynamodb-tables-to-global-tables/)
1. Se il carico di lavoro è gestito da Application Load Balancers o da Network Load Balancer, utilizza AWS Global Accelerator per migliorare la disponibilità dell'applicazione indirizzando il traffico verso più regioni che contengono endpoint integri.
1. [Endpoints for standard accelerators in AWS Global Accelerator - AWS Global Accelerator (Endpoint per acceleratori standard in AWS Global Accelerator) (amazon.com)](https://docs.aws.amazon.com/global-accelerator/latest/dg/about-endpoints.html)
1. Per le applicazioni che sfruttano AWS EventBridge, considera i bus tre regioni per inoltrare gli eventi ad altre regioni selezionate.
1. [Sending and receiving Amazon EventBridge events between Regioni AWS (Invio e ricezione di eventi Amazon EventBridge tra regioni AWS)](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-cross-region.html)
1. Per i database Amazon Aurora, considera i database globali Aurora, che si estendono su più regioni AWS. I cluster esistenti possono essere modificati per aggiungere anche nuove Regioni.
1. [Nozioni di base sui database globali Amazon Aurora](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-global-database-getting-started.html)
1. Se il carico di lavoro include chiavi di crittografia AWS Key Management Service (AWS KMS), valuta se le chiavi multi-regione sono adatte all'applicazione.
1. [Chiavi multi-regione in AWS KMS](https://docs.aws.amazon.com/kms/latest/developerguide/multi-region-keys-overview.html)
1. Per altre funzionalità del servizio AWS, vedi questa serie di blog su [Creating a Multi-Region Application with AWS Services series (Creazione di un'applicazione multi-regione con la serie di servizi AWS)](https://aws.amazon.com/blogs/architecture/tag/creating-a-multi-region-application-with-aws-services-series/)
**Livello di impegno per il piano di implementazione: **da moderato ad alto
## Risorse
**Documenti correlati:**
+ [Creating a Multi-Region Application with AWS Services series (Creazione di un'applicazione multi-regione con la serie di servizi AWS)](https://aws.amazon.com/blogs/architecture/tag/creating-a-multi-region-application-with-aws-services-series/)
+ [Disaster Recovery (DR) Architecture on AWS, Part IV: Multi-site Active/Active (Architettura di ripristino di emergenza su AWS, parte IV: attiva/attiva multi-sito)](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-iv-multi-site-active-active/)
+ [Infrastruttura globale di AWS](https://aws.amazon.com/about-aws/global-infrastructure)
+ [Domande frequenti su AWS Local Zones](https://aws.amazon.com/about-aws/global-infrastructure/localzones/faqs/)
+ [Disaster Recovery (DR) Architecture on AWS, Part I: Strategies for Recovery in the Cloud (Architettura di ripristino di emergenza su AWS parte I: strategie per il ripristino nel cloud)](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-i-strategies-for-recovery-in-the-cloud/)
+ [Il ripristino di emergenza è differente nel cloud](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/disaster-recovery-is-different-in-the-cloud.html)
+ [Tabelle globali: replica multi-regione con DynamoDB](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/GlobalTables.html)
**Video correlati:**
+ [AWS re:Invent 2018: Architecture Patterns for Multi-Region Active-Active Applications (Modelli di architettura per applicazioni attive-attive multiregione) (ARC209-R2)](https://youtu.be/2e29I3dA8o4)
+ [Auth0: architettura ad alta disponibilità multi-Regione che raggiunge più di 1,5 miliardi di accessi al mese con failover automatico](https://www.youtube.com/watch?v=vGywoYc_sA8)
**Esempi correlati:**
+ [Disaster Recovery (DR) Architecture on AWS, Part I: Strategies for Recovery in the Cloud (Architettura di ripristino di emergenza su AWS parte I: strategie per il ripristino nel cloud)](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-i-strategies-for-recovery-in-the-cloud/)
+ [DTCC raggiunge livelli di resilienza superiori a quelli che raggiunge on-premise](https://aws.amazon.com/solutions/case-studies/DTCC/)
+ [Expedia Group utilizza un'architettura multi-regione, a più zone di disponibilità con un servizio DNS proprietario per aggiungere resilienza alle applicazioni](https://aws.amazon.com/solutions/case-studies/expedia/)
+ [Uber: ripristino di emergenza per Kafka multi-Regione](https://eng.uber.com/kafka/)
+ [Netflix: attivo-attivo per la resilienza multi-regione](https://netflixtechblog.com/active-active-for-multi-regional-resiliency-c47719f6685b)
+ [Come costruiamo la posizione fisica dei dati per Atlassian Cloud](https://www.atlassian.com/engineering/how-we-build-data-residency-for-atlassian-cloud)
+ [Intuit TurboTax funziona in due regioni](https://www.youtube.com/watch?v=286XyWx5xdQ)
# REL10-BP03 Ripristino automatico dei componenti vincolati a una singola posizione
Se i componenti del carico di lavoro possono essere eseguiti solo in una singola zona di disponibilità o in un data center on-premise, è necessario implementare la capacità di eseguire una ricostruzione completa del carico di lavoro entro gli obiettivi di ripristino definiti.
Se, a causa di vincoli tecnologici, non è possibile seguire le linee guida per distribuire il carico di lavoro in più posizioni, è necessario implementare un percorso alternativo mirato alla resilienza. È necessario automatizzare la possibilità di ricreare l'infrastruttura necessaria, ridistribuire le applicazioni e ricreare i dati necessari per questi casi.
Ad esempio, Amazon EMR lancia tutti i nodi per un determinato cluster nella stessa zona di disponibilità: eseguire un cluster nella stessa zona migliora le prestazioni dei flussi di lavoro poiché fornisce una velocità di accesso ai dati più elevata. Se questo componente è necessario per la resilienza del carico di lavoro, è necessario disporre di un modo per implementare nuovamente il cluster e i relativi dati. Inoltre, per Amazon EMR è necessario effettuare il provisioning della ridondanza in modi diversi dall'utilizzo di Multi-AZ. È possibile effettuare il provisioning di [nodi multipli](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-plan-ha-launch.html). Utilizzando [EMR File System (EMRFS)](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-fs.html), i dati in EMR possono essere memorizzati in Amazon S3, che a sua volta può essere replicato su più zone di disponibilità o Regioni AWS.
Analogamente, Amazon Redshift per impostazione predefinita effettua il provisioning del cluster in una zona di disponibilità casuale all'interno della Regione AWS selezionata. Tutti i nodi del cluster vengono assegnati nella stessa zona.
**Livello di rischio associato se questa best practice non fosse adottata:** Medium
## Guida all'implementazione
+ Implementa l'autoriparazione. Distribuisci le tue istanze o container utilizzando, quando possibile, il ridimensionamento automatico. Se non è possibile utilizzare il ridimensionamento automatico, utilizza il ripristino automatico per istanze EC2 o implementa l'automazione di autoriparazione in base agli eventi del ciclo di vita di container Amazon EC2 o ECS.
+ Utilizza gruppi Auto Scaling per carichi di lavoro di container e istanze che non richiedono un indirizzo IP di una singola istanza, un indirizzo IP privato, un indirizzo IP elastico o metadati di istanza.
+ [Che cos'è EC2 Auto Scaling?](https://docs.aws.amazon.com/autoscaling/ec2/userguide/what-is-amazon-ec2-auto-scaling.html)
+ [Scalabilità automatica del servizio](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/service-auto-scaling.html)
+ È possibile impiegare i dati utente di configurazione del lancio per implementare l'automazione capace di autoriparare la maggior parte dei carichi di lavoro.
+ Utilizza il ripristino automatico delle istanze EC2 per carichi di lavoro che richiedono un indirizzo ID di una singola istanza, indirizzo IP privato, indirizzo IP elastico e metadati di istanza.
+ [Recover your instance.](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-recover.html)
+ Il ripristino automatico invierà avvisi sullo stato del ripristino a un argomento SNS quando viene rilevato l'errore dell'istanza.
+ Utilizza eventi del ciclo di vita di istanze EC2 o eventi ECS per automatizzare l'autoriparazione dove non è possibile utilizzare l'Auto Scaling o il ripristino EC2.
+ [EC2 Auto Scaling lifecycle hooks](https://docs.aws.amazon.com/autoscaling/ec2/userguide/lifecycle-hooks.html)
+ [Eventi Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs_cwe_events.html)
+ Utilizza gli eventi per invocare l'automazione che riparerà il tuo componente secondo la logica di processo richiesta.
## Risorse
**Documenti correlati:**
+ [Eventi Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs_cwe_events.html)
+ [EC2 Auto Scaling lifecycle hooks](https://docs.aws.amazon.com/autoscaling/ec2/userguide/lifecycle-hooks.html)
+ [Recover your instance.](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-recover.html)
+ [Scalabilità automatica del servizio](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/service-auto-scaling.html)
+ [Che cos'è EC2 Auto Scaling?](https://docs.aws.amazon.com/autoscaling/ec2/userguide/what-is-amazon-ec2-auto-scaling.html)
# REL10-BP04 Utilizzo di architetture a paratie per limitare la portata dell'impatto
Come per le paratie su una nave, questo modello garantisce il contenimento di un guasto in un piccolo sottoinsieme di richieste o clienti, in modo che il numero di richieste danneggiate sia limitato e si possa comunque continuare senza errori. Le paratie per i dati sono spesso chiamate partizioni, mentre le paratie per i servizi sono note come celle.
In una *architettura basata su celle*, ogni cella è un'istanza completa e indipendente del servizio e ha una dimensione massima fissa. Con l'aumentare del carico, i carichi di lavoro aumentano aggiungendo più celle. Una chiave di partizione viene utilizzata sul traffico in entrata per determinare quale cella elaborerà la richiesta. Qualsiasi guasto è contenuto nella singola cella in cui si verifica, in modo che il numero di richieste danneggiate sia limitato man mano che le altre celle continuano senza errori. È importante identificare la chiave di partizione corretta per ridurre al minimo le interazioni tra celle ed evitare la necessità di coinvolgere servizi di mappatura complessi in ogni richiesta. I servizi che richiedono una mappatura complessa finiscono semplicemente per spostare il problema ai servizi di mappatura, là dove i servizi che richiedono interazioni cross-cell creano dipendenze tra celle (e questo riduce i miglioramenti della disponibilità che ne deriverebbero).
![\[Diagramma che mostra un'architettura basata su celle\]](http://docs.aws.amazon.com/it_it/wellarchitected/2022-03-31/framework/images/cell-based-architecture.png)
In un post del suo blog AWS, Colm MacCarthaigh spiega in che modo Amazon Route 53 utilizza il concetto di [https://aws.amazon.com/blogs/architecture/shuffle-sharding-massive-and-magical-fault-isolation/](https://aws.amazon.com/blogs/architecture/shuffle-sharding-massive-and-magical-fault-isolation/) per isolare le richieste dei clienti negli shard. Uno shard in questo caso è costituito da due o più celle. In base alla chiave di partizione, il traffico da un cliente (o risorse o qualsiasi altra cosa desideri isolare) viene instradato allo shard assegnato. Nel caso di otto celle con due celle per shard e clienti divisi tra i quattro shard, il 25% dei clienti riscontrerebbe un impatto in caso di problema.
![\[Diagramma che mostra un servizio suddiviso in partizioni tradizionali\]](http://docs.aws.amazon.com/it_it/wellarchitected/2022-03-31/framework/images/service-divided-into-traditional-shards.png)
Con lo sharding casuale, puoi creare shard virtuali di due celle ciascuno e assegnare i clienti a uno di questi shard virtuali. Quando si verifica un problema, puoi comunque perdere un quarto dell'intero servizio, ma il modo in cui vengono assegnati i clienti o le risorse significa che l'ambito dell'impatto con lo sharding casuale è notevolmente inferiore al 25%. Con otto celle, ci sono 28 combinazioni univoche di due celle, il che significa che ci sono 28 possibili shard casuali (shard virtuali). Se disponi di centinaia o migliaia di clienti e assegni ogni cliente a uno shard casuale, l'impatto causato da un problema è di solo 1/28. Questo è sette volte superiore rispetto allo sharding normale.
![\[Diagramma che mostra un servizio suddiviso in partizioni casuali.\]](http://docs.aws.amazon.com/it_it/wellarchitected/2022-03-31/framework/images/service-divided-into-shuffle-shards.png)
Uno shard può essere utilizzato per server, code o altre risorse in aggiunta alle celle.
**Livello di rischio associato se questa best practice non fosse adottata:** Medium
## Guida all'implementazione
+ Utilizzo di architetture paratie Come per le paratie su una nave, questo modello garantisce il contenimento di un guasto in un piccolo sottoinsieme di richieste/utenti, in modo che il numero di richieste danneggiate sia limitato e si possa comunque continuare senza errori. Le paratie per i dati sono spesso chiamate partizioni, mentre le paratie per i servizi sono note come celle.
+ [Well-Architected lab: Fault isolation with shuffle sharding](https://wellarchitectedlabs.com/reliability/300_labs/300_fault_isolation_with_shuffle_sharding/)
+ [Shuffle-sharding: AWS re:Invent 2019: Introducing The Amazon Builders' Library (Introduzione alla libreria dei costruttori di Amazon) (DOP328)](https://youtu.be/sKRdemSirDM?t=1373)
+ [AWS re:Invent 2018: How AWS Minimizes the Blast Radius of Failures (Come AWS riduce al minimo il raggio di esplosione dei guasti) (ARC338)](https://youtu.be/swQbA4zub20)
+ Valutazione dell'architettura basata su celle per il carico di lavoro In un'architettura basata su celle, ogni cella è un'istanza completa e indipendente del servizio e ha una dimensione massima fissa. Con l'aumentare del carico, i carichi di lavoro aumentano aggiungendo più celle. Una chiave di partizione viene utilizzata sul traffico in entrata per determinare quale cella elaborerà la richiesta. Qualsiasi guasto è contenuto nella singola cella in cui si verifica, in modo che il numero di richieste danneggiate sia limitato man mano che le altre celle continuano senza errori. È importante identificare la chiave di partizione corretta per ridurre al minimo le interazioni tra celle ed evitare la necessità di coinvolgere servizi di mappatura complessi in ogni richiesta. I servizi che richiedono una mappatura complessa finiscono semplicemente per spostare il problema ai servizi di mappatura, mentre i servizi che richiedono interazioni tra celle riducono l'autonomia delle celle (e quindi i presunti miglioramenti della disponibilità che ne deriverebbero).
+ Nel suo post del blog AWS, Colm MacCarthaigh spiega in che modo Amazon Route 53 utilizza il concetto di partizione casuale per isolare le richieste dei clienti nelle partizioni
+ [Shuffle Sharding: Massive and Magical Fault Isolation](https://aws.amazon.com/blogs/architecture/shuffle-sharding-massive-and-magical-fault-isolation)
## Risorse
**Documenti correlati:**
+ [Shuffle Sharding: Massive and Magical Fault Isolation](https://aws.amazon.com/blogs/architecture/shuffle-sharding-massive-and-magical-fault-isolation)
+ [The Amazon Builders' Library: Isolamento del carico di lavoro utilizzando lo sharding casuale](https://aws.amazon.com/builders-library/workload-isolation-using-shuffle-sharding/)
**Video correlati:**
+ [AWS re:Invent 2018: How AWS Minimizes the Blast Radius of Failures (Come AWS riduce al minimo il raggio di esplosione dei guasti) (ARC338)](https://youtu.be/swQbA4zub20)
+ [Shuffle-sharding: AWS re:Invent 2019: Introducing The Amazon Builders' Library (Introduzione alla libreria dei costruttori di Amazon) (DOP328)](https://youtu.be/sKRdemSirDM?t=1373)
**Esempi correlati:**
+ [Well-Architected lab: Fault isolation with shuffle sharding](https://wellarchitectedlabs.com/reliability/300_labs/300_fault_isolation_with_shuffle_sharding/)
# REL 11 In che modo progetti il carico di lavoro affinché resista ai guasti dei componenti?
I carichi di lavoro con requisiti di disponibilità elevata e MTTR (Mean Time To Recovery) basso devono essere progettati per garantire la resilienza.
**Topics**
+ [REL11-BP01 Monitoraggio di tutti i componenti del carico di lavoro per la rilevazione dei guasti](rel_withstand_component_failures_monitoring_health.md)
+ [REL11-BP02 Failover e passaggio a risorse integre](rel_withstand_component_failures_failover2good.md)
+ [REL11-BP03 Automatizzazione della riparazione a tutti i livelli](rel_withstand_component_failures_auto_healing_system.md)
+ [REL11-BP04 Fare affidamento al piano dati invece che al piano di controllo durante il ripristino](rel_withstand_component_failures_avoid_control_plane.md)
+ [REL11-BP05 Utilizzo della stabilità statica per evitare un comportamento bimodale](rel_withstand_component_failures_static_stability.md)
+ [REL11-BP06 Invio di notifiche quando gli eventi influiscono sulla disponibilità](rel_withstand_component_failures_notifications_sent_system.md)
# REL11-BP01 Monitoraggio di tutti i componenti del carico di lavoro per la rilevazione dei guasti
Monitora continuamente lo stato del carico di lavoro, in modo che tu e i tuoi sistemi automatizzati siate consapevoli del deterioramento o del guasto non appena questo si verifica. Monitora gli indicatori chiave di prestazioni (KPI) in base al valore aziendale.
Tutti i meccanismi di ripristino e correzione devono essere in grado di rilevare rapidamente i problemi. I guasti tecnici devono essere rilevati prima in modo che possano essere risolti. Tuttavia, la disponibilità si basa sulla capacità del carico di lavoro di fornire valore aziendale, quindi gli indicatori chiave di prestazione (KPI) che misurano questo aspetto devono far parte della strategia di rilevamento e correzione.
**Anti-pattern comuni:**
+ Non sono stati configurati allarmi, pertanto le interruzioni si verificano senza notifica.
+ Gli allarmi esistono, ma a soglie che non forniscono tempo adeguato per reagire.
+ I parametri non vengono raccolti abbastanza spesso da soddisfare l'obiettivo di tempo di ripristino (RTO, recovery time objective).
+ Solo il livello del carico di lavoro rivolto al cliente viene monitorato attivamente.
+ Viene effettuata solo la raccolta di parametri tecnici, senza includere quelli delle funzioni aziendali.
+ Non è presente alcun parametro che misuri l'esperienza utente del carico di lavoro.
**Vantaggi dell'adozione di questa best practice:** Eseguire un monitoraggio appropriato a tutti i livelli consente di ridurre i tempi di ripristino riducendo i tempi di rilevamento.
**Livello di rischio associato se questa best practice non fosse adottata:** Alta
## Guida all'implementazione
+ Determina l'intervallo di raccolta per i componenti in base agli obiettivi di ripristino.
+ L'intervallo di monitoraggio dipende dalla velocità con cui è necessario ripristinare Il tempo di ripristino dipende dal tempo necessario a ripristinare, perciò è necessario determinare la frequenza della raccolta considerando tale tempo e l'obiettivo di tempo di ripristino (RTO, recovery time objective).
+ Configura il monitoraggio dettagliato per i componenti.
+ Determinare se è necessario un monitoraggio dettagliato per le istanze EC2 e l'Auto Scaling Il monitoraggio dettagliato fornisce parametri con un intervallo di 1 minuto, mentre il monitoraggio predefinito fornisce parametri con un intervallo di 5 minuti.
+ [Abilitare o disabilitare il monitoraggio dettagliato della propria istanza](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-cloudwatch-new.html)
+ [Monitoraggio di gruppi con scalabilità automatica e istanze con Amazon CloudWatch](https://docs.aws.amazon.com/autoscaling/ec2/userguide/as-instance-monitoring.html)
+ Determinare se è necessario un monitoraggio avanzato per RDS Il monitoraggio avanzato utilizza un agente sulle istanze RDS per ottenere informazioni utili su diversi processi o thread in un'istanza RDS.
+ [Monitoraggio avanzato](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_Monitoring.OS.html)
+ Creazione di parametri personalizzati per misurare indicatori chiave di prestazione (KPI) aziendali I carichi di lavoro implementano funzioni aziendali chiave. Queste funzioni devono essere utilizzate come KPI che aiutano a identificare quando si verifica un problema indiretto.
+ [Pubblicazione di parametri personalizzati](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/publishingMetrics.html)
+ Monitoraggio della presenza di errori nell'esperienza utente tramite le canary degli utenti Il test sintetico delle transazioni (noto anche come "test canary", ma da non confondere con le distribuzioni canary) in grado di eseguire e simulare il comportamento dei clienti è uno dei processi di test più importanti. Esegui questi test costantemente sugli endpoint del carico di lavoro da diverse posizioni remote.
+ [Amazon CloudWatch Synthetics consente di creare i Canary dell'utente](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html)
+ Creazione di parametri personalizzati che monitorino l'esperienza dell'utente Dotare l'esperienza del cliente di strumenti consente di determinare quando essa peggiora.
+ [Pubblicazione di parametri personalizzati](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/publishingMetrics.html)
+ Imposta gli allarmi per rilevare quando una qualsiasi parte del carico di lavoro non funziona correttamente e per indicare quando effettuare l'Auto Scaling delle risorse. Gli allarmi possono essere visualizzati sui pannelli di controllo, possono essere inviati avvisi tramite Amazon SNS o e-mail e il dimensionamento automatico può essere utilizzato per aumentare o ridurre le risorse per un carico di lavoro.
+ [Utilizzo degli allarmi di Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html)
+ Crea pannelli di controllo per visualizzare i parametri. I pannelli di controllo possono essere utilizzati per visualizzare tendenze, valori anomali e altri indicatori di potenziali problemi, oppure per fornire un'indicazione dei problemi che potresti voler esaminare.
+ [Utilizzo dei pannelli di controllo CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html)
## Risorse
**Documenti correlati:**
+ [Amazon CloudWatch Synthetics consente di creare i Canary dell'utente](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html)
+ [Abilitare o disabilitare il monitoraggio dettagliato della propria istanza](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-cloudwatch-new.html)
+ [Monitoraggio avanzato](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_Monitoring.OS.html)
+ [Monitoraggio di gruppi con scalabilità automatica e istanze con Amazon CloudWatch](https://docs.aws.amazon.com/autoscaling/ec2/userguide/as-instance-monitoring.html)
+ [Pubblicazione di parametri personalizzati](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/publishingMetrics.html)
+ [Utilizzo degli allarmi di Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html)
+ [Utilizzo dei pannelli di controllo CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html)
**Esempi correlati:**
+ [Corso Well-Architected: Level 300: Implementing Health Checks and Managing Dependencies to Improve Reliability](https://wellarchitectedlabs.com/Reliability/300_Health_Checks_and_Dependencies/README.html)
# REL11-BP02 Failover e passaggio a risorse integre
Garantisce che laddove si verifichi un errore con una risorsa, le risorse integre possano continuare a soddisfare le richieste. Per gli errori legati alle posizioni (ad esempio una zona di disponibilità o una Regione AWS), assicurati di disporre di sistemi che possano eseguire il failover e passare a risorse integre in posizioni non danneggiate.
I servizi AWS, come Elastic Load Balancing e AWS Auto Scaling, aiutano a distribuire il carico tra le risorse e le zone di disponibilità. Pertanto, il guasto di una singola risorsa (come un'istanza EC2) o la compromissione di una zona di disponibilità possono essere mitigati spostando il traffico sulle risorse integre rimanenti. Per i carichi di lavoro multi-regione, questa operazione è più complicata. Ad esempio, le repliche di lettura tra Regioni consentono di implementare i dati in più Regioni AWS, ma è comunque necessario promuovere la replica di lettura a primaria e indirizzare il traffico verso di essa in caso di failover. Amazon Route 53 e AWS Global Accelerator possono aiutare a instradare il traffico tra Regioni AWS.
Se il carico di lavoro utilizza servizi AWS, ad esempio Amazon S3 o Amazon DynamoDB, questi vengono automaticamente implementati in più zone di disponibilità. In caso di errore, il piano di controllo AWS instrada automaticamente il traffico verso le posizioni integre per te. I dati sono archiviati in modo ridondante in più zone di disponibilità e rimangono disponibili. Per Amazon RDS, è necessario scegliere l'opzione di configurazione Multi-AZ; quindi, in caso di errore, AWS indirizzerà automaticamente il traffico verso l'istanza integra. Per le istanze Amazon EC2, le attività Amazon ECS o i pod Amazon EKS, puoi scegliere le zone di disponibilità in cui implementarli. Elastic Load Balancing, quindi, fornisce la soluzione per rilevare le istanze nelle zone non integre e instradare il traffico verso quelle integre. Elastic Load Balancing può anche instradare il traffico verso i componenti del data center on-premise.
Per gli approcci multi-regione (che potrebbero includere anche data center on-premise), Amazon Route 53 offre un modo per definire domini Internet e assegnare policy di instradamento che possono includere controlli dell'integrità per garantire che il traffico venga instradato verso regioni integre. In alternativa, AWS Global Accelerator fornisce indirizzi IP statici che fungono da punto di ingresso fisso alla tua applicazione, quindi, instrada verso endpoint nelle Regioni AWS a tua scelta, utilizzando la rete globale AWS, anziché Internet, per migliorare le prestazioni e l'affidabilità.
AWS si avvicina alla progettazione dei servizi pensando al ripristino degli errori. Progettiamo servizi per ridurre al minimo i tempi di recupero da guasti e l'impatto sui dati. I nostri servizi utilizzano principalmente archivi di dati che riconoscono le richieste solo dopo che queste sono state archiviate in modo duraturo su più repliche in una Regione. Questi servizi e risorse includono Amazon Aurora, istanze database Multi-AZ Amazon Relational Database Service (Amazon RDS), Amazon S3, Amazon DynamoDB, Amazon Simple Queue Service (Amazon SQS) e Amazon Elastic File System (Amazon EFS). Sono costruiti con il criterio dell'isolamento basato sulle celle ed utilizzano l'isolamento dei guasti fornito dalle zone di disponibilità. Facciamo ampio uso dell'automazione nelle nostre procedure operative. Ottimizziamo anche la nostra funzionalità di sostituzione e riavvio per un ripristino rapidamente dalle interruzioni.
**Livello di rischio associato se questa best practice non fosse adottata:** Alta
## Guida all'implementazione
+ Failover su risorse integre. Garantisce che laddove si verifichi un errore con una risorsa, le risorse integre possano continuare a soddisfare le richieste. Per gli errori legati alle posizioni (ad esempio una zona di disponibilità o una Regione AWS), assicurati di disporre di sistemi che possano eseguire il failover e passare a risorse integre in posizioni non danneggiate.
+ Se il carico di lavoro utilizza servizi AWS, ad esempio Amazon S3 o Amazon DynamoDB, questi vengono automaticamente implementati in più zone di disponibilità. In caso di errore, il piano di controllo AWS instrada automaticamente il traffico verso le posizioni integre per te.
+ Per Amazon RDS, è necessario scegliere l'opzione di configurazione Multi-AZ; quindi, in caso di errore, AWS indirizzerà automaticamente il traffico verso l'istanza integra.
+ [Alta disponibilità (Multi-AZ) per Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Concepts.MultiAZ.html)
+ Per le istanze Amazon EC2 o le attività Amazon ECS, puoi scegliere le zone di disponibilità su cui effettuare la distribuzione.Elastic Load Balancing quindi rileverà le istanze in zone non integre e instraderà il traffico verso quelle integre. Elastic Load Balancing può persino instradare il traffico ai componenti nel tuo data center locale.
+ Per approcci multi-regione (che potrebbero includere anche data center in locale), assicurati che i dati e le risorse provenienti da posizioni integre possano continuare a servire le richieste
+ Ad esempio, le repliche di lettura tra Regioni consentono di implementare i dati in più Regioni AWS, ma è comunque necessario promuovere la replica di lettura per dominare e indirizzare il traffico verso di essa in caso di guasto di una posizione primaria.
+ [Panoramica delle repliche di lettura Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ReadRepl.html)
+ Amazon Route 53 offre un modo per definire domini Internet e assegnare policy di instradamento, che potrebbero includere controlli dell'integrità, per garantire che il traffico venga instradato verso Regioni integre. In alternativa, AWS Global Accelerator fornisce indirizzi IP statici che fungono da punto di ingresso fisso alla tua applicazione, quindi, instrada verso endpoint nelle Regioni AWS a tua scelta, utilizzando la rete globale AWS, anziché Internet, per migliorare le prestazioni e l'affidabilità.
+ [Amazon Route 53: scelta di una policy di instradamento](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-policy.html)
+ [Che cos'è AWSGlobal Accelerator?](https://docs.aws.amazon.com/global-accelerator/latest/dg/what-is-global-accelerator.html)
## Risorse
**Documenti correlati:**
+ [Partner APN: partner che possono essere d'aiuto con l'automazione della tua tolleranza ai guasti](https://aws.amazon.com/partners/find/results/?keyword=automation)
+ [Marketplace AWS: prodotti utilizzabili per la tolleranza ai guasti](https://aws.amazon.com/marketplace/search/results?searchTerms=fault+tolerance)
+ [AWS OpsWorks: Using Auto Healing to Replace Failed Instances (Utilizzo della riparazione automatica per sostituire le istanze in errore)](https://docs.aws.amazon.com/opsworks/latest/userguide/workinginstances-autohealing.html)
+ [Amazon Route 53: scelta di una policy di instradamento](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-policy.html)
+ [Alta disponibilità (Multi-AZ) per Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Concepts.MultiAZ.html)
+ [Panoramica delle repliche di lettura Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ReadRepl.html)
+ [Strategie di posizionamento dei processi di Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task-placement-strategies.html)
+ [Creating Kubernetes Auto Scaling Groups for Multiple Availability Zones (Creazione di gruppi con scalabilità automatica Kubernetes per più zone di disponibilità)](https://aws.amazon.com/blogs/containers/amazon-eks-cluster-multi-zone-auto-scaling-groups/)
+ [Che cos'è AWS Global Accelerator?](https://docs.aws.amazon.com/global-accelerator/latest/dg/what-is-global-accelerator.html)
**Esempi correlati:**
+ [Corso Well-Architected: Level 300: Implementing Health Checks and Managing Dependencies to Improve Reliability](https://wellarchitectedlabs.com/Reliability/300_Health_Checks_and_Dependencies/README.html)
# REL11-BP03 Automatizzazione della riparazione a tutti i livelli
Al rilevamento di un guasto, utilizza funzionalità automatizzate per eseguire azioni da correggere.
*La capacità di riavvio* è uno strumento importante per risolvere gli errori. Come illustrato in precedenza per i sistemi distribuiti, una best practice consiste nel rendere i servizi stateless laddove possibile. In questo modo si evita la perdita di dati o la disponibilità al riavvio. Nel cloud, puoi (e generalmente dovresti) sostituire l'intera risorsa (ad esempio, l'istanza EC2 o la funzione Lambda) come parte del riavvio. Il riavvio stesso è un modo semplice e affidabile per eseguire il ripristino in caso di guasto. Molti tipi diversi di guasto si verificano nei carichi di lavoro. Possono verificarsi guasti a livello di hardware, software, comunicazione e operazioni. Anziché creare nuovi meccanismi per intrappolare, identificare e correggere ciascuno dei diversi tipi di guasto, mappa diverse categorie di guasto alla stessa strategia di ripristino. Un'istanza può restituire un guasto causato da un guasto hardware, da un bug del sistema operativo, da una memory leak o da altre cause. Anziché creare una correzione personalizzata per ogni situazione, considera una di esse come un guasto dell'istanza. Termina l'istanza e consenti ad AWS Auto Scaling di sostituirla. In un secondo momento, esegui l'analisi sulla risorsa guasta fuori banda.
Un altro esempio è la possibilità di riavviare una richiesta di rete. Adotta lo stesso approccio di ripristino sia a un timeout di rete sia a un guasto di dipendenza in cui la dipendenza restituisce un guasto. Entrambi gli eventi hanno un effetto simile sul sistema, quindi piuttosto che tentare di trasformare entrambi gli eventi in un "caso speciale", adotta una strategia analoga di nuovi tentativi limitati con un back-off e un jitter esponenziali.
*La capacità di riavvio* è un meccanismo di ripristino presente nelle architetture di cluster ROC (Recovery Oriented Computing) e ad alta disponibilità.
Amazon EventBridge può essere utilizzato per monitorare e filtrare eventi come allarmi CloudWatch o cambiamenti di stato in altri servizi AWS. In base alle informazioni sugli eventi, può quindi attivare AWS Lambda, AWS Systems Manager Automation o altri target per eseguire una logica di riparazione sul carico di lavoro.
Amazon EC2 Auto Scaling può essere configurato per verificare lo stato dell'istanza EC2. Se l'istanza è in uno stato diverso da quello in esecuzione o se lo stato del sistema è danneggiato, Amazon EC2 Auto Scaling considera l'istanza come non integra e ne avvia una sostitutiva. Se utilizzi AWS OpsWorks, puoi configurare la riparazione automatica delle istanze EC2 a livello del layer OpsWorks.
Per le sostituzioni su larga scala (ad esempio la perdita di un'intera zona di disponibilità), anziché cercare di ottenere nuove risorse contemporaneamente è preferibile adottare la stabilità statica per trarre vantaggio dall'elevata disponibilità.
**Anti-pattern comuni:**
+ Implementazione individuale di applicazioni in istanze/container.
+ Distribuzione di applicazioni che non possono essere distribuite in più posizioni senza utilizzare il ripristino automatico.
+ Riparazione manuale delle applicazioni che il dimensionamento e il ripristino automatici non sono stati in grado di riparare.
**Vantaggi dell'adozione di questa best practice:** Il risanamento automatico, anche se il carico di lavoro può essere distribuito in una sola posizione alla volta, ridurrà il tempo medio di ripristino e garantirà la disponibilità del carico di lavoro.
**Livello di rischio associato se questa best practice non fosse adottata:** Alta
## Guida all'implementazione
+ Utilizzo dei gruppi con scalabilità automatica per implementare livelli in un carico di lavoro. Auto Scaling è in grado di eseguire il risanamento automatico sulle applicazioni stateless e aggiungere e rimuovere capacità.
+ [Come funziona AWS Auto Scaling](https://docs.aws.amazon.com/autoscaling/plans/userguide/how-it-works.html)
+ Implementa il ripristino automatico sulle istanze EC2 che includono applicazioni distribuite non distribuibili in più posizioni e possono tollerare il riavvio in caso di guasti. Il ripristino automatico può essere utilizzato per sostituire l'hardware guasto e riavviare l'istanza quando l'applicazione non è in grado di essere distribuita in più posizioni. Vengono conservati i metadati dell'istanza e gli indirizzi IP associati, nonché i volumi Amazon EBS e i punti di montaggio su Elastic File System o file system per Lustre e Windows.
+ [Ripristino automatico Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-recover.html)
+ [Amazon Elastic Block Store (Amazon EBS)](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AmazonEBS.html)
+ [Amazon Elastic File System (Amazon EFS)](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AmazonEFS.html)
+ [What is Amazon FSx for Lustre? Che cos'è Amazon FSx for Lustre?)](https://docs.aws.amazon.com/fsx/latest/LustreGuide/what-is.html)
+ [What is Amazon FSx for Windows File Server? (Che cos'è What is FSx for Windows File Server?)](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/what-is.html)
+ Se utilizzi AWS OpsWorks, puoi configurare il la riparazione automatica delle istanze EC2 a livello del layer.
+ [AWS OpsWorks: Using Auto Healing to Replace Failed Instances (Utilizzo della riparazione automatica per sostituire le istanze in errore)](https://docs.aws.amazon.com/opsworks/latest/userguide/workinginstances-autohealing.html)
+ Implementa il ripristino automatico utilizzando AWS Step Functions e AWS Lambda quando non è possibile utilizzare il dimensionamento automatico o il ripristino automatico oppure quando il ripristino automatico non riesce. Quando non puoi utilizzare il dimensionamento automatico né il ripristino automatico o il ripristino automatico non riesce, puoi automatizzare la riparazione utilizzando AWS Step Functions e AWS Lambda.
+ [What is AWS Step Functions? (Che cos'è AWS Step Functions?)](https://docs.aws.amazon.com/step-functions/latest/dg/welcome.html)
+ [Cos'è AWS Lambda?](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html)
+ Amazon EventBridge può essere utilizzato per monitorare e filtrare eventi come allarmi CloudWatch o cambiamenti di stato in altri servizi AWS. In base alle informazioni sugli eventi, può quindi attivare AWS Lambda (o altri target) per eseguire una logica di riparazione personalizzata sul tuo carico di lavoro.
+ [Che cos'è Amazon EventBridge?](https://docs.aws.amazon.com/eventbridge/latest/userguide/what-is-amazon-eventbridge.html)
+ [Utilizzo degli allarmi di Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html)
## Risorse
**Documenti correlati:**
+ [Partner APN: partner che possono essere d'aiuto con l'automazione della tua tolleranza ai guasti](https://aws.amazon.com/partners/find/results/?keyword=automation)
+ [Marketplace AWS: prodotti utilizzabili per la tolleranza ai guasti](https://aws.amazon.com/marketplace/search/results?searchTerms=fault+tolerance)
+ [AWS OpsWorks: Using Auto Healing to Replace Failed Instances (Utilizzo della riparazione automatica per sostituire le istanze in errore)](https://docs.aws.amazon.com/opsworks/latest/userguide/workinginstances-autohealing.html)
+ [Ripristino automatico Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-recover.html)
+ [Amazon Elastic Block Store (Amazon EBS)](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AmazonEBS.html)
+ [Amazon Elastic File System (Amazon EFS)](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AmazonEFS.html)
+ [Come funziona AWS Auto Scaling](https://docs.aws.amazon.com/autoscaling/plans/userguide/how-it-works.html)
+ [Utilizzo degli allarmi di Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html)
+ [Che cos'è Amazon EventBridge?](https://docs.aws.amazon.com/eventbridge/latest/userguide/what-is-amazon-eventbridge.html)
+ [Cos'è AWS Lambda?](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html)
+ [AWS Systems Manager Automation](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html)
+ [What is AWS Step Functions? (Che cos'è AWS Step Functions?)](https://docs.aws.amazon.com/step-functions/latest/dg/welcome.html)
+ [What is Amazon FSx for Lustre? Che cos'è Amazon FSx for Lustre?)](https://docs.aws.amazon.com/fsx/latest/LustreGuide/what-is.html)
+ [What is Amazon FSx for Windows File Server? (Che cos'è What is FSx for Windows File Server?)](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/what-is.html)
**Video correlati:**
+ [Static stability in AWS: AWS re:Invent 2019: Introducing The Amazon Builders' Library (Introduzione alla libreria dei costruttori di Amazon) (DOP328)](https://youtu.be/sKRdemSirDM?t=704)
**Esempi correlati:**
+ [Corso Well-Architected: Level 300: Implementing Health Checks and Managing Dependencies to Improve Reliability](https://wellarchitectedlabs.com/Reliability/300_Health_Checks_and_Dependencies/README.html)
# REL11-BP04 Fare affidamento al piano dati invece che al piano di controllo durante il ripristino
Il piano di controllo è utilizzato per configurare le risorse, mentre il piano dati fornisce servizi. I piani dati hanno tipicamente obiettivi di progettazione della disponibilità più elevati rispetto ai piani di controllo e sono solitamente meno complessi. Quando si implementano risposte di ripristino o mitigazione a eventi potenzialmente dannosi per la resilienza, l'utilizzo di operazioni sul piano di controllo può ridurre la resilienza complessiva della tua architettura. Per esempio, puoi fare affidamento sul piano dati di Amazon Route 53 per instradare in modo affidabile le query DNS basate sui controlli dell'integrità, ma l'aggiornamento delle policy di instradamento Route 53 utilizza il piano di controllo, quindi non fare affidamento su di esso per il ripristino.
I piani dati di Route 53 rispondono alle query DNS ed eseguono e valutano i controlli di integrità. Sono distribuiti a livello globale e progettati per un [accordo sul livello di servizio (SLA) con disponibilità al 100%.](https://aws.amazon.com/route53/sla/) Le API e le console di gestione di Route 53, dove si creano, aggiornano ed eliminano le risorse di Route 53, funzionano su piani di controllo progettati per privilegiare la forte coerenza e la durata necessarie per la gestione del DNS. A tal fine, i piani di controllo sono situati in un'unica regione, US East (N. Virginia). Sebbene entrambi i sistemi siano costruiti per essere molto affidabili, i piani di controllo non sono inclusi nello SLA. Possono verificarsi eventi rari in cui la progettazione resiliente del piano dati consente di mantenere la disponibilità mentre i piani di controllo non lo fanno. Per i meccanismi di ripristino di emergenza e failover, utilizzare le funzioni del piano dati per garantire la migliore affidabilità possibile.
Per ulteriori informazioni sui piani dati, sui piani di controllo e come AWS costruisce i servizi per soddisfare gli obiettivi di alta disponibilità, consulta il documento [stabilità statica utilizzando le zone di disponibilità](https://aws.amazon.com/builders-library/static-stability-using-availability-zones) e la Libreria [degli sviluppatori di Amazon.](https://aws.amazon.com/builders-library/)
**Livello di rischio associato se questa best practice non fosse adottata:** Alta
## Guida all'implementazione
+ Affidati al piano dati e non al piano di controllo quando utilizzi Amazon Route 53 per il ripristino di emergenza. Route 53 Application Recovery Controller aiuta a gestire e coordinare il failover utilizzando i controlli di disponibilità e i controlli di instradamento. Queste funzionalità monitorano continuamente la capacità dell'applicazione di riprendersi dai guasti e permettono di controllarne il ripristino su più Regioni AWS, zone di disponibilità e on-premise.
+ [What is Route 53 Application Recovery Controller (What is Amazon Route 53 Application Recovery Controller?)](https://docs.aws.amazon.com/r53recovery/latest/dg/what-is-route53-recovery.html)
+ [Creating Disaster Recovery Mechanisms Using Amazon Route 53 (Creazione di meccanismi di ripristino di emergenza con Amazon Route 53)](https://aws.amazon.com/blogs/networking-and-content-delivery/creating-disaster-recovery-mechanisms-using-amazon-route-53/)
+ [Building highly resilient applications using Amazon Route 53 Application Recovery Controller, Part 1: Single-Region stack (Creazione di applicazioni altamente resilienti con Amazon Route 53 Application Recovery Controller, parte 1: stack a singola regione)](https://aws.amazon.com/blogs/networking-and-content-delivery/building-highly-resilient-applications-using-amazon-route-53-application-recovery-controller-part-1-single-region-stack/)
+ [Building highly resilient applications using Amazon Route 53 Application Recovery Controller, Part 2: Multi-Region stack (Creazione di applicazioni altamente resilienti con Amazon Route 53 Application Recovery Controller, parte 2: stack multi-regione)](https://aws.amazon.com/blogs/networking-and-content-delivery/building-highly-resilient-applications-using-amazon-route-53-application-recovery-controller-part-2-multi-region-stack/)
+ Capire quali operazioni sono sul piano dati e quali sul piano di controllo.
+ [The Amazon Builders' Library: Avoiding overload in distributed systems by putting the smaller service in control](https://aws.amazon.com/builders-library/avoiding-overload-in-distributed-systems-by-putting-the-smaller-service-in-control/)
+ [API Amazon DynamoDB (piano di controllo e piano dati)](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/HowItWorks.API.html)
+ [AWS Lambda Executions (Esecuzioni Lambda )](https://docs.aws.amazon.com/whitepapers/latest/security-overview-aws-lambda/lambda-executions.html) (suddivise in piano di controllo e piano dati)
+ [AWS Lambda Executions (Esecuzioni Lambda )](https://docs.aws.amazon.com/whitepapers/latest/security-overview-aws-lambda/lambda-executions.html) (suddivise in piano di controllo e piano dati)
## Risorse
**Documenti correlati:**
+ [Partner APN: partner che possono essere d'aiuto con l'automazione della tua tolleranza ai guasti](https://aws.amazon.com/partners/find/results/?keyword=automation)
+ [Marketplace AWS: prodotti utilizzabili per la tolleranza ai guasti](https://aws.amazon.com/marketplace/search/results?searchTerms=fault+tolerance)
+ [The Amazon Builders' Library: Avoiding overload in distributed systems by putting the smaller service in control](https://aws.amazon.com/builders-library/avoiding-overload-in-distributed-systems-by-putting-the-smaller-service-in-control/)
+ [API Amazon DynamoDB (piano di controllo e piano dati)](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/HowItWorks.API.html)
+ [AWS Lambda Executions (Esecuzioni Lambda )](https://docs.aws.amazon.com/whitepapers/latest/security-overview-aws-lambda/lambda-executions.html) (suddivise in piano di controllo e piano dati)
+ [Piano dati AWS Elemental MediaStore](https://docs.aws.amazon.com/mediastore/latest/apireference/API_Operations_AWS_Elemental_MediaStore_Data_Plane.html)
+ [Building highly resilient applications using Amazon Route 53 Application Recovery Controller, Part 1: Single-Region stack (Creazione di applicazioni altamente resilienti con Amazon Route 53 Application Recovery Controller, parte 1: stack a singola regione)](https://aws.amazon.com/blogs/networking-and-content-delivery/building-highly-resilient-applications-using-amazon-route-53-application-recovery-controller-part-1-single-region-stack/)
+ [Building highly resilient applications using Amazon Route 53 Application Recovery Controller, Part 2: Multi-Region stack (Creazione di applicazioni altamente resilienti con Amazon Route 53 Application Recovery Controller, parte 2: stack multi-regione)](https://aws.amazon.com/blogs/networking-and-content-delivery/building-highly-resilient-applications-using-amazon-route-53-application-recovery-controller-part-2-multi-region-stack/)
+ [Creating Disaster Recovery Mechanisms Using Amazon Route 53 (Creazione di meccanismi di ripristino di emergenza con Amazon Route 53)](https://aws.amazon.com/blogs/networking-and-content-delivery/creating-disaster-recovery-mechanisms-using-amazon-route-53/)
+ [What is Route 53 Application Recovery Controller (What is Amazon Route 53 Application Recovery Controller?)](https://docs.aws.amazon.com/r53recovery/latest/dg/what-is-route53-recovery.html)
**Esempi correlati:**
+ [Introduzione a Amazon Route 53 Application Recovery Controller (Introduzione ad Amazon Route 53 Application Recovery Controller)](https://aws.amazon.com/blogs/aws/amazon-route-53-application-recovery-controller/)
# REL11-BP05 Utilizzo della stabilità statica per evitare un comportamento bimodale
Si ha un comportamento bimodale quando il carico di lavoro mostra un comportamento diverso in modalità normale e di guasto, ad esempio facendo affidamento sull'avvio di nuove istanze se una zona di disponibilità ha esito negativo. Devi invece creare carichi di lavoro che siano staticamente stabili e operino in una sola modalità. In questo caso, effettua il provisioning di istanze sufficienti in ciascuna zona di disponibilità per gestire il carico di lavoro se una zona di disponibilità è stata rimossa, quindi utilizza i controlli dello stato di Elastic Load Balancing o Amazon Route 53 per spostare il carico dalle istanze danneggiate.
La stabilità statica per la distribuzione di calcolo (ad esempio istanze EC2 o container) determinerà la massima affidabilità. Questa operazione deve essere valutata in base ai problemi relativi ai costi. Eseguire il provisioning di minore capacità di elaborazione e affidarsi all'avvio di nuove istanze in caso di guasto è meno costoso. Tuttavia, per i guasti su larga scala (ad esempio un errore nella zona di disponibilità), questo approccio è meno efficace perché si basa sulla reazione ai guasti nel momento in cui si verificano, piuttosto che prepararsi a tali problemi prima che accadano. La soluzione deve valutare l'affidabilità rispetto alle esigenze di costo per il carico di lavoro. Utilizzando più zone di disponibilità, la quantità di elaborazione aggiuntiva necessaria per la stabilità statica diminuisce.
![\[Diagramma che mostra la stabilità statica delle istanze EC2 nelle varie zone di disponibilità\]](http://docs.aws.amazon.com/it_it/wellarchitected/2022-03-31/framework/images/static-stability.png)
Dopo il trasferimento del traffico, utilizza AWS Auto Scaling per sostituire in modo asincrono le istanze dalla zona interessata dal guasto e avviarle nelle zone integre.
Un altro esempio di comportamento bimodale potrebbe essere un timeout di rete che potrebbe causare un tentativo di aggiornamento dello stato di configurazione dell'intero sistema. Ciò aggiungerebbe un carico imprevisto a un altro componente, che potrebbe quindi causare un errore, innescando altre conseguenze impreviste. Questo loop di feedback negativo influisce sulla disponibilità del tuo carico di lavoro. Al contrario, è necessario creare sistemi che siano staticamente stabili e funzionino in una sola modalità. Un progetto staticamente stabile sarebbe quello di eseguire un lavoro costante e aggiornare sempre, con cadenze fisse, lo stato di configurazione. Quando una chiamata non riesce, il carico di lavoro utilizza il valore precedentemente memorizzato nella cache e attiva un allarme.
Un altro esempio di comportamento bimodale è consentire ai client di bypassare la cache del carico di lavoro quando si verificano guasti. Potrebbe sembrare una soluzione che soddisfi le esigenze del client, ma non dovrebbe essere consentita perché modifica in modo significativo le richieste sul carico di lavoro e potrebbe causare guasti.
**Livello di rischio associato se questa best practice non fosse adottata:** Medium
## Guida all'implementazione
+ Utilizzo della stabilità statica per evitare un comportamento bimodale. Si ha un comportamento bimodale quando il carico di lavoro mostra un comportamento diverso in modalità normale e di guasto, ad esempio facendo affidamento sull'avvio di nuove istanze se una zona di disponibilità ha esito negativo.
+ [Minimizing Dependencies in a Disaster Recovery Plan](https://aws.amazon.com/blogs/architecture/minimizing-dependencies-in-a-disaster-recovery-plan/)
+ [The Amazon Builders' Library: Stabilità statica con le zone di disponibilità](https://aws.amazon.com/builders-library/static-stability-using-availability-zones)
+ [Static stability in AWS: AWS re:Invent 2019: Introducing The Amazon Builders' Library (Introduzione alla libreria dei costruttori di Amazon) (DOP328)](https://youtu.be/sKRdemSirDM?t=704)
+ Devi invece creare sistemi che siano staticamente stabili e operino in una sola modalità. In questo caso, effettua il provisioning di istanze sufficienti in ciascuna zona di disponibilità per gestire il carico di lavoro se una zona di disponibilità è stata rimossa, quindi utilizza i controlli dell'integrità di Elastic Load Balancing o Amazon Route 53 per spostare il carico dalle istanze danneggiate.
+ Un altro esempio di comportamento bimodale è consentire ai client di bypassare la cache del carico di lavoro quando si verificano guasti. Potrebbe sembrare una soluzione per soddisfare le esigenze del client, ma non dovrebbe essere consentita perché modifica in modo significativo le richieste sul carico di lavoro e potrebbe causare guasti.
## Risorse
**Documenti correlati:**
+ [Minimizing Dependencies in a Disaster Recovery Plan](https://aws.amazon.com/blogs/architecture/minimizing-dependencies-in-a-disaster-recovery-plan/)
+ [The Amazon Builders' Library: Stabilità statica con le zone di disponibilità](https://aws.amazon.com/builders-library/static-stability-using-availability-zones)
**Video correlati:**
+ [Static stability in AWS: AWS re:Invent 2019: Introducing The Amazon Builders' Library (Introduzione alla libreria dei costruttori di Amazon) (DOP328)](https://youtu.be/sKRdemSirDM?t=704)
# REL11-BP06 Invio di notifiche quando gli eventi influiscono sulla disponibilità
Le notifiche vengono inviate al rilevamento di eventi significativi, anche se il problema causato dall'evento è stato risolto automaticamente.
Il ripristino automatizzato consente al tuo carico di lavoro di essere affidabile. Tuttavia, potrebbe anche oscurare problemi sottostanti che hanno bisogno di essere risolti. Implementa il monitoraggio e gli eventi appropriati in modo da poter rilevare i modelli di problemi, inclusi quelli risolti dalla diagnostica automatica e risolvere così i problemi della causa principale. Gli allarmi di Amazon CloudWatch possono essere attivati in base ai guasti che si verificano. Possono anche attivarsi in base alle operazioni di ripristino automatizzato eseguite. Gli allarmi CloudWatch possono essere configurati per l'invio di e-mail o per la registrazione di file di log nei sistemi di monitoraggio di terze parti tramite l'integrazione con Amazon SNS.
**Anti-pattern comuni:**
+ Invio di allarmi su cui nessuno agisce.
+ Esecuzione dell'automazione del risanamento automatico, ma senza la notifica della necessità di una correzione.
**Vantaggi dell'adozione di questa best practice:** Le notifiche degli eventi di ripristino ti consentiranno di non ignorare i problemi che si verificano di rado.
**Livello di rischio associato se questa best practice non fosse adottata:** Medium
## Guida all'implementazione
+ Allarmi su indicatori chiave di prestazione aziendali al superamento di una soglia minima Un allarme su indicatori chiave di prestazione aziendali consente di sapere quando il carico di lavoro non è disponibile o non funziona.
+ [Creare un allarme CloudWatch basato su una soglia statica](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/ConsoleAlarms.html)
+ Allarme su eventi che invocano l'automazione della riparazione Puoi invocare direttamente un'API SNS per inviare notifiche con qualsiasi automazione creata.
+ [Che cos'è Amazon Simple Notification Service?](https://docs.aws.amazon.com/sns/latest/dg/welcome.html)
## Risorse
**Documenti correlati:**
+ [Creare un allarme CloudWatch basato su una soglia statica](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/ConsoleAlarms.html)
+ [Che cos'è Amazon EventBridge?](https://docs.aws.amazon.com/eventbridge/latest/userguide/what-is-amazon-eventbridge.html)
+ [Che cos'è Amazon Simple Notification Service?](https://docs.aws.amazon.com/sns/latest/dg/welcome.html)
# REL 12 In che modo testi l'affidabilità?
Dopo aver progettato il carico di lavoro in modo da essere resiliente alle sollecitazioni della produzione, i test sono l'unico modo per garantire il funzionamento corretto e offrire la resilienza prevista.
**Topics**
+ [REL12-BP01 Utilizzo dei playbook per analizzare gli errori](rel_testing_resiliency_playbook_resiliency.md)
+ [REL12-BP02 Esecuzione di analisi post-incidente](rel_testing_resiliency_rca_resiliency.md)
+ [REL12-BP03 Test dei requisiti funzionali](rel_testing_resiliency_test_functional.md)
+ [REL12-BP04 Test dei requisiti di dimensionamento e prestazioni](rel_testing_resiliency_test_non_functional.md)
+ [REL12-BP05 Test della resilienza tramite l'utilizzo dell'ingegneria del caos](rel_testing_resiliency_failure_injection_resiliency.md)
+ [REL12-BP06 Esecuzione regolare di giornate di gioco](rel_testing_resiliency_game_days_resiliency.md)
# REL12-BP01 Utilizzo dei playbook per analizzare gli errori
Abilita risposte coerenti e tempestive a scenari di guasto che non sono ben compresi, documentando il processo di analisi nei playbook. I playbook sono le fasi predefinite eseguite per identificare i fattori che contribuiscono a uno scenario di guasto. I risultati provenienti da un passaggio del processo vengono utilizzati per stabilire i passaggi successivi da intraprendere fino all'identificazione o alla risoluzione del problema.
Il playbook è una pianificazione proattiva che è necessario eseguire, in modo da potere intraprendere azioni reattive in modo efficace. Quando durante la produzione si verificano scenari di guasto non coperti dal playbook, risolvi innanzitutto il problema (spegni l'incendio). Quindi torna indietro e osserva le fasi intraprese per risolvere il problema e utilizzale per aggiungere una nuova voce al playbook.
Tieni presente che i playbook vengono utilizzati in risposta a specifici incidenti, mentre i runbook vengono utilizzati per ottenere esiti specifici. Spesso, i runbook vengono utilizzati per le attività di routine e i playbook vengono utilizzati per rispondere a eventi non di routine.
**Anti-pattern comuni:**
+ Pianificare la distribuzione di un carico di lavoro senza conoscere i processi per diagnosticare i problemi o rispondere agli incidenti.
+ Decisioni non pianificate sui sistemi da cui raccogliere log e parametri durante l'analisi di un evento.
+ Non conservare parametri e eventi abbastanza a lungo da poter recuperare i dati.
**Vantaggi dell'adozione di questa best practice:** L'acquisizione di playbook garantisce l'esecuzione coerente dei processi. La codifica dei playbook limita l'introduzione di errori derivanti dall'attività manuale. L'automazione dei playbook riduce il tempo necessario per rispondere a un evento eliminando il requisito per l'intervento dei membri del team o fornendo loro informazioni aggiuntive quando inizia l'intervento.
**Livello di rischio associato se questa best practice non fosse adottata:** Alta
## Guida all'implementazione
+ Utilizza playbook per identificare i problemi. I playbook sono processi documentati per eseguire indagini sui problemi. Abilita risposte coerenti e tempestive agli scenari di errore documentando i processi nei playbook. I playbook devono contenere le informazioni e le istruzioni necessarie affinché una persona adeguatamente qualificata possa raccogliere le informazioni applicabili, identificare potenziali fonti di errore, isolare i guasti e stabilire i fattori che contribuiscono all'origine di un problema (eseguire l'analisi post-incidente).
+ Implementazione dei playbook come codice. Esegui le operazioni come codice mediante lo scripting dei playbook per assicurare coerenza e ridurre gli errori causati dai processi manuali. I playbook possono essere composti da più script che rappresentano le diverse fasi che potrebbero essere necessarie per identificare i fattori che contribuiscono all'origine di un problema. Le attività dei runbook possono essere attivate o eseguite nell'ambito delle attività dei playbook oppure possono richiedere l'esecuzione di un playbook in risposta agli eventi identificati.
+ [Automazione dei playbook operativi con AWS Systems Manager](https://aws.amazon.com/about-aws/whats-new/2019/11/automate-your-operational-playbooks-with-aws-systems-manager/)
+ [AWS Systems Manager Run Command](https://docs.aws.amazon.com/systems-manager/latest/userguide/execute-remote-commands.html)
+ [AWS Systems Manager Automation](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html)
+ [Cos'è AWS Lambda?](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html)
+ [Che cos'è Amazon EventBridge?](https://docs.aws.amazon.com/eventbridge/latest/userguide/what-is-amazon-eventbridge.html)
+ [Utilizzo degli allarmi di Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html)
## Risorse
**Documenti correlati:**
+ [AWS Systems Manager Automation](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html)
+ [AWS Systems Manager Run Command](https://docs.aws.amazon.com/systems-manager/latest/userguide/execute-remote-commands.html)
+ [Automazione dei playbook operativi con AWS Systems Manager](https://aws.amazon.com/about-aws/whats-new/2019/11/automate-your-operational-playbooks-with-aws-systems-manager/)
+ [Utilizzo degli allarmi di Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html)
+ [Utilizzo di Canary (Amazon CloudWatch Synthetics)](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html)
+ [Che cos'è Amazon EventBridge?](https://docs.aws.amazon.com/eventbridge/latest/userguide/what-is-amazon-eventbridge.html)
+ [Cos'è AWS Lambda?](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html)
**Esempi correlati:**
+ [Automating operations with Playbooks and Runbooks (Automazione delle operazioni con Playbook e Runbook)](https://wellarchitectedlabs.com/operational-excellence/200_labs/200_automating_operations_with_playbooks_and_runbooks/)
# REL12-BP02 Esecuzione di analisi post-incidente
Esamina gli eventi che influiscono sui clienti e identifica i fattori che vi hanno contribuito e gli elementi di azione preventivi. Utilizza queste informazioni per sviluppare modi per limitare o prevenire il ripetersi degli imprevisti. Sviluppa procedure per attivare risposte rapide ed efficaci. Comunica i fattori che hanno contribuito al presentarsi dell'imprevisto e le azioni correttive secondo necessità, specificamente mirate per il pubblico di destinazione. All'occorrenza, adotta un metodo per comunicare queste cause ad altri.
Valuta perché i test esistenti non hanno individuato il problema. Aggiungi i test per questo caso se i test non esistono già.
**Anti-pattern comuni:**
+ Individuare i fattori che hanno contribuito al verificarsi dell'incidente, ma non continuare a cercare in maniera più approfondita altri potenziali problemi e approcci da mitigare.
+ Identificare le cause degli errori umani senza fornire alcuna formazione o automazione che potrebbe prevenirli.
**Vantaggi dell'adozione di questa best practice:** L'esecuzione di analisi post-incidente e la condivisione dei risultati consente ad altri carichi di lavoro di mitigare il rischio se hanno implementato gli stessi fattori che hanno contribuito al verificarsi dell'incidente e consente loro di implementare la mitigazione o il ripristino automatico prima che si verifichi un incidente.
**Livello di rischio associato se questa best practice non fosse adottata:** Alta
## Guida all'implementazione
+ Definizione di uno standard per l'analisi post-incidente. Una buona analisi post-incidente fornisce opportunità per proporre soluzioni comuni a problemi con modelli di architettura utilizzati in altri punti nei tuoi sistemi.
+ Assicurati che i fattori che hanno contribuito al verificarsi dell'incidente siano onesti e non presentino colpe.
+ Se non documenti i tuoi problemi, non puoi correggerli.
+ Assicurati che l'analisi post-incidente sia esente da colpe, in modo da poter essere obiettivo riguardo alle azioni correttive proposte e promuovere autovalutazione e collaborazione oneste nei team applicativi.
+ Utilizza un processo per determinare i fattori che concorrenti. Predisponi un processo per identificare e documentare i fattori che contribuiscono al verificarsi di un evento, in modo da sviluppare azioni di mitigazione in grado di limitare o impedire il suo ripetersi e per sviluppare procedure che consentano risposte rapide ed efficaci. Comunica i fattori che hanno contribuito al verificarsi dell'incidente in maniera appropriata, specificamente mirati al pubblico di destinazione.
+ [Che cos'è l'analisi dei log?](https://aws.amazon.com/log-analytics/)
## Risorse
**Documenti correlati:**
+ [Che cos'è l'analisi dei log?](https://aws.amazon.com/log-analytics/)
+ [Why you should develop a correction of error (COE) (Perché sviluppare una correzione dell'errore)](https://aws.amazon.com/blogs/mt/why-you-should-develop-a-correction-of-error-coe/)
# REL12-BP03 Test dei requisiti funzionali
Utilizza tecniche come i test unitari e i test di integrazione per convalidare le funzionalità richieste.
Puoi ottenere i migliori risultati quando questi test vengono eseguiti automaticamente come parte delle operazioni di sviluppo e distribuzione. Ad esempio, utilizzando AWS CodePipeline, gli sviluppatori affidano le modifiche a un repository di origine in cui CodePipeline rileva automaticamente le modifiche. Queste modifiche vengono create e vengono eseguiti test. Una volta completati i test, il codice creato viene distribuito ai server temporaneo per il test. Dal server temporaneo, CodePipeline esegue più test, come quelli di integrazione o caricamento. Una volta completati con successo i test, CodePipeline distribuisce il codice testato e approvato alle istanze di produzione.
Inoltre, l'esperienza dimostra che i test sintetici delle transazioni (noti anche come *test canary*, ma da non confondere con le implementazioni canary) in grado di eseguire e simulare il comportamento dei clienti sono uno dei processi di test più importanti. Esegui questi test costantemente sugli endpoint del carico di lavoro da diverse posizioni remote. Amazon CloudWatch Synthetics ti consente di [creare "canary"](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html) per monitorare gli endpoint e le API.
**Livello di rischio associato se questa best practice non fosse adottata:** Alta
## Guida all'implementazione
+ Test dei requisiti funzionali. Includono test delle unità e test di integrazione che convalidano la funzionalità richiesta.
+ [Utilizzo di CodePipeline con AWS CodeBuild per testare il codice ed eseguire compilazioni](https://docs.aws.amazon.com/codebuild/latest/userguide/how-to-create-pipeline.html)
+ [AWS CodePipeline Adds Support for Unit and Custom Integration Testing with AWS CodeBuild (AWS CodePipeline aggiunge il supporto per i test di unità e integrazione personalizzati con AWS CodeBuild)](https://aws.amazon.com/about-aws/whats-new/2017/03/aws-codepipeline-adds-support-for-unit-testing/)
+ [Distribuzione continua e integrazione continua](https://docs.aws.amazon.com/codepipeline/latest/userguide/concepts-continuous-delivery-integration.html)
+ [Utilizzo di Canary (Amazon CloudWatch Synthetics)](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html)
+ [Automazione e test del software](https://aws.amazon.com/marketplace/solutions/devops/software-test-automation)
## Risorse
**Documenti correlati:**
+ [Partner APN: partner che possono essere d'aiuto nell'implementazione di una pipeline di integrazione continua](https://aws.amazon.com/partners/find/results/?keyword=Continuous+Integration)
+ [AWS CodePipeline Adds Support for Unit and Custom Integration Testing with AWS CodeBuild (AWS CodePipeline aggiunge il supporto per i test di unità e integrazione personalizzati con AWS CodeBuild)](https://aws.amazon.com/about-aws/whats-new/2017/03/aws-codepipeline-adds-support-for-unit-testing/)
+ [Marketplace AWS: prodotti utilizzabili per l'integrazione continua](https://aws.amazon.com/marketplace/search/results?searchTerms=Continuous+integration)
+ [Distribuzione continua e integrazione continua](https://docs.aws.amazon.com/codepipeline/latest/userguide/concepts-continuous-delivery-integration.html)
+ [Automazione e test del software](https://aws.amazon.com/marketplace/solutions/devops/software-test-automation)
+ [Utilizzo di CodePipeline con AWS CodeBuild per testare il codice ed eseguire compilazioni](https://docs.aws.amazon.com/codebuild/latest/userguide/how-to-create-pipeline.html)
+ [Utilizzo di Canary (Amazon CloudWatch Synthetics)](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html)
# REL12-BP04 Test dei requisiti di dimensionamento e prestazioni
Utilizza tecniche come i test di carico per convalidare che il carico di lavoro soddisfi i requisiti di dimensionamento e prestazioni.
Nel cloud, puoi creare un ambiente di test su scala di produzione on demand per il tuo carico di lavoro. Se esegui questi test su un'infrastruttura ridotta, devi dimensionare i risultati osservati in base a ciò che pensi accadrà in produzione. I test di carico e prestazioni possono essere eseguiti anche in produzione se si fa attenzione a non influire sugli utenti effettivi e si contrassegna con tag i dati di test in modo da non utilizzare dati utente reali e non danneggiare le statistiche di utilizzo o i report di produzione.
Con i test, assicurati che le risorse di base, le impostazioni di dimensionamento, le quote di servizio e la progettazione di resilienza funzionino come previsto sotto carico.
**Livello di rischio associato se questa best practice non fosse adottata:** Alta
## Guida all'implementazione
+ Test dei requisiti di dimensionamento e prestazioni. Esegui test del carico per verificare che il carico di lavoro soddisfi i requisiti di dimensionamento e prestazioni.
+ [Distributed Load Testing on AWS (Test di carico distribuito su AWS): simula migliaia di utenti connessi](https://aws.amazon.com/solutions/distributed-load-testing-on-aws/)
+ [Apache JMeter](https://github.com/apache/jmeter?ref=wellarchitected)
+ Distribuisci la tua applicazione in un ambiente identico al tuo ambiente di produzione ed esegui un test di carico.
+ Utilizza un'infrastruttura come code concept per creare un ambiente il più simile possibile al tuo ambiente di produzione.
## Risorse
**Documenti correlati:**
+ [Distributed Load Testing on AWS (Test di carico distribuito su AWS): simula migliaia di utenti connessi](https://aws.amazon.com/solutions/distributed-load-testing-on-aws/)
+ [Apache JMeter](https://github.com/apache/jmeter?ref=wellarchitected)
# REL12-BP05 Test della resilienza tramite l'utilizzo dell'ingegneria del caos
Esegui regolarmente esperimenti di ingegneria del caos in ambienti di produzione o per quanto possibile ambienti analoghi per capire in che modo il sistema risponde a condizioni avverse.
** Risultato desiderato: **
La resilienza del carico di lavoro viene regolarmente verificata mediante l'applicazione dell'ingegneria del caos sotto forma di esperimenti di iniezione di errori o di inserimento di carichi imprevisti, nonché mediante il test della resilienza che convalida i comportamenti previsti noti del carico di lavoro durante un evento. Combina l'ingegneria del caos e i test della resilienza per verificare se il carico di lavoro è in grado di superare i guasti dei componenti ed eseguire il ripristino da interruzioni del servizio impreviste con un impatto minimo o nullo.
** Anti-pattern comuni: **
+ Progettazione della resilienza, ma mancata verifica del funzionamento del carico di lavoro nel suo complesso in caso di errori.
+ Mancata sperimentazione in scenari reali e con carichi previsti.
+ Mancato trattamento degli esperimenti come codice o loro conservazione durante il ciclo di sviluppo.
+ Mancata esecuzione degli esperimenti di ingegneria del caos sia nella pipeline CI/CD che esternamente alle implementazioni.
+ Mancato utilizzo delle precedenti analisi post-incidente durante la determinazione degli errori su cui eseguire i test.
** Vantaggi dell'adozione di questa best practice:** l'introduzione di errori per verificare la resilienza del carico di lavoro consente di verificare che le procedure di ripristino della progettazione resiliente funzionerà se viene generato un vero e proprio errore.
**Livello di rischio associato se questa best practice non fosse adottata:** Medio
## Guida all'implementazione
L'ingegneria del caos offre ai team la possibilità di continuare a inserire scenari di errore reali (simulazioni) in modo controllato a livello di fornitore di servizi, infrastruttura, carico di lavoro e componente con un impatto minimo o nullo per i clienti. Consente inoltre ai team di imparare dagli errori e osservare, misurare e migliorare la resilienza dei carichi di lavoro, nonché verificare l'attivazione degli avvisi e se tali avvisi vengono recapitati ai team se si verifica un evento definito.
Se applicata in modo continuativo, l'ingegneria del caos può mettere in evidenza i difetti del carico di lavoro che, se non risolti, possono avere ripercussioni negative sulla disponibilità e sulle operazioni.
**Nota**
L'ingegneria del caos è la disciplina che sperimenta un sistema per creare fiducia nella capacità del sistema di affrontare condizioni turbolenti nella produzione. – [Principi di ingegneria del caos](https://principlesofchaos.org/)
Se un sistema è in grado di sopportare queste interruzioni, l'esperimento di ingegneria del caos deve essere convertito in test automatico di regressione. In questo modo, gli esperimenti di ingegneria del caos devono essere eseguiti nell'ambito del ciclo di vita dello sviluppo dei sistemi (SDLC) e della pipeline CI/CD.
Per garantire che il carico di lavoro sia in grado di gestire un guasto del componente, esegui l'iniezione di eventi di errore reali durante l'esecuzione degli esperimenti. Ad esempio, esegui esperimenti relativi alla perdita di istanze Amazon EC2 o a eventi di failover delle istanze database Amazon RDS primario e quindi verifica che il carico di lavoro non sia stato compromesso oppure o che si stato interessato solo in minima parte. Utilizza una combinazione di errori dei componenti per simulare gli eventi che possono essere causati da un'interruzione del servizio in una zona di disponibilità.
Per gli errori a livello di applicazione, ad esempio gli arresti anomali, puoi iniziare utilizzando fattori di stress, ad esempio l'esaurimento della memoria o della CPU.
Per convalidare i [meccanismi di fallback o failover](https://aws.amazon.com/builders-library/avoiding-fallback-in-distributed-systems/) per le dipendenze esterne causate da interruzioni intermittenti dei servizi di rete, i componenti devono simulare tale evento bloccando l'accesso ai fornitori di terze parti per una durata specificata, che può durare da pochi secondi ad alcune ore.
Altre modalità di degrado possono causare funzionalità ridotte e risposte lente, spesso con conseguente interruzione dei servizi. Le fonti comuni di questo degrado sono una maggiore latenza nei servizi critici e una comunicazione di rete inaffidabile (pacchetti persi). Gli esperimenti basati su questi errori, inclusi gli effetti a livello di rete come latenza, messaggi eliminati ed errori DNS, possono prevedere l'incapacità di risolvere un nome, raggiungere il servizio DNS o stabilire connessioni a servizi dipendenti.
**Strumenti dell'ingegneria del caos**
AWS Fault Injection Service (AWS FIS) è un servizio completamente gestito per l'esecuzione di esperimenti di iniezione di errori che possono essere utilizzati come parte della pipeline di CD o al suo esterno. AWS FIS è una soluzione estremamente valida da utilizzare durante i giorni di gioco dell'ingegneria del caos. Supporta l'introduzione simultanea di errori in diversi tipi di risorse, ad esempio Amazon EC2, Amazon Elastic Container Service (Amazon ECS), Amazon Elastic Kubernetes Service (Amazon EKS) e Amazon RDS. Questi errori includono la cessazione delle risorse, la forzatura dei failover, l'applicazione di fattori di stress a CPU o memoria, la limitazione della lunghezza di banda della rete, la latenza e la perdita di pacchetti. Poiché è integrato con gli allarmi Amazon CloudWatch, è possibile impostare condizioni di arresto come guardrail per eseguire il rollback di un esperimento se causa un impatto inatteso.
![\[Diagramma che mostra AWS Fault Injection Service integrato con le risorse AWS per consentire l'esecuzione di esperimenti di iniezione di errori per i carichi di lavoro.\]](http://docs.aws.amazon.com/it_it/wellarchitected/2022-03-31/framework/images/fault-injection-simulator.png)
Esistono anche diverse opzioni di terze parti per gli esperimenti di iniezione di errori. Queste includono strumenti open source, ad esempio [Chaos Toolkit](https://chaostoolkit.org/), [Chaos Mesh](https://chaos-mesh.org/)e [Litmus Chaos](https://litmuschaos.io/), nonché opzioni commerciali come Gremlin. Per ampliare l'ambito degli errori che possono essere inseriti in AWS, AWS FIS [si integra con Chaos Mesh e Litmus Chaos](https://aws.amazon.com/about-aws/whats-new/2022/07/aws-fault-injection-simulator-supports-chaosmesh-litmus-experiments/)e ciò consente di coordinare i flussi di lavoro relativi all'iniezione di errori tra più strumenti. Ad esempio, puoi eseguire un test di stress sulla CPU di un pod utilizzando gli errori di Chaos Mesh o Litmus Chaos durante la cessazione di una percentuale casualmente selezionata di nodi di cluster mediante le operazioni di errore di AWS FIS.
## Passaggi dell'implementazione
+ Determinazione degli errori da utilizzare per gli esperimenti.
Valutazione della progettazione del carico di lavoro a livello di resilienza. Tali progettazioni, create mediante le best practice del [Canone di architettura AWS](https://docs.aws.amazon.com/wellarchitected/latest/framework/welcome.html)) giustificano i rischi in base alle dipendenze critiche, agli eventi pregressi, alle problematiche note e ai requisiti di conformità. Elenca i singoli elementi della progettazione che devono conservare la resilienza e gli errori per mitigare i quali è stata sviluppata. Per ulteriori informazioni su questi elenchi, consulta [il whitepaper relativo alla prontezza operativa](https://docs.aws.amazon.com/wellarchitected/latest/operational-readiness-reviews/wa-operational-readiness-reviews.html) , contenente linee guida su come creare un processo per impedire che si verifichino di nuovo incidenti già noti. Il processo FMEA (Failure Modes and Effects Analysis) fornisce un framework per l'esecuzione di un'analisi degli errori a livello di componente e del relativo impatto sul carico di lavoro. Il processo FMEA è descritto più in dettaglio nell'articolo di Adrian Cockcroft su [modalità di errore e resilienza continua](https://adrianco.medium.com/failure-modes-and-continuous-resilience-6553078caad5).
+ Assegna una priorità a ogni errore.
Comincia con una categorizzazione approssimativa, ad esempio alta, media o bassa. Per assegnare la priorità, considera la frequenza dell'errore e l'impatto dell'errore sul carico di lavoro nel suo complesso.
Durante la valutazione della frequenza di un errore specifico, analizza i precedenti dati per lo stesso carico di lavoro, se disponibili. Se non sono disponibili, utilizza i dati di altri carichi di lavoro eseguiti in un ambiente simile.
Durante la valutazione dell'impatto di un errore specifico, in genere maggiore è l'ambito dell'errore, maggiore sarà l'impatto. Considera la progettazione e lo scopo del carico di lavoro. Ad esempio, la capacità di accedere ai datastore di origine è di cruciale importanza per un carico di lavoro responsabile della trasformazione e dell'analisi dei dati. In questo caso, darai la precedenza agli esperimenti relativi agli errori di accesso, nonché a quelli con accesso limitato a livello di larghezza di banda e inserimento di latenza.
Le analisi post-incidente rappresentano un'ottima fonte di dati per la comprensione della frequenza e dell'impatto delle modalità di errore.
Utilizza la priorità assegnata per determinare il primo errore su cui eseguire l'esperimento e l'ordine in cui sviluppare i nuovi esperimenti di iniezione di errori.
+ Per ogni esperimento eseguito, attieniti ai principi del volano dell'ingegneria del caos e della resilienza continua.
![\[Diagramma del volano dell'ingegneria del caos e della resilienza continua, con le fasi relative a miglioramento, stato stazionario, ipotesi, esecuzione dell'esperimento e verifica.\]](http://docs.aws.amazon.com/it_it/wellarchitected/2022-03-31/framework/images/chaos-engineering-flywheel.png)
+ Definisci lo stato stazionario come output misurabile di un carico di lavoro che indica un comportamento normale.
Il carico di lavoro è associato allo stato stazionario se il suo funzionamento è affidabile e conforme a quanto previsto. Verifica pertanto che il carico di lavoro sia integro prima di definire lo stato stazionario. Lo stato stazionario non necessariamente indica l'assenza di impatto sul carico di lavoro se si verifica un errore in quanto una data percentuale di errori può rientrare nei limiti di valori accettabili. Lo stato stazionario rappresenta il punto di riferimento che verrà osservato durante l'esperimento e che metterà in evidenza le anomalie se le ipotesi definite nel passaggio successivo non sono conformi alle previsioni.
Ad esempio, lo stato stazionario di un sistema di pagamento può essere definito come elaborazione di 300 TPS con una percentuale di successo pari al 99% e un tempo di round trip pari a 500 ms.
+ Definisci un'ipotesi in merito alle reazioni del carico di lavoro all'errore.
Un'ipotesi ottimale fa riferimento al modo in cui il carico di lavoro presumibilmente è in grado di ridurre l'impatto dell'errore e salvaguardare lo stato stazionario. Nell'ipotesi è definito che, dato un errore di un tipo specifico, il sistema o il carico di lavoro rimarrà nello stato stazionario perché la progettazione del carico di lavoro ha previsto sistemi specifici di attenuazione degli errori. Il tipo di errore specifico e i sistemi di attenuazione devono essere specificati nell'ipotesi.
Per l'ipotesi è possibile utilizzare il seguente modello, anche se è accettabile una formulazione diversa:
**Nota**
Se si verifica un *errore specifico* , il carico di lavoro *nome del carico di lavoro* descriverà *i controlli di attenuazione* per controbilanciare *l'impatto sulle metriche aziendali o tecniche*.
Ad esempio:
+ In caso di arresto del 20% dei nodi nel gruppo di nodi Amazon EKS, l'API di creazione delle transazioni continua a servire il 99° percentile delle richieste in meno di 100 ms (stato stazionario). Verrà eseguito il ripristino dei nodi Amazon EKS entro cinque minuti; i pod verranno riprogrammati ed elaboreranno il traffico entro otto minuti dall'inizio dell'esperimento. Gli avvisi verranno attivati entro tre minuti.
+ Se si verifica un errore in un'istanza Amazon EC2, il controllo dell'integrità Elastic Load Balancing del sistema degli ordini farà sì che Elastic Load Balancing si limiti a inviare richieste alle rimanenti istanze integre, mentre la funzionalità Amazon EC2 Auto Scaling sostituirà l'istanza in errore, garantendo un incremento inferiore allo 0,01% degli errori (5xx) lato server (stato stazionario).
+ Se l'istanza database primario Amazon RDS restituisce un errore, il carico di lavoro della raccolta di dati della catena di approvvigionamento eseguirà il failover e si connetterà all'istanza database in standby Amazon RDS per mantenere meno di un minuto di errori di lettura o scrittura del database (stato stazionario).
+ Esegui l'esperimento inserendo l'errore.
Per impostazione predefinita, un esperimento deve essere a prova di errore e tollerato dal carico di lavoro. Se sei consapevole del fatto che il carico di lavoro avrà esito negativo, non eseguire l'esperimento. L'ingegneria del caos deve essere utilizzata per individuare scenari noti sconosciuti o scenari completamente sconosciuti. *"Scenari noti sconosciuti"* fanno riferimento a quegli scenari di cui sei consapevole, ma non ne comprendi completamente la natura, mentre con *"scenari completamente sconosciuti"* si intendono quegli scenari a te non noti e di cui non ne comprendi la natura o i motivi. L'esecuzione di esperimenti su un carico di lavoro non funzionante non può fornire nuovi approfondimenti chiarificatori. L'esperimento deve infatti essere pianificato con attenzione, essere caratterizzato da un ambito ben definito relativamente al suo impatto, nonché fornire un meccanismo di rollback applicabile in caso di esiti negativi imprevisti. Se il criterio di due diligence indica che il carico di lavoro è in grado di sostenere l'esperimento, procedi ed esegui l'esperimento. Sono disponibili varie opzioni per l'inserimento degli errori. Per i carichi di lavoro in AWS, [AWS FIS](https://docs.aws.amazon.com/fis/latest/userguide/what-is.html) fornisce numerose simulazioni di errore predefinite denominate [operazioni](https://docs.aws.amazon.com/fis/latest/userguide/actions.html). Puoi anche definire operazioni personalizzate eseguibili in AWS FIS utilizzando i [documenti AWS Systems Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/sysman-ssm-docs.html).
È sconsigliato l'uso di script personalizzati per gli esperimenti di ingegneria del caos, a meno che gli script non siano in grado di rilevare lo stato corrente del carico di lavoro, generare log e fornire meccanismi di rollback e condizioni di arresto, laddove possibile.
Un framework o set di strumenti efficace che supporta l'ingegneria del caos deve tenere traccia dello stato corrente di un esperimento, generare log e fornire meccanismi di rollback a supporto dell'esecuzione controllata di un esperimento. Inizia utilizzando un servizio noto, ad esempio AWS FIS, che consente di eseguire esperimenti con ambiti e meccanismi di sicurezza ben definiti in grado di eseguire il rollback dell'esperimento in caso di esiti negativi imprevisti. Per ulteriori informazioni sull'intera gamma di esperimenti che utilizzano AWS FIS, consulta anche la sezione relativa al [laboratorio relativo alle app Well-Architected resilienti con ingegneria del caos](https://catalog.us-east-1.prod.workshops.aws/workshops/44e29d0c-6c38-4ef3-8ff3-6d95a51ce5ac/en-US). Inoltre, [AWS Resilience Hub](https://docs.aws.amazon.com/resilience-hub/latest/userguide/what-is.html) analizzerà il carico di lavoro e creerà gli esperimenti che potrai scegliere di implementare ed eseguire in AWS FIS.
**Nota**
Per ogni esperimento, devi essere consapevole del suo ambito e del relativo impatto. È consigliabile eseguire la simulazione dell'errore in un ambiente non di produzione prima di eseguirla in un ambiente di produzione vero e proprio.
Gli esperimenti devono essere eseguiti in ambienti di produzione con un carico reale mediante [implementazioni canary](https://medium.com/the-cloud-architect/chaos-engineering-q-a-how-to-safely-inject-failure-ced26e11b3db) , che attivano sistemi sperimentali e di controllo, laddove possibile. L'esecuzione degli esperimenti durante gli orari non di punta è altamente consigliata al fine di ridurre al massimo potenziali eventi negativi durante la prima esecuzione dell'esperimento negli ambienti di produzione. Inoltre, se l'utilizzo dell'effettivo traffico clienti costituisce un rischio eccessivo, puoi eseguire gli esperimenti utilizzando una sintesi del traffico nell'infrastruttura di produzione utilizzando implementazioni sperimentali e di controllo. Se l'utilizzo di un ambiente di produzione non è possibile, esegui gli esperimenti in ambienti di pre-produzione il più simili possibile agli effettivi ambienti di produzione.
Devi definire e monitorare i guardrail per essere sicuro che l'esperimento non abbia un impatto sul traffico di produzione o sugli altri sistemi che superi i limiti accettabili. Definisci condizioni di arresto per interrompere l'esperimento se viene raggiunta la soglia definita nella metrica del guardrail. In tali condizioni devono essere incluse le metriche relative allo stato stazionario del carico di lavoro e le metriche riferite ai componenti in cui inserisci l'errore. Un [monitor sintetico](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html) (definito anche canary utente) è una metrica che in genere deve essere inclusa come proxy utente. [Le condizioni di arresto per AWS FIS](https://docs.aws.amazon.com/fis/latest/userguide/stop-conditions.html) sono supportate nel modello di esperimento, nella misura di un massimo di cinque condizioni di arresto per modello.
Uno dei principi dell'ingegneria del caos prevede la riduzione dell'ambito dell'esperimento e del relativo impatto.
Se da un lato deve essere prevista la possibilità di un determinato impatto negativo a breve termine, dall'altro il contenimento e la riduzione delle conseguenze negative degli esperimenti sono una responsabilità esclusiva dell'addetto all'ingegneria del caos.
Un metodo per verificare l'ambito e il potenziale impatto prevede l'esecuzione dell'esperimento dapprima in un ambiente non di produzione, la verifica che le soglie delle condizioni di arresto vengano attivate come previsto durante lo svolgimento di un esperimento e l'utilizzo effettivo delle misure di osservabilità finalizzate all'acquisizione di un'eccezione, anziché eseguire l'esperimento direttamente in produzione.
Durante l'esecuzione di esperimenti di iniezione di errori, verifica che tutte le parti responsabili ne siano a conoscenza. Comunica ai team appropriati, ad esempio i team responsabili delle operazioni, dell'affidabilità dei servizi e del supporto clienti, quando verranno eseguiti gli esperimenti e l'impatto previsto. Metti a disposizione di questi team strumenti di comunicazione che consentano loro di informare i responsabili dell'esperimento di eventuali effetti avversi.
È necessario ripristinare lo stato originario del carico di lavoro e dei relativi sistemi sottostanti. La progettazione resiliente del carico di lavoro è spesso caratterizzata da funzionalità di riparazione automatica. Tuttavia, alcune progettazioni difettose o alcuni esperimenti non riusciti possono compromettere in modo imprevisto lo stato del carico di lavoro. Entro la fine dell'esperimento dovrai essere consapevole di questa situazione e ripristinare il carico di lavoro e i sistemi. Con AWS FIS puoi impostare una configurazione di rollback, definita anche post-operazione, all'interno dei parametri operativi. Una post-operazione ripristina una destinazione allo stato in cui si trovava prima dell'esecuzione dell'operazione stessa. Indipendentemente dal fatto che vengano eseguite in modalità automatica, ad esempio utilizzando AWS FIS, o manuale, queste post-operazioni devono essere incluse in un playbook in cui vengono descritte le procedure di rilevamento e gestione degli errori.
+ Verifica l'ipotesi.
[Principi di ingegneria del caos](https://principlesofchaos.org/) è un documento contenente le linee guida su come verificare lo stato stazionario del carico di lavoro.
È necessario concentrarsi sull'output misurabile di un sistema e non sugli attributi interni del sistema. Le misurazioni di tale output in un breve periodo di tempo costituiscono un'attestazione dello stato stazionario del sistema. La velocità di trasmissione effettiva del sistema nel suo complesso, le percentuali di errori e i percentili della latenza possono essere considerati metriche di interesse che rappresentano il comportamento di uno stato stazionario. Sulla base dei rilevamenti dei modelli di comportamento sistematico durante gli esperimenti, l'ingegneria del caos verifica che il sistema funzioni correttamente anziché tentare di convalidare il modo in cui funziona.
Nei due esempi precedenti sono state incluse le metriche dello stato stazionario relative a un incremento inferiore allo 0,01% di errori (5xx) lato server e inferiore a un minuto di errori di lettura e scrittura del database.
Gli errori 5xx rappresentano una buona metrica perché sono la conseguenza della modalità di errore che un client del carico di lavoro sperimenterà direttamente. La misurazione degli errori del database risulta valida come conseguenza diretta dell'errore, ma deve essere supportata da una misurazione diretta dell'impatto, ad esempio le richieste cliente non riuscite o gli errori restituiti a livello di client. Includi anche un monitor sintetico, definito canary utente, in qualsiasi API o URI a cui il client del carico di lavoro ha accesso diretto.
+ Migliora la progettazione del carico di lavoro con un occhio di riguardo per la resilienza.
Se lo stato stazionario non è stato preservato, analizza in che modo puoi migliorare la progettazione del flusso di lavoro per azzerare l'impatto dell'errore applicando le best practice descritte nel [Pilastro AWS Well-Architected relativo all'affidabilità](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/welcome.html). Ulteriori linee guida e risorse sono disponibili nella [libreria di AWS Builder](https://aws.amazon.com/builders-library/), dove sono contenuti articoli su come [migliorare i controlli dell'integrità](https://aws.amazon.com/builders-library/implementing-health-checks/) oppure [impiegare nuovi tentativi con backoff nel codice dell'applicazione](https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/).
Dopo aver implementato queste modifiche, esegui di nuovo l'esperimento (rappresentato dalla linea punteggiata nel volano relativo all'ingegneria del caos) per determinare la relativa efficacia. Se nella fase di verifica risulta che l'ipotesi è vera, il carico di lavoro sarà in stato stazionario e il ciclo continuerà.
+ Esegui gli esperimenti con regolarità.
Un esperimento di ingegneria del caos è un ciclo e gli esperimenti devono essere eseguiti regolarmente nell'ambito dell'ingegneria del caos. Se un carico di lavoro è conforme all'ipotesi dell'esperimento, l'esperimento deve essere automatizzato affinché venga eseguito continuamente come fase di regressione della pipeline CI/CD. Per ulteriori informazioni in merito, consulta questo blog relativamente alle [procedure di esecuzione degli esperimenti AWS FIS utilizzando AWS CodePipeline](https://aws.amazon.com/blogs/architecture/chaos-testing-with-aws-fault-injection-simulator-and-aws-codepipeline/). Questo laboratorio relativo a esperimenti [AWS FIS ricorrenti in una pipeline CI/CD](https://chaos-engineering.workshop.aws/en/030_basic_content/080_cicd.html) ti consente di fare esperienza pratica.
Gli esperimenti di iniezione di errori fanno inoltre parte delle giornate di gioco (consulta [REL12-BP06 Esecuzione regolare di giornate di gioco](rel_testing_resiliency_game_days_resiliency.md)). Le giornate di gioco simulano un errore o un evento per verificare sistemi, processi e risposte dei team. Lo scopo è di eseguire effettivamente le azioni che compirebbe il team come se si verificasse un evento eccezionale.
+ Acquisisci e archivia i risultati degli esperimenti.
I risultati degli esperimenti di iniezione di errori devono essere acquisiti e resi persistenti. Includi tutti i dati necessari, ad esempio orari, carico di lavoro e condizioni, in modo da essere in grado di analizzare i risultati e i trend in un secondo momento. I risultati potrebbero includere, ad esempio, screenshot dei pannelli di controllo, dump in formato CSV del database delle metriche oppure appunti scritti a mano relativi a eventi e osservazioni associati all'esperimento. [La registrazione degli esperimenti mediante AWS FIS](https://docs.aws.amazon.com/fis/latest/userguide/monitoring-logging.html) può rientrare nel processo di acquisizione dei dati.
## Risorse
**Best practice correlate:**
+ [REL08-BP03 Esecuzione di test di resilienza come parte integrante dell'implementazione](rel_tracking_change_management_resiliency_testing.md)
+ [REL13-BP03 Esecuzione di test sull'implementazione del ripristino di emergenza per convalidare l'implementazione](rel_planning_for_recovery_dr_tested.md)
**Documenti correlati:**
+ [What is AWS Fault Injection Service? (Che cos'è AWS Fault Injection Service?)](https://docs.aws.amazon.com/fis/latest/userguide/what-is.html)
+ [What is AWS Resilience Hub? (Che cos'è AWS Resilience Hub?)](https://docs.aws.amazon.com/resilience-hub/latest/userguide/what-is.html)
+ [Principi di ingegneria del caos](https://principlesofchaos.org/)
+ [Chaos Engineering: Planning your first experiment (Ingegneria del caos: pianificazione del primo esperimento)](https://medium.com/the-cloud-architect/chaos-engineering-part-2-b9c78a9f3dde)
+ [Resilience Engineering: Learning to Embrace Failure](https://queue.acm.org/detail.cfm?id=2371297)
+ [Chaos Engineering stories (Storie relative all'ingegneria del caso)](https://github.com/ldomb/ChaosEngineeringPublicStories)
+ [Evitare fallback nei sistemi distribuiti](https://aws.amazon.com/builders-library/avoiding-fallback-in-distributed-systems/)
+ [Canary Deployment for Chaos Experiments (Implementazione canary per gli esperimenti di ingegneria del caos)](https://medium.com/the-cloud-architect/chaos-engineering-q-a-how-to-safely-inject-failure-ced26e11b3db)
**Video correlati:**
+ [AWS re:Invent 2020: Testing resiliency using chaos engineering (ARC316) (Esecuzione di test di resilienza mediante l'ingegneria del caos [ARC316])](https://www.youtube.com/watch?v=OlobVYPkxgg)
+ [AWS re:Invent 2019: migliorare la resilienza con l'ingegneria del caos (DOP309-R1)](https://youtu.be/ztiPjey2rfY)
+ [AWS re:Invent 2019: Performing chaos engineering in a serverless world (CMY301) (Esecuzione dell'ingegneria del caos in uno scenario serverless [CMY301])](https://www.youtube.com/watch?v=vbyjpMeYitA)
**Esempi correlati:**
+ [Well-Architected lab: Level 300: Testing for Resiliency of Amazon EC2, Amazon RDS, and Amazon S3 (Test della resilienza di Amazon EC2, Amazon RDS e Amazon S3)](https://wellarchitectedlabs.com/reliability/300_labs/300_testing_for_resiliency_of_ec2_rds_and_s3/)
+ [Chaos Engineering on AWS lab (Laboratorio relativo all'ingegneria del caos in AWS)](https://chaos-engineering.workshop.aws/en/)
+ [Resilient and Well-Architected Apps with Chaos Engineering lab (Laboratorio relativo alle app Well-Architected resilienti con ingegneria del caos)](https://catalog.us-east-1.prod.workshops.aws/workshops/44e29d0c-6c38-4ef3-8ff3-6d95a51ce5ac/en-US)
+ [Serverless Chaos lab (Laboratorio relativi a esperimenti di ingegneria del caos per architetture serverless)](https://catalog.us-east-1.prod.workshops.aws/workshops/3015a19d-0e07-4493-9781-6c02a7626c65/en-US/serverless)
+ [Measure and Improve Your Application Resilience with AWS Resilience Hub lab (Laboratorio di misurazione e ottimizzazione della resilienza dell'applicazione con AWS Resilience Hub)](https://catalog.us-east-1.prod.workshops.aws/workshops/2a54eaaf-51ee-4373-a3da-2bf4e8bb6dd3/en-US/200-labs/1wordpressapplab)
** Strumenti correlati: **
+ [AWS Fault Injection Service](https://aws.amazon.com/fis/)
+ Marketplace AWS: [Gremlin Chaos Engineering Platform (Piattaforma di ingegneria del caos di Gremlin)](https://aws.amazon.com/marketplace/pp/prodview-tosyg6v5cyney)
+ [Chaos Toolkit](https://chaostoolkit.org/)
+ [Chaos Mesh](https://chaos-mesh.org/)
+ [Litmus](https://litmuschaos.io/)
# REL12-BP06 Esecuzione regolare di giornate di gioco
Utilizza le giornate di gioco per provare regolarmente le procedure per rispondere a eventi ed errori nel modo più vicino possibile alla produzione (anche negli ambienti di produzione) con le persone che si occuperanno di eventuali scenari di errore reali. Le giornate di gioco applicano misure per garantire che gli eventi di produzione non influiscano sugli utenti.
Le giornate di gioco simulano un errore o un evento per testare sistemi, processi e risposte dei team. Lo scopo è di eseguire effettivamente le azioni che compirebbe il team come se si verificasse un evento eccezionale. Questi ti aiuta a capire dove puoi apportare dei miglioramenti e ti può aiutare a sviluppare un'esperienza organizzativa nella gestione degli eventi. Tali azioni devono essere svolte regolarmente in modo che il team costruisca *una memoria muscolare* su come rispondere.
Quando la progettazione per la resilienza è in loco ed è stata testata in ambienti non di produzione, un game day è il modo per garantire che tutto funzioni come pianificato in produzione. Una giornata di gioco, soprattutto la prima, è un'attività di duro lavoro per tutti, in cui tutti gli ingegneri e i team operativi vengono informati in merito a quando accadrà e cosa accadrà. I runbook sono in loco. Gli eventi simulati, compresi i possibili eventi di guasto, vengono eseguiti nei sistemi di produzione nel modo prescritto e ne viene valutato l'impatto. Se tutti i sistemi funzionano come progettato, il rilevamento e la correzione automatica avvengono con un impatto minimo o nullo. Tuttavia, se si osserva un impatto negativo, viene eseguito il rollback del test e i problemi relativi al carico di lavoro vengono risolti, se necessario manualmente (utilizzando il runbook). Poiché le giornate di gioco hanno spesso luogo in produzione, è necessario prendere tutte le precauzioni per garantire che non vi sia alcun impatto sulla disponibilità per i clienti.
**Anti-pattern comuni:**
+ Documentare le procedure senza mai esercitarle.
+ Non includere i responsabili delle decisioni aziendali negli esercizi di test.
**Vantaggi dell'adozione di questa best practice:** Eseguire giornate di gioco garantisce che tutto il personale segua le policy e le procedure quando si verifica un incidente reale e convalida che tali policy e procedure siano appropriate.
**Livello di rischio associato se questa best practice non fosse adottata:** Medium
## Guida all'implementazione
+ Programma giornate di gioco per provare regolarmente i tuoi runbook e playbook. Le giornate di gioco devono coinvolgere tutte le persone implicate in un evento di produzione: proprietari di aziende, personale addetto allo sviluppo, personale operativo e team di risposta agli incidenti.
+ Esegui i test di carico o delle prestazioni e successivamente esegui l'iniezione degli errori.
+ Ricerca anomalie nei tuoi runbook e opportunità di provare i tuoi playbook.
+ In caso di deviazione dai tuoi runbook, perfeziona il runbook o correggi il comportamento. Se ti eserciti sul tuo playbook, identifica il runbook che avrebbe dovuto essere usato, oppure creane uno nuovo.
## Risorse
**Documenti correlati:**
+ [Che cos'è AWS GameDay?](https://aws.amazon.com/gameday/)
**Video correlati:**
+ [AWS re:Invent 2019: migliorare la resilienza con l'ingegneria del caos (DOP309-R1)](https://youtu.be/ztiPjey2rfY)
**Esempi correlati:**
+ [AWS Well-Architected Labs – Test di resilienza](https://wellarchitectedlabs.com/reliability/300_labs/300_testing_for_resiliency_of_ec2_rds_and_s3/)
# REL 13 Come pianifichi il disaster recovery (DR)?
Avere backup e componenti del carico di lavoro ridondanti in loco è l'inizio della strategia di disaster recovery. [RTO e RPO sono i tuoi obiettivi](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/disaster-recovery-dr-objectives.html) per il ripristino del carico di lavoro. Imposta questi valori in base alle esigenze aziendali. Implementa una strategia per raggiungere questi obiettivi, prendendo in considerazione le posizioni e la funzione delle risorse e dei dati del carico di lavoro. La probabilità di interruzione e il costo del ripristino sono fattori chiave che aiutano a comunicare il valore aziendale che può avere il ripristino di emergenza per un carico di lavoro.
**Topics**
+ [REL13-BP01 Definizione degli obiettivi di ripristino in caso di downtime e perdita di dati](rel_planning_for_recovery_objective_defined_recovery.md)
+ [REL13-BP02 Utilizzo di strategie di ripristino definite per conseguire gli obiettivi di ripristino](rel_planning_for_recovery_disaster_recovery.md)
+ [REL13-BP03 Esecuzione di test sull'implementazione del ripristino di emergenza per convalidare l'implementazione](rel_planning_for_recovery_dr_tested.md)
+ [REL13-BP04 Gestione della deviazione di configurazione nel sito o nella Regione del ripristino di emergenza](rel_planning_for_recovery_config_drift.md)
+ [REL13-BP05 Automatizzazione del ripristino](rel_planning_for_recovery_auto_recovery.md)
# REL13-BP01 Definizione degli obiettivi di ripristino in caso di downtime e perdita di dati
Il carico di lavoro ha un Recovery Time Objective (RTO) e Recovery Point Objective (RPO).
*Il Recovery Time Objective (RTO)* è il ritardo massimo accettabile tra l'interruzione del servizio e il suo ripristino. Questo determina ciò che viene considerato un intervallo di tempo accettabile quando il servizio non è disponibile.
*Recovery Point Objective (RPO)* è il periodo di tempo massimo accettabile dall'ultimo punto di ripristino dei dati. Questo determina ciò che viene considerato una perdita di dati accettabile tra l'ultimo punto di ripristino e l'interruzione del servizio.
RTO e RPO sono valori importanti quando si seleziona una strategia adeguata di ripristino di emergenza per il proprio carico di lavoro. Tali obiettivi sono stabiliti dall'azienda e poi vengono utilizzati dai team tecnici per selezionare e implementare una strategia di ripristino di emergenza.
**Risultato desiderato:**
Ogni carico di lavoro ha un RTO e un RPO assegnati, definiti in base all'impatto aziendale. Il carico di lavoro viene assegnato a un livello predefinito, che stabilisce la disponibilità del servizio e la perdita accettabile di dati, con un RTO e un RPO associati. Se tale livello non è raggiungibile, è possibile assegnare un livello personalizzato per carico di lavoro, con l'obiettivo di creare i livelli in un secondo momento. RTO e RPO sono valori fondamentali per la selezione di una strategia di ripristino di emergenza da implementare per il carico di lavoro. Altre riflessioni nel momento della scelta di una strategia di ripristino di emergenza sono i vincoli economici, le dipendenze del carico di lavoro e i requisiti operativi.
Per l'RTO è necessario comprendere l'impatto in base alla durata di un'interruzione. È lineare o ci sono implicazioni non lineari? (Ad esempio, dopo 4 ore, chiudi una linea di produzione fino l'inizio del turno successivo).
Una matrice di ripristino di emergenza, come quella seguente, può aiutarti a capire come la criticità del carico di lavoro sia collegata agli obiettivi di ripristino. (Da notare che i valori reali per gli assi X e Y devono essere personalizzati in base alle esigenze della tua organizzazione).
![\[Grafico che mostra la matrice del ripristino di emergenza\]](http://docs.aws.amazon.com/it_it/wellarchitected/2022-03-31/framework/images/disaster-recovery-matrix.png)
**Anti-pattern comuni:**
+ Nessun obiettivo di ripristino definito.
+ Selezione di obiettivi di ripristino arbitrari.
+ Selezione di obiettivi di ripristino troppo tolleranti e che non soddisfano gli obiettivi di business.
+ Mancanza di comprensione dell'impatto dei tempi di inattività e perdita dei dati.
+ Selezione di obiettivi di ripristino non realistici, come tempo zero di ripristino e nessuna perdita di dati, che potrebbero non essere raggiungibili per la configurazione del tuo carico di lavoro.
+ Selezione di obiettivi di ripristino più severi rispetto agli obiettivi aziendali effettivi. Questo costringe a effettuare implementazioni di ripristino di emergenza più costose e complicate rispetto alle esigenze del carico di lavoro.
+ Selezione di obiettivi di ripristino non compatibili con quelli di un carico di lavoro dipendente.
+ I tuoi obiettivi di ripristino non considerano i requisiti di conformità normativa.
+ RTO e RPO definiti per un carico di lavoro, ma mai testati.
**Vantaggi dell'adozione di questa best practice:** Gli obiettivi di ripristino in termini di tempo e perdita di dati sono necessari per guidare l'implementazione del disaster recovery.
**Livello di rischio associato se questa best practice non fosse adottata:** Alta
## Guida all'implementazione
Per un dato carico di lavoro devi considerare l'impatto dei tempi di inattività e della perdita dei dati per la tua azienda. L'impatto generalmente aumenta all'aumentare dei tempi di inattività o della perdita dei dati, ma il ritmo di tale crescita cambia in base al tipo di carico di lavoro. Ad esempio, potresti tollerare l'inattività per massimo un'ora con conseguenze minime, ma successivamente l'impatto diventerebbe rapidamente più serio. L'impatto sull'azienda si manifesta in forme diverse, tra cui costi economici (come perdita di fatturato), fiducia del cliente (e impatto sulla reputazione), problematiche operative (come stipendi in ritardo o diminuzione della produttività) e rischi normativi. Usa i passaggi seguenti per comprendere questi aspetti e impostare i valori RTO e RPO per il tuo carico di lavoro.
**Passaggi dell'implementazione**
1. Individua gli stakeholder aziendali per questo carico di lavoro e collabora con loro per implementare questi passaggi. Gli obiettivi di ripristino di un carico di lavoro sono il frutto di una decisione aziendale. I team tecnici, quindi, lavorano con gli stakeholder aziendali e usano questi obiettivi per selezionare una strategia di ripristino di emergenza.
**Nota**
Per i passaggi 2 e 3 puoi usare [Foglio di lavoro di implementazione](#implementation-worksheet).
1. Raccogli le informazioni necessarie per prendere una decisione rispondendo alle domande qui di seguito.
1. Hai categorie o livelli di criticità in termini di impatto del tuo carico di lavoro nella tua organizzazione?
1. Se sì, assegna questo carico di lavoro a una categoria
1. Se no, definisci queste categorie. Crea al massimo cinque categorie e perfeziona l'intervallo del tuo Obiettivo del tempo di ripristino (RTO) per ognuna. Ecco alcune categorie di esempio: critico, alto, medio, basso. Per capire come mappare i carichi di lavoro rispetto alle categorie devi considerare se il carico di lavoro è mission-critical, importante per l'azienda o non trainante.
1. Imposta i valori RTO e RPO del carico di lavoro in base alla categoria. Scegli sempre una categoria più severa (RTO e RPO inferiori) rispetto ai valori grezzi calcolati in questa fase. Se ciò comporta una variazione significativa di valore non rispondente alle esigenze, prendi in considerazione la possibilità di creare una nuova categoria.
1. In base alle risposte assegna i valori RTO e RPO al carico di lavoro. Puoi farlo direttamente o assegnando il carico di lavoro a un livello predefinito di servizio.
1. Crea un documento con il piano di ripristino di emergenza (DRP) per questo carico di lavoro, che sarà parte del [piano di continuità aziendale della tua organizzazione (BCP)](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/business-continuity-plan-bcp.html), in un punto accessibile al team del carico di lavoro e agli stakeholder.
1. Registra i valori RTO e RPO e le informazioni usate per definire questi valori. Includi la strategia utilizzata per valutare l'impatto del carico di lavoro sull'azienda.
1. Registra altre metriche, oltre ai valori RTO e RPO che stai monitorando o che pensi di monitorare per gli obiettivi di ripristino di emergenza.
1. Dopo aver creato questi valori, potrai aggiungere i dettagli della tua strategia di ripristino di emergenza e il runbook.
1. Osservando le criticità del carico di lavoro in una matrice come quella della Figura 15, puoi iniziare a stabilire livelli predefiniti di servizio per la tua organizzazione.
1. Dopo aver implementato una strategia di ripristino di emergenza (o un proof of concept per una strategia di ripristino di emergenza) secondo quanto stabilito da [REL13-BP02 Utilizzo di strategie di ripristino definite per conseguire gli obiettivi di ripristino](rel_planning_for_recovery_disaster_recovery.md), testa questa strategia per stabilire i valori reali di RTC (Recovery Time Capability) e di RPC (Recovery Point Capability) del carico di lavoro. Se questi valori non sono in linea con gli obiettivi target di ripristino, puoi collaborare con gli stakeholder della tua azienda per modificarli o cambiare la strategia di ripristino di emergenza in modo che possa soddisfare tali obiettivi.
**Domande principali**
1. Qual è il tempo massimo durante il quale il carico di lavoro può essere inattivo prima che questo abbia un impatto grave sull'attività?
1. Definisci il costo monetario (impatto finanziario diretto) sull'attività al minuto se il carico di lavoro è inattivo.
1. Considera che l'impatto non è sempre lineare. L'impatto può essere limitato all'inizio e poi aumentare rapidamente oltre un punto critico specifico.
1. Qual è la quantità massima di dati che possiamo perdere prima che questo abbia un impatto grave sull'attività?
1. Considera questo valore per gli archivi di dati più strategici. identifica le criticità relative ad altri archivi di dati.
1. I dati del carico di lavoro possono essere ricreati se persi? Se questo è operativamente più facile rispetto al backup e al ripristino, scegli il valore RPO in base alla criticità dei dati di origine utilizzati per ricreare i dati del carico di lavoro.
1. Quali sono gli obiettivi di ripristino e le aspettative di disponibilità dei carichi di lavoro da cui questo valore dipende (downstream) o i carichi di lavoro che dipendono da questo valore (upstream)?
1. Scegli obiettivi di ripristino che consentono a questo carico di lavoro di soddisfare i requisiti delle dipendenze upstream.
1. Scegli obiettivi di ripristino che sono raggiungibili considerate le funzionalità di ripristino delle dipendenze downstream. Possono essere escluse le dipendenze downstream non critiche (quelle che puoi "aggirare"). In alternativa, lavora con dipendenze downstream critiche per migliorare le funzionalità di ripristino, laddove necessario.
**Domande aggiuntive**
Considera queste domande e come possono essere applicate a questo carico di lavoro:
1. Hai RTO e RPO diversi a seconda del tipo di interruzione (Regione rispetto ad AZ e così via)?
1. Esiste un periodo specifico (stagionalità, eventi commerciali, lanci di prodotto) in cui RTO/RPO possono cambiare? Se sì, qual è la misurazione diversa e il vincolo temporale?
1. Se il carico di lavoro viene perturbato, quanti clienti ne subiranno l'impatto?
1. Qual è l'impatto sulla reputazione se il carico di lavoro è perturbato?
1. Quali altri impatti operativi possono verificarsi se il carico di lavoro subisce perturbazioni? Ad esempio, l'impatto sulla produttività dei dipendenti se i sistemi e-mail non sono disponibili o sei i sistemi di buste paga non sono in grado di inviare le transazioni.
1. In che modo il carico di lavoro e i valori RTO e RPO si allineano alla linea di business e alla strategia di ripristino di emergenza dell'organizzazione?
1. Esistono obblighi contrattuali interni per fornire un servizio? Esistono delle penali nel caso in cui non siano soddisfatti?
1. Quali sono i limiti normativi o di conformità dei dati?
## Foglio di lavoro di implementazione
Puoi usare questo foglio di lavoro per le fasi 2 e 3 dell'implementazione. Adegua questo foglio di lavoro in base alle tue esigenze specifiche, aggiungendo, ad esempio, altre domande.
![\[Foglio di lavoro\]](http://docs.aws.amazon.com/it_it/wellarchitected/2022-03-31/framework/images/worksheet.png)
**Livello di impegno per il piano di implementazione: **Bassa
## Risorse
**Best practice correlate:**
+ [REL09-BP04 Ripristino periodico dei dati per verificare l'integrità e i processi di backup:](rel_backing_up_data_periodic_recovery_testing_data.md)
+ [REL13-BP02 Utilizzo di strategie di ripristino definite per conseguire gli obiettivi di ripristino](rel_planning_for_recovery_disaster_recovery.md)
+ [REL13-BP03 Esecuzione di test sull'implementazione del ripristino di emergenza per convalidare l'implementazione](rel_planning_for_recovery_dr_tested.md)
**Documenti correlati:**
+ [AWS Architecture Blog: Disaster Recovery Series](https://aws.amazon.com/blogs/architecture/tag/disaster-recovery-series/)
+ [Ripristino di emergenza dei carichi di lavoro su AWS: ripristino nel cloud (whitepaper di AWS)](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/disaster-recovery-workloads-on-aws.html)
+ [Gestire le policy di resilienza con AWS Resilience Hub](https://docs.aws.amazon.com/resilience-hub/latest/userguide/resiliency-policies.html)
+ [Partner APN: partner che possono assistere con disaster recovery](https://aws.amazon.com/partners/find/results/?keyword=Disaster+Recovery)
+ [Marketplace AWS: prodotti utilizzabili per il disaster recovery](https://aws.amazon.com/marketplace/search/results?searchTerms=Disaster+recovery)
**Video correlati:**
+ [AWS re:Invent 2018: Architecture Patterns for Multi-Region Active-Active Applications (Modelli architetturali per applicazioni attive-attive su più Regioni) (ARC209-R2)](https://youtu.be/2e29I3dA8o4)
+ [Ripristino di emergenza di carichi di lavoro su AWS](https://www.youtube.com/watch?v=cJZw5mrxryA)
# REL13-BP02 Utilizzo di strategie di ripristino definite per conseguire gli obiettivi di ripristino
Definisci una strategia di ripristino di emergenza (DR) che soddisfi gli obiettivi di ripristino del carico di lavoro. Scegli una strategia come: backup e ripristino, standby (attivo/passivo) o attivo/attivo.
Una strategia di ripristino di emergenza si basa sulla capacità di creare il tuo carico di lavoro in un sito di ripristino se la tua sede principale non è disponibile per eseguire il carico di lavoro. Gli obiettivi di ripristino più comuni sono RTO e RPO, come discusso in [REL13-BP01 Definizione degli obiettivi di ripristino in caso di downtime e perdita di dati](rel_planning_for_recovery_objective_defined_recovery.md).
Una strategia di ripristino di emergenza (DR) su più zone di disponibilità (AZ) all'interno di un singolo Regione AWS può offrire la mitigazione rispetto a eventi disastrosi come incendi, alluvioni e interruzioni gravi dell'energia. Se è un requisito implementare una protezione rispetto a un evento improbabile che impedisca al tuo carico di lavoro di poter essere eseguito in un determinato Regione AWS, puoi usare una strategia di ripristino di emergenza basata su più regioni.
Quando pianifichi una strategia di ripristino di emergenza su più regioni, devi scegliere una delle seguenti strategie. Sono elencate in ordine crescente di complessità e di costi e in ordine decrescente di RTO e RPO. *La regione di ripristino* si riferisce a una Regione AWS diversa da quella principale utilizzata per il tuo carico di lavoro.
![\[Diagramma che mostra le strategie di ripristino di emergenza\]](http://docs.aws.amazon.com/it_it/wellarchitected/2022-03-31/framework/images/disaster-recovery-strategies.png)
+ **Backup e ripristino** (RPO in poche ore, RTO in 24 ore o meno): esegui il backup dei dati e delle applicazioni nella regione di ripristino. Adottando backup continui o automatizzati otterrai un ripristino point-in-ime che può ridurre il valore dell'RPO fino a raggiungere in alcuni casi 5 minuti. Nel caso in cui si verifichi un disastro, distribuirai l'infrastruttura (usando l'infrastruttura come codice per ridurre l'RTO), distribuirai il codice e ripristinerai i dati del backup dopo un disastro nella regione di ripristino.
+ **Pilot light** (RPO in minuti, RTO in decine di minuti): fornisci una copia dell'infrastruttura del carico di lavoro di base nella regione di ripristino. Replica i dati nella regione di ripristino e crea un backup in essa. Le risorse necessarie per supportare la replica dei dati e il backup, come database e archiviazione di oggetti, sono sempre attive. Altri elementi come i server applicativi o il calcolo serverless non vengono distribuiti, ma possono essere creati quando necessari con la configurazione e il codice applicativo richiesti.
+ **Warm standby** (RPO in secondi, RTO in minuti): mantieni sempre una versione ridotta del carico di lavoro completamente funzionante in esecuzione nella regione di ripristino. I sistemi business critical sono completamente duplicati e sono sempre accesi, ma con un parco istanze ridimensionato. I dati vengono replicati e si trovano nella regione di ripristino. Quando viene il momento del ripristino, il sistema viene dimensionato rapidamente per gestire il carico di produzione. Più il Warm standby è dimensionato verso l'alto e più bassi saranno l'RTO e l'affidamento al piano di controllo. Quando il dimensionamento è completo ci troviamo nello **Standby a caldo**.
+ **Multi-regione (multi-sito) attivo-attivo** (RPO vicino a zero, RTO uguale potenzialmente a zero): il carico di lavoro viene distribuito in più regioni Regioni AWS e serve attivamente il traffico da esse proveniente. Questa strategia comporta la sincronizzazione dei dati tra le regioni. È necessario evitare o gestire possibili conflitti causati da scritture sullo stesso record in due diverse repliche regionali, un'attività che potrebbe rivelarsi complessa. La replica dei dati è utile per la sincronizzazione dei dati e ti proteggerà da alcuni tipi di disastri, ma non dalla corruzione o dalla distruzione dei dati, a meno che la tua soluzione non includa opzioni per il ripristino point-in-time.
**Nota**
La differenza tra Pilot Light e Warm Standby può talvolta essere difficile da comprendere. Entrambe prevedono un ambiente nella tua regione di ripristino con copie degli asset della tua regione principale. La differenza è che Pilot Light non può elaborare le richieste senza aver prima intrapreso altre azioni, mentre Warm Standby può gestire immediatamente il traffico (a livelli ridotti di capacità). Pilot Light ti richiederà di attivare i server, distribuire possibilmente un'infrastruttura aggiuntiva (non di base) e aumentare il dimensionamento, mentre Warm Standby richiede solo di aumentare il dimensionamento (tutto è già stato distribuito ed è in esecuzione). Scegli tra queste opzioni in base alle tue esigenze di RTO e RPO.
**Risultato desiderato:**
Per ogni carico di lavoro esiste una strategia di ripristino di emergenza definita e implementata che consente a quel carico di lavoro di raggiungere gli obiettivi di ripristino. Le strategie di ripristino di emergenza tra carichi di lavoro utilizzano modelli riutilizzabili (come strategie descritte in precedenza),
**Anti-pattern comuni:**
+ Implementazione di procedure di ripristino incoerenti per carichi di lavoro con obiettivi di ripristino simili.
+ Implementazione di una strategia di ripristino di emergenza ad-hoc quando si verifica un disastro.
+ Assenza di un piano per il ripristino di emergenza.
+ Dipendenza dalle operazioni del piano di controllo durante il ripristino.
**Vantaggi dell'adozione di questa best practice:**
+ L'utilizzo di strategie di ripristino definite consente di utilizzare strumenti e procedure di test comuni.
+ L'utilizzo di strategie di ripristino definite consente una condivisione più efficiente delle conoscenze tra i team e un'implementazione più facile del ripristino di emergenza sui carichi di lavoro proprietari.
**Livello di rischio associato se questa best practice non fosse adottata:** Alto
+ Senza una strategia di ripristino di emergenza pianificata, implementata e testata, è poco probabile riuscire a raggiungere gli obiettivi di ripristino in caso di eventi disastrosi.
## Guida all'implementazione
Per ognuno di questi passaggi guarda i dettagli qui di seguito.
1. Definisci una strategia di ripristino di emergenza in linea con i requisiti di ripristino di questo carico di lavoro.
1. Esamina i modelli con cui la strategia di ripristino di emergenza selezionata può essere implementata.
1. Valuta le risorse del tuo carico di lavoro e quale sarà la loro configurazione nella regione di ripristino prima del failover (durante la normale operatività).
1. Stabilisci e implementa le modalità con cui preparerai la tua regione al failover nel momento in cui sarà necessario (durante un evento disastroso).
1. Stabilisci e implementa le modalità con cui reindirizzerai il traffico al failover nel momento in cui sarà necessario (durante un evento disastroso).
1. Progetta un piano per il failback del carico di lavoro.
**Passaggi dell'implementazione**
1. **Definisci una strategia di ripristino di emergenza in linea con i requisiti di ripristino di questo carico di lavoro.**
Scegliere una strategia di ripristino di emergenza significa raggiungere un compromesso tra la riduzione dei tempi di inattività e della perdita di dati (RTO e RPO) e costi e complessità di implementazione. Dovresti evitare di implementare una strategia che sia più severa del necessario, in quanto questo comporterebbe costi aggiuntivi.
Ad esempio, nel diagramma seguente, l'azienda ha stabilito l'RTO massimo concesso e il limite di spesa per la strategia di ripristino del servizio. Considerati gli obiettivi dell'azienda, le strategie di ripristino di emergenza Pilot Light o Warm Standby soddisfano i criteri sui costi e l'RTO.
![\[Grafico che mostra la scelta di una strategia di ripristino di emergenza in base all'RTO e ai costi\]](http://docs.aws.amazon.com/it_it/wellarchitected/2022-03-31/framework/images/choosing-a-dr-strategy.png)
Per saperne di più consulta il [piano di continuità aziendale (BCP)](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/business-continuity-plan-bcp.html).
1. **Esamina i modelli con cui la strategia di ripristino di emergenza selezionata può essere implementata.**
Questo passaggio consiste nel capire come implementare la strategia selezionata. Le strategie vengono spiegate con Regioni AWS come siti principali e di ripristino. Tuttavia, puoi anche decidere di utilizzare le zone di disponibilità in una singola regione come strategia di ripristino di emergenza, utilizzando aspetti di più strategie.
Nei passaggi successivi a questo, applicherai la strategia per il tuo carico di lavoro specifico.
**Backup e ripristino**
*Backup e ripristino* è la strategia meno complessa da implementare, ma richiederà più tempo e impegno per ripristinare il carico di lavoro, generando così valori RTO e RPO più elevati. È buona pratica creare sempre backup dei dati e copiarli in un altro sito (ad esempio, un altro Regione AWS).
![\[Diagramma che mostra un'architettura di backup e ripristino\]](http://docs.aws.amazon.com/it_it/wellarchitected/2022-03-31/framework/images/backup-restore-architecture.png)
Per maggiori dettagli su questa strategia consulta [Disaster Recovery (DR) Architecture on AWS, Part II: Backup and Restore with Rapid Recovery (Architettura di ripristino di emergenza (DR) su AWS, Parte II: backup e ripristino con recupero rapido)](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-ii-backup-and-restore-with-rapid-recovery/).
**Pilot light**
Con l'approccio *Pilot light* , replichi i dati dalla tua regione principale alla regione di ripristino. Le risorse di base utilizzate per l'infrastruttura del carico di lavoro vengono distribuite nella regione di ripristino; tuttavia sono comunque necessarie risorse aggiuntive ed eventuali dipendenze per rendere funzionale questo stack. Ad esempio, nella Figura 20, non vengono distribuite istanze di calcolo.
![\[Diagramma che mostra un'architettura pilot light\]](http://docs.aws.amazon.com/it_it/wellarchitected/2022-03-31/framework/images/pilot-light-architecture.png)
Per maggiori dettagli su questa strategia consulta [Disaster Recovery (DR) Architecture on AWS, Part III: Pilot Light and Warm Standby (Architettura di ripristino di emergenza (DR) su AWS, Parte III: Pilot Light e Warm Standby)](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-iii-pilot-light-and-warm-standby/).
**Warm standby**
L'approccio *warm standby* implica la verifica della presenza di una copia ridotta, ma comunque funzionale, dell'ambiente di produzione in un'altra regione. Questo approccio estende il concetto di Pilot Light e diminuisce il tempo di ripristino, poiché il carico di lavoro è sempre attivo in un'altra regione. Se la regione di ripristino ha raggiunto il massimo della capacità, allora viene definita come *Standby a caldo*.
![\[Figura 21: Diagramma che mostra un'architettura Warm standby\]](http://docs.aws.amazon.com/it_it/wellarchitected/2022-03-31/framework/images/warm-standby-architecture.png)
Se si utilizza Warm Standby o Pilot Light è necessario un aumento delle risorse nella regione di ripristino. Per garantire che la capacità sia disponibile quando necessario, valuta l'uso di [prenotazioni delle capacità](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-capacity-reservations.html) per le istanze EC2. Se utilizzi AWS Lambda, la [concorrenza fornita](https://docs.aws.amazon.com/lambda/latest/dg/provisioned-concurrency.html) può garantire gli ambienti di esecuzione, in modo che siano pronti a rispondere immediatamente ai richiami della funzione.
Per maggiori dettagli su questa strategia consulta [Disaster Recovery (DR) Architecture on AWS, Part III: Pilot Light and Warm Standby (Architettura di ripristino di emergenza (DR) su AWS, Parte III: Pilot Light e Warm Standby)](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-iii-pilot-light-and-warm-standby/).
**Attivo/attivo multi-sito**
Puoi eseguire il carico di lavoro simultaneamente in più regioni come parte di una *strategia attivo/attivo multi-sito* . La strategia attivo/attivo multi-sito serve il traffico da tutte le regioni in cui è distribuita. I clienti possono selezionare questa strategia per motivi diversi dal ripristino di emergenza. Può essere utilizzata per aumentare la disponibilità o nella distribuzione di un carico di lavoro a un pubblico globale (per posizionare l'endpoint più vicino agli utenti e/o per distribuire stack localizzati al pubblico di quella regione). Come strategia di ripristino di emergenza, se il carico di lavoro non può essere supportato in una delle Regioni AWS in cui è stato distribuito, allora quella regione viene evacuata e le regioni rimanenti vengono utilizzate per garantire la disponibilità. Attivo/attivo multi-sito è la strategia di ripristino operativamente più complessa e dovrebbe essere selezionata solo quando lo richiedono i requisiti aziendali.
![\[Diagramma che mostra un'architettura attivo/attivo multi-sito\]](http://docs.aws.amazon.com/it_it/wellarchitected/2022-03-31/framework/images/multi-site-active-active-architecture.png)
Per maggiori dettagli su questa strategia consulta [Disaster Recovery (DR) Architecture on AWS, Part IV: Multi-site Active/Active (Architettura di ripristino di emergenza su AWS, parte IV: attiva/attiva multi-sito)](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-iv-multi-site-active-active/).
**Procedure aggiuntive per la protezione dei dati**
Con tutte le strategie devi anche mitigare un disastro relativo ai dati. La replica continua dei dati ti proteggerà da alcuni tipi di disastri, ma non dalla corruzione o dalla distruzione dei dati, a meno che la tua soluzione non includa opzioni per il ripristino point-in-time o il controllo delle versioni dei dati archiviati. Devi anche creare un backup dei dati replicati nel sito di ripristino per creare backup point-in-time in aggiunta alle repliche.
**Utilizzo di più zone di disponibilità all'interno di una singola Regione AWS**
Quando si usano più zone di disponibilità all'interno di un'unica regione, l'implementazione della strategia di ripristino di emergenza usa più elementi delle strategie precedenti. Per prima cosa devi creare un'architettura con disponibilità elevata (HA), usando più zone di disponibilità come mostrato nella Figura 23. Questa architettura utilizza un approccio attivo/attivo multi-sito, poiché le [istanze Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-regions-availability-zones.html#concepts-availability-zones) ed [Elastic Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/how-elastic-load-balancing-works.html#availability-zones) hanno risorse distribuite in più zone di disponibilità che gestiscono attivamente le richieste. L'architettura dimostra anche lo standby a caldo e se l'istanza [Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Concepts.MultiAZ.html) primaria fallisce (o la zona di disponibilità stessa fallisce), l'istanza in standby viene promossa a principale.
![\[Figura 23: Diagramma che mostra un'architettura con più zone di disponibilità\]](http://docs.aws.amazon.com/it_it/wellarchitected/2022-03-31/framework/images/multi-az-architecture2.png)
Oltre a questa architettura HA, devi aggiungere i backup di tutti i dati richiesti per eseguire il tuo carico di lavoro. Questo aspetto è importante soprattutto per i dati limitati a una singola zona come [i volumi Amazon EBS](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-volumes.html) oppure [i cluster Amazon Redshift](https://docs.aws.amazon.com/redshift/latest/mgmt/working-with-clusters.html). Se fallisce una zona di disponibilità, dovrai ripristinare i dati in un'altra zona di disponibilità. Laddove possibile, devi anche copiare i backup di dati su un'altra Regione AWS come livello di protezione aggiuntivo.
Un approccio alternativo meno comune a una strategia di ripristino di emergenza con una singola regione e più zone di disponibilità è illustrata nel post del blog, [Building highly resilient applications using Amazon Route 53 Application Recovery Controller, Part 1: Single-Region stack (Creazione di applicazioni altamente resilienti con Amazon Route 53 Application Recovery Controller, parte 1: stack a singola regione)](https://aws.amazon.com/blogs/networking-and-content-delivery/building-highly-resilient-applications-using-amazon-route-53-application-recovery-controller-part-1-single-region-stack/). In questo caso la strategia adottata è quella di garantire il più possibile l'isolamento tra le zone di disponibilità, ossia come le regioni operano. Usando questa strategia alternativa puoi scegliere un approccio attivo/attivo o attivo/passivo.
Nota: alcuni carichi di lavoro hanno requisiti normativi di residenza dei dati. Se questo si applica a un carico di lavoro in una località che attualmente ha solo una Regione AWS, la multi-regione non soddisferà i requisiti aziendali. Le strategie con più zone di disponibilità offrono una buona protezione dalla maggior parte dei disastri.
1. **Valuta le risorse del tuo carico di lavoro e quale sarà la loro configurazione nella regione di ripristino prima del failover (durante la normale operatività).**
Per infrastrutture e risorse AWS usa l'infrastruttura come codice come [AWS CloudFormation](https://aws.amazon.com/cloudformation) o strumenti di terze parti come Hashicorp Terraform. Per distribuire in più account e regioni con una singola operazione puoi usare [AWS CloudFormation StackSets](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/what-is-cfnstacksets.html). Per le strategie multi-sito attivo/attivo e standby a caldo, l'infrastruttura distribuita nella tua regione di ripristino ha le stesse risorse della regione principale. Per le strategie Pilot Light e Warm Standby l'infrastruttura distribuita richiederà azioni aggiuntive per essere pronta per la produzione. Con l'utilizzo dei parametri di [CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/parameters-section-structure.html) e [della logica condizionale](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/intrinsic-function-reference-conditions.html), puoi verificare se uno stack distribuito è attivo o in standby con un singolo modello. Un esempio di tale modello CloudFormation è incluso in [questo post del blog](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-iii-pilot-light-and-warm-standby/).
Tutte le strategie di ripristino di emergenza richiedono un backup delle origini dei dati all'interno della Regione AWS e una copia di tali backup nella regione di ripristino. [AWS Backup](https://aws.amazon.com/backup/) offre una visualizzazione centralizzata dove puoi configurare, pianificare e monitorare i backup di queste risorse. Per Pilot Light, Warm Standby e Multi-sito attivo/attivo, you should also replicate data from the primary devi anche replicare i dati dalla regione principale alle risorse di dati nella regione di ripristino, come [istanze DB Amazon Relational Database Service (Amazon RDS)](https://aws.amazon.com/rds) o tabelle [Amazon DynamoDB](https://aws.amazon.com/dynamodb) . Queste risorse di dati sono pertanto attive e pronte per servire le richieste nella regione di ripristino.
Per saperne di più su come i servizi AWS operano nelle regioni, guarda questa serie di blog su [Creazione di un'applicazione multiregione con i servizi AWS](https://aws.amazon.com/blogs/architecture/tag/creating-a-multi-region-application-with-aws-services-series/).
1. **Stabilisci e implementa le modalità con cui preparerai la tua regione al failover nel momento in cui sarà necessario (durante un evento disastroso).**
Per la strategia attivo/attivo multi-sito, il failover significa evacuare una regione e affidarsi alle regioni attive rimanenti. In generale, tali regioni sono pronte per accettare il traffico. Per le strategie Pilot Light e Warm Standby, le azioni di ripristino devono distribuire le risorse mancanti, come le istanze EC2 nella Figura 20, oltre ad risorse mancanti aggiuntive.
Per tutte le strategie precedenti potresti dover promuovere istanze di database i sola lettura a istanze di lettura/scrittura principali.
Per il backup e il ripristino, il ripristino dei dati dai backup crea risorse per tali dati, come volumi EBS, istanze DB RDS e tabelle DynamoDB. Devi anche ripristinare l'infrastruttura e distribuire il codice. Puoi usare AWS Backup per ripristinare i dati nella regione di ripristino. Consulta [REL09-BP01 Identificazione e backup di tutti i dati che richiedono un backup o riproduzione dei dati dalle origini](rel_backing_up_data_identified_backups_data.md) per ulteriori dettagli. Ricreare l'infrastruttura significa anche creare risorse come istanze EC2 oltre a [Amazon Virtual Private Cloud (Amazon VPC)](https://aws.amazon.com/vpc), sottoreti e i gruppi di sicurezza necessari. Puoi automatizzare gran parte del processo di ripristino. Per scoprire come guarda [questo post del blog](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-ii-backup-and-restore-with-rapid-recovery/).
1. **Stabilisci e implementa le modalità con cui reindirizzerai il traffico al failover nel momento in cui sarà necessario (durante un evento disastroso).**
Questa operazione di failover può essere avviata automaticamente o manualmente. Il failover avviato automaticamente in base a controlli dell'integrità o allarmi deve essere usato con attenzione, poiché un failover non necessario (falso allarme) comporta dei costi in termini di non disponibilità e perdita dei dati. Pertanto si usa spesso il failover avviato manualmente. In questo caso, devi comunque automatizzare i passaggi del failover, in modo che l'avvio manuale si limiti al clic su un pulsante.
Esistono diverse opzioni di gestione del traffico da considerare quando si usano i servizi AWS. Un'opzione consiste nell'utilizzare [Amazon Route 53](https://aws.amazon.com/route53). Con Amazon Route 53 puoi associare più endpoint IP in una o più Regioni AWS con un nome di dominio Route 53. Per implementare un failover avviato manualmente puoi usare [Amazon Route 53 Application Recovery Controller](https://aws.amazon.com/route53/application-recovery-controller/), che offre un'API del piano dati altamente disponibile per reindirizzare il traffico alla regione di ripristino. Nella fase di implementazione del failover, usa le operazioni di piano dati ed evita quelle del piano di controllo come descritto in [REL11-BP04 Fare affidamento al piano dati invece che al piano di controllo durante il ripristino](rel_withstand_component_failures_avoid_control_plane.md).
Per saperne di più su questa e su altre opzioni consulta [questa sezione del whitepaper sul Ripristino di emergenza](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/disaster-recovery-options-in-the-cloud.html#pilot-light).
1. **Progetta un piano per il failback del carico di lavoro.**
Si parla di failback quando un'operazione del carico di lavoro torna alla regione principale, dopo che un vento disastroso è diminuito di intensità. Il provisioning di infrastruttura e codice alla regione principale in genere segue gli stessi passaggi usati inizialmente, affidandosi all'infrastruttura come codice e alle pipeline di distribuzione del codice. La sfida del failback è il ripristino dei data store e la garanzia della loro coerenza con la regione di ripristino attiva.
Nello stato di failover i database nella regione di ripristino sono attivi e hanno dati aggiornati. L'obiettivo è eseguire una nuova sincronizzazione tra la regione di ripristino e la regione principale, per garantire il suo aggiornamento.
Alcuni servizi AWS eseguono questa operazione in automatico. Se si utilizzano [tabelle globali Amazon DynamoDB](https://aws.amazon.com/dynamodb/global-tables/), anche se la tabella nella regione principale era diventata non disponibile, quando torna di nuovo online, DynamoDB ripristina la propagazione di scritture in sospeso. Se si utilizzano [Database globale Amazon Aurora](https://aws.amazon.com/rds/aurora/global-database/) e [failover pianificato gestito](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-global-database-disaster-recovery.html#aurora-global-database-disaster-recovery.managed-failover), viene mantenuta la topologia di replica esistente del database globale Aurora. Pertanto, l'istanza precedente in lettura/scrittura nella regione principale diventa una replica e riceve gli aggiornamenti dalla regione di ripristino.
Nei casi in cui questo non è automatico devi ristabilire il database nella regione principale come replica del database nella regione di ripristino. In molti casi questo comporterà l'eliminazione del database principale precedente e la creazione di nuove repliche. Ad esempio, per istruzioni su come procedere con il Database globale Amazon Aurora in caso di failover *non pianificato* , consulta questa scheda: [Failback di un database globale](https://awsauroralabsmy.com/global/failback/).
Dopo un failover, se puoi proseguire l'esecuzione nella tua regione di ripristino, valuta la possibilità di farlo nella tua regione principale. Compieresti comunque tutte le operazioni precedenti per trasformare la precedente regione principale in una regione di ripristino. Alcune organizzazioni eseguono una rotazione pianificata, scambiando periodicamente le regioni principale e di ripristino (ad esempio, ogni tre mesi).
Tutti i passaggi richiesti per failover e failback devono essere inseriti in un playbook disponibile a tutti i membri del team, sottoposto periodicamente a revisione.
**Livello di impegno per il piano di implementazione**: elevato
## Risorse
**Best practice correlate:**
+ [REL09-BP01 Identificazione e backup di tutti i dati che richiedono un backup o riproduzione dei dati dalle origini](rel_backing_up_data_identified_backups_data.md)
+ [REL11-BP04 Fare affidamento al piano dati invece che al piano di controllo durante il ripristino](rel_withstand_component_failures_avoid_control_plane.md)
+ [REL13-BP01 Definizione degli obiettivi di ripristino in caso di downtime e perdita di dati](rel_planning_for_recovery_objective_defined_recovery.md)
**Documenti correlati:**
+ [AWS Architecture Blog: Disaster Recovery Series](https://aws.amazon.com/blogs/architecture/tag/disaster-recovery-series/)
+ [Ripristino di emergenza dei carichi di lavoro su AWS: ripristino nel cloud (whitepaper di AWS)](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/disaster-recovery-workloads-on-aws.html)
+ [Opzioni di ripristino di emergenza nel cloud](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/disaster-recovery-options-in-the-cloud.html)
+ [Build a serverless multi-region, active-active backend solution in an hour](https://read.acloud.guru/building-a-serverless-multi-region-active-active-backend-36f28bed4ecf)
+ [Multi-region serverless backend — reloaded](https://medium.com/@adhorn/multi-region-serverless-backend-reloaded-1b887bc615c0)
+ [RDS: creazione di una replica di lettura in una regione AWS diversa](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ReadRepl.html#USER_ReadRepl.XRgn)
+ [Route 53: configurazione del failover DNS](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/dns-failover-configuring.html)
+ [S3: replica tra regioni](https://docs.aws.amazon.com/AmazonS3/latest/dev/crr.html)
+ [Che cos'è AWS Backup?](https://docs.aws.amazon.com/aws-backup/latest/devguide/whatisbackup.html)
+ [What is Route 53 Application Recovery Controller? (Che cos'è Amazon Route 53 Application Recovery Controller?)](https://docs.aws.amazon.com/r53recovery/latest/dg/what-is-route53-recovery.html)
+ [AWS Elastic Disaster Recovery (Ripristino di emergenza elastico AWS)](https://docs.aws.amazon.com/drs/latest/userguide/what-is-drs.html)
+ [HashiCorp Terraform: inizia subito - AWS](https://learn.hashicorp.com/collections/terraform/aws-get-started)
+ [Partner APN: partner che possono assistere con disaster recovery](https://aws.amazon.com/partners/find/results/?keyword=Disaster+Recovery)
+ [Marketplace AWS: prodotti utilizzabili per il disaster recovery](https://aws.amazon.com/marketplace/search/results?searchTerms=Disaster+recovery)
**Video correlati:**
+ [Ripristino di emergenza di carichi di lavoro su AWS](https://www.youtube.com/watch?v=cJZw5mrxryA)
+ [AWS re:Invent 2018: Architecture Patterns for Multi-Region Active-Active Applications (Modelli di architettura per applicazioni attive-attive multiregione) (ARC209-R2)](https://youtu.be/2e29I3dA8o4)
+ [Get Started with AWS Elastic Disaster Recovery \$1 Amazon Web Services (Nozioni di base sul ripristino di emergenza elastico AWS \$1 Amazon Web Services)](https://www.youtube.com/watch?v=GAMUCIJR5as)
**Esempi correlati:**
+ [AWS Well-Architected Labs - Ripristino di emergenza](https://wellarchitectedlabs.com/reliability/disaster-recovery/) - Serie di workshop che illustrano le strategie di ripristino di emergenza
# REL13-BP03 Esecuzione di test sull'implementazione del ripristino di emergenza per convalidare l'implementazione
Testa con regolarità il failover nella tua sede di ripristino per verificare la correttezza delle operazioni e l'allineamento ai valori RPO e RTO.
Un modello da evitare è lo sviluppo di percorsi di ripristino eseguiti raramente. Ad esempio, è possibile che si disponga di un archivio dati secondario utilizzato per query di sola lettura. Quando scrivi in un archivio dati e quello principale ha un guasto, puoi eseguire il failover verso l'archivio dati secondario. Se non testi frequentemente questo failover, è possibile che i presupposti relativi alle funzionalità dell'archivio dati secondario non siano corretti. La capacità dell'archivio dati secondario, che potrebbe essere stata sufficiente durante l'ultimo test, potrebbe non essere più in grado di tollerare il carico in questo scenario. La nostra esperienza ha dimostrato che l'unico ripristino da errore che funziona è il percorso sottoposto a frequenti test. Per questo è preferibile avere un numero ridotto di percorsi di ripristino. Puoi stabilire dei modelli di ripristino e testarli regolarmente. Se disponi di un percorso di ripristino complesso o critico, devi comunque riprodurre regolarmente il guasto specifico in produzione per convincerti che il percorso di ripristino funzioni. Nell'esempio appena discusso, è necessario eseguire il failover regolarmente in standby, indipendentemente dalle necessità.
**Anti-pattern comuni:**
+ Non eseguire mai failover di prova in produzione.
**Vantaggi dell'adozione di questa best practice:** Testare regolarmente il piano di disaster recovery assicura che funzioni quando necessario e che il tuo team sappia come eseguire la strategia.
**Livello di rischio associato se questa best practice non fosse adottata:** Alto
## Guida all'implementazione
+ Progetta i carichi di lavoro per il ripristino. Testa con regolarità se l'informatica orientata al ripristino (ROC, Recovery Oriented Computing) identifica le caratteristiche nei sistemi che migliorano il ripristino. Queste caratteristiche sono: isolamento e ridondanza, capacità a livello di sistema di ripristinare le modifiche, capacità di monitorare e determinare lo stato, capacità di fornire diagnostica, ripristino automatizzato, progettazione modulare e possibilità di riavvio. Esegui il percorso di ripristino per assicurarti di poter realizzare il ripristino nel tempo specificato allo stato specificato. Usa i tuoi runbook durante questo ripristino per documentare i problemi e trovare le loro soluzioni prima del test successivo.
+ [Il progetto di informatica orientata al ripristino Berkeley/Stanford](http://roc.cs.berkeley.edu/)
+ Usa il ripristino di emergenza CloudEndure per implementare e testare la tua strategia di ripristino di emergenza.
+ [Testing the Disaster Recovery Solution with CloudEndure](https://docs.cloudendure.com/Content/Configuring_and_Running_Disaster_Recovery/Testing_the_Distaster_Recovery_Solution/Testing_the_Disaster_Recovery_Solution.htm)
+ [CloudEndure Disaster Recovery](https://aws.amazon.com/cloudendure-disaster-recovery/)
+ [Ripristino di emergenza CloudEndure in AWS](https://aws.amazon.com/marketplace/pp/B07XQNF22L)
## Risorse
**Documenti correlati:**
+ [Partner APN: partner che possono assistere con disaster recovery](https://aws.amazon.com/partners/find/results/?keyword=Disaster+Recovery)
+ [AWS Architecture Blog: Disaster Recovery Series](https://aws.amazon.com/blogs/architecture/tag/disaster-recovery-series/)
+ [Marketplace AWS: prodotti utilizzabili per il disaster recovery](https://aws.amazon.com/marketplace/search/results?searchTerms=Disaster+recovery)
+ [CloudEndure Disaster Recovery](https://aws.amazon.com/cloudendure-disaster-recovery/)
+ [Ripristino di emergenza dei carichi di lavoro su AWS: ripristino nel cloud (whitepaper di AWS)](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/disaster-recovery-workloads-on-aws.html)
+ [Testing the Disaster Recovery Solution with CloudEndure](https://docs.cloudendure.com/Content/Configuring_and_Running_Disaster_Recovery/Testing_the_Distaster_Recovery_Solution/Testing_the_Disaster_Recovery_Solution.htm)
+ [Il progetto di informatica orientata al ripristino Berkeley/Stanford](http://roc.cs.berkeley.edu/)
+ [Che cos'è AWS Fault Injection Simulator?](https://docs.aws.amazon.com/fis/latest/userguide/what-is.html)
**Video correlati:**
+ [AWS re:Invent 2018: Architecture Patterns for Multi-Region Active-Active Applications (Modelli di architettura per applicazioni attive-attive multiregione) (ARC209-R2)](https://youtu.be/2e29I3dA8o4)
+ [AWS re:Invent 2019: Backup-and-restore and disaster-recovery solutions with AWS (STG208)](https://youtu.be/7gNXfo5HZN8)
**Esempi correlati:**
+ [AWS Well-Architected Labs - Test di resilienza](https://wellarchitectedlabs.com/reliability/300_labs/300_testing_for_resiliency_of_ec2_rds_and_s3/)
# REL13-BP04 Gestione della deviazione di configurazione nel sito o nella Regione del ripristino di emergenza
Assicurati che l'infrastruttura, i dati e la configurazione soddisfino le esigenze del sito o nella Regione del ripristino di emergenza. Ad esempio, controlla che le AMI e le quote di servizio siano aggiornate.
AWS Config monitora e registra in modo continuo le configurazioni delle risorse AWS. È in grado di rilevare le deviazioni e attivare [AWS Systems Manager Automation](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html) per risolverle e attivare allarmi. AWS CloudFormation è inoltre in grado di rilevare le deviazioni negli stack distribuiti.
**Anti-pattern comuni:**
+ Non eseguire aggiornamenti nelle sedi di ripristino, quando esegui modifiche di configurazione o di infrastruttura nelle tue sedi principali.
+ Ignorare le limitazioni potenziali (ad esempio le differenze di servizio) nelle sedi di disaster recovery e principali.
**Vantaggi dell'adozione di questa best practice:** Assicurarsi che l'ambiente di disaster recovery sia coerente con quello esistente garantisce il ripristino completo.
**Livello di rischio associato se questa best practice non fosse adottata:** Medio
## Guida all'implementazione
+ Assicurati che le tue pipeline di distribuzione riforniscano sia i siti principali che di backup. Le pipeline per la distribuzione di applicazioni in produzione devono essere distribuite in tutte le posizioni della strategia di disaster recovery specificate, inclusi gli ambienti di sviluppo e test.
+ Abilitazione di AWS Config per monitorare le potenziali posizioni di deviazione. Utilizza le regole AWS Config per creare sistemi in grado di applicare le strategie di disaster recovery e generare avvisi quando rilevano una deviazione.
+ [Correzione di risorse AWS non conformi in base alle regole di Regole di AWS Config](https://docs.aws.amazon.com/config/latest/developerguide/remediation.html)
+ [AWS Systems Manager Automation](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html)
+ Utilizza AWS CloudFormation per distribuire la tua infrastruttura. AWS CloudFormation è in grado di rilevare le deviazioni tra ciò che i modelli di CloudFormation specificano e ciò che viene effettivamente distribuito.
+ [AWS CloudFormation: rilevamento delle deviazioni su un intero stack CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/detect-drift-stack.html)
## Risorse
**Documenti correlati:**
+ [Partner APN: partner che possono assistere con disaster recovery](https://aws.amazon.com/partners/find/results/?keyword=Disaster+Recovery)
+ [AWS Architecture Blog: Disaster Recovery Series](https://aws.amazon.com/blogs/architecture/tag/disaster-recovery-series/)
+ [AWS CloudFormation: rilevamento delle deviazioni su un intero stack CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/detect-drift-stack.html)
+ [Marketplace AWS: prodotti utilizzabili per il disaster recovery](https://aws.amazon.com/marketplace/search/results?searchTerms=Disaster+recovery)
+ [AWS Systems Manager Automation](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html)
+ [Ripristino di emergenza dei carichi di lavoro su AWS: ripristino nel cloud (whitepaper di AWS)](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/disaster-recovery-workloads-on-aws.html)
+ [In che modo è possibile implementare una soluzione di gestione della configurazione dell'infrastruttura in AWS?](https://aws.amazon.com/answers/configuration-management/aws-infrastructure-configuration-management/?ref=wellarchitected)
+ [Correzione di risorse AWS non conformi in base alle regole di Regole di AWS Config](https://docs.aws.amazon.com/config/latest/developerguide/remediation.html)
**Video correlati:**
+ [AWS re:Invent 2018: Architecture Patterns for Multi-Region Active-Active Applications (Modelli di architettura per applicazioni attive-attive multiregione) (ARC209-R2)](https://youtu.be/2e29I3dA8o4)
# REL13-BP05 Automatizzazione del ripristino
Utilizza AWS o strumenti di terze parti per automatizzare il ripristino del sistema e instradare il traffico verso il sito o la Regione del ripristino di emergenza.
In base ai controlli di integrità configurati, i servizi AWS, come Elastic Load Balancing e AWS Auto Scaling, possono distribuire il carico a zone di disponibilità integre, mentre i servizi, come Amazon Route 53 e AWS Global Accelerator, instradano il carico a Regioni AWS integre. Amazon Route 53 Application Recovery Controller aiuta a gestire e coordinare il failover utilizzando i controlli di disponibilità e le funzionalità di controlli di routing. Queste funzionalità monitorano continuamente la capacità dell'applicazione di riprendersi dai guasti e permettono di controllarne il ripristino delle applicazioni su più Regioni AWS, zone di disponibilità e on-premise.
Per i carichi di lavoro su data center fisici o virtuali o cloud privati, [Ripristino di emergenza elastico AWS](https://aws.amazon.com/cloudendure-disaster-recovery/), disponibile tramite Marketplace AWS, consente alle organizzazioni di organizzare una strategia di ripristino di emergenza su AWS. CloudEndure supporta, inoltre, il ripristino di emergenza tra Regioni e zone di disponibilità in AWS.
**Anti-pattern comuni:**
+ L'implementazione di failover e failback automatici identici può causare flapping quando si verifica un errore.
**Vantaggi dell'adozione di questa best practice:** Il ripristino automatico riduce i tempi di ripristino eliminando la possibilità di errori manuali.
**Livello di rischio associato se questa best practice non fosse adottata:** Medio
## Guida all'implementazione
+ Automatizzazione dei percorsi di ripristino. Per tempi di ripristino brevi, non è possibile servirsi del giudizio umano e dell'azione per scenari di disponibilità elevata. Il sistema dovrebbe ripristinarsi automaticamente in ogni situazione.
+ Usa il ripristino di emergenza CloudEndure per failover e failback automatizzati. Il ripristino di emergenza CloudEndure replica in modo continuo le macchine (tra cui sistema operativo, configurazione dello stato del sistema, database, applicazioni e file) in un'area di gestione temporanea a basso costo nell'Account AWS di destinazione e nella Regione preferita. In caso di emergenza, è possibile indicare a CloudEndure Disaster Recovery di avviare automaticamente migliaia di macchine nello stato di provisioning completo in pochi minuti.
+ [Performing a Disaster Recovery Failover and Failback](https://docs.cloudendure.com/Content/Configuring_and_Running_Disaster_Recovery/Performing_a_Disaster_Recovery_Failover/Performing_a_Disaster_Recovery_Failover.htm)
+ [CloudEndure Disaster Recovery](https://aws.amazon.com/cloudendure-disaster-recovery/)
## Risorse
**Documenti correlati:**
+ [Partner APN: partner che possono assistere con disaster recovery](https://aws.amazon.com/partners/find/results/?keyword=Disaster+Recovery)
+ [AWS Architecture Blog: Disaster Recovery Series](https://aws.amazon.com/blogs/architecture/tag/disaster-recovery-series/)
+ [Marketplace AWS: prodotti utilizzabili per il disaster recovery](https://aws.amazon.com/marketplace/search/results?searchTerms=Disaster+recovery)
+ [AWS Systems Manager Automation](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html)
+ [Ripristino di emergenza CloudEndure in AWS](https://aws.amazon.com/marketplace/pp/B07XQNF22L)
+ [Ripristino di emergenza dei carichi di lavoro su AWS: ripristino nel cloud (whitepaper di AWS)](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/disaster-recovery-workloads-on-aws.html)
**Video correlati:**
+ [AWS re:Invent 2018: Architecture Patterns for Multi-Region Active-Active Applications (Modelli architetturali per applicazioni attive-attive su più Regioni) (ARC209-R2)](https://youtu.be/2e29I3dA8o4)