Definizione della strategia di ripristino di emergenza

A seconda dell'importanza delle applicazioni dell'azienda, è possibile scegliere una strategia uniforme per tutte le applicazioni o sviluppare una strategia di ripristino di emergenza più complessa basata sulla criticità di ciascuna applicazione. L'organizzazione potrebbe tollerare un periodo di inattività di diverse ore prima che tutte le applicazioni vengano ripristinate nel sito di ripristino di emergenza. In questo caso, puoi optare per una strategia di ripristino di emergenza economica basata sul backup e sul ripristino di tutti i database. D'altra parte, l'attività dell'organizzazione potrebbe dipendere dalla rapida disponibilità di alcuni servizi o applicazioni fondamentali, con requisiti RPO e RTO più stringenti, mentre altre applicazioni potrebbero tollerare esigenze meno rigorose. In questo caso, dovrai assegnare la giusta strategia di ripristino di emergenza per ogni livello di applicazioni e database.

La tabella seguente descrive quattro opzioni di DR per i carichi di lavoro eseguiti in Cloud AWS, per aiutarti a determinare e definire la strategia di DR dell'organizzazione. Gli obiettivi RPO e RTO documentati in questa tabella si riferiscono a uno stack completo che include sia i componenti dell'applicazione che quelli del database. Per ulteriori informazioni, consulta Opzioni di disaster recovery nel cloud nella documentazione di AWS Well-Architected Framework. La sezione successiva illustra le opzioni di RPO e RTO specifiche per i database.

Opzione di ripristino	RPO	RTO	Attività infrastrutturali nella regione di ripristino di emergenza	Costo
Backup e ripristino	Ore	Inferiore a 24 ore	Eseguire il provisioning di tutte le risorse applicative richieste nella regione di ripristino di emergenza e ripristinare il database da uno snapshot copiato.	Bassa
Pilot light	Decine di minuti	Decine di minuti	Eseguire il provisioning di una copia dell'infrastruttura dell'applicazione e disattivare le risorse nel relativo stack. Replicare i dati da una regione all'altra. Mantenere i database sempre attivi e sincronizzati con i database primari. Fornire le risorse su richiesta durante il failover e l'evento di test. È inoltre necessario implementare le modifiche apportate all'infrastruttura e alle applicazioni in entrambe le regioni contemporaneamente. È possibile semplificare questa operazione tramite la creazione di pipeline di automazione in grado di sincronizzare codice e infrastruttura sia nelle regioni primarie che in quelle di ripristino di emergenza.	Media
Warm standby	Minuti	Minuti	Effettuare il provisioning di una copia dell'intera infrastruttura dell'applicazione nella regione di ripristino di emergenza, ma mantenere la copia dimensionata rispetto alla regione principale. La regione di ripristino di emergenza potrà accettare il traffico a un volume inferiore rispetto alla regione principale.	Elevata
Multisito o attivo/attivo	Vicino allo zero	Zero o vicino allo zero	Effettuare il provisioning di una copia completa dell'infrastruttura nella regione di ripristino di emergenza. Tutte le risorse nella regione di ripristino di emergenza saranno equivalenti a quelle della regione principale. Inoltre, saranno in grado di servire il traffico con lo stesso dimensionamento rispetto della regione principale. Poiché non vi è alcuna interruzione nel flusso di traffico, questa opzione non richiede un'attività di failover come parte del piano di ripristino di emergenza.	Più alto