{"id":5955,"date":"2023-06-23T10:06:03","date_gmt":"2023-06-23T08:06:03","guid":{"rendered":"https:\/\/blog.besharp.it\/?p=5955"},"modified":"2023-06-23T10:15:31","modified_gmt":"2023-06-23T08:15:31","slug":"best-practices-per-strategie-di-disaster-recovery-da-aws-verso-aws","status":"publish","type":"post","link":"https:\/\/blog.besharp.it\/it\/best-practices-per-strategie-di-disaster-recovery-da-aws-verso-aws\/","title":{"rendered":"Best practices per strategie di Disaster Recovery da AWS verso AWS"},"content":{"rendered":"\n

Leggi Parte 1<\/a> | Leggi Parte 2<\/a><\/p>\n\n\n\n

Questo \u00e8  il terzo e ultimo capitolo della serie sul Disaster Recovery. nalizzeremo come varia il concetto di  disaster recovery e quali tecniche adottare se la nostra infrastruttura di produzione si trova gi\u00e0 sul  Cloud di AWS.<\/p>\n\n\n\n

AWS \u00e8 responsabile della resilienza dell’infrastruttura fisica che sta alla base di tutti i servizi offerti, mentre il cliente ha la responsabilit\u00e0 in base ai servizi che si selezionano. Per esempio, un servizio come Amazon Elastic Compute Cloud (Amazon EC2) richiede di eseguire tutte le necessarie configurazioni e attivit\u00e0 di gestione per la resilienza. Infatti, \u00e8 il cliente che si deve occupare di sfruttare le Availability Zones che AWS ci mette a disposizione per poter ottenere l\u2019alta disponibilit\u00e0. Per i servizi gestiti, come Amazon S3 e Amazon DynamoDB, AWS gestisce l’infrastruttura, il sistema operativo e le piattaforme, mentre i clienti sono responsabili dei dati, comprese le strategie di backup, versioning e replica.Questo concetto si pu\u00f2 riassumere in poche parole dicendo che AWS<\/strong> \u00e8 responsabile della resilienza DEL Cloud<\/strong> e il cliente<\/strong> \u00e8 responsabile della resilienza NEL Cloud<\/strong>.<\/p>\n\n\n\n

<\/p>\n\n\n

\n
\"courtesy
Courtesy of AWS<\/figcaption><\/figure><\/div>\n\n\n

<\/p>\n\n\n\n

Quindi avere i propri workload nel Cloud non comporta che possiamo dimenticarci di resilienza e business continuity. Anzi, dobbiamo capire come cambia il concetto di disastro. <\/p>\n\n\n\n

I tipo di \u201cdisastro\u201d sul Cloud<\/h3>\n\n\n\n

Normalmente si cerca di classificare in diverse categorie le differenti tipologie di disastro.<\/p>\n\n\n\n

    \n
  1. Guasti hardware o software: questo pu\u00f2 includere il fallimento di server, dispositivi di archiviazione, switch di rete o componenti critici del sistema. Interruzioni di rete: un’interruzione della connettivit\u00e0 pu\u00f2 essere causata da problemi di rete, errori di configurazione o interruzioni dei provider di servizi di rete. In questi casi, \u00e8 necessario ripristinare la connettivit\u00e0 per garantire l’accesso alle risorse e alle applicazioni Cloud.<\/li>\n\n\n\n
  2. Disastri naturali: eventi come terremoti, alluvioni, incendi o tempeste possono causare danni fisici agli edifici o ai data center, compromettendo l’infrastruttura IT. In questi casi, \u00e8 necessario ripristinare l’ambiente IT in un’area geograficamente diversa.<\/li>\n\n\n\n
  3. Errori umani: errori umani, come l’eliminazione accidentale di dati critici o la configurazione errata di un’applicazione, possono causare interruzioni e perdite di dati. <\/li>\n\n\n\n
  4. Attacchi informatici: gli attacchi informatici, come gli attacchi ransomware, possono compromettere la sicurezza dei dati e dei sistemi. <\/li>\n<\/ol>\n\n\n\n

    Nel Cloud al verificarsi di eventi catastrofici \u00e8 AWS a occuparsi di ripristinare la propria infrastruttura fisica, mentre noi dobbiamo occuparci di mantenere i servizi attivi. Per alcune tipologie di eventi, errori umani e attacchi informatici, dobbiamo essere noi a prenderci cura anche del ripristino, oltre che della Business Continuity.<\/p>\n\n\n\n

    Nel Cloud gli attacchi informatici acquisiscono una nuova sfaccettatura in quanto questo ambiente \u00e8 programmabile attraverso chiamate ad API pubbliche. La corretta configurazione secondo best practices di AWS IAM (rotazione credenziali, MFA, password sicure, ecc..) \u00e8 utile al fine di fare prevenzione, ma non basta: a volte sono gli errori umani a stravolgere lo scenario. Si pensi per esempio, al furto delle credenziali da parte di malintenzionati che cos\u00ec, con uno script, possono sospendere il funzionamento dei nostri servizi.<\/p>\n\n\n\n

    Mettendo insieme tutti questi concetti capiamo quanto fondamentale sia progettare bene anche il Disaster Recovery da Cloud a Cloud. <\/p>\n\n\n\n

    Disaster Recovery AWS-to-AWS<\/h2>\n\n\n\n

    Implementare strategie di Disaster recovery su AWS significa utilizzare differenti AWS Region<\/strong> per tutti gli eventi di interruzione dovuti ad hardware, rete e\/o disastri naturali e significa anche utilizzare, contestualmente, differenti sottoscrizioni<\/strong> (AWS le chiama Account) per essere resilienti ad attacchi informatici e\/o errori umani.<\/p>\n\n\n\n

    Concentriamoci innanzitutto sulla selezione della Region secondaria. <\/p>\n\n\n\n

    In questo caso dobbiamo tenere presente che non tutti i servizi AWS sono presenti in tutte le Region<\/strong>, quindi prima di scegliere dobbiamo assicurarci che siano presenti tutte le componenti che sfruttiamo nel nostro sito primario. <\/p>\n\n\n\n

    Altro punto da considerare sono le quote di servizio<\/strong>. Le quote sono presenti per evitare di effettuare accidentalmente il provisioning di pi\u00f9 risorse di quelle necessarie e limitare i tassi di richiesta sulle operazioni API in modo da proteggere i servizi da un uso illecito. Le quote si possono aumentare tramite apertura di ticket di supporto fornendo le motivazioni e aspettando l\u2019intervento del provider. Se abbiamo chiesto degli incrementi di quote nel nostro sito di produzione, dobbiamo ricordarci di richiederli anche per il sito di disaster recovery altrimenti rischieremmo di avere un\u2019infrastruttura funzionante, ma non in grado di reggere il traffico.<\/p>\n\n\n\n

    Particolare attenzione, come sempre, va prestata ai costi<\/strong>. Sia la selezione della Region, che \u00e8 soggetta a differenti legislazioni e regimi fiscali degli stati, sia la strategia di replica dei dati, influiscono sull\u2019impatto economico.<\/p>\n\n\n\n

    Le fasi del ripristino<\/h2>\n\n\n\n

    Una buona strategia di disaster recovery prevede, quindi, di valutare ambiente, tempistiche e costi. La strategia va poi declinata in diverse fasi: rilevamento<\/strong>, ripristino<\/strong> e failover<\/strong>. Per adesso il failback lo lasciamo da parte. Queste tre fasi vanno considerate nella definizione di RTO: a valle di un disastro impieghiamo del tempo per accorgerci dell\u2019evento, altro tempo per attivare le nostre risorse e altro tempo per dirottare il traffico.<\/p>\n\n\n\n

    <\/p>\n\n\n

    \n
    \"\"
    Courtesy of AWS<\/figcaption><\/figure><\/div>\n\n\n

    <\/p>\n\n\n\n

    Al fine di ridurre il tempo di ripristino, la fase di rilevamento (o detection) andrebbe automatizzata. Non bisogna aspettare che qualcuno si accorga del disastro, dobbiamo anticipare i nostri clienti. <\/p>\n\n\n\n

    Per esempio, Amazon Event Bridge<\/strong> supporta le varie tipologie di eventi presenti nei servizi AWS e anche i trigger per le remediation. Tra gli eventi supportati ci sono quelli dei Cloud Watch Alarms che possiamo configurare sulle metriche che definiamo noi. Otteniamo cos\u00ec degli health check specifici basati sul funzionamento dei nostri workload. <\/p>\n\n\n\n

    Come detto in precedenza, esistono eventi che impattano direttamente AWS che ci notifica tramite la Personal Health Dashboard. Event Bridge supporta anche questo tipo di eventi.<\/p>\n\n\n\n

    Per ripristinare l’infrastruttura nella Region di ripristino \u00e8 fortemente consigliato l\u2019utilizzo del paradigma dell’Infrastructure as Code (IaC)<\/em>. Questo include AWS CloudFormation<\/strong> e AWS Cloud Development Kit (AWS CDK)<\/strong> per creare in modo coerente l’infrastruttura sia nel sito primario che secondario. <\/p>\n\n\n\n

    Nella Region (e nell’account) di ripristino dobbiamo quindi trovare tutte le configurazioni di base, dal networking alle immagini delle nostre istanze o container. Per le EC2, sfruttiamo le AMI per incorporare il sistema operativo e i pacchetti necessari e automatizziamo la loro creazione e la distribuzione. Dato che le AMI contengono gli snapshot dei volumi, possiamo temporizzare il processo per avere una copia sempre pi\u00f9 recente. Stesso principio vale per i container e sfruttando Elastic Container Registry (ECR) \u00e8 possibile pubblicare le immagini replicandole in entrambi gli ambienti.<\/p>\n\n\n\n

    Per poter fare il ripristino anche i dati vanno replicati. Per esempio, se abbiamo file su S3 \u00e8 possibile configurare la cross-account e cross-region bucket replication<\/strong> che ci permette di tenere in sync i file da entrambe le parti. <\/p>\n\n\n\n

    Piccolo consiglio: i bucket devono avere per forza nomi diversi, ricordatevi di configurare il vostro applicativo per utilizzare puntamenti diversi in caso di failover.<\/p>\n\n\n\n

    Per quanto riguarda i database possiamo usare la stessa tecnica utilizzata per le EC2 sfruttando gli snapshot copiandoli e portandoli nel sito di disaster recovery. Se l\u2019RPO del nostro workload \u00e8 molto stringente allora dovremo appoggiarsi a strumenti che tengono in sync il database di produzione con il secondario.  <\/p>\n\n\n\n

    In generale un ottimo strumento per mettere a terra il nostro DR \u00e8 AWS Backup<\/strong> che ci permette di configurare la frequenza con cui facciamo i backup e di distribuirli cross-region e cross-account.<\/p>\n\n\n\n

    Infine con la fase di failover il traffico viene rediretto sull\u2019infrastruttura di DR. In questo caso viene in nostro soccorso Amazon Route53 <\/strong>tramite il quale configuriamo il DNS utilizzando una policy di routing di failover con controlli di stato (Health Check). Usare i controlli di stato \u00e8 fondamentale per poter automatizzare la redirezione degli utenti verso l\u2019infrastruttura secondaria.<\/p>\n\n\n\n

    Conclusioni<\/h2>\n\n\n\n

    Siamo giunti alla fine di questa serie di 3 articoli dedicati al  Disaster Recovery in cui abbiamo visto come garantire la continuit\u00e0 del business sia in ambienti ibridi, che in ecosistemi fully Cloud. <\/p>\n\n\n\n

    In particolare abbiamo visto come l’utilizzo dei servizi AWS in questo contesto offra numerosi vantaggi, tra cui la garanzia di resilienza, scalabilit\u00e0 e sicurezza delle infrastrutture, la disponibilit\u00e0 di strumenti avanzati per la protezione dei dati e la gestione semplificata delle risorse e dei costi. <\/p>\n\n\n\n

    Come emerge da questa nostra panoramica, tuttavia, esiste un aspetto critico che nessun provider, servizio o tecnologia possono gestire e che richiede quindi da parte delle aziende particolare attenzione, ovvero la pianificazione di una strategia di Disaster Recovery realmente disruption-proof. Per pianificare la strategia migliore per la propria organizzazione, infatti, oltre a conoscere i building block utili allo scopo, occorre comprendere appieno i concetti su cui tali strategie si basano, cosa si intende per responsabilit\u00e0 condivise e quali sono all\u2019interno di ciascuna organizzazione e seguire best practices appropriate per affrontare con successo i diversi tipi di disastro. Va inoltre considerato che ciascuna strategia implementata richiede attenzione costante e un’adeguata gestione dei rischi e che il suo mantenimento resti un processo continuativo e in costante evoluzione.<\/p>\n\n\n\n

    In questa serie abbiamo cercato di porre l\u2019accento proprio sulla criticit\u00e0 di tutto ci\u00f2 e speriamo di avervi dato un punto di vista pi\u00f9 completo su questo aspetto spesso sottovalutato in molte realt\u00e0.<\/p>\n\n\n\n

    Avete avuto esperienze di cui volete discutere? Aspettiamo le vostre testimonianze! <\/p>\n\n\n\n

    A presto con un nuovo articolo su Proud2beCloud<\/strong>!<\/p>\n\n\n\n

    Leggi Parte 1<\/a> | Leggi Parte 2<\/a><\/p>\n\n\n\n

    Related resources:<\/h3>\n\n\n\n