# REL 13. Come si pianifica il disaster recovery?
Avere backup e componenti del carico di lavoro ridondanti in loco è l'inizio della strategia di disaster recovery. [RTO ed RPO sono gli 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 disaster recovery 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 disaster recovery per convalidare l'implementazione](rel_planning_for_recovery_dr_tested.md)
+ [REL13-BP04 Gestione della deviazione di configurazione nel sito o nella regione del disaster recovery](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
Guasti ed errori possono avere un impatto sull'attività in diversi modi. In primo luogo, possono causare l'interruzione del servizio (tempo di inattività). In secondo luogo, possono causare la perdita, l'incoerenza o il mancato aggiornamento dei dati. Per guidare le modalità di risposta e recupero dagli errori, definisci un Obiettivo del tempo di ripristino (RTO) e un Obiettivo del punto di ripristino (RPO) per ogni carico di lavoro. L'*Obiettivo del tempo di ripristino (RTO)* è il ritardo massimo accettabile tra l'interruzione del servizio e il ripristino del servizio. L'*Obiettivo del punto di ripristino (RPO)* è il tempo massimo accettabile dopo l'ultimo punto di ripristino dei dati.
**Risultato desiderato:** ogni carico di lavoro ha un RTO e un RPO designati in base a considerazioni tecniche e all'impatto aziendale.
**Anti-pattern comuni:**
+ Non hai designato gli obiettivi di ripristino.
+ Selezioni obiettivi di ripristino arbitrari.
+ Selezioni obiettivi di ripristino troppo blandi e che non soddisfano gli obiettivi aziendali.
+ Non hai valutato l'impatto del tempo di inattività e della perdita di dati.
+ Scegli obiettivi di ripristino non realistici, come il tempo zero di ripristino o nessuna perdita di dati, che potrebbero non essere raggiungibili per la configurazione del carico di lavoro.
+ Selezioni obiettivi di ripristino più severi rispetto agli obiettivi aziendali reali. Questo costringe a implementazioni di ripristino più costose e complicate rispetto alle esigenze del carico di lavoro.
+ Selezioni obiettivi di ripristino incompatibili con quelli di un carico di lavoro dipendente.
+ Non tieni conto dei requisiti normativi e di conformità.
**Vantaggi dell'adozione di questa best practice:** quando definisci gli RTO e gli RPO per i carichi di lavoro, stabilisci obiettivi chiari e misurabili per il ripristino in base alle esigenze aziendali. Una volta fissati questi obiettivi, puoi creare piani di disaster recovery (DR) su misura per raggiungerli.
**Livello di rischio associato se questa best practice non fosse adottata:** elevato
## Guida all’implementazione
Costruisci una matrice o un foglio di lavoro per guidare la pianificazione del disaster recovery. Nella matrice, crea diverse categorie o livelli di carico di lavoro in base al loro impatto sull'azienda (ad esempio, critico, alto, medio e basso) e i relativi RTO e RPO da raggiungere per ciascuno di essi. La matrice seguente fornisce un possibile esempio (nota che i valori RTO e RPO possono differire) da seguire:
![\[Grafico che mostra la matrice di disaster recovery\]](http://docs.aws.amazon.com/it_it/wellarchitected/2024-06-27/framework/images/disaster-recovery-matrix.png)
Per ogni carico di lavoro, devi analizzare e comprendere l'impatto sull'azienda del tempo di inattività e della perdita di dati. L'impatto cresce tipicamente con il tempo di inattività e la perdita di dati, ma la forma dell'impatto può variare in base al tipo di carico di lavoro. Ad esempio, un tempo di inattività fino a un'ora potrebbe avere un impatto ridotto, ma in seguito l'impatto potrebbe intensificarsi rapidamente. L'impatto può assumere diverse forme, tra cui l'impatto finanziario (come la perdita di fatturato), l'impatto a livello di reputazione (tra cui la perdita di fiducia dei clienti), l'impatto operativo (come il mancato pagamento degli stipendi o la diminuzione della produttività) e il rischio normativo. Una volta completato, assegna il carico di lavoro al livello appropriato.
Considera le seguenti domande quando analizzi l'impatto del guasto o dell'errore:
1. Qual è il tempo massimo di indisponibilità del carico di lavoro prima che si verifichi un impatto inaccettabile sull'azienda?
1. Qual è l'intensità e il tipo di impatto che l'azienda subirà a causa di un'interruzione del carico di lavoro? Prendi in considerazione tutti i tipi di impatto, compresi quelli finanziari, a livello di reputazione, operativi e normativi.
1. Qual è la quantità massima di dati che può essere persa o non recuperata prima che si verifichi un impatto inaccettabile sull'azienda?
1. I dati persi possono essere ricreati da altre fonti (note anche come dati *derivati*)? In tal caso, considera anche gli RPO di tutti i 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 dipende (a valle)? Gli obiettivi del carico di lavoro devono essere raggiungibili in base alle capacità di ripristino delle relative dipendenze a valle. Valuta possibili soluzioni alternative o mitigazioni delle dipendenze downstream che possono migliorare la capacità di ripristino di questo carico di lavoro.
1. Quali sono gli obiettivi di ripristino e le aspettative di disponibilità dei carichi di lavoro che dipendono da questo (upstream)? Gli obiettivi del carico di lavoro upstream possono richiedere che questo carico di lavoro disponga di capacità di ripristino più rigorose di quanto non sembri a prima vista.
1. Esistono obiettivi di recupero diversi in base al tipo di incidente? Ad esempio, si possono avere RTO e RPO diversi a seconda che l'incidente riguardi una zona di disponibilità o un'intera Regione.
1. Gli obiettivi di ripristino cambiano durante determinati eventi o periodi dell'anno? Ad esempio, si possono avere RTO e RPO diversi in base alle stagioni dello shopping, agli eventi sportivi, alle vendite speciali e al lancio di nuovi prodotti.
1. In che modo gli obiettivi di ripristino si allineano con la strategia di disaster recovery aziendale e organizzativa?
1. Ci sono implicazioni legali o contrattuali da considerare? Ad esempio, hai l'obbligo per contratto di fornire un servizio con un determinato RTO o RPO? In quali sanzioni potresti incorrere in caso di inadempienza?
1. Devi mantenere l'integrità dei dati per soddisfare i requisiti normativi o di conformità?
Il seguente foglio di lavoro può aiutarti a valutare ogni carico di lavoro. Puoi modificare questo foglio di lavoro per adattarlo alle tue esigenze specifiche, ad esempio aggiungendo altre domande.
![\[Foglio di lavoro\]](http://docs.aws.amazon.com/it_it/wellarchitected/2024-06-27/framework/images/worksheet.png)
### Passaggi dell’implementazione
1. Identifica le parti interessate aziendali e i team tecnici responsabili di ciascun carico di lavoro e collabora con loro.
1. Crea categorie o livelli di criticità per l'impatto del carico di lavoro nell'organizzazione. Le categorie di esempio sono: critico, alto, medio e basso. Per ogni categoria, scegli un RTO e un RPO che riflettano gli obiettivi e i requisiti aziendali.
1. Assegna a ciascun carico di lavoro una delle categorie di impatto create nel passaggio precedente. Per decidere in che modo un carico di lavoro rientra in una categoria, considera l'importanza del carico di lavoro per l'azienda e l'impatto di un'interruzione o di una perdita di dati e utilizza le domande di cui sopra come guida. Ne conseguono un RTO e un RPO per ogni carico di lavoro.
1. Considera l'RTO e l'RPO per ogni carico di lavoro determinato nel passaggio precedente. Coinvolgi i team aziendali e tecnici del carico di lavoro per determinare se gli obiettivi devono essere modificati. Ad esempio, le parti interessate aziendali potrebbero stabilire che siano necessari obiettivi più severi. In alternativa, i team di tecnici potrebbero decidere di modificare gli obiettivi per renderli raggiungibili con le risorse disponibili e i vincoli tecnologici.
## Risorse
**Best practice correlate:**
+ [REL09-BP04 Ripristino periodico dei dati per verificare l'integrità e i processi di backup](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_backing_up_data_periodic_recovery_testing_data.html)
+ [REL12-BP01 Utilizzo dei playbook per analizzare gli errori](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_testing_resiliency_playbook_resiliency.html)
+ [REL13-BP02 Utilizzo di strategie di ripristino definite per conseguire gli obiettivi di ripristino](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_planning_for_recovery_disaster_recovery.html)
+ [REL13-BP03 Esecuzione di test sull'implementazione del disaster recovery per convalidare l'implementazione](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_planning_for_recovery_dr_tested.html)
**Documenti correlati:**
+ [AWS Architecture Blog: serie sul disaster recovery](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)
+ [Managing resiliency policies with AWS Resilience Hub](https://docs.aws.amazon.com/resilience-hub/latest/userguide/resiliency-policies.html)
+ [Partner APN: partner che possono assistere con il 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](https://youtu.be/2e29I3dA8o4)
+ [Disaster Recovery of Workloads on 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 disaster recovery che soddisfi gli obiettivi di ripristino del carico di lavoro. Scegli una strategia, ad esempio backup e ripristino, standby (attivo/passivo) o attivo/attivo.
**Risultato desiderato:** per ciascun carico di lavoro esiste una strategia di disaster recovery definita e implementata che consente a quel carico di lavoro di raggiungere gli obiettivi di disaster recovery. Le strategie di disaster recovery 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 disaster recovery ad-hoc quando si verifica un disastro.
+ Assenza di piani per il disaster recovery.
+ Dipendenza dalle operazioni del piano di controllo (control-plane) 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'uso di strategie di ripristino definite permette la condivisione delle informazioni tra team e l'implementazione del disaster recovery nei carichi dl lavoro di loro proprietà.
**Livello di rischio associato se questa best practice non fosse adottata:** elevato. Senza una strategia di disaster recovery pianificata, implementata e testata, è poco probabile riuscire a raggiungere gli obiettivi di ripristino in caso di emergenze.
## Guida all'implementazione
Una strategia di disaster recovery 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 disaster recovery (DR) su più zone di disponibilità (AZ) all'interno di un singolo Regione AWS può offrire la mitigazione rispetto a emergenze 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 disaster recovery di emergenza basata su più regioni.
Quando pianifichi una strategia di disaster recovery su più regioni, devi scegliere una delle seguenti strategie. Sono elencati in ordine crescente di costo e complessità e in ordine decrescente di RTO e RPO. La *regione di ripristino* indica una Regione AWS diversa da quella principale utilizzata per il carico di lavoro.
![\[Diagramma che mostra le strategie di disaster recovery\]](http://docs.aws.amazon.com/it_it/wellarchitected/2024-06-27/framework/images/disaster-recovery-strategies.png)
+ **Backup e ripristino** (RPO in ore, RTO in 24 ore o meno): esegui il backup dei dati e delle applicazioni nella regione di recupero. Adottando backup continui o automatizzati otterrai un ripristino point-in-time (PITR) 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 il modello Infrastructure as code per ridurre l'RTO), implementerai 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 ridotto verticalmente. I dati vengono replicati e si trovano nella regione di recupero. Al momento del ripristino, il sistema viene fatto aumentare verticalmente rapidamente per gestire il carico di produzione. Più si aumenterà verticalmente nella strategia di Warm Standby, più bassi saranno l'RTO e la dipendenza del piano di controllo (control-plane). Quando il dimensionamento è completo, si parla di *standby a caldo*.
+ **Attivo/attivo multi-regione (multisito)** (RPO vicino a zero, RTO uguale potenzialmente a zero): il carico di lavoro viene implementato in più 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 la strategia 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à). La strategia Pilot Light richiede l'attivazione dei server, possibilmente l'implementazione di un'infrastruttura aggiuntiva (non principale) e l'aumentare verticalmente, mentre Warm Standby richiede solo l'aumentare verticalmente (tutto è già stato implementato ed è in esecuzione). Scegli tra queste opzioni in base alle tue esigenze di RTO e RPO.
Quando i costi sono un motivo di preoccupazione e vuoi realizzare obiettivi RPO ed RTO simili a quelli definiti nella strategia di Warm Standby, puoi prendere in considerazione soluzioni cloud-native (native del cloud), come AWS Elastic Disaster Recovery, che adotta l'approccio Pilot Light e offre obiettivi RPO ed RTO migliori.
**Passaggi dell'implementazione**
1. **Definisci una strategia di disaster recovery in linea con i requisiti di ripristino di questo carico di lavoro.**
La scelta di una strategia di disaster recovery è un compromesso tra la riduzione dei tempi di inattività e della perdita di dati (RTO ed RPO) e i costi e la complessità di implementazione della strategia. 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 disaster recovery Pilot Light o di Warm Standby soddisfano sia l'RTO sia i criteri per i costi.
![\[Grafico che mostra la scelta di una strategia di disaster recovery in base all'RTO e ai costi\]](http://docs.aws.amazon.com/it_it/wellarchitected/2024-06-27/framework/images/choosing-a-dr-strategy.png)
Per ulteriori informazioni, consulta [Piano di continuità aziendale](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 disaster recovery 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 disaster recovery, utilizzando aspetti di più strategie.
Nei passaggi seguenti puoi applicare la strategia al carico di lavoro specifico.
**Backup e ripristino**
*Backup 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'altra Regione AWS).
![\[Diagramma che mostra un'architettura di backup e ripristino\]](http://docs.aws.amazon.com/it_it/wellarchitected/2024-06-27/framework/images/backup-restore-architecture.png)
Per ulteriori dettagli su questa strategia, consulta [Disaster Recovery (DR) Architecture on AWS, Part II: Backup and Restore with Rapid Recovery](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 implementate nella regione di ripristino; tuttavia sono comunque necessarie risorse aggiuntive ed eventuali dipendenze per rendere funzionale questo stack. Ad esempio, nella Figura 20 non viene implementata alcuna risorsa di calcolo.
![\[Diagramma che mostra un'architettura pilot light\]](http://docs.aws.amazon.com/it_it/wellarchitected/2024-06-27/framework/images/pilot-light-architecture.png)
Per ulteriori informazioni su questa strategia, consulta [Disaster Recovery (DR) Architecture on AWS, Part III: Pilot Light and 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 verticalmente, 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/2024-06-27/framework/images/warm-standby-architecture.png)
Se si utilizza Warm Standby o Pilot Light è necessario aumentare verticalmente le risorse nella regione di ripristino. Per verificare che sia disponibile capacità sufficiente quando necessario, valuta l'eventuale utilizzo delle [prenotazioni della capacità](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-capacity-reservations.html) per le istanze EC2. In caso di utilizzo di AWS Lambda, la [concorrenza allocata](https://docs.aws.amazon.com/lambda/latest/dg/provisioned-concurrency.html) può fornire ambienti di runtime pronti a rispondere immediatamente alle invocazioni della funzione.
Per ulteriori informazioni su questa strategia, consulta [Disaster Recovery (DR) Architecture on AWS, Part III: Pilot Light and 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 disaster recovery. 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 disaster recovery, se il carico di lavoro non può essere supportato in una delle Regioni AWS in cui viene implementato, la regione viene evacuata e vengono usate le regioni rimanenti per garantire la disponibilità. La strategia 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/2024-06-27/framework/images/multi-site-active-active-architecture.png)
Per ulteriori informazioni su questa strategia, consulta [Disaster Recovery (DR) Architecture on AWS, Part IV: Multi-site Active/Active](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-iv-multi-site-active-active/).
**AWS Elastic Disaster Recovery**
Se stai prendendo in considerazione la strategia pilot light o warm standby per il disaster recovery, AWS Elastic Disaster Recovery potrebbe fornire un approccio alternativo con maggiori vantaggi. Elastic Disaster Recovery può offrire obiettivi RPO e RTO simili alla strategia warm standby, ma con l'approccio a basso costo della strategia pilot light. Elastic Disaster Recovery replica i dati dalla regione primaria a quella di ripristino, usando una protezione continua dei dati per conseguire un RPO misurato in secondi e un RTO misurabile in minuti. Solo le risorse necessarie per replicare i dati vengono implementate nella regione di ripristino, mantenendo i costi ridotti come nella strategia Pilot Light. Quando usi Elastic Disaster Recovery, il servizio coordina e orchestra il ripristino delle risorse di calcolo quando viene avviato come parte di un failover o di un'esercitazione.
![\[Diagramma dell'architettura che descrive il funzionamento di AWS Elastic Disaster Recovery.\]](http://docs.aws.amazon.com/it_it/wellarchitected/2024-06-27/framework/images/drs-architecture.png)
**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 disaster recovery usa più elementi delle strategie precedenti. Devi innanzitutto creare un'architettura con disponibilità elevata usando più zone di disponibilità, come mostrato nella Figura 23. Questa architettura utilizza un approccio attivo/attivo multisito, in quanto 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) dispongono di risorse implementate in più zone di disponibilità, che gestiscono attivamente le richieste. L'architettura dimostra inoltre che lo standby a caldo, in cui in caso di errore dell'istanza [Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Concepts.MultiAZ.html) primaria (o della stessa zona di disponibilità), l'istanza di standby viene promossa a primaria.
![\[Figura 24: diagramma che mostra un'architettura con più zone di disponibilità\]](http://docs.aws.amazon.com/it_it/wellarchitected/2024-06-27/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 è di particolare importanza per i dati vincolati a una singola zona, come i [volumi Amazon EBS](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-volumes.html) o i [cluster Amazon Redshift.](https://docs.aws.amazon.com/redshift/latest/mgmt/working-with-clusters.html) In caso di errore di una zona di disponibilità, dovrai ripristinare i dati in un'altra zona di disponibilità. Laddove possibile, dovrai anche copiare i backup di dati su un'altra Regione AWS come forma di ulteriore protezione.
Un approccio alternativo meno comune alla singola Regione, ossia il disaster recovery multi-AZ, è presentato nel post del blog, [Building highly resilient applications using Amazon Application Recovery Controller, Part 1: Single-Region stack](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 l'infrastruttura e le risorse AWS, usa il modello Infrastructure as code, come [AWS CloudFormation](https://aws.amazon.com/cloudformation) o strumenti di terze parti, come Hashicorp Terraform. Per l'implementazione 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. I [parametri](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/parameters-section-structure.html) e la [logica condizionale](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/intrinsic-function-reference-conditions.html) di CloudFormation permettono di controllare se uno stack implementato è attivo o in standby con [un unico modello](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-iii-pilot-light-and-warm-standby/). Quando usi Elastic Disaster Recovery, il servizio replica e orchestra il ripristino delle configurazioni delle applicazioni e delle risorse di calcolo.
Tutte le strategie di disaster recovery richiedono l'esecuzione del backup delle origini dati all'interno della Regione AWS e la copia di tali backup nella regione di ripristino. [AWS Backup](https://aws.amazon.com/backup/) offre una visualizzazione a livello centrale che consente di configurare, pianificare e monitorare i backup per tali risorse. Per Pilot Light, Warm Standby e Multi-sito attivo/attivo, devi anche replicare i dati dalla regione principale alle risorse di dati nella regione di ripristino, come le istanze DB di [Amazon Relational Database Service (Amazon RDS)](https://aws.amazon.com/rds) o le tabelle di [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 ulteriori informazioni sul funzionamento dei servizi AWS fra le regioni, consulta questa serie di blog sulla [creazione di un'applicazione in più regioni con 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'emergenza).**
Per la strategia attivo/attivo multisito, il failover significa evacuare una regione e usare le regioni attive rimanenti. In generale, tali regioni sono pronte per accettare il traffico. Per le strategie Pilot Light e di Warm Standby, le azioni di ripristino devono implementare le risorse mancanti, come le istanze EC2 nella Figura 20, insieme a risorse mancanti di altro tipo.
Per tutte le strategie precedenti potresti dover promuovere istanze di database di 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 implementare il codice. Puoi usare AWS Backup per ripristinare i dati nella regione di ripristino. Per ulteriori dettagli, consulta [REL09-BP01 Identificazione e backup di tutti i dati che richiedono un backup o una riproduzione dei dati dalle origini](rel_backing_up_data_identified_backups_data.md). La ricostruzione dell'infrastruttura comprende la creazione di risorse come istanze EC2, oltre ad [Amazon Virtual Private Cloud (Amazon VPC)](https://aws.amazon.com/vpc), sottoreti e gruppi di sicurezza necessari. Puoi automatizzare gran parte del processo di ripristino. Per scoprire come farlo, consulta [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'emergenza).**
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. Tra le opzioni, vi è l'utilizzo di [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 il failover avviato manualmente, puoi utilizzare [Amazon Application Recovery Controller](https://aws.amazon.com/application-recovery-controller/), che fornisce un'API del piano dati a elevata disponibilità per reinstradare il traffico verso la Regione di ripristino. Nella fase di implementazione del failover, usa le operazioni di piano dati ed evita quelle del piano di controllo (control-plane), come illustrato in [REL11-BP04 Fare affidamento al piano dati invece che al piano di controllo (control-plane) durante il ripristino](rel_withstand_component_failures_avoid_control_plane.md).
Per ulteriori informazioni su questa e 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'emergenza è diminuita di intensità. Il provisioning di infrastruttura e codice alla regione principale in genere segue gli stessi passaggi usati inizialmente, affidandosi al modello Infrastructure as code e alle pipeline di implementazione 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. In caso di utilizzo delle [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, ripristina la propagazione di scritture in sospeso. Se utilizzi il [Database globale Amazon Aurora](https://aws.amazon.com/rds/aurora/global-database/) e un [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.
Dopo un failover, se puoi proseguire l'esecuzione nella tua regione di ripristino, valuta la possibilità di farlo nella tua regione principale. Effettueresti 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.
Se usi Elastic Disaster Recovery, il servizio fornirà assistenza per l'orchestrazione e l'automazione del processo di failback. Per ulteriori informazioni, consulta [Performing a failback](https://docs.aws.amazon.com/drs/latest/userguide/failback-performing-main.html).
**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 una 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 (control-plane) 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: serie sul disaster recovery](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 disaster recovery 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 un fra le regioni](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)
+ [Cosa è AWS Backup?](https://docs.aws.amazon.com/aws-backup/latest/devguide/whatisbackup.html)
+ [What is Amazon Application Recovery Controller?](https://docs.aws.amazon.com/r53recovery/latest/dg/what-is-route53-recovery.html)
+ [AWS Elastic Disaster Recovery](https://docs.aws.amazon.com/drs/latest/userguide/what-is-drs.html)
+ [HashiCorp Terraform: Get Started - AWS](https://learn.hashicorp.com/collections/terraform/aws-get-started)
+ [Partner APN: partner che possono assistere con il 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:**
+ [Disaster Recovery of Workloads on AWS](https://www.youtube.com/watch?v=cJZw5mrxryA)
+ [AWS re:Invent 2018: Architecture Patterns for Multi-Region Active-Active Applications (ARC209-R2)](https://youtu.be/2e29I3dA8o4)
+ [Get Started with AWS Elastic Disaster Recovery \$1 Amazon Web Services](https://www.youtube.com/watch?v=GAMUCIJR5as)
# REL13-BP03 Esecuzione di test sull'implementazione del disaster recovery per convalidare l'implementazione
Testa regolarmente il failover nel sito di ripristino per verificare che funzioni correttamente e che sia possibile soddisfare l'RTO e l'RPO.
**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 verifica 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:** elevato
## Guida all’implementazione
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à.
**Passaggi dell'implementazione**
1. Progetta i carichi di lavoro per il ripristino. Esegui regolarmente test dei tuoi percorsi di ripristino. Il calcolo orientato al ripristino identifica le caratteristiche nei sistemi che migliorano il ripristino: isolamento e ridondanza, ripristino a livello di sistema dello stato precedente rispetto alle modifiche, capacità di fornire diagnostica, ripristino automatico, progettazione modulare e possibilità di riavvio. Prova il percorso di ripristino per verificare di poter completare il ripristino nel tempo specificato e in base allo stato specificato. Usa i tuoi runbook durante questo ripristino per documentare i problemi e trovarne le soluzioni prima del test successivo.
1. Per i carichi di lavoro basati su Amazon EC2, utilizza [AWS Elastic Disaster Recovery](https://docs.aws.amazon.com/drs/latest/userguide/what-is-drs.html) per implementare e avviare istanze di esercitazione per la tua strategia di disaster recovery. AWS Elastic Disaster Recovery consente di eseguire esercitazioni in modo efficiente, per prepararsi per un evento di failover. Puoi anche avviare spesso le istanze usando Elastic Disaster Recovery per scopi di test ed esercitazione senza reindirizzare il traffico.
## Risorse
**Documenti correlati:**
+ [Partner APN: partner che possono assistere con il ripristino di emergenza](https://aws.amazon.com/partners/find/results/?keyword=Disaster+Recovery)
+ [AWS Architecture Blog: serie sul disaster recovery](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 Elastic Disaster Recovery](https://aws.amazon.com/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)
+ [AWS Elastic Disaster Recovery Preparing for Failover](https://docs.aws.amazon.com/drs/latest/userguide/failback-preparing.html)
+ [The Berkeley/Stanford recovery-oriented computing project](http://roc.cs.berkeley.edu/)
+ [What is 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](https://youtu.be/2e29I3dA8o4)
+ [AWS re:Invent 2019: Backup-and-restore and disaster-recovery solutions with AWS](https://youtu.be/7gNXfo5HZN8)
# REL13-BP04 Gestione della deviazione di configurazione nel sito o nella regione del disaster recovery
Per eseguire una procedura di disaster recovery (DR), il carico di lavoro deve essere in grado di riprendere le normali operazioni in modo tempestivo, senza perdite rilevanti di funzionalità o di dati, una volta che l'ambiente di DR è stato messo online. Per raggiungere questo obiettivo, è essenziale mantenere coerenti l'infrastruttura, i dati e le configurazioni tra l'ambiente di disaster recovery e l'ambiente primario.
**Risultato desiderato:** la configurazione e i dati del sito di disaster recovery sono identici a quelli del sito primario, il che facilita un ripristino rapido e completo in caso di necessità.
**Anti-pattern comuni:**
+ Non riesci ad aggiornare le posizioni di ripristino quando vengono apportate modifiche alle posizioni primarie. Questo determina configurazioni obsolete che potrebbero ostacolare gli sforzi di ripristino.
+ Non consideri le potenziali limitazioni, come le differenze di servizio tra le posizioni primaria e di ripristino, che possono portare a errori imprevisti durante il failover.
+ Per l'aggiornamento e la sincronizzazione dell'ambiente di disaster recovery fai riferimento a processi manuali, il che aumenta il rischio di errore umano e di incoerenza.
+ Non riesci a rilevare la deviazione di configurazione. Questo ti porta falsamente a pensare che il sito di disaster recovery sia pronto prima di un incidente.
**Vantaggi dell'adozione di questa best practice:** la coerenza tra l'ambiente di disaster recovery e l'ambiente primario migliora notevolmente le probabilità della riuscita di un ripristino dopo un incidente e riduce il rischio di errore della procedura di ripristino.
**Livello di rischio associato se questa best practice non fosse adottata:** elevato
## Guida all’implementazione
Un approccio completo alla gestione della configurazione e alla preparazione al failover può aiutarti a verificare che il sito di disaster recovery sia costantemente aggiornato e pronto a subentrare in caso di errore del sito primario.
Per ottenere la coerenza tra l'ambiente primario e quello di disaster recovery (DR), verifica che le pipeline di distribuzione distribuiscano le applicazioni sia al sito primario che a quello di disaster recovery. Implementa le modifiche ai siti di disaster recovery dopo un adeguato periodo di valutazione (noto anche come *implementazioni distribuite*) per rilevare i problemi nel sito primario e arrestare l'implementazione prima che si diffondano. Implementa il monitoraggio per rilevare la deviazione della configurazione e tenere traccia delle modifiche e della conformità negli ambienti. Esegui la correzione automatica nel sito di disaster recovery per mantenerlo completamente coerente e pronto a subentrare in caso di incidente.
### Passaggi dell’implementazione
1. Verifica che la Regione di disaster recovery contenga i servizi AWS e le funzionalità richieste per una corretta esecuzione del piano di disaster recovery.
1. Utilizza infrastructure as code (IaC). Mantieni accurati i modelli di configurazione dell'infrastruttura di produzione e dell'applicazione e applicali regolarmente all'ambiente di disaster recovery. [AWS CloudFormation](https://aws.amazon.com/cloudformation/) è in grado di rilevare le deviazioni tra ciò che i modelli CloudFormation specificano e ciò che viene effettivamente distribuito.
1. Configura le pipeline CI/CD per distribuire le applicazioni e gli aggiornamenti dell'infrastruttura in tutti gli ambienti, compresi i siti primari e di disaster recovery. Soluzioni CI/CD come [AWS CodePipeline](https://aws.amazon.com/codepipeline/) possono automatizzare il processo di implementazione, riducendo il rischio di deviazione della configurazione.
1. Implementazioni distribuite tra gli ambienti primario e di disaster recovery. Questo approccio consente di distribuire e testare inizialmente gli aggiornamenti nell'ambiente primario, isolando così i problemi nel sito primario prima che vengano propagati al sito di disaster recovery. Questo approccio impedisce che i difetti vengano inviati contemporaneamente alla produzione e al sito di disaster recovery e mantiene l'integrità dell'ambiente di disaster recovery.
1. Monitora costantemente le configurazioni delle risorse sia nell'ambiente primario che in quello di disaster recovery. Soluzioni come [AWS Config](https://aws.amazon.com/config/) possono aiutare a far rispettare la conformità della configurazione e a rilevare eventuali deviazioni, contribuendo a mantenere configurazioni coerenti tra gli ambienti.
1. Implementa meccanismi di avviso per monitorare e notificare qualsiasi deviazione della configurazione o interruzione o ritardo nella replica dei dati.
1. Automatizza la correzione delle deviazioni di configurazione rilevate.
1. Pianifica audit periodici e controlli di conformità per verificare l'allineamento continuo tra le configurazioni primaria e di disaster recovery. Le revisioni periodiche aiutano a mantenere la conformità con le regole definite e a identificare eventuali discrepanze che devono essere risolte.
1. Verifica eventuali discordanze nella capacità allocata da AWS, in Service Quotas, nelle limitazioni (della larghezza di banda della rete) e nelle discrepanze di configurazione e versione.
## Risorse
**Best practice correlate:**
+ [REL01-BP01 Consapevolezza su Service Quotas e vincoli di servizio](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_manage_service_limits_aware_quotas_and_constraints.html)
+ [REL01-BP02 Gestione delle Service Quotas in più account e Regioni](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_manage_service_limits_limits_considered.html)
+ [REL01-BP04 Monitoraggio e gestione delle quote](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_manage_service_limits_monitor_manage_limits.html)
+ [REL13-BP03 Esecuzione di test sull'implementazione del disaster recovery per convalidare l'implementazione](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_planning_for_recovery_dr_tested.html)
**Documenti correlati:**
+ [Remediating Noncompliant AWS Resources by 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)
+ [AWS CloudFormation: Detecting unmanaged configuration changes to stacks and resources](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/using-cfn-stack-drift.html)
+ [AWS CloudFormation: Detect Drift on an Entire CloudFormation Stack](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/detect-drift-stack.html)
+ [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)
+ [Remediating Noncompliant AWS Resources by 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 (ARC209-R2)](https://youtu.be/2e29I3dA8o4)
**Esempi correlati:**
+ [CloudFormation Registry](https://aws.amazon.com/blogs/devops/identify-regional-feature-parity-using-the-aws-cloudformation-registry/)
+ [Quota Monitor for AWS](https://aws.amazon.com/solutions/implementations/quota-monitor/)
+ [Implement automatic drift remediation for AWS CloudFormation using Amazon CloudWatch and AWS Lambda](https://aws.amazon.com/blogs/mt/implement-automatic-drift-remediation-for-aws-cloudformation-using-amazon-cloudwatch-and-aws-lambda/)
+ [AWS Architecture Blog: serie sul disaster recovery](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)
+ [Automatizzazione di distribuzioni pratiche e sicure](https://aws.amazon.com/builders-library/automating-safe-hands-off-deployments/)
# REL13-BP05 Automatizzazione del ripristino
Implementa meccanismi di ripristino testati e automatizzati che siano affidabili, osservabili e riproducibili per ridurre il rischio e l'impatto aziendale di guasti ed errori.
**Risultato desiderato:** hai implementato un flusso di lavoro di automazione ben documentato, standardizzato e accuratamente testato per i processi di ripristino. L'automazione del ripristino corregge automaticamente i problemi secondari che comportano un basso rischio di perdita di dati o di indisponibilità. Puoi invocare rapidamente i processi di ripristino per gli incidenti gravi, osservare il comportamento della correzione durante il loro funzionamento e terminare i processi se osservi situazioni pericolose o errori.
**Anti-pattern comuni:**
+ Dipendi da componenti o meccanismi che si trovano in uno stato non riuscito o danneggiato come parte del piano di ripristino.
+ I processi di ripristino richiedono un intervento manuale, come l'accesso alla console (noto anche come *ClickOps*).
+ Avvii le procedure di ripristino automaticamente in situazioni che presentano un rischio elevato di perdita o indisponibilità dei dati.
+ Non includi un meccanismo per interrompere una procedura di ripristino (come un *cavo Andon* o un *grande pulsante rosso di arresto*) che non funziona o che comporta rischi aggiuntivi.
**Vantaggi dell'adozione di questa best practice:**
+ Maggiore affidabilità, prevedibilità e coerenza delle operazioni di ripristino.
+ Capacità di soddisfare obiettivi di ripristino più rigorosi, tra cui Obiettivo del tempo di ripristino (RTO) e Obiettivo del punto di ripristino (RPO).
+ Riduzione della probabilità di non riuscita del ripristino durante un incidente.
+ Riduzione del rischio di errori associati a processi di ripristino manuali, soggetti a errori umani.
**Livello di rischio associato se questa best practice non fosse adottata:** medio
## Guida all'implementazione
Per implementare il ripristino automatizzato, è necessario un approccio completo che utilizzi i servizi AWS e le best practice. Per iniziare, identifica i componenti critici e i potenziali punti di errore nel carico di lavoro. Sviluppa processi automatizzati in grado di ripristinare i carichi di lavoro e i dati in caso di errori senza l'intervento umano.
Sviluppa l'automazione del ripristino utilizzando i principi infrastructure as code (IaC). In questo modo l'ambiente di ripristino è coerente con l'ambiente di origine e consente il controllo delle versioni dei processi di ripristino. Per orchestrare flussi di lavoro di ripristino complessi, valuta soluzioni come [AWS Systems Manager Automations](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html) o [AWS Step Functions](https://aws.amazon.com/step-functions/).
L'automazione dei processi di ripristino offre vantaggi significativi e può aiutare a raggiungere più facilmente Obiettivo del tempo di ripristino (RTO) e Obiettivo del punto di ripristino (RPO). Tuttavia, si possono verificare situazioni impreviste che possono causare un esito negativo o creare nuovi rischi, come tempo di inattività aggiuntivo e perdita di dati. Per ridurre questo rischio, occorre offrire la possibilità di interrompere rapidamente un'automazione dei ripristino in corso. Una volta interrotta, si può indagare e adottare misure correttive.
Per i carichi di lavoro supportati, valuta soluzioni come AWS Elastic Disaster Recovery (AWS DRS) per fornire un failover automatico. AWS DRS replica continuamente le macchine (compresi sistema operativo, configurazione dello stato del sistema, database, applicazioni e file) in un'area di gestione temporanea nell'Account AWS di destinazione e nella Regione preferita. Se si verifica un incidente, AWS DRS automatizza la conversione dei server replicati in carichi di lavoro completamente allocati nella Regione di ripristino su AWS.
La manutenzione e il miglioramento del ripristino automatico sono un processo continuo. Verifica e perfeziona continuamente le procedure di ripristino in base alle lezioni apprese e rimani aggiornato sui nuovi servizi e funzionalità AWS che possono migliorare le capacità di ripristino.
### Passaggi dell'implementazione
1. **Pianifica il ripristino automatico**
1. Esegui una revisione approfondita dell'architettura, dei componenti e delle dipendenze del carico di lavoro per identificare e pianificare i meccanismi di ripristino automatico. Classifica le dipendenze del carico di lavoro in dipendenze *hard* e *soft*. Le dipendenze hard sono quelle senza le quali il carico di lavoro non può funzionare e per le quali non è possibile fornire un sostituto. Le dipendenze soft sono quelle utilizzate abitualmente dal carico di lavoro, ma che possono essere sostituite da sistemi o processi sostitutivi temporanei o che possono essere gestite con una [degradazione regolare](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_mitigate_interaction_failure_graceful_degradation).
1. Stabilisci processi per identificare e recuperare i dati mancanti o danneggiati.
1. Definisci i passaggi per confermare lo stato stazionario ripristinato dopo il completamento delle azioni di ripristino.
1. Prendi in considerazione tutte le azioni necessarie per rendere il sistema ripristinato pronto per il servizio completo, come il pre-riscaldamento e la compilazione delle cache.
1. Considera i problemi che si potrebbero verificare durante il processo di ripristino e come individuarli e correggerli.
1. Considera gli scenari in cui il sito primario e il relativo piano di controllo (control-plane) non sono accessibili. Verifica che le azioni di ripristino possano essere eseguite in modo indipendente senza ricorso al sito primario. Considera soluzioni come [Amazon Application Recovery Controller (ARC)](https://aws.amazon.com/application-recovery-controller/) per reindirizzare il traffico senza dover modificare manualmente i record DNS.
1. **Sviluppa un processo di ripristino automatico**
1. Implementa il rilevamento automatico dei guasti e meccanismi di failover per un ripristino automatico. Crea dashboard, ad esempio con [Amazon CloudWatch](https://aws.amazon.com/cloudwatch/), per segnalare lo stato di avanzamento e lo stato di integrità delle procedure di ripristino automatiche. Includi procedure per convalidare le operazioni di ripristino riuscite. Fornisci un meccanismo per interrompere un ripristino in corso.
1. Crea [playbook](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_testing_resiliency_playbook_resiliency) come processo di fallback per guasti che non possono essere ripristinati automaticamente e prendi in considerazione il [piano di disaster recovery](https://aws.amazon.com/disaster-recovery/faqs/#Core_concepts).
1. Esegui il test dei processi di ripristino come descritto in [REL13-BP03](https://docs.aws.amazon.com/wellarchitected/latest/framework/rel_planning_for_recovery_dr_tested.html).
1. **Preparati per il ripristino**
1. Valuta lo stato del sito di ripristino e distribuisci in anticipo i componenti critici. Per ulteriori dettagli, consulta [REL13-BP04](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_planning_for_recovery_config_drift.html).
1. Definisci ruoli, responsabilità e processi decisionali chiari per le operazioni di ripristino, coinvolgendo le parti interessate e i team dell'organizzazione.
1. Definisci le condizioni per avviare i processi di ripristino.
1. Crea un piano per invertire il processo di ripristino e tornare al sito primario, se richiesto o dopo che è stato considerato sicuro.
## Risorse
**Best practice correlate:**
+ [REL07-BP01 Utilizzo dell'automazione per l'acquisizione o il dimensionamento delle risorse](https://docs.aws.amazon.com/wellarchitected/latest/framework/rel_adapt_to_changes_autoscale_adapt.html)
+ [REL11-BP01 Monitoraggio di tutti i componenti del carico di lavoro per la rilevazione dei guasti](https://docs.aws.amazon.com/wellarchitected/latest/framework/rel_withstand_component_failures_monitoring_health.html)
+ [REL13-BP02 Utilizzo di strategie di ripristino definite per conseguire gli obiettivi di ripristino](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_planning_for_recovery_disaster_recovery.html)
+ [REL13-BP03 Esecuzione di test sull'implementazione del disaster recovery per convalidare l'implementazione](https://docs.aws.amazon.com/wellarchitected/latest/framework/rel_planning_for_recovery_dr_tested.html)
+ [REL13-BP04 Gestione della deviazione di configurazione nel sito o nella Regione del disaster recovery](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_planning_for_recovery_config_drift.html)
**Documenti correlati:**
+ [AWS Architecture Blog: serie sul disaster recovery](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)
+ [Orchestrate Disaster Recovery Automation using Amazon Route 53 ARC and AWS Step Functions](https://aws.amazon.com/blogs/networking-and-content-delivery/orchestrate-disaster-recovery-automation-using-amazon-route-53-arc-and-aws-step-functions/)
+ [Build AWS Systems Manager Automation runbooks using AWS CDK](https://aws.amazon.com/blogs/mtbuild-aws-systems-manager-automation-runbooks-using-aws-cdk/)
+ [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)
+ [AWS Elastic Disaster Recovery](https://aws.amazon.com/disaster-recovery/)
+ [Using Elastic Disaster Recovery for Failover and Failback](https://docs.aws.amazon.com/drs/latest/userguide/failback.html)
+ [Risorse di AWS Elastic Disaster Recovery](https://aws.amazon.com/disaster-recovery/resources/)
+ [Partner APN: partner che possono assistere con il disaster recovery](https://aws.amazon.com/partners/find/results/?keyword=Disaster+Recovery)
**Video correlati:**
+ [AWS re:Invent 2018: Architecture Patterns for Multi-Region Active-Active Applications (ARC209-R2)](https://youtu.be/2e29I3dA8o4)
+ [AWS re:Invent 2022: AWS On Air ft. AWS Failback for AWS Elastic Disaster Recovery](https://youtu.be/Ok-vpV8b1Hs)