# 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)