# Affidabilità
**Topics**
+ [Fondamenti](a-foundations.md)
+ [Architettura del carico di lavoro](a-workload-architecture.md)
+ [Gestione delle modifiche](a-change-management.md)
+ [Gestione degli errori](a-failure-management.md)
# Fondamenti
**Topics**
+ [REL 1 In che modo gestisci quote e vincoli di servizio?](w2aac19b9b5b5.md)
+ [REL 2 In che modo pianifichi la topologia di rete?](w2aac19b9b5b7.md)
# REL 1 In che modo gestisci quote e vincoli di servizio?
Per le architetture di carichi di lavoro basate sul cloud, esistono quote di servizio (definite anche come restrizioni dei servizi). Queste quote sono presenti per evitare di effettuare accidentalmente il provisioning di più risorse di quelle necessarie e limitare i tassi di richiesta sulle operazioni API in modo da proteggere i servizi da un uso illecito. Esistono anche vincoli di risorse, ad esempio la velocità con cui è possibile trasferire i bit su un cavo in fibra ottica o la quantità di storage su un disco fisico.
**Topics**
+ [REL01-BP01 Consapevolezza su quote e vincoli di servizio](rel_manage_service_limits_aware_quotas_and_constraints.md)
+ [REL01-BP02 Gestione delle quote di servizio in più account e regioni](rel_manage_service_limits_limits_considered.md)
+ [REL01-BP03 Adattamento di quote e vincoli di servizio fissi mediante l'architettura](rel_manage_service_limits_aware_fixed_limits.md)
+ [REL01-BP04 Monitoraggio e gestione delle quote](rel_manage_service_limits_monitor_manage_limits.md)
+ [REL01-BP05 Automazione della gestione delle quote](rel_manage_service_limits_automated_monitor_limits.md)
+ [REL01-BP06 Creazione di un divario sufficiente tra le quote attuali e l'utilizzo massimo per consentire eventuali failover](rel_manage_service_limits_suff_buffer_limits.md)
# REL01-BP01 Consapevolezza su quote e vincoli di servizio
Conosci le quote predefinite e le richieste di aumento delle quote per l'architettura del carico di lavoro. Inoltre, sai quali vincoli delle risorse, ad esempio disco o rete, sono potenzialmente influenti.
Service Quotas è un servizio AWS che ti aiuta a gestire le quote per oltre 100 servizi AWS da un'unica posizione. Oltre a cercare i valori delle quote, puoi anche richiedere e monitorare gli aumenti delle quote stesse tramite la console Service Quotas o tramite l'SDK AWS. AWS Trusted Advisor offre un controllo delle quote di servizio che mostra l'utilizzo e le quote per alcuni aspetti di determinati servizi. Le quote predefinite per ciascun servizio sono riportate anche nella rispettiva documentazione di AWS. Consulta ad esempio [le quote di Amazon VPC](https://docs.aws.amazon.com/vpc/latest/userguide/amazon-vpc-limits.html). I limiti di velocità sulle API con throttling vengono impostati all'interno del API Gateway stesso configurando un piano di utilizzo. Altri limiti impostati come configurazione per i rispettivi servizi includono Provisioned IOPS, storage RDS allocato e allocazioni di volumi EBS. Amazon Elastic Compute Cloud (Amazon EC2) dispone di un proprio pannello di controllo sui limiti del servizio che consente di gestire l'istanza, Amazon Elastic Block Store (Amazon EBS) e i limiti degli indirizzi IP elastici. Se hai un caso d'uso in cui le quote di servizio influiscono sulle prestazioni della tua applicazione e non sono adattabili alle tue esigenze, contatta Supporto AWS per vedere se sono possibili riduzioni.
**Anti-pattern comuni:**
+ Implementazione di un carico di lavoro senza tenere conto delle quote di servizio sui servizi AWS utilizzati.
+ Progettazione di un carico di lavoro senza esaminare e soddisfare i vincoli di progettazione dei servizi AWS.
+ Implementazione di un carico di lavoro con un utilizzo significativo che sostituisce un carico di lavoro noto esistente senza contattare Supporto AWS in anticipo.
+ Pianificazione di un evento per indirizzare il traffico verso il carico di lavoro, ma senza configurare le quote necessarie o contattare Supporto AWS in anticipo.
**Vantaggi dell'adozione di questa best practice:** Essere a conoscenza delle quote di servizio, dei limiti di throttling delle API e dei vincoli di progettazione ti consentirà di tenerne conto nella progettazione, nell'implementazione e nel funzionamento del carico di lavoro.
**Livello di rischio associato se questa best practice non fosse adottata:** Alta
## Guida all'implementazione
+ Esamina le quote dei servizi AWS nella documentazione pubblicata e in Service Quotas
+ [AWS Service Quotas (precedentemente note come restrizioni dei servizi)](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html)
+ Stabilisci tutti i servizi necessari per il tuo carico di lavoro analizzando il codice di implementazione.
+ Utilizza AWS Config per trovare tutte le risorse AWS utilizzate in Account AWS.
+ [Tipi di risorse e relazioni tra risorse AWS Config supportate da AWS](https://docs.aws.amazon.com/config/latest/developerguide/resource-config-reference.html)
+ Puoi anche utilizzare AWS CloudFormation per individuare le risorse AWS utilizzate. Esamina le risorse create nella Console di gestione AWS o tramite il comando list-stack-resources dell'interfaccia a riga di comando. Puoi anche visualizzare le risorse configurate per essere distribuite nel modello stesso.
+ [Visualizzazione delle risorse e dei dati dello stack AWS CloudFormation sulla Console di gestione AWS](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/cfn-console-view-stack-data-resources.html)
+ [AWS CLI per CloudFormation: list-stack-resources](https://docs.aws.amazon.com/cli/latest/reference/cloudformation/list-stack-resources.html)
+ Determina le quote di servizio applicabili. Utilizza le informazioni accessibili in modo programmatico tramite Trusted Advisor e Service Quotas.
## Risorse
**Documenti correlati:**
+ [Marketplace AWS: prodotti CMDB per il monitoraggio delle restrizioni](https://aws.amazon.com/marketplace/search/results?searchTerms=CMDB)
+ [AWS Service Quotas (precedentemente note come restrizioni dei servizi)](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html)
+ [Elenco di controllo delle best practice di AWS Trusted Advisor (consulta la sezione Restrizioni dei servizi)](https://aws.amazon.com/premiumsupport/technology/trusted-advisor/best-practice-checklist/)
+ [AWS limit monitor on AWS answers (Monitoraggio quota AWS su risposte AWS)](https://aws.amazon.com/answers/account-management/limit-monitor/)
+ [Quote di servizio di Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-resource-limits.html)
+ [What is Service Quotas? (Che cos'è Service Quotas?)](https://docs.aws.amazon.com/servicequotas/latest/userguide/intro.html)
**Video correlati:**
+ [AWS Live re:Inforce 2019 - Service Quotas](https://youtu.be/O9R5dWgtrVo)
# REL01-BP02 Gestione delle quote di servizio in più account e regioni
Se utilizzi più Account AWS o Regioni AWS, assicurati di richiedere le quote appropriate in tutti gli ambienti in cui vengono eseguiti i carichi di lavoro di produzione.
Le quote di servizio vengono monitorate per account. Salvo diversa indicazione, ogni quota è specifica della Regione AWS. Oltre agli ambienti di produzione, gestisci anche le quote in tutti gli ambienti non di produzione applicabili, in modo che i test e lo sviluppo non siano ostacolati.
**Anti-pattern comuni:**
+ Consentire l'aumento dell'utilizzo delle risorse in una zona di isolamento senza alcun meccanismo per mantenere la capacità nelle altre.
+ Impostazione manuale di tutte le quote in modo indipendente nelle zone di isolamento.
+ Non avere la garanzia che le implementazioni isolate a livello regionale siano dimensionate per accogliere l'aumento del traffico da un'altra regione in caso di perdita di un'implementazione.
**Vantaggi dell'adozione di questa best practice:** Avere la garanzia di poter gestire il carico corrente se una zona di isolamento non è disponibile può aiutare a ridurre il numero di errori che si verificano durante il failover, invece di causare un denial of service ai clienti.
**Livello di rischio associato se questa best practice non fosse adottata:** Alta
## Guida all'implementazione
+ Seleziona gli account e le regioni pertinenti in base ai tuoi requisiti di servizio, di latenza, normativi e di ripristino di emergenza.
+ Identifica le quote dei servizi per tutti gli account, le regioni e le zone di disponibilità pertinenti. Le restrizioni si riferiscono ad account e regione.
+ [What is Service Quotas? (Che cos'è Service Quotas?)](https://docs.aws.amazon.com/servicequotas/latest/userguide/intro.html)
## Risorse
**Documenti correlati:**
+ [Marketplace AWS: prodotti CMDB per il monitoraggio delle restrizioni](https://aws.amazon.com/marketplace/search/results?searchTerms=CMDB)
+ [AWS Service Quotas (precedentemente note come restrizioni dei servizi)](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html)
+ [Elenco di controllo delle best practice di AWS Trusted Advisor (consulta la sezione Restrizioni dei servizi)](https://aws.amazon.com/premiumsupport/technology/trusted-advisor/best-practice-checklist/)
+ [AWS limit monitor on AWS answers (Monitoraggio quota AWS su risposte AWS)](https://aws.amazon.com/answers/account-management/limit-monitor/)
+ [Quote di servizio di Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-resource-limits.html)
+ [What is Service Quotas? (Che cos'è Service Quotas?)](https://docs.aws.amazon.com/servicequotas/latest/userguide/intro.html)
**Video correlati:**
+ [AWS Live re:Inforce 2019 - Service Quotas](https://youtu.be/O9R5dWgtrVo)
# REL01-BP03 Adattamento di quote e vincoli di servizio fissi mediante l'architettura
Considera le quote di servizio immutabili e le risorse fisiche e progetta per evitare che queste compromettano l'affidabilità.
Alcuni esempi includono larghezza di banda di rete, dimensioni di payload di AWS Lambda, velocità di ottimizzazione del throttling per API Gateway e connessioni utente simultanee a un cluster Amazon Redshift.
**Anti-pattern comuni:**
+ Eseguire il benchmarking per un periodo di tempo troppo breve, utilizzando il limite di picco, ma aspettandosi poi che il servizio mantenga tale capacità per periodi prolungati.
+ Scegliere un progetto che utilizza una risorsa di un servizio per utente o cliente, ignorando che ci sono vincoli di progettazione che causeranno un errore durante il dimensionamento.
**Vantaggi dell'adozione di questa best practice:** monitorare le quote fisse nei servizi AWS e i vincoli in altre parti del carico di lavoro, ad esempio vincoli di connettività, vincoli di indirizzo IP e vincoli nei servizi di terze parti, ti consente di capire quando ti stai avvicinando a una quota e di gestirla prima che venga superata.
**Livello di rischio associato se questa best practice non fosse adottata:** Medium
## Guida all'implementazione
+ Essere consapevoli delle quote di servizio fisse Essere consapevoli delle quote di servizio fisse e dei vincoli e progettare in base a questi.
+ [AWS Service Quotas](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html)
## Risorse
**Documenti correlati:**
+ [Marketplace AWS: prodotti CMDB per il monitoraggio delle restrizioni](https://aws.amazon.com/marketplace/search/results?searchTerms=CMDB)
+ [AWS Service Quotas (precedentemente note come restrizioni dei servizi)](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html)
+ [Elenco di controllo delle best practice di AWS Trusted Advisor (consulta la sezione Restrizioni dei servizi)](https://aws.amazon.com/premiumsupport/technology/trusted-advisor/best-practice-checklist/)
+ [AWS limit monitor on AWS answers (Monitoraggio quota AWS su risposte AWS)](https://aws.amazon.com/answers/account-management/limit-monitor/)
+ [Quote di servizio di Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-resource-limits.html)
+ [Che cos'è Service Quotas?](https://docs.aws.amazon.com/servicequotas/latest/userguide/intro.html)
**Video correlati:**
+ [AWS Live re:Inforce 2019 - Service Quotas](https://youtu.be/O9R5dWgtrVo)
# REL01-BP04 Monitoraggio e gestione delle quote
Valuta il tuo utilizzo potenziale e aumenta le quote in modo appropriato per una crescita pianificata dell'utilizzo.
Per i servizi supportati, puoi gestire le quote configurando gli allarmi CloudWatch affinché monitorino l'utilizzo e ti inviino una notifica in caso di raggiungimento delle quote. Questi allarmi possono essere attivati da Service Quotas o da Trusted Advisor. Puoi anche utilizzare i filtri dei parametri su CloudWatch Logs per cercare ed estrarre modelli nei log al fine di determinare se l'utilizzo è vicino alle soglie delle quote.
**Anti-pattern comuni:**
+ Configurare avvisi che si attivano quando le Service Quotas stanno per essere raggiunte, ma senza avere alcun processo sulle modalità di risposta a un avviso.
+ Configurare allarmi solo per i servizi supportati da Service Quotas, escludendo il monitoraggio di altri servizi.
**Vantaggi dell'adozione di questa best practice:** il monitoraggio automatico delle quote di servizio AWS e il monitoraggio dell'utilizzo rispetto a tali quote ti consentiranno di sapere quando stai per raggiungere il limite di una quota. Puoi anche utilizzare questi dati di monitoraggio per valutare quando puoi ridurre le quote per ridurre i costi.
**Livello di rischio associato se questa best practice non fosse adottata:** Medium
## Guida all'implementazione
+ Monitora e gestisci le quote Valuta l'utilizzo potenziale su AWS, aumenta le quote dei servizi regionali in modo appropriato e consenti una crescita pianificata dell'utilizzo.
+ Acquisisci l'attuale consumo di risorse, ad esempio bucket e istanze. Utilizza le operazioni delle API di servizi come l'API DescribeInstances di Amazon EC2 per raccogliere informazioni sul consumo attuale delle risorse.
+ Acquisisci le quote correnti Utilizza la documentazione di AWS Service Quotas, AWS Trusted Advisor e AWS.
+ AWS Service Quotas è un servizio AWS che ti aiuta a gestire le quote per oltre 100 servizi AWS da un'unica posizione.
+ Utilizza le restrizioni dei servizi di Trusted Advisor per determinare le restrizioni dei servizi attuali.
+ Utilizza le operazioni delle API di servizi per determinare le attuali quote di servizio, quando supportate.
+ Tieni un registro degli aumenti di quota richiesti e del loro stato Dopo l'approvazione di un aumento di quota, assicurati di aggiornare i registri per riflettere la modifica della quota.
## Risorse
**Documenti correlati:**
+ [Marketplace AWS: prodotti CMDB per il monitoraggio delle restrizioni](https://aws.amazon.com/marketplace/search/results?searchTerms=CMDB)
+ [AWS Service Quotas (precedentemente note come restrizioni dei servizi)](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html)
+ [Controlli delle best practice AWS Trusted Advisor per i limiti del servizio](https://docs.aws.amazon.com/awssupport/latest/user/service-limits.html)
+ [AWS limit monitor on AWS answers (Monitoraggio quota AWS su risposte AWS)](https://aws.amazon.com/answers/account-management/limit-monitor/)
+ [Quote di servizio di Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-resource-limits.html)
+ [Che cos'è Service Quotas?](https://docs.aws.amazon.com/servicequotas/latest/userguide/intro.html)
+ [Monitora Service Quotas utilizzando allarmi Amazon CloudWatch](https://docs.aws.amazon.com/servicequotas/latest/userguide/configure-cloudwatch.html)
**Video correlati:**
+ [AWS Live re:Inforce 2019 - Service Quotas](https://youtu.be/O9R5dWgtrVo)
# REL01-BP05 Automazione della gestione delle quote
Implementa strumenti per ricevere avvisi quando le soglie stanno per essere raggiunte. Puoi automatizzare le richieste di aumento delle quote utilizzando le API AWS Service Quotas.
Se integri il tuo database di gestione della configurazione (CMDB) o il sistema di ticketing con le Service Quotas, puoi automatizzare il monitoraggio delle richieste di aumento delle quote e delle quote correnti. Oltre all'SDK AWS, Service Quotas offre automazione utilizzando AWS Command Line Interface (AWS CLI).
**Anti-pattern comuni:**
+ Monitoraggio delle quote e dell'utilizzo nei fogli di calcolo.
+ Esecuzione di report sull'utilizzo giornaliero, settimanale o mensile e successivo confronto dell'utilizzo con le quote.
**Vantaggi dell'adozione di questa best practice:** Il monitoraggio automatico delle quote di servizio AWS e il monitoraggio dell'utilizzo rispetto a tale quota ti consentiranno di sapere quando stai per raggiungere una quota. Puoi configurare l'automazione affinché ti aiuti a richiedere un aumento della quota quando necessario. Puoi decidere di ridurre alcune quote quando il tuo utilizzo tende alla direzione opposta per ottenere i vantaggi di riduzione del rischio (in caso di credenziali compromesse) e dei costi.
**Livello di rischio associato se questa best practice non fosse adottata:** Medium
## Guida all'implementazione
+ Impostazione del monitoraggio automatico: implementa strumenti utilizzando gli SDK per ricevere avvisi quando le soglie stanno per essere raggiunte.
+ Utilizza Service Quotas e potenzia il servizio con una soluzione di monitoraggio automatico delle quote come AWS Limit Monitor o un'offerta di Marketplace AWS.
+ [What is Service Quotas? (Che cos'è Service Quotas?)](https://docs.aws.amazon.com/servicequotas/latest/userguide/intro.html)
+ [Monitoraggio delle quota su AWS – Soluzione AWS](https://aws.amazon.com/answers/account-management/limit-monitor/)
+ Impostazione di risposte attivate in base alle soglie delle quote tramite l'utilizzo delle API di Amazon SNS e AWS Service Quotas.
+ Automazione dei test.
+ Configura le soglie delle restrizioni.
+ Integrazione con eventi di modifica di AWS Config, pipeline di implementazione, Amazon EventBridge o terze parti.
+ Imposta artificialmente soglie basse per le quote in modo da testare le risposte.
+ Configura i trigger per eseguire azioni adeguate in seguito alle notifiche e contatta Supporto AWS se necessario.
+ Attiva manualmente gli eventi di modifica.
+ Esegui una giornata di gioco per testare il processo di modifica dell'aumento delle quote.
## Risorse
**Documenti correlati:**
+ [Partner APN: partner per la gestione della configurazione](https://aws.amazon.com/partners/find/results/?keyword=Configuration+Management)
+ [Marketplace AWS: prodotti CMDB per il monitoraggio delle restrizioni](https://aws.amazon.com/marketplace/search/results?searchTerms=CMDB)
+ [AWS Service Quotas (precedentemente note come restrizioni dei servizi)](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html)
+ [Elenco di controllo delle best practice di AWS Trusted Advisor (consulta la sezione Restrizioni dei servizi)](https://aws.amazon.com/premiumsupport/technology/trusted-advisor/best-practice-checklist/)
+ [Monitoraggio delle quota su AWS – Soluzione AWS](https://aws.amazon.com/answers/account-management/limit-monitor/)
+ [Quote di servizio di Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-resource-limits.html)
+ [What is Service Quotas? (Che cos'è Service Quotas?)](https://docs.aws.amazon.com/servicequotas/latest/userguide/intro.html)
**Video correlati:**
+ [AWS Live re:Inforce 2019 - Service Quotas](https://youtu.be/O9R5dWgtrVo)
# REL01-BP06 Creazione di un divario sufficiente tra le quote attuali e l'utilizzo massimo per consentire eventuali failover
Quando una risorsa presenta un errore, può continuare a essere conteggiata ai fini del raggiungimento delle quote fino a quando non viene terminata correttamente. Assicurati che le quote coprano la sovrapposizione di tutte le risorse non riuscite con sostituzioni prima che le risorse non riuscite vengano terminate. Nel calcolo di questo intervallo dovresti considerare un errore nella zona di disponibilità.
**Anti-pattern comuni:**
+ Impostazione delle quote di servizio in base alle esigenze attuali senza tenere conto degli scenari di failover.
**Vantaggi dell'adozione di questa best practice:** Quando gli eventi hanno un impatto potenziale sulla disponibilità, il cloud consente di implementare strategie per mitigare o recuperare tali eventi. Queste strategie spesso includono la creazione di risorse aggiuntive per sostituire quelle in errore. La tua strategia di quote deve tenere conto di queste risorse aggiuntive.
**Livello di rischio associato se questa best practice non fosse adottata:** Medium
## Guida all'implementazione
+ Assicurati che ci sia un intervallo sufficiente tra la quota di servizio e l'utilizzo massimo per consentire un eventuale failover.
+ Determina le quote di servizio, specificando i pattern di implementazione, i requisiti di disponibilità e la crescita dei consumi.
+ Richiedi aumenti delle quote, se necessario. Pianifica tenendo conto del tempo necessario affinché le richieste di aumento delle quote siano soddisfatte.
+ Determina i requisiti di affidabilità, chiamati anche "numero di 9".
+ Determina gli scenari di errore (ad esempio, perdita di un componente, una zona di disponibilità o una regione).
+ Stabilisci la metodologia di implementazione (ad esempio, canary, blu/verde, rosso/nero o rolling).
+ Includi un buffer appropriato (ad esempio, 15%) rispetto alla restrizione attuale.
+ Pianifica la crescita dei consumi (ad esempio, monitora le tendenze dei consumi).
## Risorse
**Documenti correlati:**
+ [Marketplace AWS: prodotti CMDB per il monitoraggio delle restrizioni](https://aws.amazon.com/marketplace/search/results?searchTerms=CMDB)
+ [AWS Service Quotas (precedentemente note come restrizioni dei servizi)](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html)
+ [Elenco di controllo delle best practice di AWS Trusted Advisor (consulta la sezione Restrizioni dei servizi)](https://aws.amazon.com/premiumsupport/technology/trusted-advisor/best-practice-checklist/)
+ [Quote di servizio di Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-resource-limits.html)
+ [Che cos'è Service Quotas?](https://docs.aws.amazon.com/servicequotas/latest/userguide/intro.html)
**Video correlati:**
+ [AWS Live re:Inforce 2019 - Service Quotas](https://youtu.be/O9R5dWgtrVo)
# REL 2 In che modo pianifichi la topologia di rete?
I carichi di lavoro sono spesso presenti in più ambienti. Questi includono più ambienti cloud (sia pubblicamente accessibili sia privati) e, possibilmente, l'infrastruttura del data center esistente. I piani devono includere considerazioni di rete, ad esempio connettività intrasistema e intersistema, gestione di indirizzi IP pubblici, gestione di indirizzi IP privati e risoluzione dei nomi di dominio.
**Topics**
+ [REL02-BP01 Utilizzo di una connettività di rete a disponibilità elevata per gli endpoint pubblici del carico di lavoro](rel_planning_network_topology_ha_conn_users.md)
+ [REL02-BP02 Esecuzione del provisioning di connettività ridondante tra reti private nel cloud e negli ambienti on-premise.](rel_planning_network_topology_ha_conn_private_networks.md)
+ [REL02-BP03 Verifica che l'allocazione delle sottoreti IP consenta l'espansione e la disponibilità:](rel_planning_network_topology_ip_subnet_allocation.md)
+ [REL02-BP04 Preferire topologie hub-and-spoke rispetto a mesh da-molti-a-molti](rel_planning_network_topology_prefer_hub_and_spoke.md)
+ [REL02-BP05 Applicazione di intervalli di indirizzi IP privati non sovrapposti in tutti gli spazi con indirizzi privati a cui sono connessi](rel_planning_network_topology_non_overlap_ip.md)
# REL02-BP01 Utilizzo di una connettività di rete a disponibilità elevata per gli endpoint pubblici del carico di lavoro
Questi endpoint e il routing verso di essi devono essere altamente disponibili. Per ottenere questo risultato, utilizza DNS ad alta disponibilità, reti di distribuzione di contenuti (CDN), API Gateway, bilanciamento del carico o proxy inversi.
Amazon Route 53, AWS Global Accelerator, Amazon CloudFront, Amazon API Gateway e Elastic Load Balancing (ELB) offrono tutti endpoint pubblici altamente disponibili. Puoi anche scegliere di valutare le appliance software di Marketplace AWS per il bilanciamento del carico e il proxy.
I consumatori del servizio fornito dal carico di lavoro, che siano utenti finali o altri servizi, effettuano richieste su questi endpoint del servizio. Sono disponibili diverse risorse AWS che ti consentono di fornire endpoint a disponibilità elevata.
Elastic Load Balancing fornisce bilanciamento del carico tra le zone di disponibilità, esegue l'instradamento di livello 4 (TCP) o 7 (http/https) e si integra con AWS WAF e con AWS Auto Scaling per contribuire a creare un'infrastruttura con riparazione automatica e assorbire gli aumenti di traffico, mentre rilascia risorse quando questo diminuisce.
Amazon Route 53 è un servizio del sistema di nomi di dominio (DNS) scalabile e altamente disponibile che collega le richieste degli utenti all'infrastruttura in esecuzione in AWS, come istanze Amazon EC2, load balancer Elastic Load Balancing o bucket Amazon S3 e può essere utilizzato anche per instradare gli utenti a un'infrastruttura esterna ad AWS.
AWS Global Accelerator è un servizio a livello di rete che puoi utilizzare per indirizzare il traffico verso endpoint ottimali sulla rete globale AWS.
Gli attacchi DDoS (Distributed Denial of Service) rischiano di chiudere il traffico legittimo e di ridurre la disponibilità per gli utenti. AWS Shield fornisce protezione automatica da questi attacchi senza costi aggiuntivi per gli endpoint del servizio AWS sul carico di lavoro. Puoi potenziare queste caratteristiche con appliance virtuali dei partner APN e di Marketplace AWS per soddisfare le tue esigenze.
**Anti-pattern comuni:**
+ Utilizzo di indirizzi Internet pubblici su istanze o container e gestione della connettività tramite DNS.
+ Utilizzo degli indirizzi del protocollo Internet anziché dei nomi di dominio per l'individuazione dei servizi.
+ Fornitura di contenuti (pagine Web, asset statici, file multimediali) a un'area geografica di grandi dimensioni senza l'utilizzo di una rete di distribuzione di contenuti.
**Vantaggi dell'adozione di questa best practice:** Implementando servizi ad alta disponibilità nel carico di lavoro, ti assicuri che il carico di lavoro sarà disponibile per i tuoi utenti.
**Livello di rischio associato se questa best practice non fosse adottata:** Alta
## Guida all'implementazione
Assicurati di avere una connettività altamente disponibile per gli utenti del carico di lavoro. Amazon Route 53, AWS Global Accelerator, Amazon CloudFront, Amazon API Gateway e Elastic Load Balancing (ELB) forniscono tutti endpoint rivolti al pubblico altamente disponibili. Puoi anche scegliere di valutare le appliance software di Marketplace AWS per il bilanciamento del carico e il proxy.
+ Assicurati di avere una connessione altamente disponibile per i tuoi utenti.
+ Accertati di utilizzare un DNS altamente disponibile per gestire i nomi di dominio degli endpoint delle applicazioni.
+ Se gli utenti accedono alla tua applicazione tramite Internet, utilizza le operazioni delle API di servizio per confermare il corretto utilizzo degli Internet gateway. Assicurati inoltre che le voci delle tabelle di routing per le sottoreti che ospitano gli endpoint dell'applicazione siano corrette.
+ [DescribeInternetGateways](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DescribeInternetGateways.html)
+ [DescribeRouteTables](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DescribeRouteTables.html)
+ Assicurati di utilizzare un proxy inverso o un load balancer altamente disponibile prima dell'applicazione.
+ Se gli utenti accedono all'applicazione tramite l'ambiente on-premise, verifica che la connettività tra quest'ultimo e AWS sia altamente disponibile.
+ Utilizza Route 53 per gestire i nomi di dominio.
+ [Che cos'è Amazon Route 53?](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/Welcome.html)
+ Utilizza un provider DNS di terze parti che soddisfi i tuoi requisiti.
+ Utilizza Elastic Load Balancing.
+ [What is Elastic Load Balancing? (Che cos'è Elastic Load Balancer)](https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/what-is-load-balancing.html)
+ Utilizza un'appliance di Marketplace AWS che soddisfi i tuoi requisiti.
## Risorse
**Documenti correlati:**
+ [Partner APN: partner per la pianificazione della rete](https://aws.amazon.com/partners/find/results/?keyword=network)
+ [Suggerimenti sulla resilienza di AWS Direct Connect](https://aws.amazon.com/directconnect/resiliency-recommendation/)
+ [Marketplace AWS per l'infrastruttura di rete](https://aws.amazon.com/marketplace/b/2649366011)
+ [Whitepaper: Opzioni di connettività di Amazon Virtual Private Cloud](https://docs.aws.amazon.com/whitepapers/latest/aws-vpc-connectivity-options/introduction.html)
+ [Connettività di rete di elevata disponibilità in più data center](https://aws.amazon.com/answers/networking/aws-multiple-data-center-ha-network-connectivity/)
+ [Utilizzo del kit di strumenti di resilienza di Direct Connect per iniziare](https://docs.aws.amazon.com/directconnect/latest/UserGuide/resilency_toolkit.html)
+ [Endpoint VPC e servizi di endpoint VPC (AWS PrivateLink)](https://docs.aws.amazon.com/vpc/latest/userguide/endpoint-services-overview.html)
+ [Che cos'è AWSGlobal Accelerator?](https://docs.aws.amazon.com/global-accelerator/latest/dg/what-is-global-accelerator.html)
+ [Che cos'è Amazon VPC?](https://docs.aws.amazon.com/vpc/latest/userguide/what-is-amazon-vpc.html)
+ [Che cos'è un Transit Gateway?](https://docs.aws.amazon.com/vpc/latest/tgw/what-is-transit-gateway.html)
+ [Che cos'è Amazon CloudFront?](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/Introduction.html)
+ [Che cos'è Amazon Route 53?](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/Welcome.html)
+ [What is Elastic Load Balancing? (Che cos'è Elastic Load Balancer)](https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/what-is-load-balancing.html)
+ [Lavorare con gateway Direct Connect](https://docs.aws.amazon.com/directconnect/latest/UserGuide/direct-connect-gateways.html)
**Video correlati:**
+ [AWS re:Invent 2018: Advanced VPC Design and New Capabilities for Amazon VPC (Progettazione avanzata di VPC e nuove funzionalità per Amazon VPC) (NET303) ](https://youtu.be/fnxXNZdf6ew)
+ [AWS re:Invent 2019: AWS Transit Gateway reference architectures for many VPCs (Architetture di riferimento del Gateway di transito AWS per molte VPC) (NET406-R1)](https://youtu.be/9Nikqn_02Oc)
# REL02-BP02 Esecuzione del provisioning di connettività ridondante tra reti private nel cloud e negli ambienti on-premise.
Utilizza più connessioni AWS Direct Connect o tunnel VPN tra reti private implementate separatamente. Utilizza più ubicazioni Direct Connect per un'elevata disponibilità. Se utilizzi più Regioni AWS, garantisci la ridondanza in almeno due di esse. È possibile valutare le appliance Marketplace AWS che terminano le VPN. Se utilizzi appliance di Marketplace AWS, distribuisci le istanze ridondanti per la disponibilità elevata in diverse zone di disponibilità.
AWS Direct Connect è un servizio cloud che semplifica la creazione di una connessione di rete dedicata dall'ambiente on-premise ad AWS. Utilizzando il gateway Direct Connect, il data center on-premise può essere collegato a più VPC AWS distribuiti in più Regioni AWS.
Questa ridondanza risolve possibili errori che condizionano la resilienza della connettività:
+ Come pensi di essere resiliente ai fallimenti nella topologia?
+ Cosa succede se configuri qualcosa in modo errato e rimuovi la connettività?
+ Sarai in grado di gestire un inaspettato aumento del traffico o dell'utilizzo dei tuoi servizi?
+ Sarai in grado di assorbire un tentativo di attacco DDoS (Distributed Denial of Service)?
Quando si connette il VPC al data center in locale tramite VPN, si devono considerare i requisiti di resilienza e larghezza di banda necessari quando si seleziona la dimensione del fornitore e dell'istanza su cui è necessario eseguire l'appliance. Se si utilizza un'appliance VPN non resiliente nella sua implementazione, è necessario disporre di una connessione ridondante tramite una seconda appliance. Per tutti questi scenari, è necessario definire un orario accettabile per il ripristino e il test per garantire che sia possibile soddisfare tali requisiti.
Se scegli di connettere il VPC al data center utilizzando una connessione Direct Connect e hai bisogno che questa connessione sia altamente disponibile, predisponi connessioni Direct Connect ridondanti da ogni data center. La connessione ridondante dovrebbe utilizzare una seconda connessione Direct Connect da una posizione diversa rispetto alla prima. Se disponi di più data center, assicurati che le connessioni terminino in posizioni diverse. Utilizza il [Kit di strumenti di resilienza Direct Connect](https://docs.aws.amazon.com/directconnect/latest/UserGuide/resiliency_toolkit.html) come ausilio per la configurazione.
Se scegli di eseguire il failover sul VPN su Internet utilizzando Site-to-Site VPN, è importante capire che supporta fino a 1,25 Gbps di velocità di trasmissione effettiva per tunnel VPN, ma non supporta Equal Cost Multi Path (ECMP) per il traffico in uscita nel caso di più tunnel VPN gestiti da AWS che terminano sullo stesso gateway privato virtuale (VGW). Non è consigliabile utilizzare VPN gestite da AWS come backup per le connessioni Direct Connect, a meno che non sia possibile tollerare velocità inferiori a 1 Gbps durante il failover.
Puoi anche utilizzare gli endpoint VPC per connettere privatamente il tuo VPC ai servizi AWS supportati e ai servizi endpoint VPC basati su AWS PrivateLink senza dover attraversare la rete Internet pubblica. Gli endpoint sono dispositivi virtuali. Sono componenti VPC a scalabilità orizzontale, ridondanti e ad alta disponibilità. Consentono la comunicazione tra le istanze nel VPC e i servizi senza imporre rischi di disponibilità o vincoli di larghezza di banda sul traffico di rete.
**Anti-pattern comuni:**
+ Avere un solo provider di connettività tra la rete in locale e AWS.
+ Utilizzare le funzionalità di connettività della connessione AWS Direct Connect, ma con una sola connessione.
+ Disporre di un solo percorso per la connettività VPN.
**Vantaggi dell'adozione di questa best practice:** implementando una connettività ridondante tra il tuo ambiente cloud e l'ambiente aziendale/on-premise, puoi garantire che i servizi dipendenti tra i due ambienti possano comunicare in maniera affidabile.
**Livello di rischio associato se questa best practice non fosse adottata:** Alta
## Guida all'implementazione
+ Garantire una connettività altamente disponibile tra AWS e l'ambiente on-premise. Utilizza più connessioni AWS Direct Connect o tunnel VPN tra reti private implementate separatamente. Utilizza più ubicazioni Direct Connect per un'elevata disponibilità. Se utilizzi più Regioni AWS, garantisci la ridondanza in almeno due di esse. È possibile valutare le appliance Marketplace AWS che terminano le VPN. Se utilizzi appliance di Marketplace AWS, distribuisci le istanze ridondanti per la disponibilità elevata in diverse zone di disponibilità.
+ Assicurati di avere una connessione ridondante con l'ambiente on-premise Potresti aver bisogno di connessioni ridondanti a più Regioni AWS per soddisfare le tue esigenze di disponibilità.
+ [Suggerimenti sulla resilienza di AWS Direct Connect](https://aws.amazon.com/directconnect/resiliency-recommendation/)
+ [Utilizzo di connessioni VPN da sito a sito ridondanti per fornire il failover](https://docs.aws.amazon.com/vpn/latest/s2svpn/VPNConnections.html)
+ Utilizza le operazioni delle API di servizi per identificare l'utilizzo corretto dei circuiti Direct Connect.
+ [DescribeConnections](https://docs.aws.amazon.com/directconnect/latest/APIReference/API_DescribeConnections.html)
+ [DescribeConnectionsOnInterconnect](https://docs.aws.amazon.com/directconnect/latest/APIReference/API_DescribeConnectionsOnInterconnect.html)
+ [DescribeDirectConnectGatewayAssociations](https://docs.aws.amazon.com/directconnect/latest/APIReference/API_DescribeDirectConnectGatewayAssociations.html)
+ [DescribeDirectConnectGatewayAttachments](https://docs.aws.amazon.com/directconnect/latest/APIReference/API_DescribeDirectConnectGatewayAttachments.htmll)
+ [DescribeDirectConnectGateways](https://docs.aws.amazon.com/directconnect/latest/APIReference/API_DescribeDirectConnectGateways.html)
+ [DescribeHostedConnections](https://docs.aws.amazon.com/directconnect/latest/APIReference/API_DescribeHostedConnections.html)
+ [DescribeInterconnects](https://docs.aws.amazon.com/directconnect/latest/APIReference/API_DescribeInterconnects.html)
+ Se esiste una sola connessione Direct Connect o se non ne hai nessuna, crea dei tunnel VPN ridondanti verso i tuoi gateway privati virtuali (VGW).
+ [Cos'è VPN sito-sito AWS?](https://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_VPN.html)
+ Acquisisci la tua attuale connettività (ad esempio, Direct Connect, gateway privati virtuali, appliance Marketplace AWS).
+ Utilizza le operazioni delle API di servizi per eseguire la query della configurazione delle connessioni Direct Connect.
+ [DescribeConnections](https://docs.aws.amazon.com/directconnect/latest/APIReference/API_DescribeConnections.html)
+ [DescribeConnectionsOnInterconnect](https://docs.aws.amazon.com/directconnect/latest/APIReference/API_DescribeConnectionsOnInterconnect.html)
+ [DescribeDirectConnectGatewayAssociations](https://docs.aws.amazon.com/directconnect/latest/APIReference/API_DescribeDirectConnectGatewayAssociations.html)
+ [DescribeDirectConnectGatewayAttachments](https://docs.aws.amazon.com/directconnect/latest/APIReference/API_DescribeDirectConnectGatewayAttachments.htmll)
+ [DescribeDirectConnectGateways](https://docs.aws.amazon.com/directconnect/latest/APIReference/API_DescribeDirectConnectGateways.html)
+ [DescribeHostedConnections](https://docs.aws.amazon.com/directconnect/latest/APIReference/API_DescribeHostedConnections.html)
+ [DescribeInterconnects](https://docs.aws.amazon.com/directconnect/latest/APIReference/API_DescribeInterconnects.html)
+ Utilizza le operazioni delle API di servizi per raccogliere i gateway privati virtuali (VGW) dove vengono utilizzati dalle tabelle di instradamento.
+ [DescribeVpnGateways](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DescribeVpnGateways.html)
+ [DescribeRouteTables](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DescribeRouteTables.html)
+ Utilizza le operazioni delle API di servizi per raccogliere le applicazioni di Marketplace AWS dove vengono utilizzate dalle tabelle di instradamento.
+ [DescribeRouteTables](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DescribeRouteTables.html)
## Risorse
**Documenti correlati:**
+ [Partner APN: partner per la pianificazione della rete](https://aws.amazon.com/partners/find/results/?keyword=network)
+ [Suggerimenti sulla resilienza di AWS Direct Connect](https://aws.amazon.com/directconnect/resiliency-recommendation/)
+ [Marketplace AWS per l'infrastruttura di rete](https://aws.amazon.com/marketplace/b/2649366011)
+ [Whitepaper: Opzioni di connettività di Amazon Virtual Private Cloud](https://docs.aws.amazon.com/whitepapers/latest/aws-vpc-connectivity-options/introduction.html)
+ [Connettività di rete di elevata disponibilità in più data center](https://aws.amazon.com/answers/networking/aws-multiple-data-center-ha-network-connectivity/)
+ [Utilizzo di connessioni VPN da sito a sito ridondanti per fornire il failover](https://docs.aws.amazon.com/vpn/latest/s2svpn/VPNConnections.html)
+ [Utilizzo del kit di strumenti di resilienza di Direct Connect per iniziare](https://docs.aws.amazon.com/directconnect/latest/UserGuide/resilency_toolkit.html)
+ [Endpoint VPC e servizi di endpoint VPC (AWS PrivateLink)](https://docs.aws.amazon.com/vpc/latest/userguide/endpoint-services-overview.html)
+ [Che cos'è Amazon VPC?](https://docs.aws.amazon.com/vpc/latest/userguide/what-is-amazon-vpc.html)
+ [Che cos'è un Transit Gateway?](https://docs.aws.amazon.com/vpc/latest/tgw/what-is-transit-gateway.html)
+ [Cos'è VPN sito-sito AWS?](https://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_VPN.html)
+ [Lavorare con gateway Direct Connect](https://docs.aws.amazon.com/directconnect/latest/UserGuide/direct-connect-gateways.html)
**Video correlati:**
+ [AWS re:Invent 2018: Advanced VPC Design and New Capabilities for Amazon VPC (Progettazione avanzata di VPC e nuove funzionalità per Amazon VPC) (NET303) ](https://youtu.be/fnxXNZdf6ew)
+ [AWS re:Invent 2019: AWS Transit Gateway reference architectures for many VPCs (Architetture di riferimento del Gateway di transito AWS per molte VPC) (NET406-R1)](https://youtu.be/9Nikqn_02Oc)
# REL02-BP03 Verifica che l'allocazione delle sottoreti IP consenta l'espansione e la disponibilità:
Gli intervalli di indirizzi IP dei Amazon VPC devono essere sufficientemente ampi per soddisfare i requisiti del carico di lavoro, tenendo conto anche dell'espansione futura e dell'allocazione degli indirizzi IP alle sottoreti nelle zone di disponibilità. Sono inclusi sistemi di bilanciamento del carico, istanze EC2 e applicazioni basate su container.
Quando si pianifica la topologia di rete, il primo passo è definire lo spazio stesso degli indirizzi IP. Gli intervalli di indirizzi IP privati (secondo le linee guida RFC 1918) dovrebbero essere allocati per ogni VPC. Nell'ambito di questo processo, soddisfa i seguenti requisiti:
+ Lascia spazi per indirizzi IP per più di un VPC per Regione.
+ All'interno di un VPC, lascia spazio per più sottoreti che coprono più zone di disponibilità.
+ Lascia sempre spazio per un blocco CIDR inutilizzato all'interno di un VPC per un'espansione futura.
+ Assicurati che sia disponibile spazio per gli indirizzi IP, al fine di soddisfare le esigenze di qualsiasi parco istanze EC2 transitorio che puoi utilizzare, ad esempio parchi istanze Spot per il machine learning, cluster Amazon EMR o cluster Amazon Redshift.
+ Tieni presente che i primi quattro indirizzi IP e l'ultimo indirizzo IP in ogni blocco CIDR della sottorete sono riservati e non disponibili per l'uso.
+ È consigliabile pianificare la distribuzione di blocchi CIDR VPC di grandi dimensioni. Tieni presente che il blocco CIDR VPC iniziale allocato al VPC non può essere modificato o eliminato, ma puoi aggiungere ulteriori blocchi CIDR non sovrapposti al VPC. I CIDR IPv4 della sottorete non possono essere modificati, mentre ciò è possibile con i CIDR IPv6. Tieni presente che la distribuzione del VPC più grande possibile (/16) genera oltre 65.000 indirizzi IP. Solo nello spazio degli indirizzi IP di base 10.x.x.x potresti effettuare il provisioning di 255 VPC di questo tipo. Pertanto, dovresti peccare per eccesso piuttosto che per difetto per semplificare la gestione dei VPC.
**Anti-pattern comuni:**
+ Creazione di VPC di piccole dimensioni.
+ Creare sottoreti di piccole dimensioni e dover quindi aggiungere sottoreti alle configurazioni man mano che cresci.
+ Stima erronea del numero di indirizzi IP che un elastic load balancer può utilizzare.
+ Distribuzione di numerosi sistemi di bilanciamento del carico a traffico elevato nelle stesse sottoreti.
**Vantaggi dell'adozione di questa best practice:** In questo modo puoi consentire la crescita dei carichi di lavoro e continuare a fornire disponibilità man mano che incrementi le dimensioni.
**Livello di rischio associato se questa best practice non fosse adottata:** Medium
## Guida all'implementazione
+ Pianificazione della rete in base a crescita, compliance normativa e integrazione con altre reti. Senza una pianificazione adeguata, la crescita può essere sottovalutata, la compliance normativa può cambiare e l'implementazione di acquisizioni o di connessioni a reti private può rivelarsi difficile.
+ Seleziona gli Account AWS e le Regioni pertinenti in base ai tuoi requisiti di servizio, di latenza, normativi e di ripristino di emergenza.
+ Identifica le esigenze delle implementazioni di VPC regionali.
+ Identifica le dimensioni dei VPC.
+ Stabilisci se intendi implementare connettività multi-VPC.
+ [Che cos'è un Transit Gateway?](https://docs.aws.amazon.com/vpc/latest/tgw/what-is-transit-gateway.html)
+ [Connettività multi-VPC a singola Regione](https://aws.amazon.com/answers/networking/aws-single-region-multi-vpc-connectivity/)
+ Stabilisci se hai bisogno di reti separate a causa di requisiti normativi.
+ Fai in modo che i VPC abbiano le dimensioni maggiori possibili. Il blocco CIDR VPC iniziale allocato al VPC non può essere modificato o eliminato, ma puoi aggiungere ulteriori blocchi CIDR non sovrapposti al VPC. Tuttavia, questo potrebbe frammentare gli intervalli degli indirizzi.
+ Fai in modo che i VPC abbiano le dimensioni maggiori possibili. Il blocco CIDR VPC iniziale allocato al VPC non può essere modificato o eliminato, ma puoi aggiungere ulteriori blocchi CIDR non sovrapposti al VPC. Tuttavia, questo potrebbe frammentare gli intervalli degli indirizzi.
## Risorse
**Documenti correlati:**
+ [Partner APN: partner per la pianificazione della rete](https://aws.amazon.com/partners/find/results/?keyword=network)
+ [Marketplace AWS per l'infrastruttura di rete](https://aws.amazon.com/marketplace/b/2649366011)
+ [Whitepaper: Opzioni di connettività di Amazon Virtual Private Cloud](https://docs.aws.amazon.com/whitepapers/latest/aws-vpc-connectivity-options/introduction.html)
+ [Connettività di rete di elevata disponibilità in più data center](https://aws.amazon.com/answers/networking/aws-multiple-data-center-ha-network-connectivity/)
+ [Connettività multi-VPC a singola Regione](https://aws.amazon.com/answers/networking/aws-single-region-multi-vpc-connectivity/)
+ [Che cos'è Amazon VPC?](https://docs.aws.amazon.com/vpc/latest/userguide/what-is-amazon-vpc.html)
**Video correlati:**
+ [AWS re:Invent 2018: Advanced VPC Design and New Capabilities for Amazon VPC (Progettazione avanzata di VPC e nuove funzionalità per Amazon VPC) (NET303) ](https://youtu.be/fnxXNZdf6ew)
+ [AWS re:Invent 2019: AWS Transit Gateway reference architectures for many VPCs (Architetture di riferimento del Gateway di transito AWS per molte VPC) (NET406-R1)](https://youtu.be/9Nikqn_02Oc)
# REL02-BP04 Preferire topologie hub-and-spoke rispetto a mesh da-molti-a-molti
Se più di due spazi di indirizzi di rete (ad esempio, VPC e reti on-premise) sono connessi tramite peering VPC, AWS Direct Connect o VPN, utilizza un modello hub-and-spoke, come quello fornito da AWS Transit Gateway.
Se disponi solo di due reti di questo tipo, puoi semplicemente connetterle tra loro, tuttavia, man mano che il numero di reti cresce, la complessità di tali connessioni mesh diventa insostenibile. AWS Transit Gateway offre un modello hub-and-spoke di facile manutenzione, consentendo l'instradamento del traffico su più reti.
![\[Diagramma che mostra il non utilizzo di AWS Transit Gateway\]](http://docs.aws.amazon.com/it_it/wellarchitected/2022-03-31/framework/images/without-transit-gateway.png)
![\[Diagramma che mostra l'utilizzo di AWS Transit Gateway\]](http://docs.aws.amazon.com/it_it/wellarchitected/2022-03-31/framework/images/with-transit-gateway.png)
**Anti-pattern comuni:**
+ Utilizzo del peering VPC per connettere più di due VPC.
+ Creazione di più sessioni BGP per ogni VPC per stabilire una connettività che si estende su cloud privati virtuali (VPC, Virtual Private Cloud) distribuiti in più Regioni AWS.
**Vantaggi dell'adozione di questa best practice:** Man mano che il numero di reti cresce, la complessità di tali connessioni mesh diventa insostenibile. AWS Transit Gateway offre un modello hub-and-spoke di facile manutenzione, consentendo l'instradamento del traffico su più reti.
**Livello di rischio associato se questa best practice non fosse adottata:** Medium
## Guida all'implementazione
+ Preferire topologie hub-and-spoke rispetto a mesh da-molti-a-molti. Se più di due spazi di indirizzi di rete (VPC, reti on-premise) sono connessi tramite peering VPC, AWS Direct Connect o VPN, utilizza un modello hub-and-spoke, come quello fornito da AWS Transit Gateway.
+ Se disponi solo di due reti di questo tipo, puoi semplicemente connetterle tra loro, tuttavia, man mano che il numero di reti cresce, la complessità di tali connessioni mesh diventa insostenibile. AWS Transit Gateway offre un modello hub-and-spoke di facile manutenzione, consentendo l'instradamento del traffico su più reti.
+ [Che cos'è un Transit Gateway?](https://docs.aws.amazon.com/vpc/latest/tgw/what-is-transit-gateway.html)
## Risorse
**Documenti correlati:**
+ [Partner APN: partner per la pianificazione della rete](https://aws.amazon.com/partners/find/results/?keyword=network)
+ [Marketplace AWS per l'infrastruttura di rete](https://aws.amazon.com/marketplace/b/2649366011)
+ [Connettività di rete di elevata disponibilità in più data center](https://aws.amazon.com/answers/networking/aws-multiple-data-center-ha-network-connectivity/)
+ [Endpoint VPC e servizi di endpoint VPC (AWS PrivateLink)](https://docs.aws.amazon.com/vpc/latest/userguide/endpoint-services-overview.html)
+ [Che cos'è Amazon VPC?](https://docs.aws.amazon.com/vpc/latest/userguide/what-is-amazon-vpc.html)
+ [Che cos'è un Transit Gateway?](https://docs.aws.amazon.com/vpc/latest/tgw/what-is-transit-gateway.html)
**Video correlati:**
+ [AWS re:Invent 2018: Advanced VPC Design and New Capabilities for Amazon VPC (Progettazione avanzata di VPC e nuove funzionalità per Amazon VPC) (NET303) ](https://youtu.be/fnxXNZdf6ew)
+ [AWS re:Invent 2019: AWS Transit Gateway reference architectures for many VPCs (Architetture di riferimento del Gateway di transito AWS per molte VPC) (NET406-R1)](https://youtu.be/9Nikqn_02Oc)
# REL02-BP05 Applicazione di intervalli di indirizzi IP privati non sovrapposti in tutti gli spazi con indirizzi privati a cui sono connessi
Gli intervalli di indirizzi IP di ogni VPC non devono sovrapporsi quando collegati in peering o connessi tramite VPN. Analogamente, è necessario evitare conflitti di indirizzi IP tra un VPC e ambienti in locale o con altri provider di servizi cloud utilizzati. Bisogna inoltre disporre di un modo per allocare gli intervalli di indirizzi IP privati quando necessario.
Un sistema di gestione degli indirizzi IP (IPAM) può aiutarti in questo. Su Marketplace AWS sono disponibili diversi IPAM.
**Anti-pattern comuni:**
+ Utilizzo nel VPC dello stesso intervallo IP utilizzato in locale o nella rete aziendale.
+ Non tenere traccia degli intervalli IP dei VPC utilizzati per distribuire i carichi di lavoro.
**Vantaggi dell'adozione di questa best practice:** La pianificazione attiva della rete garantisce di non avere più occorrenze dello stesso indirizzo IP nelle reti interconnesse. In questo modo si evitano problemi di instradamento in parti del carico di lavoro che utilizzano le diverse applicazioni.
**Livello di rischio associato se questa best practice non fosse adottata:** Medium
## Guida all'implementazione
+ Monitora e gestisci l'uso di CIDR. Valuta il tuo utilizzo potenziale su AWS, aggiungi intervalli CIDR ai VPC esistenti e crea i VPC per consentire la crescita pianificata dell'utilizzo.
+ Acquisisci il consumo attuale di CIDR (ad esempio, VPC e sottoreti)
+ Utilizza le operazioni delle API di servizi per raccogliere il consumo attuale di CIDR.
+ Acquisisci l'utilizzo attuale delle sottoreti.
+ Utilizza le operazioni delle API di servizio per raccogliere le sottoreti per VPC in ogni Regione.
+ [DescribeSubnets](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DescribeSubnets.html)
+ Registra l'uso attuale.
+ Verifica se hai creato intervalli di indirizzi IP sovrapposti.
+ Calcola la capacità inutilizzata.
+ Individua gli intervalli di indirizzi IP sovrapposti. Puoi eseguire la migrazione a un nuovo intervallo di indirizzi o utilizzare le appliance NAT (Network and Port Translation) di Marketplace AWS se hai l'esigenza di connettere gli intervalli sovrapposti.
## Risorse
**Documenti correlati:**
+ [Partner APN: partner per la pianificazione della rete](https://aws.amazon.com/partners/find/results/?keyword=network)
+ [Marketplace AWS per l'infrastruttura di rete](https://aws.amazon.com/marketplace/b/2649366011)
+ [Whitepaper: Opzioni di connettività di Amazon Virtual Private Cloud](https://docs.aws.amazon.com/whitepapers/latest/aws-vpc-connectivity-options/introduction.html)
+ [Connettività di rete di elevata disponibilità in più data center](https://aws.amazon.com/answers/networking/aws-multiple-data-center-ha-network-connectivity/)
+ [Che cos'è Amazon VPC?](https://docs.aws.amazon.com/vpc/latest/userguide/what-is-amazon-vpc.html)
+ [Che cos'è IPAM?](https://docs.aws.amazon.com/vpc/latest/ipam/what-it-is-ipam.html)
**Video correlati:**
+ [AWS re:Invent 2018: Advanced VPC Design and New Capabilities for Amazon VPC (Progettazione avanzata di VPC e nuove funzionalità per Amazon VPC) (NET303) ](https://youtu.be/fnxXNZdf6ew)
+ [AWS re:Invent 2019: AWS Transit Gateway reference architectures for many VPCs (Architetture di riferimento del Gateway di transito AWS per molte VPC) (NET406-R1)](https://youtu.be/9Nikqn_02Oc)
# Architettura del carico di lavoro
**Topics**
+ [REL 3 In che modo progetti l'architettura del servizio di carico di lavoro?](w2aac19b9b7b5.md)
+ [REL 4 In che modo progetti le interazioni in un sistema distribuito per evitare errori?](w2aac19b9b7b7.md)
+ [REL 5 In che modo progetti le interazioni in un sistema distribuito per mitigare o affrontare gli errori?](w2aac19b9b7b9.md)
# REL 3 In che modo progetti l'architettura del servizio di carico di lavoro?
Creazione di carichi di lavoro altamente scalabili e affidabili utilizzando un'architettura orientata ai servizi (SOA) o un'architettura di microservizi. L'architettura orientata ai servizi (SOA) è la pratica di rendere i componenti software riutilizzabili tramite interfacce di servizio. L'architettura dei microservizi va oltre, per rendere i componenti più piccoli e semplici.
**Topics**
+ [REL03-BP01 Scelta del tipo di segmentazione del carico di lavoro](rel_service_architecture_monolith_soa_microservice.md)
+ [REL03-BP02 Creazione di servizi focalizzati su domini e funzionalità aziendali specifici](rel_service_architecture_business_domains.md)
+ [REL03-BP03 Fornitura di contratti di servizio per API](rel_service_architecture_api_contracts.md)
# REL03-BP01 Scelta del tipo di segmentazione del carico di lavoro
La segmentazione del carico di lavoro è importante quando vengono determinati i requisiti di resilienza dell'applicazione. L'architettura monolitica deve essere evitata se possibile. Valuta invece con particolare attenzione quali componenti dell'applicazione possono essere suddivisi in microservizi. A seconda dei requisiti dell'applicazione, ciò potrebbe risultare in una combinazione di architettura orientata ai servizi (SOA) e microservizi, laddove possibile. I carichi di lavoro stateless sono maggiormente idonei a essere implementati come microservizi.
**Risultato desiderato:** i carichi di lavoro devono essere supportabili, scalabili e devono essere caratterizzati dalla minore interdipendenza possibile.
Quando scegli come segmentare il carico di lavoro, trova il giusto compromesso tra i vantaggi e le complessità. Ciò che è giusto per un nuovo prodotto al primo lancio è diverso dai requisiti di un carico di lavoro creato per ridimensionare le risorse. Durante la rifattorizzazione (riprogettazione) di un monolito, dovrai considerare la capacità dell'applicazione di supportare la suddivisione in servizi stateless. La suddivisione dei servizi in elementi più piccoli consente a team ristretti e ben definiti di svilupparli e gestirli. Tuttavia, servizi di piccole dimensioni possono introdurre complessità, che includono un eventuale aumento della latenza, un debug più complesso e un maggiore carico operativo.
**Anti-pattern comuni:**
+ Il [microservizio *Death Star*](https://mrtortoise.github.io/architecture/lean/design/patterns/ddd/2018/03/18/deathstar-architecture.html) rappresenta una situazione in cui i componenti atomici diventano così interdipendenti che un errore verificatosi in un componente genera un errore molto più grande, rendendo i componenti rigidi e fragili se considerati come monolito.
**Vantaggi dell'adozione di questa best practice:**
+ Segmenti più specifici comportano maggiore agilità, flessibilità organizzativa e scalabilità.
+ Riduzione dell'impatto derivante dall'interruzione dei servizi.
+ I componenti dell'applicazione possono avere requisiti di disponibilità diversi, che a loro volta possono essere supportati da una segmentazione più atomica.
+ Responsabilità ben definite per i team che supportano il carico di lavoro.
**Livello di rischio associato se questa best practice non fosse adottata:** alto
## Guida all'implementazione
Scegli il tipo di architettura in base al tipo di segmentazione del carico di lavoro. Scegli una SOA o un'architettura di microservizi (o, in alcuni rari casi, un'architettura monolitica). Anche se scegli di iniziare con un'architettura monolitica, devi assicurarti che sia modulare e possa evolvere in SOA o microservizi man mano che il prodotto si dimensiona con l'adozione da parte degli utenti. La SOA e i microservizi offrono rispettivamente una segmentazione più piccola, preferita come architettura moderna scalabile e affidabile, ma ci sono compromessi da considerare soprattutto quando si distribuisce un'architettura di microservizi.
Uno dei principali compromessi è che ora disponi di un'architettura di calcolo distribuita che può rendere più difficile il raggiungimento dei requisiti di latenza degli utenti ed è presente un'ulteriore complessità nel debug e nel tracciamento delle interazioni degli utenti. Puoi utilizzare AWS X-Ray per risolvere questo problema. Un altro effetto da considerare è l'aumento della complessità operativa man mano che aumenta il numero di applicazioni che gestisci, che richiede la distribuzione di più componenti di indipendenza.
![\[Diagramma che illustra il confronto tra architettura monolitica, orientata ai servizi e di microservizi\]](http://docs.aws.amazon.com/it_it/wellarchitected/2022-03-31/framework/images/monolith-soa-microservices-comparison.png)
## Passaggi dell'implementazione
+ Determina l'architettura più appropriata per rifattorizzare (riprogettare) o creare l'applicazione. SOA e microservizi offrono segmentazione rispettivamente di dimensioni minori, preferita in quanto architettura moderna, scalabile e affidabile. SOA può essere un buon compromesso per ottenere una segmentazione di dimensioni minori, evitando al contempo alcune delle complessità dei microservizi. Per ulteriori dettagli, consulta [I compromessi dei microservizi](https://martinfowler.com/articles/microservice-trade-offs.html).
+ Se il carico di lavoro è adatto e la tua organizzazione può supportarla, è consigliabile utilizzare un'architettura di microservizi per ottenere la massima agilità e affidabilità. Per ulteriori dettagli, consulta [Implementing Microservices on AWS (Implementazione di microservizi in AWS).](https://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/introduction.html)
+ Considera l'ipotesi di attenerti al modello [*Strangler* Fig](https://martinfowler.com/bliki/StranglerFigApplication.html) per eseguire la rifattorizzazione (riprogettazione) di un monolito in componenti più piccoli. Ciò comporta la graduale sostituzione di componenti specifici dell'applicazione con nuove applicazioni e nuovi servizi. [AWS Migration Hub Refactor Spaces](https://docs.aws.amazon.com/migrationhub-refactor-spaces/latest/userguide/what-is-mhub-refactor-spaces.html) funge da punto di partenza per la rifattorizzazione incrementale. Per ulteriori dettagli, consulta [Seamlessly migrate on-premises legacy workloads using a strangler pattern (Migrazione senza problemi di carichi di lavoro legacy on-premise mediante un modello Strangler)](https://aws.amazon.com/blogs/architecture/seamlessly-migrate-on-premises-legacy-workloads-using-a-strangler-pattern/).
+ L'implementazione di microservizi può richiedere un meccanismo di individuazione dei servizi per consentire ai servizi distribuiti di comunicare tra loro. [AWS App Mesh](https://docs.aws.amazon.com/app-mesh/latest/userguide/what-is-app-mesh.html) può essere utilizzato con architetture orientate ai servizi per offrire rilevamento e accesso affidabili ai servizi. [AWS Cloud Map](https://aws.amazon.com/cloud-map/) può inoltre essere utilizzato per il rilevamento dinamico dei servizi basato su DNS.
+ In caso di migrazione da un monolito a una SOA, [Amazon MQ](https://docs.aws.amazon.com/amazon-mq/latest/developer-guide/welcome.html) può aiutare a colmare il divario come bus del servizio durante la riprogettazione delle applicazioni legacy nel cloud.
+ Per i monoliti esistenti con un unico database condiviso, scegli come riorganizzare i dati in segmenti più piccoli. Questa riorganizzazione può avvenire per unità aziendale, schema di accesso o struttura dei dati. A questo punto del processo di rifattorizzazione (riprogettazione), deve orientare la scelta verso un database di tipo relazionale o non relazionale (NoSQL). Per ulteriori dettagli, consulta [From SQL to NoSQL (Da SQL a NoSQL)](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/SQLtoNoSQL.html).
**Livello di impegno per il piano di implementazione:** alto
## Risorse
**Best practice correlate:**
+ [REL03-BP02 Creazione di servizi focalizzati su domini e funzionalità aziendali specifici](rel_service_architecture_business_domains.md)
**Documenti correlati:**
+ [Amazon API Gateway: configurazione di una REST API mediante OpenAPI](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-import-api.html)
+ [Cosa si intende per architettura orientata ai servizi?](https://aws.amazon.com/what-is/service-oriented-architecture/)
+ [Bounded Context (un modello centrale in Domain-Driven Design)](https://martinfowler.com/bliki/BoundedContext.html)
+ [Implementazione di microservizi in AWS](https://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/introduction.html)
+ [I compromessi dei microservizi](https://martinfowler.com/articles/microservice-trade-offs.html)
+ [Microservizi: una definizione di questo nuovo termine di architettura](https://www.martinfowler.com/articles/microservices.html)
+ [Implementazione di microservizi in AWS](https://aws.amazon.com/microservices/)
+ [What is AWS App Mesh? (Che cos'è AWS App Mesh?)](https://docs.aws.amazon.com/app-mesh/latest/userguide/what-is-app-mesh.html)
**Esempi correlati:**
+ [Iterative App Modernization Workshop (Workshop sulla modernizzazione delle applicazioni interattive)](https://catalog.us-east-1.prod.workshops.aws/workshops/f2c0706c-7192-495f-853c-fd3341db265a/en-US/intro)
**Video correlati:**
+ [Delivering Excellence with Microservices on AWS (Implementazione dell'eccellenza con i microservizi in AWS)](https://www.youtube.com/watch?v=otADkIyugzY)
# REL03-BP02 Creazione di servizi focalizzati su domini e funzionalità aziendali specifici
L'architettura orientata ai servizi (SOA) crea servizi con funzioni ben delineate definite dalle esigenze aziendali. I microservizi utilizzano modelli di dominio e contesto delimitato per restringere ulteriormente questa operazione, in modo che ogni servizio esegua una sola operazione. Focalizzarsi su funzionalità specifiche consente di differenziare i requisiti di affidabilità dei diversi servizi e mirare agli investimenti in modo più specifico. Un problema aziendale conciso e l'associazione di un piccolo team a ciascun servizio facilitano il dimensionamento dell'organizzazione.
Nella progettazione di un'architettura di microservizi, è utile impiegare Domain-Driven Design (DDD) per modellare il problema aziendale utilizzando le entità. Ad esempio, per il sito Web Amazon.com, le entità possono includere pacchetti, consegna, pianificazione, prezzo, sconto e valuta. Quindi il modello viene ulteriormente suddiviso in modelli più piccoli utilizzando il [https://martinfowler.com/bliki/BoundedContext.html](https://martinfowler.com/bliki/BoundedContext.html), dove le entità che condividono caratteristiche e attributi simili vengono raggruppate insieme. Pertanto, utilizzando il pacchetto di esempio di Amazon.com, la consegna e la pianificazione sarebbero parte del contesto di spedizione, mentre il prezzo, lo sconto e la valuta fanno parte del contesto dei prezzi. Con il modello diviso in contesti, emerge un modello su come delimitare i microservizi.
![\[Modello di come delimitare i microservizi\]](http://docs.aws.amazon.com/it_it/wellarchitected/2022-03-31/framework/images/building-services.png)
**Livello di rischio associato se questa best practice non fosse adottata:** Alta
## Guida all'implementazione
+ Progetta il carico di lavoro in base ai domini aziendali e alle loro rispettive funzionalità. Focalizzarsi su funzionalità specifiche consente di differenziare i requisiti di affidabilità dei diversi servizi e mirare agli investimenti in modo più specifico. Un problema aziendale conciso e l'associazione di un piccolo team a ciascun servizio facilitano il dimensionamento dell'organizzazione.
+ Esegui l'analisi di dominio per mappare una progettazione basata sul dominio (DDD, domain-driven design) per il carico di lavoro. In seguito, puoi scegliere un tipo di architettura per soddisfare le esigenze del carico di lavoro.
+ [How to break a Monolith into Microservices (Come trasformare un monolite in microservizi)](https://martinfowler.com/articles/break-monolith-into-microservices.html)
+ [Getting Started with DDD when Surrounded by Legacy Systems (Iniziare con il DDD quando si è circondati da sistemi legacy)](https://domainlanguage.com/wp-content/uploads/2016/04/GettingStartedWithDDDWhenSurroundedByLegacySystemsV1.pdf)
+ [Eric Evans "Domain-Driven Design: Tackling Complexity in the Heart of Software"](https://www.amazon.com/gp/product/0321125215)
+ [Implementazione di microservizi in AWS](https://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/introduction.html)
+ Suddividi i tuoi servizi in componenti più piccoli possibile. Con l'architettura di microservizi, puoi dividere il tuo carico di lavoro in componenti dotati della funzionalità minima per consentire agilità e ridimensionamento dell'organizzazione.
+ Definisci l'API per il carico di lavoro e i suoi obiettivi di progettazione, limiti e qualsiasi altra considerazione per l'uso.
+ Definizione dell'API.
+ La definizione dell'API deve consentire la crescita e parametri aggiuntivi.
+ Definizione delle disponibilità progettate.
+ La tua API può avere più obiettivi di progettazione per funzioni differenti.
+ Definizione di limiti
+ Esegui test per definire i limiti delle tue capacità di carico di lavoro.
## Risorse
**Documenti correlati:**
+ [Amazon API Gateway: configurazione di una REST API mediante OpenAPI](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-import-api.html)
+ [Bounded Context (un modello centrale in Domain-Driven Design)](https://martinfowler.com/bliki/BoundedContext.html)
+ [Eric Evans "Domain-Driven Design: Tackling Complexity in the Heart of Software"](https://www.amazon.com/gp/product/0321125215)
+ [Getting Started with DDD when Surrounded by Legacy Systems (Iniziare con il DDD quando si è circondati da sistemi legacy)](https://domainlanguage.com/wp-content/uploads/2016/04/GettingStartedWithDDDWhenSurroundedByLegacySystemsV1.pdf)
+ [How to break a Monolith into Microservices (Come trasformare un monolite in microservizi)](https://martinfowler.com/articles/break-monolith-into-microservices.html)
+ [Implementazione di microservizi in AWS](https://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/introduction.html)
+ [I compromessi dei microservizi](https://martinfowler.com/articles/microservice-trade-offs.html)
+ [Microservizi: una definizione di questo nuovo termine di architettura](https://www.martinfowler.com/articles/microservices.html)
+ [Implementazione di microservizi in AWS](https://aws.amazon.com/microservices/)
# REL03-BP03 Fornitura di contratti di servizio per API
I contratti di servizio sono accordi documentati tra i team sull'integrazione dei servizi e includono una definizione API leggibile dal computer, limiti di velocità e aspettative di prestazioni. Una strategia di controllo delle versioni consente ai clienti di continuare a utilizzare l'API esistente e migrare le applicazioni all'API più recente quando sono pronte. La distribuzione può avvenire in qualsiasi momento, purché il contratto non venga violato. Il team del fornitore di servizi può utilizzare lo stack tecnologico scelto per soddisfare il contratto API. Analogamente, l'utente del servizio può utilizzare la propria tecnologia.
I microservizi portano il concetto dell'architettura orientata ai servizi (SOA) al punto della creazione di servizi che hanno una serie minima di funzionalità. Ogni servizio pubblica un'API e obiettivi di progettazione, limiti e altre considerazioni per l'utilizzo del servizio. Questo stabilisce un *contratto* con le applicazioni di chiamata. Questo comporta tre vantaggi principali:
+ Il servizio ha un problema aziendale circoscritto da risolvere e un piccolo team proprietario del problema aziendale. Questo consente un miglior ridimensionamento organizzativo.
+ Ciascun team può effettuare un'implementazione in qualsiasi momento purché questa soddisfi i rispettivi requisiti "contrattuali" e dell'API.
+ Il team può utilizzare qualsiasi stack tecnologico a condizione che soddisfi le proprie API e altri requisiti di "contratto".
Amazon API Gateway è un servizio completamente gestito che semplifica agli sviluppatori la creazione, la pubblicazione, la manutenzione, il monitoraggio e la protezione delle API su qualsiasi scala. Gestisce tutte le attività coinvolte nell'accettazione e nell'elaborazione di fino a centinaia di migliaia di chiamate API simultanee, tra cui la gestione del traffico, il controllo delle autorizzazioni e degli accessi, il monitoraggio e la gestione delle versioni delle API. Utilizzando OpenAPI Specification (OAS), precedentemente noto come Swagger Specification, è possibile definire il contratto API e importarlo in API Gateway. Con API Gateway, puoi eseguire la versione e la distribuzione delle API.
**Livello di rischio associato se questa best practice non fosse adottata:** Bassa
## Guida all'implementazione
+ Fornisci contratti di servizio per API: i contratti di servizio sono accordi documentati tra i team sull'integrazione dei servizi e includono una definizione di API leggibile meccanicamente, limiti di velocità e aspettative di prestazioni.
+ [Amazon API Gateway: configurazione di una REST API mediante OpenAPI](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-import-api.html)
+ Una strategia di controllo delle versioni consente ai client di continuare a utilizzare l'API esistente e migrare le applicazioni all'API più recente quando sono pronte.
+ Amazon API Gateway è un servizio completamente gestito che semplifica agli sviluppatori la creazione delle API su qualsiasi scala. Utilizzando OpenAPI Specification (OAS), precedentemente noto come Swagger Specification, puoi definire il contratto API e importarlo in API Gateway. Con API Gateway, puoi eseguire la versione e la distribuzione delle API.
## Risorse
**Documenti correlati:**
+ [Amazon API Gateway: configurazione di una REST API mediante OpenAPI](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-import-api.html)
+ [Bounded Context (un modello centrale in Domain-Driven Design)](https://martinfowler.com/bliki/BoundedContext.html)
+ [Implementazione di microservizi in AWS](https://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/introduction.html)
+ [I compromessi dei microservizi](https://martinfowler.com/articles/microservice-trade-offs.html)
+ [Microservizi: una definizione di questo nuovo termine di architettura](https://www.martinfowler.com/articles/microservices.html)
+ [Implementazione di microservizi in AWS](https://aws.amazon.com/microservices/)
# REL 4 In che modo progetti le interazioni in un sistema distribuito per evitare errori?
I sistemi distribuiti si basano sulle reti di comunicazione per interconnettere i componenti (ad esempio server o servizi). Il carico di lavoro deve funzionare in modo affidabile nonostante la perdita o la latenza dei dati in queste reti. I componenti del sistema distribuito devono funzionare in modo da non influire negativamente su altri componenti o sul carico di lavoro. Queste best practice prevengono gli errori e migliorano il tempo medio tra errori (MTBF).
**Topics**
+ [REL04-BP01 Identificazione del tipo di sistema distribuito necessario](rel_prevent_interaction_failure_identify.md)
+ [REL04-BP02 Implementazione di dipendenze "loosely coupled"](rel_prevent_interaction_failure_loosely_coupled_system.md)
+ [REL04-BP03 Esecuzione di un lavoro costante](rel_prevent_interaction_failure_constant_work.md)
+ [REL04-BP04 Rendere tutte le risposte idempotenti](rel_prevent_interaction_failure_idempotent.md)
# REL04-BP01 Identificazione del tipo di sistema distribuito necessario
I sistemi distribuiti hard real-time richiedono risposte che devono essere fornite in modo sincrono e rapido, mentre i sistemi soft real-time hanno una finestra temporale più generosa di minuti o più per la risposta. I sistemi offline gestiscono le risposte tramite elaborazione in batch o asincrona. I sistemi distribuiti hard real-time hanno i requisiti di affidabilità più severi.
Le difficoltà maggiori [con i sistemi distribuiti](https://aws.amazon.com/builders-library/challenges-with-distributed-systems/) riguardano i sistemi distribuiti hard real-time, noti anche come servizi di richiesta/risposta. La difficoltà sta nel fatto che le richieste arrivino in modo imprevedibile e le risposte debbano essere fornite rapidamente (ad esempio, il cliente è attivamente in attesa della risposta). Alcuni esempi includono server Web front-end, pipeline degli ordini, transazioni con carte di credito, ogni API AWS e telefonia.
**Livello di rischio associato se questa best practice non fosse adottata:** Alta
## Guida all'implementazione
+ Identifica il tipo di sistema distribuito necessario. Le sfide nell'ambito dei sistemi distribuiti includevano la latenza, il dimensionamento, la comprensione delle API di rete, i dati di marshalling e non-marshalling e la complessità di algoritmi come Paxos. Man mano che i sistemi diventano più grandi e più distribuiti, quelli che erano casi teorici limite diventano eventi regolari.
+ [The Amazon Builders' Library: Difficoltà dei sistemi distribuiti](https://aws.amazon.com/builders-library/challenges-with-distributed-systems/)
+ I sistemi distribuiti hard real-time richiedono risposte da fornire in modo sincrono e rapido.
+ I sistemi soft real-time hanno una finestra temporale più generosa di minuti o più per la risposta.
+ I sistemi offline gestiscono le risposte tramite elaborazione in batch o asincrona.
+ I sistemi distribuiti hard real-time hanno i requisiti di affidabilità più severi.
## Risorse
**Documenti correlati:**
+ [Amazon EC2: Ensuring Idempotency (EC2: garantire l'idempotenza)](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/Run_Instance_Idempotency.html)
+ [The Amazon Builders' Library: Difficoltà dei sistemi distribuiti](https://aws.amazon.com/builders-library/challenges-with-distributed-systems/)
+ [The Amazon Builders' Library: Reliability, constant work, and a good cup of coffee](https://aws.amazon.com/builders-library/reliability-and-constant-work/)
+ [Che cos'è Amazon EventBridge?](https://docs.aws.amazon.com/eventbridge/latest/userguide/what-is-amazon-eventbridge.html)
+ [Che cos'è Amazon Simple Queue Service?](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/welcome.html)
**Video correlati:**
+ [AWS New York Summit 2019: Intro to Event-driven Architectures and Amazon EventBridge (AWS New York Summit 2019: Introduzione alle architetture guidate dagli eventi e ad Amazon EventBridge) (MAD205)](https://youtu.be/tvELVa9D9qU)
+ [AWS re:Invent 2018: Close Loops and Opening Minds: How to Take Control of Systems, Big and Small (Chiudere i cicli e aprire le menti: come prendere il controllo dei sistemi, grandi e piccoli) (sono inclusi accoppiamento debole, lavoro costante e stabilità statica) (ARC337)](https://youtu.be/O8xLxNje30M)
+ [AWS re:Invent 2019: Moving to event-driven architectures (Passare alle architetture basate sugli eventi) (SVS308)](https://youtu.be/h46IquqjF3E)
# REL04-BP02 Implementazione di dipendenze "loosely coupled"
Le dipendenze come sistemi di accodamento, sistemi di streaming, flussi di lavoro e sistemi di bilanciamento del carico sono "loosely coupled" (con accoppiamento debole). L'accoppiamento debole aiuta a isolare il comportamento di un componente dagli altri componenti che dipendono da esso, aumentando la resilienza e l'agilità.
Se i cambiamenti apportati a un componente forzano la modifica anche di altri componenti basati sullo stesso, allora si parla di *"tightly* coupling" (accoppiamento stretto). *Il "loose* coupling" (accoppiamento debole) interrompe questa dipendenza, in modo che i componenti dipendenti debbano conoscere solo l'interfaccia con versione e pubblicata. L'implementazione di un accoppiamento debole tra dipendenze isola un errore all'interno di una dipendenza affinché non influenzi l'altra.
L'accoppiamento debole consente di aggiungere liberamente ulteriore codice o caratteristiche a un componente, riducendo al minimo i rischi per i componenti che dipendono da esso. Inoltre, la scalabilità è migliorata in quanto è possibile aumentare orizzontalmente o persino modificare l'implementazione sottostante della dipendenza.
Per migliorare ulteriormente la resilienza tramite accoppiamento debole, rendi le interazioni dei componenti asincrone laddove possibile. Questo modello è idoneo a qualsiasi interazione che non richieda una risposta immediata e laddove la conferma della registrazione di una richiesta sia sufficiente. Include un componente che genera eventi e un altro che li utilizza. I due componenti non si integrano tramite un'interazione diretta point-to-point, ma in genere attraverso un livello di archiviazione intermedio durevole, come una coda SQS o una piattaforma di dati in streaming come Amazon Kinesis o AWS Step Functions.
![\[Diagramma che mostra le dipendenze come i sistemi di accodamento e i load balancer sono "loosely coupled"\]](http://docs.aws.amazon.com/it_it/wellarchitected/2022-03-31/framework/images/loosely-coupled-dependencies.png)
Le code Amazon SQS ed Elastic Load Balancer sono solo due modi per aggiungere un livello intermedio per l'accoppiamento debole. Le architetture basate su eventi possono anche essere create in Cloud AWS utilizzando Amazon EventBridge, che può astrarre i client (produttori di eventi) dai servizi a cui fanno affidamento (consumatori di eventi). Amazon Simple Notification Service (Amazon SNS) è una soluzione efficace quando hai bisogno di messaggistica da-molti-a-molti, dalla velocità di trasmissione effettiva elevata e basata su push. Utilizzando gli argomenti di Amazon SNS, i sistemi di pubblicazione possono inviare messaggi a un numero elevato di endpoint sottoscrittori per l'elaborazione parallela.
Mentre le code offrono diversi vantaggi, nella maggior parte dei sistemi hard real-time, le richieste più vecchie di una soglia temporale (spesso secondi) dovrebbero essere considerate obsolete (il client ha abbandonato e non è più in attesa di una risposta) e non elaborate. In questo modo, è possibile elaborare invece le richieste più recenti (e probabilmente ancora valide).
**Anti-pattern comuni:**
+ Distribuzione di un singleton come parte di un carico di lavoro.
+ Invocazione diretta di API tra livelli di carico di lavoro senza funzionalità di failover o elaborazione asincrona della richiesta.
**Vantaggi dell'adozione di questa best practice:** L'accoppiamento debole aiuta a isolare il comportamento di un componente dagli altri componenti che dipendono da esso, aumentando la resilienza e l'agilità. L'errore in un componente è isolato dagli altri.
**Livello di rischio associato se questa best practice non fosse adottata:** Alta
## Guida all'implementazione
+ Implementazione di dipendenze "loosely coupled". Le dipendenze come sistemi di accodamento, sistemi di streaming, flussi di lavoro e sistemi di bilanciamento del carico sono "loosely coupled" (con accoppiamento debole). L'accoppiamento debole aiuta a isolare il comportamento di un componente dagli altri componenti che dipendono da esso, aumentando la resilienza e l'agilità.
+ [AWS re:Invent 2019: Moving to event-driven architectures (Passare alle architetture basate sugli eventi) (SVS308)](https://docs.aws.amazon.com/eventbridge/latest/userguide/what-is-amazon-eventbridge.html)
+ [Che cos'è Amazon EventBridge?](https://docs.aws.amazon.com/eventbridge/latest/userguide/what-is-amazon-eventbridge.html)
+ [Che cos'è Amazon Simple Queue Service?](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/welcome.html)
+ Amazon EventBridge consente di creare architetture basate su eventi caratterizzate da accoppiamento e distribuzione deboli.
+ [AWS New York Summit 2019: Intro to Event-driven Architectures and Amazon EventBridge (AWS New York Summit 2019: Introduzione alle architetture guidate dagli eventi e ad Amazon EventBridge) (MAD205)](https://youtu.be/tvELVa9D9qU)
+ Se i cambiamenti apportati a un componente forzano la modifica anche di altri componenti che si basano su esso, allora sono strettamente accoppiati. L'accoppiamento debole interrompe questa dipendenza, in modo che i componenti dipendenti debbano conoscere solo l'interfaccia con versione e pubblicata.
+ Rendere le interazioni dei componenti asincrone, laddove possibile. Questo modello è idoneo a qualsiasi interazione che non richieda una risposta immediata e laddove la conferma della registrazione di una richiesta sia sufficiente.
+ [AWS re:Invent 2019: Scalable serverless event-driven applications using Amazon SQS and Lambda (Applicazioni scalabili serverless basate sugli eventi con l'utilizzo di Amazon SQS e Lambda) (API304)](https://youtu.be/2rikdPIFc_Q)
## Risorse
**Documenti correlati:**
+ [AWS re:Invent 2019: Moving to event-driven architectures (Passare alle architetture basate sugli eventi) (SVS308)](https://docs.aws.amazon.com/eventbridge/latest/userguide/what-is-amazon-eventbridge.html)
+ [Amazon EC2: Ensuring Idempotency (EC2: garantire l'idempotenza)](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/Run_Instance_Idempotency.html)
+ [The Amazon Builders' Library: Difficoltà dei sistemi distribuiti](https://aws.amazon.com/builders-library/challenges-with-distributed-systems/)
+ [The Amazon Builders' Library: Reliability, constant work, and a good cup of coffee](https://aws.amazon.com/builders-library/reliability-and-constant-work/)
+ [Che cos'è Amazon EventBridge?](https://docs.aws.amazon.com/eventbridge/latest/userguide/what-is-amazon-eventbridge.html)
+ [Che cos'è Amazon Simple Queue Service?](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/welcome.html)
**Video correlati:**
+ [AWS New York Summit 2019: Intro to Event-driven Architectures and Amazon EventBridge (AWS New York Summit 2019: Introduzione alle architetture guidate dagli eventi e ad Amazon EventBridge) (MAD205)](https://youtu.be/tvELVa9D9qU)
+ [AWS re:Invent 2018: Close Loops and Opening Minds: How to Take Control of Systems, Big and Small (Chiudere i cicli e aprire le menti: come prendere il controllo dei sistemi, grandi e piccoli) (sono inclusi accoppiamento debole, lavoro costante e stabilità statica) (ARC337)](https://youtu.be/O8xLxNje30M)
+ [AWS re:Invent 2019: Moving to event-driven architectures (Passare alle architetture basate sugli eventi) (SVS308)](https://youtu.be/h46IquqjF3E)
+ [AWS re:Invent 2019: Scalable serverless event-driven applications using Amazon SQS and Lambda (Applicazioni scalabili serverless basate sugli eventi con l'utilizzo di Amazon SQS e Lambda) (API304)](https://youtu.be/2rikdPIFc_Q)
# REL04-BP03 Esecuzione di un lavoro costante
I sistemi possono fallire quando si verificano modifiche rapide e di grandi dimensioni nel carico. Ad esempio, se il carico di lavoro effettua un controllo dell'integrità di migliaia di server deve inviare ogni volta lo stesso payload delle dimensioni (uno snapshot completo dello stato corrente). Indipendentemente dal fatto che non ci siano server guasti, o che lo siano tutti, il sistema di controllo dello stato esegue un lavoro costante con modifiche rapide e di piccole dimensioni.
Ad esempio, se il sistema di controllo dello stato monitora 100.000 server, il carico su di esso è nominale al di sotto del tasso di errore normalmente basso del server. Tuttavia, se un evento importante rendesse la metà di questi server non integra, il sistema di controllo dello stato sarebbe sovraccarico nel tentativo di aggiornare i sistemi di notifica e comunicare lo stato con i client. Pertanto, il sistema di controllo dello stato dovrebbe ogni volta inviare lo snapshot completo dello stato corrente. 100.000 stati di integrità del server, ciascuno rappresentato da un bit, sarebbero solo un payload di 12,5 KB. Indipendentemente dal fatto che non ci siano server guasti, o che lo siano tutti, il sistema di controllo dello stato esegue un lavoro costante e le modifiche rapide e di grandi dimensioni non rappresentano una minaccia per la stabilità del sistema. Questo è in realtà il modo in cui Amazon Route 53 gestisce i controlli dell'integrità degli endpoint (come gli indirizzi IP) per stabilire come gli utenti finali vengono instradati verso di loro.
**Livello di rischio associato se questa best practice non fosse adottata:** Bassa
## Guida all'implementazione
+ Esegui un lavoro costante in modo che i sistemi non falliscano quando si verificano cambiamenti rapidi e significativi nel carico.
+ Implementazione di dipendenze "loosely coupled". Le dipendenze come sistemi di accodamento, sistemi di streaming, flussi di lavoro e sistemi di bilanciamento del carico sono "loosely coupled" (con accoppiamento debole). L'accoppiamento debole aiuta a isolare il comportamento di un componente dagli altri componenti che dipendono da esso, aumentando la resilienza e l'agilità.
+ [The Amazon Builders' Library: Reliability, constant work, and a good cup of coffee](https://aws.amazon.com/builders-library/reliability-and-constant-work/)
+ [AWS re:Invent 2018: Close Loops and Opening Minds: How to Take Control of Systems, Big and Small (Chiudere i cicli e aprire le menti: come prendere il controllo dei sistemi, grandi e piccoli), include lavoro costante (ARC337)](https://youtu.be/O8xLxNje30M?t=2482)
+ Per l'esempio di un sistema di controllo dell'integrità che monitora 100.000 server, progetta i carichi di lavoro in modo che le dimensioni dei payload rimangano costanti indipendentemente dal numero di successi o di fallimenti.
## Risorse
**Documenti correlati:**
+ [Amazon EC2: garantire l'idempotenza](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/Run_Instance_Idempotency.html)
+ [The Amazon Builders' Library: Difficoltà dei sistemi distribuiti](https://aws.amazon.com/builders-library/challenges-with-distributed-systems/)
+ [The Amazon Builders' Library: Reliability, constant work, and a good cup of coffee](https://aws.amazon.com/builders-library/reliability-and-constant-work/)
**Video correlati:**
+ [AWS New York Summit 2019: Intro to Event-driven Architectures and Amazon EventBridge (Introduzione alle architetture guidate dagli eventi e ad Amazon EventBridge) (MAD205)](https://youtu.be/tvELVa9D9qU)
+ [AWS re:Invent 2018: Close Loops and Opening Minds: How to Take Control of Systems, Big and Small (Chiudere i cicli e aprire le menti: come prendere il controllo dei sistemi, grandi e piccoli), include lavoro costante (ARC337)](https://youtu.be/O8xLxNje30M?t=2482)
+ [AWS re:Invent 2018: Close Loops and Opening Minds: How to Take Control of Systems, Big and Small (Chiudere i cicli e aprire le menti: come prendere il controllo dei sistemi, grandi e piccoli), sono inclusi accoppiamento debole, lavoro costante e stabilità statica (ARC337)](https://youtu.be/O8xLxNje30M)
+ [AWS re:Invent 2019: passare alle architetture basate sugli eventi (SVS308)](https://youtu.be/h46IquqjF3E)
# REL04-BP04 Rendere tutte le risposte idempotenti
Un servizio idempotente promette il completamento di ogni richiesta esattamente una volta, in modo tale che effettuare più richieste identiche abbia lo stesso effetto di effettuare una singola richiesta. Un servizio idempotente semplifica ad un client l'implementazione di nuovi tentativi senza temere che una richiesta venga elaborata erroneamente più volte. Per eseguire questa operazione, i client possono inviare richieste API con un token di idempotenza: viene utilizzato lo stesso token ogni volta che si ripete la richiesta. Un'API del servizio idempotente utilizza il token per restituire una risposta identica a quella restituita la prima volta che la richiesta è stata completata.
In un sistema distribuito, è facile eseguire un'operazione al massimo una volta (il client effettua una sola richiesta) o almeno una volta (la richiesta continua finché il client non ottiene la conferma dell'esito positivo). Tuttavia, è difficile garantire che un'operazione sia idempotente, il che significa che viene eseguita *esattamente* una volta, in modo tale che effettuare più richieste identiche abbia lo stesso effetto di effettuare una singola richiesta. Utilizzando i token di idempotenza nelle API, i servizi possono ricevere una richiesta di mutazione una o più volte senza creare record duplicati o effetti collaterali.
**Livello di rischio associato se questa best practice non fosse adottata:** Medium
## Guida all'implementazione
+ Rendi tutte le risposte idempotenti. Un servizio idempotente promette il completamento di ogni richiesta esattamente una volta, in modo tale che effettuare più richieste identiche abbia lo stesso effetto di effettuare una singola richiesta.
+ I client possono inviare richieste API con un token di idempotenza: viene utilizzato lo stesso token ogni volta che si ripete la richiesta. Un'API del servizio idempotente utilizza il token per restituire una risposta identica a quella restituita la prima volta che la richiesta è stata completata.
+ [Amazon EC2: Ensuring Idempotency (EC2: garantire l'idempotenza)](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/Run_Instance_Idempotency.html)
## Risorse
**Documenti correlati:**
+ [Amazon EC2: Ensuring Idempotency (EC2: garantire l'idempotenza)](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/Run_Instance_Idempotency.html)
+ [The Amazon Builders' Library: Difficoltà dei sistemi distribuiti](https://aws.amazon.com/builders-library/challenges-with-distributed-systems/)
+ [The Amazon Builders' Library: Reliability, constant work, and a good cup of coffee](https://aws.amazon.com/builders-library/reliability-and-constant-work/)
**Video correlati:**
+ [AWS New York Summit 2019: Intro to Event-driven Architectures and Amazon EventBridge (AWS New York Summit 2019: Introduzione alle architetture guidate dagli eventi e ad Amazon EventBridge) (MAD205)](https://youtu.be/tvELVa9D9qU)
+ [AWS re:Invent 2018: Close Loops and Opening Minds: How to Take Control of Systems, Big and Small (Chiudere i cicli e aprire le menti: come prendere il controllo dei sistemi, grandi e piccoli) (sono inclusi accoppiamento debole, lavoro costante e stabilità statica) (ARC337)](https://youtu.be/O8xLxNje30M)
+ [AWS re:Invent 2019: Moving to event-driven architectures (Passare alle architetture basate sugli eventi) (SVS308)](https://youtu.be/h46IquqjF3E)
# REL 5 In che modo progetti le interazioni in un sistema distribuito per mitigare o affrontare gli errori?
I sistemi distribuiti si basano sulle reti di comunicazione per interconnettere i componenti (ad esempio server o servizi). Il carico di lavoro deve funzionare in modo affidabile nonostante la perdita o la latenza dei dati su queste reti. I componenti del sistema distribuito devono funzionare in modo da non influire negativamente su altri componenti o sul carico di lavoro. Queste best practice consentono ai carichi di lavoro di affrontare stress o guasti, recuperare più rapidamente e mitigare l'impatto di tali problemi. Il risultato è un miglioramento del tempo medio di ripristino (MTTR).
**Topics**
+ [REL05-BP01 Implementazione del degrado elegante per trasformare le dipendenze forti applicabili in dipendenze deboli](rel_mitigate_interaction_failure_graceful_degradation.md)
+ [REL05-BP02 Richieste di limitazione (della larghezza di banda della rete)](rel_mitigate_interaction_failure_throttle_requests.md)
+ [REL05-BP03 Controllo e limitazione delle chiamate di ripetizione](rel_mitigate_interaction_failure_limit_retries.md)
+ [REL05-BP04 Errore rapido e limitazione delle code](rel_mitigate_interaction_failure_fail_fast.md)
+ [REL05-BP05 Impostazione dei timeout dei client](rel_mitigate_interaction_failure_client_timeouts.md)
+ [REL05-BP06 Rendere i servizi stateless laddove possibile](rel_mitigate_interaction_failure_stateless.md)
+ [REL05-BP07 Implementazione di leve di emergenza](rel_mitigate_interaction_failure_emergency_levers.md)
# REL05-BP01 Implementazione del degrado elegante per trasformare le dipendenze forti applicabili in dipendenze deboli
Quando le dipendenze di un componente non sono integre, il componente stesso può comunque funzionare, anche se in modo degradato. Ad esempio, quando una chiamata di dipendenza non riesce, utilizza invece una risposta statica predeterminata.
Considera un servizio B chiamato dal servizio A che a sua volta chiama il servizio C.
![\[Diagramma che mostra l'errore del servizio C quando viene chiamato dal servizio B. Il servizio B restituisce una risposta degradata al servizio A\]](http://docs.aws.amazon.com/it_it/wellarchitected/2022-03-31/framework/images/graceful-degradation.png)
Quando il servizio B chiama il servizio C, ha ricevuto da quest'ultimo un errore o un timeout. Il servizio B, senza una risposta dal servizio C (e dai dati che contiene) restituisce invece ciò che può. Questo può essere l'ultimo valore buono memorizzato nella cache oppure il servizio B può sostituire una risposta statica predeterminata a ciò che avrebbe ricevuto dal servizio C. Può quindi restituire una risposta degradata all'intermediario, il servizio A. Senza questa risposta statica, l'errore nel servizio C si propagherebbe attraverso il servizio B fino al servizio A, causando una perdita di disponibilità.
Secondo il fattore moltiplicativo nell'equazione di disponibilità per le dipendenze forti (consulta [https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/availability.html#dbedbedda68f9a15ACLX122](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/availability.html#dbedbedda68f9a15ACLX122)), qualsiasi calo della disponibilità di C influisce notevolmente sulla disponibilità effettiva di B. Restituendo il servizio di risposta statica B mitiga l'errore in C e, sebbene degradato, rende la disponibilità del servizio C simile alla disponibilità del 100% (presupponendo che restituisca in modo affidabile la risposta statica in condizioni di errore). La risposta statica è una semplice alternativa alla restituzione di un errore e non è un tentativo di ricalcolare la risposta utilizzando metodi diversi. Tali tentativi a livello di un meccanismo completamente diverso che cercano di ottenere lo stesso risultato sono chiamati comportamento di fallback e sono un anti-modello da evitare.
Un altro esempio di degrado elegante è il *modello dell'interruttore*. Le strategie di ripetizione devono essere utilizzate quando l'errore è transitorio. Quando non è il caso e l'operazione potrebbe non riuscire, il modello dell'interruttore impedisce al client di eseguire una richiesta che potrebbe non riuscire. Quando le richieste vengono elaborate normalmente, l'interruttore viene chiuso e le richieste scorrono. Quando il sistema remoto inizia a restituire errori o presenta una latenza elevata, l'interruttore si apre e la dipendenza viene ignorata o i risultati vengono sostituiti con risposte ottenute più semplicemente, ma meno complete (che potrebbero essere semplicemente una cache di risposta). Periodicamente, il sistema tenta di chiamare la dipendenza per determinare se è stata ripristinata. In questo caso, l'interruttore viene chiuso.
![\[Diagramma che mostra l'interruttore in stato aperto e chiuso.\]](http://docs.aws.amazon.com/it_it/wellarchitected/2022-03-31/framework/images/circuit-breaker.png)
Oltre agli stati chiusi e aperti mostrati nel diagramma, dopo un periodo di tempo configurabile nello stato aperto, l'interruttore può passare allo stato semiaperto. In questo stato, tenta periodicamente di chiamare il servizio a una velocità molto inferiore rispetto al normale. Questa indagine viene utilizzata per controllare lo stato del servizio. Dopo un certo numero di successi nello stato semiaperto, l'interruttore passa allo stato chiuso e le normali richieste riprendono.
**Livello di rischio associato se questa best practice non fosse adottata:** Alta
## Guida all'implementazione
+ Implementa il degrado elegante per trasformare le dipendenze forti applicabili in dipendenze deboli. Quando le dipendenze di un componente non sono integre, il componente stesso può comunque funzionare, anche se in modo degradato. Ad esempio, quando una chiamata di dipendenza non riesce, utilizza invece una risposta statica predeterminata.
+ Restituendo una risposta statica, il carico di lavoro mitiga gli errori che si verificano nelle sue dipendenze.
+ [Corso Well-Architected: Level 300: Implementing Health Checks and Managing Dependencies to Improve Reliability](https://wellarchitectedlabs.com/Reliability/300_Health_Checks_and_Dependencies/README.html)
+ Rileva quando è probabile che l'operazione di ripetizione non vada a buon fine e impedisci al client di effettuare chiamate non riuscite con il modello dell'interruttore.
+ [CircuitBreaker](https://martinfowler.com/bliki/CircuitBreaker.html)
## Risorse
**Documenti correlati:**
+ [Amazon API Gateway: throttling delle richieste API per migliorare le prestazioni](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-request-throttling.html)
+ [CircuitBreaker (riepilogo dal libro Circuit Breaker da "Release It\$1")](https://martinfowler.com/bliki/CircuitBreaker.html)
+ [Ripetizione dei tentativi in caso di errore e backoff esponenziale in AWS](https://docs.aws.amazon.com/general/latest/gr/api-retries.html)
+ [Michael Nygard "Release It\$1 Design and Deploy Production-Ready Software"](https://pragprog.com/titles/mnee2/release-it-second-edition/)
+ [The Amazon Builders' Library: Evitare il fallback nei sistemi distribuiti](https://aws.amazon.com/builders-library/avoiding-fallback-in-distributed-systems)
+ [The Amazon Builders' Library: Evitare insormontabili backlog di code](https://aws.amazon.com/builders-library/avoiding-insurmountable-queue-backlogs)
+ [The Amazon Builders' Library: Sfide e strategie del caching](https://aws.amazon.com/builders-library/caching-challenges-and-strategies/)
+ [The Amazon Builders' Library: Timeout, nuovi tentativi e backoff con jitter](https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/)
**Video correlati:**
+ [Retry, backoff, and jitter: AWS re:Invent 2019: Introducing The Amazon Builders' Library (Presentazione della libreria dei costruttori di Amazon) (DOP328)](https://youtu.be/sKRdemSirDM?t=1884)
**Esempi correlati:**
+ [Corso Well-Architected: Level 300: Implementing Health Checks and Managing Dependencies to Improve Reliability](https://wellarchitectedlabs.com/Reliability/300_Health_Checks_and_Dependencies/README.html)
# REL05-BP02 Richieste di limitazione (della larghezza di banda della rete)
La richiesta di limitazione (della larghezza di banda della rete) è un modello di mitigazione per rispondere a un aumento imprevisto della domanda. Alcune richieste vengono soddisfatte, ma quelle che superano un limite definito vengono rifiutate e restituiscono un messaggio che indica che sono state sottoposte a throttling. L'aspettativa per i client è che si ritirino e abbandonino la richiesta o riprovino a una velocità più lenta.
I servizi devono essere progettati per gestire una capacità nota di richieste che ogni nodo o cella può elaborare. Questa capacità può essere stabilita mediante test di carico. È quindi necessario tenere traccia del tasso di arrivo delle richieste e se il tasso di arrivo temporaneo supera questo limite, la risposta appropriata è segnalare che la richiesta è stata limitata. Ciò consente all'utente di riprovare, potenzialmente su un nodo o una cella differente che potrebbe avere capacità disponibile. Amazon API Gateway fornisce metodi per la limitazione (della larghezza di banda della rete) delle richieste. Amazon SQS e Amazon Kinesis possono eseguire il buffer delle richieste, livellare il tasso di richiesta e alleggerire la necessità di limitazione (della larghezza di banda della rete) per le richieste che possono essere gestite in modo asincrono.
**Livello di rischio associato se questa best practice non fosse adottata:** Alta
## Guida all'implementazione
+ Richieste di limitazione (della larghezza di banda della rete). Si tratta di un modello di mitigazione per rispondere a un aumento imprevisto della domanda. Alcune richieste vengono soddisfatte, ma quelle che superano un limite definito vengono rifiutate e restituiscono un messaggio che indica che sono state sottoposte a throttling. L'aspettativa per i client è che si ritirino e abbandonino la richiesta o riprovino a una velocità più lenta.
+ Utilizzo di Amazon API Gateway
+ [throttling delle richieste API per migliorare il throughput](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-request-throttling.html)
## Risorse
**Documenti correlati:**
+ [Amazon API Gateway: throttling delle richieste API per migliorare le prestazioni](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-request-throttling.html)
+ [Ripetizione dei tentativi in caso di errore e backoff esponenziale in AWS](https://docs.aws.amazon.com/general/latest/gr/api-retries.html)
+ [The Amazon Builders' Library: Evitare il fallback nei sistemi distribuiti](https://aws.amazon.com/builders-library/avoiding-fallback-in-distributed-systems)
+ [The Amazon Builders' Library: Evitare insormontabili backlog di code](https://aws.amazon.com/builders-library/avoiding-insurmountable-queue-backlogs)
+ [The Amazon Builders' Library: Timeout, nuovi tentativi e backoff con jitter](https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/)
+ [throttling delle richieste API per migliorare il throughput](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-request-throttling.html)
**Video correlati:**
+ [Retry, backoff, and jitter: AWS re:Invent 2019: Introducing The Amazon Builders' Library (Presentazione della libreria dei costruttori di Amazon) (DOP328)](https://youtu.be/sKRdemSirDM?t=1884)
# REL05-BP03 Controllo e limitazione delle chiamate di ripetizione
Utilizza il backoff esponenziale per eseguire nuovi tentativi dopo intervalli progressivamente più lunghi. Introduci il jitter per randomizzare gli intervalli di ripetizione e limitare il numero massimo di tentativi.
I componenti tipici di un sistema software distribuito includono server, sistemi di bilanciamento del carico, database e server DNS. Durante il funzionamento, e sempre soggetti ad anomalie, uno qualsiasi tra questi componenti può iniziare a generare errori. La tecnica predefinita per gestire gli errori consiste nell'implementare nuovi tentativi lato client. Questa tecnica aumenta l'affidabilità e la disponibilità dell'applicazione. Tuttavia, su vasta scala, e se i client tentano di riprovare l'operazione fallita non appena si verifica un errore, la rete può diventare rapidamente satura di richieste nuove e riproposte, ognuna delle quali compete per la larghezza di banda della rete. Ciò può causare una *tempesta di ripetizione dei tentativi,* che ridurrà la disponibilità del servizio. Questo modello potrebbe continuare finché non si verifica un errore completo del sistema.
Per evitare tali scenari, è necessario utilizzare gli algoritmi di backoff come il *backoff esponenziale* comune. Gli algoritmi di backoff esponenziale riducono gradualmente la velocità con cui vengono eseguiti i nuovi tentativi, evitando così la congestione della rete.
Molti SDK e librerie software, inclusi quelli di AWS, implementano una versione di questi algoritmi. Tuttavia, **non dare mai per scontato che esista un algoritmo di backoff: esegui sempre test e verificane la presenza.**
Il backoff semplice da solo non è sufficiente perché nei sistemi distribuiti tutti i client possono eseguire simultaneamente il backoff, creando cluster di chiamate ripetute. Nel suo post del blog [Exponential Backoff and Jitter (Jitter e backoff esponenziale) ](https://aws.amazon.com/blogs/architecture/exponential-backoff-and-italics%0djitter/), spiega come modificare la funzione wait() nel backoff esponenziale per evitare cluster di chiamate riproposte. La soluzione consiste nell'aggiungere *jitter* nella funzione wait(). Per evitare di eseguire nuovi tentativi per troppo tempo, le implementazioni dovrebbero limitare il backoff a un valore massimo.
Infine, è importante configurare un *numero massimo di tentativi* o di tempo trascorso, dopo il quale i nuovi tentativi semplicemente falliranno. Gli SDK AWS lo implementano per impostazione predefinita e può essere configurato. Per i servizi di livello inferiore, un limite massimo di tentativi di risposta pari a zero o a uno può limitare il rischio ed essere comunque efficace in quanto i tentativi di risposta sono delegati ai servizi di livello superiore.
**Livello di rischio associato se questa best practice non fosse adottata:** Alta
## Guida all'implementazione
+ Controlla e limita le chiamate riproposte. Utilizza il backoff esponenziale per eseguire nuovi tentativi dopo intervalli progressivamente più lunghi. Introduci il jitter per randomizzare gli intervalli di ripetizione e limitare il numero massimo di tentativi.
+ [Ripetizione dei tentativi in caso di errore e backoff esponenziale in AWS](https://docs.aws.amazon.com/general/latest/gr/api-retries.html)
+ Gli SDK di Amazon implementano i nuovi tentativi e il backoff esponenziale per impostazione predefinita. Potrai implementare una logica similare nel tuo livello di dipendenze quando effettui chiamate ai tuoi servizi dipendenti. Potrai decidere quali sono i timeout e quando cessare i tentativi in base al tuo caso d'uso.
## Risorse
**Documenti correlati:**
+ [Amazon API Gateway: throttling delle richieste API per migliorare le prestazioni ](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-request-throttling.html)
+ [Ripetizione dei tentativi in caso di errore e backoff esponenziale in AWS](https://docs.aws.amazon.com/general/latest/gr/api-retries.html)
+ [The Amazon Builders' Library: Evitare il fallback nei sistemi distribuiti](https://aws.amazon.com/builders-library/avoiding-fallback-in-distributed-systems)
+ [The Amazon Builders' Library: Evitare insormontabili backlog di code](https://aws.amazon.com/builders-library/avoiding-insurmountable-queue-backlogs)
+ [The Amazon Builders' Library: Sfide e strategie del caching](https://aws.amazon.com/builders-library/caching-challenges-and-strategies/)
+ [The Amazon Builders' Library: Timeout, nuovi tentativi e backoff con jitter](https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/)
**Video correlati:**
+ [Retry, backoff, and jitter: AWS re:Invent 2019: Introducing The Amazon Builders' Library (Presentazione della libreria dei costruttori di Amazon) (DOP328)](https://youtu.be/sKRdemSirDM?t=1884)
# REL05-BP04 Errore rapido e limitazione delle code
Se il carico di lavoro non è in grado di rispondere correttamente a una richiesta, restituisce rapidamente un errore. Ciò consente il rilascio delle risorse associate a una richiesta e permette al servizio di recuperare se le risorse sono in esaurimento. Se il carico di lavoro è in grado di rispondere correttamente, ma la frequenza delle richieste è troppo elevata, utilizza una coda per eseguire il buffer delle richieste. Tuttavia, non consentire code lunghe che possono comportare l'elaborazione di richieste obsolete a cui il client ha già rinunciato.
Questa best practice si applica al lato server, o ricevitore, della richiesta.
Tieni presente che le code possono essere create a più livelli di un sistema e possono compromettere notevolmente la possibilità di recuperare rapidamente quando le richieste obsolete (che non necessitano più di una risposta) vengono elaborate prima di richieste più recenti. Fai attenzione ai luoghi in cui sono presenti code. Spesso si nascondono nei flussi di lavoro o nel lavoro registrato in un database.
**Livello di rischio associato se questa best practice non fosse adottata:** Alta
## Guida all'implementazione
+ Errore rapido e limitazione delle code. Se il carico di lavoro non è in grado di rispondere correttamente a una richiesta, restituisce rapidamente un errore. Ciò consente il rilascio delle risorse associate a una richiesta e permette al servizio di recuperare se le risorse sono in esaurimento. Se il carico di lavoro è in grado di rispondere correttamente, ma la frequenza delle richieste è troppo elevata, utilizza una coda per eseguire il buffer delle richieste. Tuttavia, non consentire code lunghe che possono comportare l'elaborazione di richieste obsolete a cui il client ha già rinunciato.
+ Implementazione d'errore rapido quando il servizio è eccessivamente sollecitato.it
+ [Errore rapido](https://www.martinfowler.com/ieeeSoftware/failFast.pdf)
+ Limita le code in un sistema basato su code, quando l'elaborazione si interrompe ma i messaggi continuano ad arrivare, il debito di messaggi può accumularsi in un backlog di grandi dimensioni, determinando un aumento del tempo di elaborazione. Il lavoro potrebbe essere completato troppo tardi perché i risultati siano utili, provocando essenzialmente il danneggiamento della disponibilità che l'accodamento doveva evitare.
+ [The Amazon Builders' Library: Evitare insormontabili backlog di code](https://aws.amazon.com/builders-library/avoiding-insurmountable-queue-backlogs)
## Risorse
**Documenti correlati:**
+ [Ripetizione dei tentativi in caso di errore e backoff esponenziale in AWS](https://docs.aws.amazon.com/general/latest/gr/api-retries.html)
+ [Errore rapido](https://www.martinfowler.com/ieeeSoftware/failFast.pdf)
+ [The Amazon Builders' Library: Evitare il fallback nei sistemi distribuiti](https://aws.amazon.com/builders-library/avoiding-fallback-in-distributed-systems)
+ [The Amazon Builders' Library: Evitare insormontabili backlog di code](https://aws.amazon.com/builders-library/avoiding-insurmountable-queue-backlogs)
+ [The Amazon Builders' Library: Sfide e strategie del caching](https://aws.amazon.com/builders-library/caching-challenges-and-strategies/)
+ [The Amazon Builders' Library: Timeout, nuovi tentativi e backoff con jitter](https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/)
**Video correlati:**
+ [Retry, backoff, and jitter: AWS re:Invent 2019: Introducing The Amazon Builders' Library (Presentazione della libreria dei costruttori di Amazon) (DOP328)](https://youtu.be/sKRdemSirDM?t=1884)
# REL05-BP05 Impostazione dei timeout dei client
Imposta i timeout in modo appropriato, verificali sistematicamente e non fare affidamento sui valori predefiniti poiché sono generalmente troppo alti.
Questa best practice si applica al lato client, o al mittente, della richiesta.
Imposta sia un timeout di connessione che un timeout di richiesta su qualsiasi chiamata remota e, generalmente, su qualsiasi chiamata tra i processi. Molti framework offrono funzionalità di timeout integrate, ma fai attenzione perché molti hanno valori predefiniti infiniti o troppo alti. Un valore troppo elevato riduce l'utilità del timeout perché le risorse continuano a essere consumate mentre il client attende che si verifichi il timeout. Un valore troppo basso può generare un aumento del traffico sul back-end e una maggiore latenza perché vengono ritentate troppe richieste. In alcuni casi, questo può portare a interruzioni complete perché tutte le richieste vengono ritentate.
Per ulteriori informazioni su come Amazon utilizza timeout, nuovi tentativi e backoff con jitter, consulta la [https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/?did=ba_card&trk=ba_card](https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/?did=ba_card&trk=ba_card).
**Livello di rischio associato se questa best practice non fosse adottata:** Alta
## Guida all'implementazione
+ Imposta sia un timeout di connessione che un timeout di richiesta su qualsiasi chiamata remota e, generalmente, su qualsiasi chiamata tra i processi. Molti framework offrono funzionalità di timeout integrate, ma fai attenzione perché molti hanno valori predefiniti infiniti o troppo alti. Un valore troppo elevato riduce l'utilità del timeout perché le risorse continuano a essere consumate mentre il client attende che si verifichi il timeout. Un valore troppo basso può generare un aumento del traffico sul back-end e una maggiore latenza perché vengono ritentate troppe richieste. In alcuni casi, questo può portare a interruzioni complete perché tutte le richieste vengono ritentate.
+ [AWS SDK: Retries and Timeouts (SDK AWS: nuovi tentativi e timeout)](https://docs.aws.amazon.com/sdk-for-net/v3/developer-guide/retries-timeouts.html)
## Risorse
**Documenti correlati:**
+ [AWS SDK: Retries and Timeouts (SDK AWS: nuovi tentativi e timeout)](https://docs.aws.amazon.com/sdk-for-net/v3/developer-guide/retries-timeouts.html)
+ [Amazon API Gateway: throttling delle richieste API per migliorare le prestazioni](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-request-throttling.html)
+ [Ripetizione dei tentativi in caso di errore e backoff esponenziale in AWS](https://docs.aws.amazon.com/general/latest/gr/api-retries.html)
+ [The Amazon Builders' Library: Timeout, nuovi tentativi e backoff con jitter](https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/)
**Video correlati:**
+ [Retry, backoff, and jitter: AWS re:Invent 2019: Introducing The Amazon Builders' Library (Presentazione della libreria dei costruttori di Amazon) (DOP328)](https://youtu.be/sKRdemSirDM?t=1884)
# REL05-BP06 Rendere i servizi stateless laddove possibile
I servizi non devono richiedere lo stato oppure devono eseguire l'offload dello stato in modo tale che, tra diverse richieste client, non vi sia alcuna dipendenza dai dati archiviati localmente su disco o in memoria. In questo modo i server possono essere sostituiti a piacimento senza compromettere la disponibilità. Amazon ElastiCache o Amazon DynamoDB sono ottime destinazioni per lo stato di offload.
![\[In questa applicazione Web stateless, viene eseguito l'offload dello stato della sessione in Amazon ElastiCache.\]](http://docs.aws.amazon.com/it_it/wellarchitected/2022-03-31/framework/images/stateless-webapp.png)
Quando gli utenti o i servizi interagiscono con un'applicazione, spesso eseguono una serie di interazioni che formano una sessione. Una sessione è un dato univoco per gli utenti che persistono tra le richieste mentre utilizzano l'applicazione. Un'applicazione stateless è un'applicazione che non richiede la conoscenza delle interazioni precedenti e non memorizza le informazioni sulla sessione.
Una volta progettata per essere stateless, puoi utilizzare servizi di elaborazione serverless, come AWS Lambda o AWS Fargate.
Oltre alla sostituzione del server, un altro vantaggio delle applicazioni stateless è che possono ricalibrare orizzontalmente perché qualsiasi risorsa di calcolo disponibile (ad esempio istanze EC2 e funzioni AWS Lambda) può soddisfare ogni richiesta.
**Livello di rischio associato se questa best practice non fosse adottata:** Medium
## Guida all'implementazione
+ Trasforma le applicazioni in stateless. Applicazioni stateless consentono un dimensionamento orizzontale e sono tolleranti al guasto di un singolo nodo.
+ Eliminazione dello stato che potrebbe effettivamente essere memorizzato nei parametri di richiesta.
+ Dopo aver esaminato se lo stato è necessario, sposta qualsiasi tracciamento dello stato in una cache multizona resiliente o in un archivio di dati come Amazon ElastiCache, Amazon RDS, Amazon DynamoDB o una soluzione di dati distribuiti di terze parti. Memorizza uno stato impossibile da spostare in datastore resilienti.
+ Alcuni dati (come i cookie) possono passare nei titoli o nei parametri di query.
+ Effettua il refactoring per rimuovere uno stato che può essere passato velocemente nelle richieste.
+ È possibile che alcuni dati non siano effettivamente necessari per richiesta e possano essere recuperati on demand.
+ Rimuovi i dati recuperabili in modo asincrono.
+ Scegli un datastore che soddisfi i requisiti per uno stato necessario.
+ Valuta l'utilizzo di un database NoSQL per dati non relazionali.
## Risorse
**Documenti correlati:**
+ [The Amazon Builders' Library: Evitare il fallback nei sistemi distribuiti](https://aws.amazon.com/builders-library/avoiding-fallback-in-distributed-systems)
+ [The Amazon Builders' Library: Evitare insormontabili backlog di code](https://aws.amazon.com/builders-library/avoiding-insurmountable-queue-backlogs)
+ [The Amazon Builders' Library: Sfide e strategie del caching](https://aws.amazon.com/builders-library/caching-challenges-and-strategies/)
# REL05-BP07 Implementazione di leve di emergenza
Le leve di emergenza sono processi rapidi che possono mitigare l'impatto sulla disponibilità sul carico di lavoro.
**Livello di rischio associato se questa best practice non fosse adottata:** Medium
## Guida all'implementazione
+ Implementa leve di emergenza. Si tratta di processi rapidi che possono mitigare l'impatto della disponibilità sul carico di lavoro. Possono essere utilizzati in assenza di una causa principale. Una leva di emergenza ideale riduce a zero il carico cognitivo dei resolver fornendo criteri di attivazione e disattivazione completamente deterministici. Le leve sono spesso manuali, ma possono anche essere automatizzate
+ Esempi di leve includono
+ Bloccare tutto il traffico dei robot
+ Servire pagine statiche anziché dinamiche
+ Ridurre la frequenza delle chiamate a una dipendenza
+ Limitare le chiamate dalle dipendenze
+ Suggerimenti per l'implementazione e l'utilizzo di leve di emergenza
+ Quando le leve sono attivate, fai di meno, non di più
+ Rendi le cose semplici, evita comportamenti bimodali
+ Testare periodicamente le leve
+ Di seguito sono elencati alcuni esempi di operazioni che NON rappresentano leve di emergenza
+ Aggiunta di capacità
+ Chiamare i proprietari dei servizi dei client che dipendono dal tuo servizio e chiedere loro di ridurre le chiamate
+ Apportare una modifica al codice e rilasciarlo
# Gestione delle modifiche
**Topics**
+ [REL 6 In che modo monitori le risorse del carico di lavoro?](w2aac19b9b9b5.md)
+ [REL 7 In che modo progetti il carico di lavoro per adattarti ai cambiamenti della domanda?](w2aac19b9b9b7.md)
+ [REL 8 In che modo implementi le modifiche?](w2aac19b9b9b9.md)
# REL 6 In che modo monitori le risorse del carico di lavoro?
I log e i parametri sono strumenti molto efficaci per ottenere informazioni sullo stato del tuo carico di lavoro. È possibile configurare il carico di lavoro in modo da monitorare i log e i parametri e inviare notifiche quando vengono superate le soglie o si verificano eventi significativi. Il monitoraggio consente al carico di lavoro di riconoscere quando vengono superate le soglie di prestazioni basse o si verificano errori, in modo che possa essere ripristinato automaticamente di rimando.
**Topics**
+ [REL06-BP01 Monitoraggio di tutti i componenti per il carico di lavoro (generazione)](rel_monitor_aws_resources_monitor_resources.md)
+ [REL06-BP02 Definizione e calcolo dei parametri (aggregazione)](rel_monitor_aws_resources_notification_aggregation.md)
+ [REL06-BP03 Invio di notifiche (elaborazione e avvisi in tempo reale)](rel_monitor_aws_resources_notification_monitor.md)
+ [REL06-BP04 Automatizzazione delle risposte (elaborazione e avvisi in tempo reale)](rel_monitor_aws_resources_automate_response_monitor.md)
+ [REL06-BP05 Analisi](rel_monitor_aws_resources_storage_analytics.md)
+ [REL06-BP06 Esecuzione di revisioni periodiche](rel_monitor_aws_resources_review_monitoring.md)
+ [REL06-BP07 Monitoraggio del tracciamento end-to-end delle richieste attraverso il sistema](rel_monitor_aws_resources_end_to_end.md)
# REL06-BP01 Monitoraggio di tutti i componenti per il carico di lavoro (generazione)
monitora i componenti del carico di lavoro con Amazon CloudWatch o con strumenti di terze parti. Monitora i servizi AWS con il pannello di controllo AWS Health.
Occorre monitorare tutti i componenti del carico di lavoro, inclusi front-end, logica aziendale e livelli di storage. Definisci i parametri chiave e come estrarli dai registri, se necessario, e imposta soglie per l'attivazione degli eventi di allarme corrispondenti. Assicurati che i parametri siano pertinenti agli indicatori chiave di prestazione (KPI) del tuo carico di lavoro e utilizza i parametri e i registri per identificare i primi segnali di degrado del servizio. Ad esempio, un parametro legato ai risultati aziendali, come il numero di ordini elaborati con successo al minuto, può indicare problemi di carico di lavoro più rapidamente di un parametro tecnico, come l'utilizzo della CPU. Utilizza il pannello di controllo AWS Health per una visualizzazione personalizzata delle prestazioni e della disponibilità dei servizi AWS sottostanti alle risorse AWS.
Il monitoraggio nel cloud offre nuove opportunità. La maggior parte dei provider cloud ha sviluppato hook personalizzabili e può fornire approfondimenti per aiutarti a monitorare più livelli del carico di lavoro. I servizi AWS come Amazon CloudWatch applicano algoritmi statistici e di apprendimento automatico per analizzare continuamente i parametri di sistemi e applicazioni, determinare le normali linee di base e far emergere le anomalie con un intervento minimo da parte dell'utente. Gli algoritmi di rilevamento delle anomalie tengono conto della stagionalità e delle variazioni di tendenza dei parametri.
AWS mette a disposizione una grande quantità di informazioni di monitoraggio e di registro che possono essere utilizzate per definire parametri specifici per i carichi di lavoro, processi di variazione della domanda e per l'adozione di tecniche di apprendimento automatico indipendentemente dalle competenze di ML.
Inoltre, monitora tutti gli endpoint esterni per avere la certezza che siano indipendenti dall'implementazione di base. Questo monitoraggio attivo può essere effettuato con transazioni sintetiche (talvolta indicate come *canary utente,*ma da non confondere con le implementazioni canary) che eseguono periodicamente una serie di attività comuni che corrispondono alle azioni eseguite dai client del carico di lavoro. Mantieni queste attività di breve durata e assicurati di non sovraccaricare il carico di lavoro durante il test. Amazon CloudWatch Synthetics ti consente di [creare canary sintetici](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html) per monitorare gli endpoint e le API. Puoi anche combinare i nodi client sintetici Canary con la console AWS X-Ray per individuare quali Canary sintetiche stanno riscontrando problemi con errori, guasti o velocità di throttling per l'intervallo di tempo selezionato.
**Risultato desiderato: **
raccogliere e utilizzare i parametri critici di tutti i componenti del carico di lavoro per garantire l'affidabilità del carico di lavoro e un'esperienza utente ottimale. Rilevare che un carico di lavoro non sta raggiungendo i risultati aziendali consente di dichiarare rapidamente un disastro e di riprendersi da un incidente.
**Anti-pattern comuni:**
+ Solo monitoraggio delle interfacce esterne per il carico di lavoro.
+ Non generare parametri specifici per il carico di lavoro e affidati solo ai parametri forniti dai servizi AWS utilizzati dal carico di lavoro.
+ Utilizzare solo parametri tecnici nel carico di lavoro e non monitorare i parametri relativi agli indicatori chiave di prestazione (KPI) non tecnici a cui il carico di lavoro contribuisce.
+ Affidarsi al traffico di produzione e a semplici controlli di integrità per monitorare e valutare lo stato del carico di lavoro.
**Vantaggi dell'adozione di questa best practice:** il monitoraggio a tutti i livelli del carico di lavoro consente di prevedere e risolvere più rapidamente i problemi dei componenti che costituiscono il carico di lavoro.
**Livello di rischio associato se questa best practice non fosse adottata:** Alta
## Guida all'implementazione
1. **Abilitazione della registrazione ove disponibile.** I dati di monitoraggio devono essere ottenuti da tutti i componenti dei carichi di lavoro. Attiva ulteriori registri, come i registri di accesso S3, e abilita il carico di lavoro per registrare i dati specifici del carico di lavoro. Raccogli i parametri per le medie di CPU, I/O di rete e I/O su disco da servizi come Amazon ECS, Amazon EKS, Amazon EC2, Elastic Load Balancing, AWS Auto Scaling ed Amazon EMR. Consulta [Servizi AWS che pubblicano parametri CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CW_Support_For_AWS.html) Servizi AWS che pubblicano parametri su CloudWatch.
1. **Esamina tutti i parametri predefiniti ed esplora eventuali lacune nella raccolta dei dati.** Tutti i servizi generano parametri predefiniti. La raccolta di parametri predefiniti consente di comprendere meglio le dipendenze tra i componenti del carico di lavoro e il modo in cui l'affidabilità e le prestazioni dei componenti influiscono sul carico di lavoro. Puoi anche creare e [pubblicare parametri propri](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/publishingMetrics.html) affinché CloudWatch utilizzi la AWS CLI o un'API. Questo
1. **valuta tutti i parametri per decidere quelli a cui inviare avvisi per ogni servizio AWS nel carico di lavoro.** Puoi scegliere di selezionare un sottoinsieme di parametri che hanno un impatto importante sull'affidabilità del carico di lavoro. La focalizzazione su soglie e parametri critici consente di affinare il numero di avvisi [informativi](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html) e può contribuire a ridurre al minimo i falsi positivi.
1. **Definisci gli avvisi e il processo di recupero del carico di lavoro dopo l'attivazione dell'avviso.** La definizione degli avvisi consente di notificare, intensificare e seguire rapidamente le fasi necessarie per il ripristino da un incidente e il rispetto dell'obiettivo di tempo di ripristino (RTO) prescritto. Puoi utilizzare [https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html#alarms-and-actions](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html#alarms-and-actions) per invocare flussi di lavoro automatici e avviare procedure di ripristino in base a soglie definite.
1. **Esplora l'uso di transazioni sintetiche per raccogliere dati rilevanti sullo stato dei carichi di lavoro.** Il monitoraggio sintetico segue gli stessi percorsi ed esegue le stesse azioni di un cliente, il che consente di verificare continuamente l'esperienza del cliente anche quando non c'è traffico di clienti sui carichi di lavoro. Utilizzando [le transazioni sintetiche,](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html)puoi individuare i problemi prima dei clienti.
## Risorse
**Best practice correlate:**
+ [REL11-BP03 Automatizzazione della riparazione a tutti i livelli](rel_withstand_component_failures_auto_healing_system.md)
**Documenti correlati:**
+ [Getting started with your AWS Health Dashboard – Your account health (Nozioni di base su AWS HealthDashboard: stato del tuo account)](https://docs.aws.amazon.com/health/latest/ug/getting-started-health-dashboard.html)
+ [Servizi AWS che pubblicano parametri CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CW_Support_For_AWS.html)
+ [Log di accesso per Network Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/load-balancer-access-logs.html)
+ [Log di accesso per Application Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-access-logs.html)
+ [Accesso a Amazon CloudWatch Logs per AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/monitoring-functions-logs.html)
+ [Registrazione delle richieste con registrazione dell'accesso al server Amazon S3 ](https://docs.aws.amazon.com/AmazonS3/latest/dev/ServerLogs.html)
+ [Abilita i log di accesso per Classic Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/classic/enable-access-logs.html)
+ [Esportazione di dati di registro in Amazon S3](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/S3Export.html)
+ [Installazione dell'agente CloudWatch su un'istanza Amazon EC2](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/install-CloudWatch-Agent-on-EC2-Instance.html)
+ [Pubblicazione di parametri personalizzati](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/publishingMetrics.html)
+ [Utilizzo dei pannelli di controllo Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html)
+ [Utilizzare i parametri Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/working_with_metrics.html)
+ [Utilizzo di Canary (Amazon CloudWatch Synthetics)](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html)
+ [Cosa sono i Amazon CloudWatch Logs?](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/WhatIsCloudWatchLogs.html)
**Guide per l'utente:**
+ [Creazione di un trail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-create-a-trail-using-the-console-first-time.html)
+ [Monitoraggio dei parametri di memoria e del disco per le istanze Amazon EC2 Linux](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/mon-scripts.html)
+ [Utilizzo di CloudWatch Logs con istanze di container](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/using_cloudwatch_logs.html)
+ [Log di flusso VPC](https://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/flow-logs.html)
+ [Che cos'è Amazon DevOps Guru?](https://docs.aws.amazon.com/devops-guru/latest/userguide/welcome.html)
+ [Che cos'è AWS X-Ray?](https://docs.aws.amazon.com/xray/latest/devguide/aws-xray.html)
**Blog correlati:**
+ [Effettuare il debug con Amazon CloudWatch Synthetics e AWS X-Ray](https://aws.amazon.com/blogs/devops/debugging-with-amazon-cloudwatch-synthetics-and-aws-x-ray/)
**Esempi e workshop correlati:**
+ [AWS Well-Architected Labs: Operational Excellence - Dependency Monitoring (Laboratori ben strutturati AWS: Eccellenza operativa - Monitoraggio delle dipendenze)](https://wellarchitectedlabs.com/operational-excellence/100_labs/100_dependency_monitoring/)
+ [The Amazon Builders' Library: Dotazione dei sistemi distribuiti per la visibilità operativa](https://aws.amazon.com/builders-library/instrumenting-distributed-systems-for-operational-visibility/)
+ [Workshop sull'osservabilità](https://catalog.workshops.aws/observability/en-US)
# REL06-BP02 Definizione e calcolo dei parametri (aggregazione)
Archivia i dati di registro e applica i filtri, laddove necessari, per calcolare i parametri, ad esempio i conteggi di un evento di registro specifico o la latenza calcolata dai timestamp del registro eventi.
Amazon CloudWatch e Amazon S3 fungono da principali livelli di aggregazione e storage. Per alcuni servizi, come AWS Auto Scaling e Elastic Load Balancing, i parametri predefiniti vengono forniti per impostazione predefinita per il carico della CPU o la latenza media delle richieste in un cluster o in un'istanza. Per i servizi di streaming, come i registri di flusso VPC e AWS CloudTrail, i dati degli eventi vengono inoltrati a CloudWatch Logs ed è necessario definire e applicare filtri di parametri per estrarre i parametri dai dati dell'evento. In questo modo vengono forniti dati di serie temporali, che possono fungere da input per gli allarmi CloudWatch definiti dall'utente per attivare gli avvisi.
**Livello di rischio associato se questa best practice non fosse adottata:** Alta
## Guida all'implementazione
+ Aggregazione: definisci e calcola i parametri. Archivia i dati di log e applica filtri, se necessario, per calcolare i parametri, ad esempio i conteggi di un evento di log specifico o la latenza calcolata dai timestamp degli eventi di log
+ I filtri dei parametri definiscono i termini e i modelli da ricercare nei dati di registro inviati a CloudWatch Logs. CloudWatch Logs utilizza questi filtri di parametri per trasformare i dati di registro in parametri CloudWatch numerici che è possibile rappresentare su un grafico o un avviso.
+ [Ricerca e filtraggio dei dati di log](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/MonitoringLogData.html)
+ Utilizza una terza parte affidabile per aggregare i registri.
+ Segui le istruzioni che ti vengono fornite dalle terze parti. La maggior parte dei prodotti di terze parti si integra con CloudWatch e Amazon S3.
+ Alcuni servizi AWS possono pubblicare registri direttamente in Amazon S3. Se il requisito principale per i registri è l'archiviazione in Amazon S3, si può facilmente fare in modo che il servizio che produce i registri li invii direttamente a Amazon S3, senza dover creare un'infrastruttura aggiuntiva.
+ [Invio di registri direttamente a Amazon S3](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/Sending-Logs-Directly-To-S3.html)
## Risorse
**Documenti correlati:**
+ [Query di esempio di Amazon CloudWatch Logs Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CWL_QuerySyntax-examples.html)
+ [Effettuare il debug con Amazon CloudWatch Synthetics e AWS X-Ray](https://aws.amazon.com/blogs/devops/debugging-with-amazon-cloudwatch-synthetics-and-aws-x-ray/)
+ [One Observability Workshop](https://observability.workshop.aws/)
+ [Ricerca e filtraggio dei dati di log](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/MonitoringLogData.html)
+ [Invio di registri direttamente a Amazon S3](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/Sending-Logs-Directly-To-S3.html)
+ [The Amazon Builders' Library: Dotazione dei sistemi distribuiti per la visibilità operativa](https://aws.amazon.com/builders-library/instrumenting-distributed-systems-for-operational-visibility/)
# REL06-BP03 Invio di notifiche (elaborazione e avvisi in tempo reale)
Le organizzazioni interessate ricevono le notifiche quando si verificano eventi significativi.
Gli avvisi possono essere inviati ad argomenti Amazon Simple Notification Service (Amazon SNS) e poi inoltrati a un numero qualsiasi di iscritti. Ad esempio, Amazon SNS può inoltrare avvisi a un alias e-mail in modo che il personale tecnico possa rispondere.
**Anti-pattern comuni:**
+ La configurazione di avvisi a una soglia troppo bassa causa l'invio di troppe notifiche.
+ Non archiviare avvisi per l'esplorazione futura.
**Vantaggi dell'adozione di questa best practice:** le notifiche sugli eventi (anche quelle che è possibile gestire e risolvere in automatico) consentono di avere un record di eventi e di affrontarli potenzialmente in modo diverso in futuro.
**Livello di rischio associato se questa best practice non fosse adottata:** Alta
## Guida all'implementazione
+ Elaborazione e avvisi in tempo reale. Le organizzazioni che devono essere messe al corrente ricevono le notifiche nel caso si verifichino eventi significativi
+ I pannelli di controllo di Amazon CloudWatch sono home page personalizzabili nella console CloudWatch che puoi utilizzare per monitorare le tue risorse in un'unica visualizzazione, anche quelle distribuite tra regioni diverse.
+ [Utilizzo dei pannelli di controllo Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html)
+ Crea un avviso quando un parametro supera un limite.
+ [Utilizzo degli allarmi di Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html)
## Risorse
**Documenti correlati:**
+ [One Observability Workshop](https://observability.workshop.aws/)
+ [The Amazon Builders' Library: Dotazione dei sistemi distribuiti per la visibilità operativa](https://aws.amazon.com/builders-library/instrumenting-distributed-systems-for-operational-visibility/)
+ [Utilizzo degli allarmi di Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html)
+ [Utilizzo dei pannelli di controllo Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html)
+ [Utilizzare i parametri Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/working_with_metrics.html)
# REL06-BP04 Automatizzazione delle risposte (elaborazione e avvisi in tempo reale)
utilizza l'automazione per agire quando viene rilevato un evento; ad esempio, per sostituire i componenti guasti.
Gli avvisi possono attivare eventi di AWS Auto Scaling, in modo che i cluster reagiscano ai cambiamenti della domanda. Gli avvisi possono essere inviati a Amazon Simple Queue Service (Amazon SQS), che può fungere da punto di integrazione per sistemi di ticket di terze parti. AWS Lambda può anche effettuare l'iscrizione ad avvisi, fornendo agli utenti un modello serverless asincrono che reagisce alle modifiche in modo dinamico. AWS Config monitora e registra continuamente le configurazioni delle risorse AWS e può attivare [AWS Systems Manager Automation](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html) per risolvere i problemi.
Amazon DevOps Guru monitora automaticamente le risorse dell'applicazione per rilevare comportamenti anomali e fornisce raccomandazioni mirate per accelerare i tempi di identificazione e riparazione dei problemi.
**Livello di rischio associato se questa best practice non fosse adottata:** Medium
## Guida all'implementazione
+ Utilizza Amazon DevOps Guru per eseguire azioni automatizzate. Amazon DevOps Guru monitora automaticamente le risorse dell'applicazione per rilevare comportamenti anomali e fornisce raccomandazioni mirate per accelerare i tempi di identificazione e riparazione dei problemi.
+ [What is Amazon DevOps Guru? (Che cos'è Amazon DevOps Guru?)](https://docs.aws.amazon.com/devops-guru/latest/userguide/welcome.html)
+ Utilizza AWS Systems Manager per eseguire azioni automatizzate. AWS Config monitora e registra in modo continuo le configurazioni delle risorse AWS e può attivare AWS Systems Manager per risolvere i problemi.
+ [AWS Systems Manager Automation](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html)
+ Crea e utilizza documenti Systems Manager Automation. Questi definiscono le operazioni che Systems Manager esegue sulle istanze gestite e su altre risorse AWS quando si avvia un processo di automazione.
+ [Gestione dei documenti di automazione (playbook)](https://docs.aws.amazon.com/systems-manager/latest/userguide/automation-documents.html)
+ Amazon CloudWatch invia eventi di modifica dello stato di avviso a Amazon EventBridge. Crea regole di EventBridge per automatizzare le risposte.
+ [Creazione di una regola EventBridge che si attivi su un evento da una risorsa AWS](https://docs.aws.amazon.com/eventbridge/latest/userguide/create-eventbridge-rule.html)
+ Crea ed esegui un piano per automatizzare le risposte.
+ Effettua l'inventario di tutte le procedure di risposta agli avvisi. Devi pianificare le risposte agli avvisi prima di classificare le attività.
+ Effettua l'inventario di tutte le attività con azioni specifiche da intraprendere. La maggior parte di queste azioni è documentata nei runbook. È inoltre necessario disporre di playbook per gli avvisi relativi a eventi imprevisti.
+ Esamina i runbook e i playbook per tutte le azioni automatizzabili. In generale, se è possibile definire un'azione, è molto probabile che si possa anche automatizzare.
+ Classifica innanzitutto le attività soggette a errori o dispendiose in termini di tempo. È molto utile eliminare le fonti di errore e ridurre i tempi di risoluzione.
+ Definisci un piano per completare l'automazione. Mantieni un piano attivo per automatizzare e aggiornare l'automazione.
+ Esamina i requisiti manuali per le opportunità di automazione. Metti alla prova il processo manuale per scoprire opportunità di automazione.
## Risorse
**Documenti correlati:**
+ [AWS Systems Manager Automation](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html)
+ [Creazione di una regola EventBridge che si attivi su un evento da una risorsa AWS](https://docs.aws.amazon.com/eventbridge/latest/userguide/create-eventbridge-rule.html)
+ [One Observability Workshop](https://observability.workshop.aws/)
+ [The Amazon Builders' Library: Dotazione dei sistemi distribuiti per la visibilità operativa](https://aws.amazon.com/builders-library/instrumenting-distributed-systems-for-operational-visibility/)
+ [What is Amazon DevOps Guru? (Che cos'è Amazon DevOps Guru?)](https://docs.aws.amazon.com/devops-guru/latest/userguide/welcome.html)
+ [Gestione dei documenti di automazione (playbook)](https://docs.aws.amazon.com/systems-manager/latest/userguide/automation-documents.html)
# REL06-BP05 Analisi
raccogli i file di log e le cronologie dei parametri e analizzali per ottenere informazioni più ampie sulle tendenze e sui carichi di lavoro.
Amazon CloudWatch Logs Insights supporta un [linguaggio di query semplice ma potente](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CWL_QuerySyntax.html) che puoi utilizzare per analizzare i dati di log. Amazon CloudWatch Logs supporta anche le sottoscrizioni che consentono ai dati di fluire in modo ottimale verso Amazon S3, dove puoi utilizzare o Amazon Athena per eseguire query sui dati. Supporta, inoltre, le query su un'ampia gamma di formati. Consulta [SerDe e formati di dati supportati](https://docs.aws.amazon.com/athena/latest/ug/supported-format.html) nella Guida per l'utente Amazon Athena per ulteriori informazioni. Per l'analisi di enormi set di file di log, puoi eseguire un cluster Amazon EMR per effettuare analisi con capacità nell'ordine dei petabyte.
Esistono numerosi strumenti forniti da Partner AWS e terze parti che consentono aggregazione, elaborazione, archiviazione e analisi. Questi strumenti includono New Relic, Splunk, Loggly, Logstash, CloudHealth e Nagios. Tuttavia, la generazione esterna di log di sistema e applicazioni è univoca per ciascun provider di servizi cloud e spesso per ciascun servizio.
Una parte spesso trascurata del processo di monitoraggio è la gestione dei dati. È necessario determinare i requisiti di conservazione per il monitoraggio dei dati, quindi applicare le policy del ciclo di vita di conseguenza. Amazon S3 supporta la gestione del ciclo di vita a livello di bucket S3. Questa gestione del ciclo di vita può essere applicata in modo diverso ai diversi percorsi nel bucket. Verso la fine del ciclo di vita è possibile trasferire i dati su Amazon Glacier per l'archiviazione a lungo termine fino alla scadenza, al termine del periodo di conservazione. La classe di storage S3 Intelligent-Tiering è progettata per ottimizzare i costi trasferendo automaticamente i dati nel livello di accesso più conveniente, senza impatto sulle prestazioni o sovraccarico operativo.
**Livello di rischio associato se questa best practice non fosse adottata:** Medium
## Guida all'implementazione
+ Gli approfondimenti CloudWatch Logs consentono di cercare e analizzare in modo interattivo i dati di registro in Amazon CloudWatch Logs.
+ [Analisi dei dati di registro con gli approfondimenti CloudWatch Logs](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/using_cloudwatch_logs.html)
+ [Query di esempio di Amazon CloudWatch Logs Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AnalyzingLogData.html)
+ Utilizza Amazon CloudWatch Logs per inviare registri a Amazon S3 dove puoi utilizzare Amazon Athena per le query dei dati.
+ [Come faccio ad analizzare i miei registri di accesso al server Amazon S3 utilizzando Athena?](https://aws.amazon.com/premiumsupport/knowledge-center/analyze-logs-athena/)
+ Crea una policy del ciclo di vita di S3 per il bucket dei log di accesso al server. Configura la policy del ciclo di vita per rimuovere periodicamente i file di log. In questo modo si riduce la quantità di dati che Athena deve analizzare per ogni query.
+ [Come faccio a creare una policy del ciclo di vita per un bucket S3?](https://docs.aws.amazon.com/AmazonS3/latest/user-guide/create-lifecycle.html)
## Risorse
**Documenti correlati:**
+ [Query di esempio di Amazon CloudWatch Logs Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CWL_QuerySyntax-examples.html)
+ [Analisi dei dati di registro con gli approfondimenti CloudWatch Logs](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/using_cloudwatch_logs.html)
+ [Effettuare il debug con Amazon CloudWatch Synthetics e AWS X-Ray](https://aws.amazon.com/blogs/devops/debugging-with-amazon-cloudwatch-synthetics-and-aws-x-ray/)
+ [Come faccio a creare una policy del ciclo di vita per un bucket S3?](https://docs.aws.amazon.com/AmazonS3/latest/user-guide/create-lifecycle.html)
+ [Come faccio ad analizzare i miei registri di accesso al server Amazon S3 utilizzando Athena?](https://aws.amazon.com/premiumsupport/knowledge-center/analyze-logs-athena/)
+ [One Observability Workshop](https://observability.workshop.aws/)
+ [The Amazon Builders' Library: Dotazione dei sistemi distribuiti per la visibilità operativa](https://aws.amazon.com/builders-library/instrumenting-distributed-systems-for-operational-visibility/)
# REL06-BP06 Esecuzione di revisioni periodiche
Esegui verifiche frequenti delle modalità di implementazione del monitoraggio del carico di lavoro e aggiornalo in base a eventi e modifiche significativi.
Il monitoraggio efficace è basato su parametri aziendali chiave. Assicurati che questi parametri siano presenti nel carico di lavoro man mano che le priorità aziendali cambiano.
L'audit del monitoraggio consente di sapere quando un'applicazione sta raggiungendo gli obiettivi di disponibilità. L'analisi delle cause principali richiede la capacità di scoprire cosa è successo in caso di errori. AWS consente di monitorare lo stato dei tuoi servizi durante un incidente:
+ **Amazon CloudWatch Logs:** è possibile archiviare i log in questo servizio e controllarne i contenuti.
+ **Amazon CloudWatch Logs Insights**: è un servizio completamente gestito che consente di eseguire analisi di registri di grandi dimensioni in pochi secondi. Offre query e visualizzazioni rapide e interattive.
+ **AWS Config:** è possibile vedere quale infrastruttura AWS era in uso in momenti differenti.
+ **AWS CloudTrail:** è possibile vedere quali API AWS sono state richiamate, a che ora e da quale principale.
In AWS, conduciamo meeting settimanali per [esaminare le prestazioni operative](https://docs.aws.amazon.com/wellarchitected/latest/operational-readiness-reviews/wa-operational-readiness-reviews.html) e condividere quanto appreso tra i team. Dato l'elevato numero di team presenti in AWS, abbiamo creato [La ruota](https://aws.amazon.com/blogs/opensource/the-wheel/) per scegliere casualmente un carico di lavoro da esaminare. Stabilire una cadenza regolare per le revisioni delle prestazioni operative e la condivisione delle conoscenze migliora la capacità di ottenere prestazioni più elevate dai team operativi.
**Anti-pattern comuni:**
+ Raccolta dei soli parametri predefiniti.
+ Impostazione di una strategia di monitoraggio senza alcuna revisione.
+ Nessuna discussione sul monitoraggio quando vengono distribuite modifiche importanti.
**Vantaggi dell'adozione di questa best practice:** la verifica periodica del monitoraggio consente di prevedere potenziali problemi, invece di rispondere alle notifiche quando un problema previsto si verifica effettivamente.
**Livello di rischio associato se questa best practice non fosse adottata:** Medium
## Guida all'implementazione
+ Crea più pannelli di controllo per il carico di lavoro. È necessario disporre di un pannello di controllo di primo livello contenente i parametri aziendali chiave, nonché i parametri tecnici che hai identificato come i più rilevanti per lo stato previsto del carico di lavoro al variare dell'utilizzo. È inoltre importante disporre di pannelli di controllo per vari livelli di applicazione e dipendenze che è possibile ispezionare.
+ [Utilizzo dei pannelli di controllo Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html)
+ Pianifica ed effettua revisioni periodiche dei pannelli di controllo del carico di lavoro. Effettua un'ispezione regolare dei pannelli di controllo. La frequenza può essere diversa a seconda di quanto l'ispezione sia approfondita.
+ Ispeziona l'andamento nei parametri. Confronta i valori dei parametri con i valori storici per vedere se ci sono tendenze che potrebbero suggerire l'esame di un particolare aspetto. Riportiamo alcuni esempi: aumento della latenza, riduzione della funzione aziendale primaria e aumento delle risposte all'errore.
+ Identificazione di outlier/anomalie nei parametri. Le medie o mediane possono nascondere outlier e anomalie. Osserva i valori più alti e più bassi nell'intervallo di tempo e analizza le cause dei risultati estremi. Man mano che continui a eliminare tali cause, la riduzione del numero di valori estremi ti consente di continuare a migliorare la coerenza delle prestazioni del carico di lavoro.
+ Ricerca di bruschi cambiamenti nel comportamento. Un cambiamento repentino della quantità o della direzione di un parametro può indicare un cambiamento nell'applicazione o fattori esterni che potrebbero richiedere l'aggiunta di ulteriori parametri da monitorare.
## Risorse
**Documenti correlati:**
+ [Query di esempio di Amazon CloudWatch Logs Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CWL_QuerySyntax-examples.html)
+ [Effettuare il debug con Amazon CloudWatch Synthetics e AWS X-Ray](https://aws.amazon.com/blogs/devops/debugging-with-amazon-cloudwatch-synthetics-and-aws-x-ray/)
+ [One Observability Workshop](https://observability.workshop.aws/)
+ [The Amazon Builders' Library: Dotazione dei sistemi distribuiti per la visibilità operativa](https://aws.amazon.com/builders-library/instrumenting-distributed-systems-for-operational-visibility/)
+ [Utilizzo dei pannelli di controllo Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html)
# REL06-BP07 Monitoraggio del tracciamento end-to-end delle richieste attraverso il sistema
Utilizza AWS X-Ray o strumenti di terze parti per consentire agli sviluppatori di eseguire più facilmente l'analisi e il debug di sistemi distribuiti, per comprendere l'andamento delle prestazioni delle loro applicazioni e dei relativi servizi sottostanti.
**Livello di rischio associato se questa best practice non fosse adottata:** Medium
## Guida all'implementazione
+ Monitora il tracciamento end-to-end delle richieste attraverso il sistema. AWS X-Ray è un servizio che raccoglie dati sulle richieste elaborate dalla tua applicazione e fornisce strumenti che puoi utilizzare per visualizzare, filtrare e ottenere informazioni approfondite su tali dati per identificare problemi e opportunità di ottimizzazione. Per qualsiasi richiesta tracciata alla tua applicazione, puoi visualizzare informazioni dettagliate non solo sulla richiesta e sulla risposta, ma anche sulle chiamate effettuate dall'applicazione verso microservizi, database, API Web e risorse AWS a valle.
+ [Che cos'è AWS X-Ray?](https://docs.aws.amazon.com/xray/latest/devguide/aws-xray.html)
+ [Effettuare il debug con Amazon CloudWatch Synthetics e AWS X-Ray](https://aws.amazon.com/blogs/devops/debugging-with-amazon-cloudwatch-synthetics-and-aws-x-ray/)
## Risorse
**Documenti correlati:**
+ [Effettuare il debug con Amazon CloudWatch Synthetics e AWS X-Ray](https://aws.amazon.com/blogs/devops/debugging-with-amazon-cloudwatch-synthetics-and-aws-x-ray/)
+ [One Observability Workshop](https://observability.workshop.aws/)
+ [The Amazon Builders' Library: Dotazione dei sistemi distribuiti per la visibilità operativa](https://aws.amazon.com/builders-library/instrumenting-distributed-systems-for-operational-visibility/)
+ [Utilizzo di Canary (Amazon CloudWatch Synthetics)](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html)
+ [Che cos'è AWS X-Ray?](https://docs.aws.amazon.com/xray/latest/devguide/aws-xray.html)
# REL 7 In che modo progetti il carico di lavoro per adattarti ai cambiamenti della domanda?
Un carico di lavoro scalabile fornisce elasticità per aggiungere o rimuovere risorse automaticamente, in modo che vi sia una stretta corrispondenza con la domanda attuale in un dato momento.
**Topics**
+ [REL07-BP01 Utilizzo dell'automazione per l'acquisizione o il dimensionamento delle risorse](rel_adapt_to_changes_autoscale_adapt.md)
+ [REL07-BP02 Ottenimento di risorse quando viene rilevata la compromissione di un carico di lavoro](rel_adapt_to_changes_reactive_adapt_auto.md)
+ [REL07-BP03 Ottenimento di risorse dopo aver rilevato che sono necessarie più risorse per un carico di lavoro](rel_adapt_to_changes_proactive_adapt_auto.md)
+ [REL07-BP04 Esecuzione di un test di carico sul carico di lavoro](rel_adapt_to_changes_load_tested_adapt.md)
# REL07-BP01 Utilizzo dell'automazione per l'acquisizione o il dimensionamento delle risorse
Quando sostituisci risorse danneggiate o esegui il dimensionamento del carico di lavoro, puoi automatizzare il processo utilizzando servizi AWS gestiti, come Amazon S3 e AWS Auto Scaling. Puoi anche utilizzare strumenti di terze parti e SDK AWS per automatizzare il dimensionamento.
I servizi gestiti AWS includono Amazon S3, Amazon CloudFront, AWS Auto Scaling, AWS Lambda, Amazon DynamoDB, AWS Fargate e Amazon Route 53.
AWS Auto Scaling consente di rilevare e sostituire le istanze danneggiate. Inoltre, permette di creare piani di dimensionamento per le risorse, tra cui istanze e parchi istanze [Amazon EC2](https://aws.amazon.com/ec2/) , attività [Amazon ECS](https://aws.amazon.com/ecs/) , tabelle e indici [Amazon DynamoDB](https://aws.amazon.com/dynamodb/) e repliche di [Amazon Aurora](https://aws.amazon.com/aurora/) .
Durante il dimensionamento di istanze EC2, assicurati di utilizzare più zone di disponibilità (preferibilmente almeno tre) e di aggiungere o rimuovere capacità per mantenere il bilanciamento tra queste zone. Anche le attività ECS o i pod Kubernetes (quando si utilizza Amazon Elastic Kubernetes Service) devono essere distribuiti su più zone di disponibilità.
Quando utilizzi AWS Lambda, le istanze subiscono un dimensionamento automatico. Ogni volta che viene ricevuta una notifica di evento per la funzione, AWS Lambda individua rapidamente la capacità libera all'interno del parco istanze di calcolo ed esegue il codice fino alla simultaneità allocata. Devi assicurarti che la simultaneità necessaria sia configurata sulla Lambda specifica e nelle tue Service Quotas.
Amazon S3 ricalibra automaticamente le risorse per gestire elevati tassi di richiesta. Ad esempio, l'applicazione può ottenere almeno 3.500 richieste PUT/COPY/POST/DELETE o 5.500 richieste GET /HEAD al secondo per prefisso in un bucket. Non ci sono limiti al numero di prefissi in un bucket. Puoi aumentare le prestazioni di lettura o scrittura parallelizzando le letture. Ad esempio, se crei 10 prefissi in un bucket Amazon S3 per parallelizzare le letture, potresti dimensionare le prestazioni di lettura a 55.000 richieste al secondo.
Configura e utilizza Amazon CloudFront o una rete di distribuzione di contenuti (CDN) attendibile. Una CDN può fornire tempi di risposta più rapidi agli utenti finali e può servire le richieste di contenuti dalla cache, riducendo così la necessità di dimensionare il carico di lavoro.
**Anti-pattern comuni:**
+ Implementare gruppi Auto Scaling per la correzione automatica, ma senza elasticità.
+ Utilizzare l'auto scaling per rispondere a grandi aumenti di traffico.
+ Distribuire applicazioni altamente stateful, eliminando l'opzione di elasticità.
**Vantaggi dell'adozione di questa best practice:** L'automazione elimina il potenziale di errori manuali nella distribuzione e nella disattivazione delle risorse. L'automazione elimina il rischio di superamento dei costi e di rifiuto del servizio a causa della risposta lenta alle esigenze di distribuzione o disattivazione.
**Livello di rischio associato se questa best practice non fosse adottata:** Alta
## Guida all'implementazione
+ Configura e utilizza AWS Auto Scaling. In questo modo è possibile monitorare le applicazioni e regolare automaticamente la capacità per mantenere prestazioni stabili e prevedibili al minor costo possibile. Grazie ad AWS Auto Scaling, puoi configurare il dimensionamento delle applicazioni per più risorse in vari servizi.
+ [Che cos'è AWS Auto Scaling?](https://docs.aws.amazon.com/autoscaling/plans/userguide/what-is-aws-auto-scaling.html)
+ Configura il dimensionamento automatico su serie di istanze Spot e istanze Amazon EC2, attività Amazon ECS, indici e tabelle Amazon DynamoDB, repliche Amazon Aurora e applicazioni Marketplace AWS, come applicabile.
+ [Gestione automatica della capacità di throughput con DynamoDB Auto Scaling](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/AutoScaling.html)
+ Utilizza le operazioni delle API di servizi per specificare gli avvisi, le policy di ridimensionamento e i tempi di riscaldamento e raffreddamento.
+ Utilizza Elastic Load Balancing. I sistemi di bilanciamento del carico possono distribuire il carico in base al percorso o alla connettività di rete.
+ [Che cos'è Elastic Load Balancing?](https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/what-is-load-balancing.html)
+ Application Load Balancers può distribuire il carico per percorso.
+ [What is an Application Load Balancer? (Che cos'è un Application Load Balancer?)](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/introduction.html)
+ Configura un Application Load Balancer per distribuire il traffico su diversi carichi di lavoro in base a un percorso nello stesso nome di dominio.
+ Gli Application Load Balancers possono essere utilizzati per distribuire i carichi in modo da gestire la domanda attraverso l'integrazione con AWS Auto Scaling.
+ [Uso di un sistema di bilanciamento del carico con un gruppo Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/autoscaling-load-balancer.html)
+ I Network Load Balancer possono distribuire il carico in base alla connessione.
+ [Che cos'è un Network Load Balancer?](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/introduction.html)
+ Configura un Network Load Balancer per distribuire il traffico su diversi carichi di lavoro tramite TCP o per disporre di un set costante di indirizzi IP per il carico di lavoro.
+ I Network Load Balancer possono essere utilizzati per distribuire i carichi in modo da gestire la domanda attraverso l'integrazione con AWS Auto Scaling.
+ Uso di un provider DNS altamente disponibile I nomi DNS consentono agli utenti di accedere ai carichi di lavoro utilizzando nomi anziché indirizzi IP e distribuire queste informazioni in un ambito definito, solitamente a livello globale per gli utenti del carico di lavoro.
+ Utilizza Amazon Route 53 o un provider DNS affidabile.
+ [Che cos'è Amazon Route 53?](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/Welcome.html)
+ Utilizza Route 53 per gestire le distribuzioni CloudFront e i load balancer.
+ Individua i domini e i sottodomini da gestire.
+ Crea set di record appropriati utilizzando record ALIAS o CNAME.
+ [Uso dei record](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/rrsets-working-with.html)
+ Utilizza la rete globale AWS per ottimizzare il percorso dagli utenti alle applicazioni. AWS Global Accelerator monitora costantemente l'integrità degli endpoint delle applicazioni e reindirizza il traffico verso endpoint integri in meno di 30 secondi.
+ AWS Global Accelerator è un servizio che migliora la disponibilità e le prestazioni delle applicazioni con utenti locali o globali, fornendo indirizzi IP statici che fungono da punto di ingresso fisso agli endpoint delle applicazioni in una o più regioni Regioni AWS, ad esempio Application Load Balancers, Network Load Balancer o istanze Amazon EC2.
+ [Che cos'è AWS Global Accelerator?](https://docs.aws.amazon.com/global-accelerator/latest/dg/what-is-global-accelerator.html)
+ Configura e utilizza Amazon CloudFront o una rete di distribuzione di contenuti (CDN) attendibile. Una rete di distribuzione di contenuti (CDN) può fornire tempi di risposta più rapidi agli utenti finali e soddisfare richieste di contenuti che possono causare un dimensionamento non necessario dei carichi di lavoro.
+ [Che cos'è Amazon CloudFront?](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/Introduction.html)
+ Configura le distribuzioni di Amazon CloudFront per i carichi di lavoro oppure utilizza una CDN di terze parti.
+ Puoi limitare l'accesso ai tuoi carichi di lavoro in modo che siano accessibili solo da CloudFront utilizzando gli intervalli di indirizzi IP per CloudFront nelle policy di accesso o nei gruppi di sicurezza degli endpoint.
## Risorse
**Documenti correlati:**
+ [Partner APN: partner per la creazione di soluzioni di elaborazione automatizzate](https://aws.amazon.com/partners/find/results/?facets=%27Product%20:%20Compute%27)
+ [AWS Auto Scaling: come funzionano i piani di dimensionamento](https://docs.aws.amazon.com/autoscaling/plans/userguide/how-it-works.html)
+ [Marketplace AWS: prodotti che possono essere utilizzati con Auto Scaling](https://aws.amazon.com/marketplace/search/results?searchTerms=Auto+Scaling)
+ [Gestione automatica della capacità di throughput con DynamoDB Auto Scaling](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/AutoScaling.html)
+ [Uso di un sistema di bilanciamento del carico con un gruppo Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/autoscaling-load-balancer.html)
+ [Che cos'è AWS Global Accelerator?](https://docs.aws.amazon.com/global-accelerator/latest/dg/what-is-global-accelerator.html)
+ [Che cos'è Amazon EC2 Auto Scaling?](https://docs.aws.amazon.com/autoscaling/ec2/userguide/what-is-amazon-ec2-auto-scaling.html)
+ [Che cos'è AWS Auto Scaling?](https://docs.aws.amazon.com/autoscaling/plans/userguide/what-is-aws-auto-scaling.html)
+ [Che cos'è Amazon CloudFront?](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/Introduction.html?ref=wellarchitected)
+ [Che cos'è Amazon Route 53?](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/Welcome.html)
+ [Che cos'è Elastic Load Balancing?](https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/what-is-load-balancing.html)
+ [Che cos'è un Network Load Balancer?](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/introduction.html)
+ [What is an Application Load Balancer? (Che cos'è un Application Load Balancer?)](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/introduction.html)
+ [Uso dei record](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/rrsets-working-with.html)
# REL07-BP02 Ottenimento di risorse quando viene rilevata la compromissione di un carico di lavoro
All'occorrenza, ridimensiona le risorse in modo reattivo se la disponibilità è influenzata per ripristinare la disponibilità del carico di lavoro.
Devi prima configurare i controlli dello stato e i criteri su questi controlli per indicare quando la disponibilità è influenzata dalla mancanza di risorse. Quindi notificare al personale appropriato di dimensionare manualmente la risorsa o attivare l'automazione per dimensionarla automaticamente.
Il dimensionamento può essere regolato manualmente in base al carico di lavoro, ad esempio modificando il numero di istanze EC2 in un gruppo con scalabilità automatica o modificando la velocità di trasmissione effettiva di una tabella DynamoDB tramite la Console di gestione AWS o la AWS CLI. Tuttavia, l'automazione deve essere utilizzata ogni qualvolta sia possibile (consulta **Utilizzo dell'automazione per l'acquisizione o il dimensionamento delle risorse**).
**Livello di rischio associato se questa best practice non fosse adottata:** Medium
## Guida all'implementazione
+ Ottieni le risorse quando viene rilevata la compromissione di un carico di lavoro All'occorrenza, ridimensiona le risorse in modo reattivo se la disponibilità è influenzata per ripristinare la disponibilità del carico di lavoro.
+ Utilizza i piani di dimensionamento, che sono il componente principale di AWS Auto Scaling, per configurare una serie di istruzioni per dimensionare le risorse. Se lavori con AWS CloudFormation o aggiungi tag alle risorse AWS, puoi impostare piani di dimensionamento per diversi set di risorse, per ogni applicazione. AWS Auto Scaling fornisce raccomandazioni per strategie di dimensionamento personalizzate per ogni risorsa. Dopo aver creato il piano, AWS Auto Scaling combina i metodi di dimensionamento dinamico e predittivo per supportare la tua strategia di dimensionamento.
+ [AWS Auto Scaling: come funzionano i piani di dimensionamento](https://docs.aws.amazon.com/autoscaling/plans/userguide/how-it-works.html)
+ Amazon EC2 Auto Scaling aiuta a garantire che sia disponibile il numero corretto di istanze Amazon EC2 per gestire il carico dell'applicazione. È possibile creare raccolte di istanze EC2, denominate gruppi Auto Scaling. Puoi specificare il numero minimo di istanze in ciascun gruppo con scalabilità automatica, mentre Amazon EC2 Auto Scaling garantisce che il gruppo non scenda mai al di sotto di tale quantità. Puoi specificare il numero massimo di istanze in ciascun gruppo con scalabilità automatica, mentre Amazon EC2 Auto Scaling garantisce che il gruppo non scenda mai al di sotto di tale quantità.
+ [Che cos'è Amazon EC2 Auto Scaling?](https://docs.aws.amazon.com/autoscaling/ec2/userguide/what-is-amazon-ec2-auto-scaling.html)
+ Il dimensionamento automatico Amazon DynamoDB utilizza il servizio di dimensionamento automatico dell'applicazione AWS per regolare dinamicamente la capacità effettiva di trasmissione assegnata per tuo conto, in risposta ai modelli di traffico effettivi. Ciò consente a una tabella o a un indice secondario globale di aumentare la capacità di lettura e scrittura assegnata per gestire aumenti di traffico improvvisi, senza throttling.
+ [Gestione automatica della capacità di throughput con DynamoDB Auto Scaling](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/AutoScaling.html)
## Risorse
**Documenti correlati:**
+ [Partner APN: partner per la creazione di soluzioni di elaborazione automatizzate](https://aws.amazon.com/partners/find/results/?facets=%27Product%20:%20Compute%27)
+ [AWS Auto Scaling: come funzionano i piani di dimensionamento](https://docs.aws.amazon.com/autoscaling/plans/userguide/how-it-works.html)
+ [Marketplace AWS: prodotti che possono essere utilizzati con Auto Scaling](https://aws.amazon.com/marketplace/search/results?searchTerms=Auto+Scaling)
+ [Gestione automatica della capacità di throughput con DynamoDB Auto Scaling](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/AutoScaling.html)
+ [Che cos'è Amazon EC2 Auto Scaling?](https://docs.aws.amazon.com/autoscaling/ec2/userguide/what-is-amazon-ec2-auto-scaling.html)
# REL07-BP03 Ottenimento di risorse dopo aver rilevato che sono necessarie più risorse per un carico di lavoro
Dimensiona le risorse in modo proattivo per soddisfare la domanda ed evitare l'impatto sulla disponibilità.
Molti servizi AWS dimensionano automaticamente le risorse per soddisfare la domanda. Se si utilizzano istanze Amazon EC2 o cluster Amazon ECS, puoi configurare la scalabilità automatica di tali istanze in base ai parametri di utilizzo corrispondenti alla richiesta del carico di lavoro. Per Amazon EC2, è possibile impiegare l'utilizzo medio della CPU, il conteggio delle richieste del sistema di bilanciamento del carico o la larghezza di banda di rete per aumentare (o ridurre) le istanze EC2. Per Amazon ECS, è possibile impiegare l'utilizzo medio della CPU, il conteggio delle richieste del load balancer e l'utilizzo della memoria per aumentare orizzontalmente (o ridurre orizzontalmente) le attività ECS. Utilizzando il dimensionamento automatico di destinazione su AWS, l'autoscaler si comporta come un termostato domestico, aggiungendo o rimuovendo risorse per mantenere il valore di destinazione (ad esempio, il 70% di utilizzo della CPU) specificato.
AWS Auto Scaling può anche eseguire l' [Auto Scaling predittivo](https://aws.amazon.com/blogs/aws/new-predictive-scaling-for-ec2-powered-by-machine-learning/), che utilizza il machine learning per analizzare il carico di lavoro cronologico di ciascuna risorsa e prevede regolarmente il carico futuro per i due giorni successivi.
La legge di Little aiuta a calcolare il numero di istanze di calcolo (istanze EC2, funzioni Lambda simultanee, ecc.) necessarie.
*L* = *λW*
L = numero di istanze (o simultaneità media nel sistema)
λ = velocità media alla quale arrivano le richieste (richieste/sec)
W = tempo medio trascorso da ogni richiesta nel sistema (sec)
Ad esempio, a 100 rps, se ogni richiesta impiega 0,5 secondi per l'elaborazione, avrai bisogno di 50 istanze per tenere il passo con la domanda.
**Livello di rischio associato se questa best practice non fosse adottata:** Medium
## Guida all'implementazione
+ Ottieni risorse dopo aver rilevato che sono necessarie più risorse per un carico di lavoro Dimensiona le risorse in modo proattivo per soddisfare la domanda ed evitare l'impatto sulla disponibilità.
+ Valuta quante risorse di calcolo sono necessarie (simultaneità di calcolo) per gestire un determinato tasso di richiesta
+ [Telling Stories About Little's Law](https://brooker.co.za/blog/2018/06/20/littles-law.html)
+ Quando disponi di un modello cronologico per l'utilizzo, imposta il dimensionamento programmato per il dimensionamento automatico Amazon EC2.
+ [Dimensionamento programmato per Amazon EC2 Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/schedule_time.html)
+ Utilizza il dimensionamento predittivo di AWS.
+ [Dimensionamento predittivo per EC2, alimentato dal machine learning](https://aws.amazon.com/blogs/aws/new-predictive-scaling-for-ec2-powered-by-machine-learning/)
## Risorse
**Documenti correlati:**
+ [AWS Auto Scaling: come funzionano i piani di dimensionamento](https://docs.aws.amazon.com/autoscaling/plans/userguide/how-it-works.html)
+ [Marketplace AWS: prodotti che possono essere utilizzati con Auto Scaling](https://aws.amazon.com/marketplace/search/results?searchTerms=Auto+Scaling)
+ [Gestione automatica della capacità di throughput con DynamoDB Auto Scaling](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/AutoScaling.html)
+ [Dimensionamento predittivo per EC2, alimentato dal machine learning](https://aws.amazon.com/blogs/aws/new-predictive-scaling-for-ec2-powered-by-machine-learning/)
+ [Dimensionamento programmato per Amazon EC2 Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/schedule_time.html)
+ [Telling Stories About Little's Law](https://brooker.co.za/blog/2018/06/20/littles-law.html)
+ [Che cos'è Amazon EC2 Auto Scaling?](https://docs.aws.amazon.com/autoscaling/ec2/userguide/what-is-amazon-ec2-auto-scaling.html)
# REL07-BP04 Esecuzione di un test di carico sul carico di lavoro
Adotta un metodo di test del carico per misurare se l'attività di dimensionamento soddisfa i requisiti del carico di lavoro.
È importante eseguire test di carico prolungati. I test di carico devono rilevare il punto di rottura e testare le prestazioni del carico di lavoro. AWS consente di creare facilmente ambienti di test temporanei che riproducono la scala del carico di lavoro di produzione. Nel cloud, puoi creare un ambiente di test su scala produttiva on demand, completare i test e disattivare le risorse. Poiché paghi per l'ambiente di test solo quando è in esecuzione, puoi simulare un ambiente live a un costo notevolmente inferiore rispetti ai test in locale.
I test di carico in produzione dovrebbero anche essere considerati come parte dei game day in cui il sistema di produzione viene messo alla prova, durante le ore di utilizzo inferiore del cliente, con tutto il personale a disposizione per interpretare i risultati e risolvere eventuali problemi che si presentano.
**Anti-pattern comuni:**
+ Eseguire test di carico su distribuzioni che non presentano la stessa configurazione della tua produzione.
+ Eseguire test di carico solo su singole parti del carico di lavoro e non sulla sua interezza.
+ Eseguire test di carico con un sottoinsieme di richieste e non con un set rappresentativo delle richieste effettive.
+ Eseguire test di carico su un fattore di sicurezza di poco superiore al carico previsto.
**Vantaggi dell'adozione di questa best practice:** Saprai quali sono i componenti dell'architettura che non funzionano sotto carico e potrai identificare per tempo i parametri che indicano l'avvicinamento al carico in questione, così da affrontare il problema e prevenire l'impatto dell'esito negativo.
**Livello di rischio associato se questa best practice non fosse adottata:** Medium
## Guida all'implementazione
+ Esegui test di carico per identificare quali aspetti del carico di lavoro indicano la necessità di aggiungere o rimuovere capacità. Il test di carico deve avere un traffico rappresentativo simile a quello che ricevi nella produzione. Aumenta il carico mentre osservi i parametri implementati per stabilire quale di questi indica quando è necessario aggiungere o rimuovere risorse.
+ [Distributed Load Testing on AWS (Test di carico distribuito su AWS): simula migliaia di utenti connessi](https://aws.amazon.com/solutions/distributed-load-testing-on-aws/)
+ Identifica la combinazione di richieste. Potresti avere diverse combinazioni di richieste, quindi dovresti esaminare vari intervalli di tempo per identificare la combinazione di traffico.
+ Implementa un driver di caricamento. Puoi utilizzare codice personalizzato, software open source o software commerciale per implementare un driver di carico.
+ Esegui un test di carico iniziale con una capacità ridotta. Puoi vedere alcuni effetti immediati applicando il carico su una capacità inferiore, possibilmente pari a un'istanza o a un container.
+ Esegui un test di carico con una capacità maggiore. Gli effetti saranno diversi su un carico distribuito, quindi è necessario eseguire il test in condizioni quanto più simili possibili all'ambiente del prodotto.
## Risorse
**Documenti correlati:**
+ [Distributed Load Testing on AWS (Test di carico distribuito su AWS): simula migliaia di utenti connessi](https://aws.amazon.com/solutions/distributed-load-testing-on-aws/)
# REL 8 In che modo implementi le modifiche?
Per distribuire nuove funzionalità e garantire che i carichi di lavoro e l'ambiente operativo eseguano software noti e che sia possibile applicare patch o sostituirli in modo prevedibile, sono necessarie modifiche controllate. Se invece non sono controllate, risulta difficile prevederne l'effetto o risolvere eventuali problemi che causano.
**Topics**
+ [REL08-BP01 Utilizzo di runbook per attività standard come l'implementazione](rel_tracking_change_management_planned_changemgmt.md)
+ [REL08-BP02 Esecuzione di test funzionali come parte integrante dell'implementazione](rel_tracking_change_management_functional_testing.md)
+ [REL08-BP03 Esecuzione di test di resilienza come parte integrante dell'implementazione](rel_tracking_change_management_resiliency_testing.md)
+ [REL08-BP04 Esecuzione dell'implementazione utilizzando un'infrastruttura immutabile](rel_tracking_change_management_immutable_infrastructure.md)
+ [REL08-BP05 Implementazione delle modifiche tramite automazione](rel_tracking_change_management_automated_changemgmt.md)
# REL08-BP01 Utilizzo di runbook per attività standard come l'implementazione
I runbook sono le procedure predefinite per ottenere risultati specifici. Utilizza i runbook per eseguire attività standard, o manualmente o automaticamente. Alcuni esempi includono l'implementazione di un carico di lavoro, l'applicazione di patch a un carico di lavoro o la realizzazione di modifiche DNS.
Ad esempio, metti in atto processi per [garantire la sicurezza del rollback durante le distribuzioni](https://aws.amazon.com/builders-library/ensuring-rollback-safety-during-deployments). Garantire la possibilità di eseguire il rollback di una distribuzione senza interruzioni per i clienti è fondamentale per rendere un servizio affidabile.
Per le procedure di runbook, inizia da un processo manuale valido ed efficace, implementalo nel codice e attivalo per l'esecuzione automatica, se necessario.
Anche per carichi di lavoro sofisticati e altamente automatizzati, i runbook rimangono utili per [eseguire game day](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/test-reliability.html#GameDays) o soddisfare rigorosi requisiti di reportistica e audit.
Tieni presente che i playbook vengono utilizzati in risposta a incidenti specifici e i runbook vengono utilizzati per ottenere risultati specifici. Spesso, i runbook sono per attività di routine, mentre i playbook vengono utilizzati per rispondere a eventi non di routine.
**Anti-pattern comuni:**
+ Eseguire modifiche impreviste alla configurazione nella produzione.
+ Ignorare le fasi del piano per velocizzare l'implementazione, compromettendone la riuscita.
+ Apportare modifiche senza testarne l'annullamento.
**Vantaggi dell'adozione di questa best practice:** Una pianificazione efficace aumenta la capacità di eseguire correttamente la modifica, perché sei a conoscenza di tutti i sistemi interessati. Convalidare la modifica negli ambienti di test aumenta la sicurezza.
**Livello di rischio associato se questa best practice non fosse adottata:** Alta
## Guida all'implementazione
+ Abilita risposte coerenti e tempestive agli eventi noti documentando le procedure nei runbook.
+ [Framework AWS Well-Architected – Concetti – Runbook](https://wa.aws.amazon.com/wat.concept.runbook.en.html)
+ Uso del principio di infrastruttura come codice per definire l'infrastruttura Utilizzando AWS CloudFormation o una terza parte affidabile per definire la tua infrastruttura, puoi utilizzare un software per il controllo delle versioni per gestire le versioni e tenere traccia delle modifiche.
+ Utilizza AWS CloudFormation o un provider di terze parti affidabile per definire l'infrastruttura.
+ [Che cos'è AWS CloudFormation?](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html)
+ Crea modelli unici e disaccoppiati, utilizzando solidi principi di progettazione del software.
+ Stabilisci le autorizzazioni, i modelli e le parti responsabili dell'implementazione
+ [ Controllo degli accessi con AWS Identity and Access Management](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/using-iam-template.html)
+ Utilizza un controllo sorgente come AWS CodeCommit o uno strumento di terze parti affidabili per il controllo delle versioni.
+ [Che cos'è AWS CodeCommit?](https://docs.aws.amazon.com/codecommit/latest/userguide/welcome.html)
## Risorse
**Documenti correlati:**
+ [Partner APN: partner per la creazione di soluzioni di distribuzione automatizzate](https://aws.amazon.com/partners/find/results/?keyword=devops)
+ [Marketplace AWS: prodotti per l'automazione delle distribuzioni](https://aws.amazon.com/marketplace/search/results?searchTerms=DevOps)
+ [Framework AWS Well-Architected – Concetti – Runbook](https://wa.aws.amazon.com/wat.concept.runbook.en.html)
+ [Che cos'è AWS CloudFormation?](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html)
+ [Che cos'è AWS CodeCommit?](https://docs.aws.amazon.com/codecommit/latest/userguide/welcome.html)
**Esempi correlati:**
+ [Automating operations with Playbooks and Runbooks (Automazione delle operazioni con Playbook e Runbook)](https://wellarchitectedlabs.com/operational-excellence/200_labs/200_automating_operations_with_playbooks_and_runbooks/)
# REL08-BP02 Esecuzione di test funzionali come parte integrante dell'implementazione
I test funzionali vengono eseguiti come parte integrante della distribuzione automatizzata. Se non vengono soddisfatti i criteri di esito positivo, la pipeline viene arrestata o ripresa dall'inizio.
Questi test vengono eseguiti in un ambiente di pre-produzione, gestito per fasi prima della produzione nella pipeline. Idealmente, questa operazione viene eseguita come parte di una pipeline di distribuzione.
**Livello di rischio associato se questa best practice non fosse adottata:** Alta
## Guida all'implementazione
+ Esegui test funzionali come parte integrante dell'implementazione. I test funzionali vengono eseguiti come parte integrante della distribuzione automatizzata. Se non vengono soddisfatti i criteri di esito positivo, la pipeline viene arrestata o ripresa dall'inizio.
+ Richiama AWS CodeBuild durante l'azione di test delle pipeline di rilascio di software modellate in AWS CodePipeline. Questa funzionalità consente di eseguire facilmente un'ampia gamma di test sul codice, tra cui test delle unità, analisi del codice statico e test di integrazione.
+ [AWS CodePipeline Adds Support for Unit and Custom Integration Testing with AWS CodeBuild (AWS CodePipeline aggiunge il supporto per i test di unità e integrazione personalizzati con AWS CodeBuild)](https://aws.amazon.com/about-aws/whats-new/2017/03/aws-codepipeline-adds-support-for-unit-testing/)
+ Utilizza le soluzioni Marketplace AWS per eseguire test automatizzati come parte integrante della tua pipeline di distribuzione di software.
+ [Automazione e test del software](https://aws.amazon.com/marketplace/solutions/devops/software-test-automation)
## Risorse
**Documenti correlati:**
+ [AWS CodePipeline Adds Support for Unit and Custom Integration Testing with AWS CodeBuild (AWS CodePipeline aggiunge il supporto per i test di unità e integrazione personalizzati con AWS CodeBuild)](https://aws.amazon.com/about-aws/whats-new/2017/03/aws-codepipeline-adds-support-for-unit-testing/)
+ [Automazione e test del software](https://aws.amazon.com/marketplace/solutions/devops/software-test-automation)
+ [Che cos'è AWS CodePipeline?](https://docs.aws.amazon.com/codepipeline/latest/userguide/welcome.html)
# REL08-BP03 Esecuzione di test di resilienza come parte integrante dell'implementazione
I test di resilienza (eseguiti utilizzando i [Principles of Chaos Engineering](https://principlesofchaos.org/)) vengono svolti nell'ambito della pipeline di implementazione automatizzata in un ambiente di pre-produzione.
Questi test vengono gestiti per fasi ed eseguiti nella pipeline di pre-produzione. Devono anche essere eseguiti in produzione, ma come parte di [https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/test-reliability.html#GameDays](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/test-reliability.html#GameDays).
**Livello di rischio associato se questa best practice non fosse adottata:** Medium
## Guida all'implementazione
+ Esegui test di resilienza come parte integrante della distribuzione Utilizza l'ingegneria del caos, la disciplina che consiste nello sperimentare su un carico di lavoro per aumentare la fiducia nella capacità del carico di lavoro di resistere a condizioni turbolente in produzione.
+ I test di resilienza inseriscono errori o causano un degrado delle risorse per valutare se il carico di lavoro risponde con la resilienza progettata
+ [Corso Well-Architected: Level 300: Testing for Resiliency of EC2 RDS and S3](https://wellarchitectedlabs.com/Reliability/300_Testing_for_Resiliency_of_EC2_RDS_and_S3/README.html)
+ Questi test possono essere eseguiti regolarmente in ambienti di pre-produzione nelle pipeline di distribuzione automatizzate.
+ È opportuno eseguirli anche in produzione, nell'ambito delle giornate di gioco pianificate.
+ A partire dai principi di ingegneristica del caos, avanza ipotesi sulle prestazioni del carico di lavoro in caso di vari problemi, quindi mettile alla prova utilizzando i test di resilienza.
+ [Principles of Chaos Engineering](https://principlesofchaos.org/)
## Risorse
**Documenti correlati:**
+ [Principles of Chaos Engineering](https://principlesofchaos.org/)
+ [Che cos'è AWS Fault Injection Simulator?](https://docs.aws.amazon.com/fis/latest/userguide/what-is.html)
**Esempi correlati:**
+ [Corso Well-Architected: Level 300: Testing for Resiliency of EC2 RDS and S3](https://wellarchitectedlabs.com/Reliability/300_Testing_for_Resiliency_of_EC2_RDS_and_S3/README.html)
# REL08-BP04 Esecuzione dell'implementazione utilizzando un'infrastruttura immutabile
L'infrastruttura immutabile è un modello che richiede che non vengano applicati aggiornamenti, patch di sicurezza o modifiche di configurazione sui carichi di lavoro di produzione. Quando è necessaria una modifica, l'architettura viene costruita su una nuova infrastruttura e distribuita alla produzione.
L'implementazione più comune del paradigma dell'infrastruttura immutabile è il ***server immutabile***. Ciò significa che se un server necessita di un aggiornamento o di una correzione, vengono distribuiti nuovi server invece di aggiornare quelli già in uso. Pertanto, invece di accedere al server tramite SSH e aggiornare la versione del software, ogni modifica nell'applicazione inizia con un push del software al repository di codice, ad esempio git push. Poiché non sono consentite modifiche nell'infrastruttura immutabile, puoi essere sicuro dello stato del sistema distribuito. Le infrastrutture immutabili sono intrinsecamente più coerenti, affidabili e prevedibili e semplificano molti aspetti dello sviluppo e delle operazioni di software.
Utilizza una distribuzione Canary o blue/green durante la distribuzione di applicazioni in infrastrutture immutabili.
[https://martinfowler.com/bliki/CanaryRelease.html](https://martinfowler.com/bliki/CanaryRelease.html) : è la pratica di indirizzare un piccolo numero di clienti alla nuova versione, in genere in esecuzione su una singola istanza di servizio (la release Canary). Quindi analizzerai in modo approfondito le modifiche di comportamento o gli errori generati. Puoi rimuovere il traffico dalla release Canary in caso di problemi critici e reindirizzare gli utenti alla versione precedente. Se la distribuzione viene completata correttamente, puoi continuare a distribuire alla velocità desiderata, monitorando le modifiche alla ricerca di errori, fino a quando non sarai completamente distribuito. AWS CodeDeploy può essere configurato con una configurazione di distribuzione che abilita una distribuzione Canary.
[https://martinfowler.com/bliki/BlueGreenDeployment.html](https://martinfowler.com/bliki/BlueGreenDeployment.html) : è simile alla distribuzione Canary, tranne per il fatto che un intero parco dell'applicazione è distribuito in parallelo. Puoi alternare le distribuzioni tra i due stack (blue e green). Ancora una volta, puoi inviare il traffico alla nuova versione e tornare alla versione precedente in caso di problemi con la distribuzione. Generalmente, tutto il traffico viene trasferito contemporaneamente, tuttavia puoi anche utilizzare frazioni del traffico verso ciascuna versione per accelerare l'adozione della nuova versione mediante le funzionalità di instradamento DNS ponderato di Amazon Route 53. AWS CodeDeploy e AWS Elastic Beanstalk possono essere impostati con una configurazione di implementazione che abilita un'implementazione blu/verde.
![\[Diagramma che mostra l'implementazione blu/verde con AWS Elastic Beanstalk e Amazon Route 53\]](http://docs.aws.amazon.com/it_it/wellarchitected/2022-03-31/framework/images/blue-green-deployment.png)
Vantaggi dell'infrastruttura immutabile:
+ **Riduzione delle deviazioni di configurazione:** sostituendo frequentemente i server da una configurazione di base, nota e controllata dalla versione, l'infrastruttura viene **reimpostata** a uno stato noto, evitando deviazioni di configurazione.
+ **Distribuzioni semplificate**: le distribuzioni sono semplificate perché non devono supportare gli aggiornamenti. Gli aggiornamenti sono solo nuove distribuzioni.
+ **Distribuzioni atomiche affidabili:** le distribuzioni vengono completate correttamente o non cambia nulla. Offre maggiore fiducia nel processo di distribuzione.
+ **Distribuzioni più sicure con processi di rollback e ripristino rapidi:** Le distribuzioni sono più sicure perché la versione funzionante precedente non viene modificata. Puoi eseguire il rollback se vengono rilevati errori.
+ **Ambienti di test e debug ottimizzati:** poiché tutti i server utilizzano la stessa immagine, non ci sono differenze tra gli ambienti. Una build viene distribuita in più ambienti. Inoltre, evita ambienti incoerenti e semplifica test e debug.
+ **Maggiore scalabilità:** poiché i server utilizzano un'immagine di base, sono coerenti e ripetibili, la scalabilità automatica è intrinseca.
+ **Toolchain semplificata**: la toolchain è semplificata poiché è possibile eliminare gli strumenti di gestione della configurazione che gestiscono gli aggiornamenti del software di produzione. Non vengono installati altri strumenti o agenti sui server. Le modifiche vengono apportate all'immagine di base, testate e implementate.
+ **Maggiore sicurezza:** negando tutte le modifiche ai server, puoi disabilitare SSH sulle istanze e rimuovere le chiavi. Questo riduce il vettore di attacco, migliorando l'assetto di sicurezza dell'organizzazione.
**Livello di rischio associato se questa best practice non fosse adottata:** Medium
## Guida all'implementazione
+ Distribuisci utilizzando un'infrastruttura immutabile. Un'infrastruttura immutabile è un modello che impone che non vengano *applicati* aggiornamenti, patch di sicurezza o modifiche sui carichi di lavoro di produzione. Quando è necessaria una modifica, viene creata una nuova versione dell'architettura e distribuita alla produzione.
+ [Panoramica di una distribuzione Blue/Green](https://docs.aws.amazon.com/codedeploy/latest/userguide/welcome.html#welcome-deployment-overview-blue-green)
+ [Distribuzione graduale di applicazioni serverless](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/automating-updates-to-serverless-apps.html)
+ [Infrastruttura immutabile: affidabilità, coerenza e fiducia attraverso l'immutabilità](https://medium.com/@adhorn/immutable-infrastructure-21f6613e7a23)
+ [Release Canary](https://martinfowler.com/bliki/CanaryRelease.html)
## Risorse
**Documenti correlati:**
+ [Release Canary](https://martinfowler.com/bliki/CanaryRelease.html)
+ [Distribuzione graduale di applicazioni serverless](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/automating-updates-to-serverless-apps.html)
+ [Infrastruttura immutabile: affidabilità, coerenza e fiducia attraverso l'immutabilità](https://medium.com/@adhorn/immutable-infrastructure-21f6613e7a23)
+ [Panoramica di una distribuzione Blue/Green](https://docs.aws.amazon.com/codedeploy/latest/userguide/welcome.html#welcome-deployment-overview-blue-green)
+ [The Amazon Builders' Library: Garantire la sicurezza del rollback durante le distribuzioni](https://aws.amazon.com/builders-library/ensuring-rollback-safety-during-deployments)
# REL08-BP05 Implementazione delle modifiche tramite automazione
Le distribuzioni e l'applicazione di patch sono automatizzate per eliminare l'impatto negativo.
Apportare modifiche ai sistemi produttivi è una delle maggiori aree di rischio per molte organizzazioni. Riteniamo che le distribuzioni siano un problema prioritario da risolvere insieme ai problemi aziendali affrontati dal software. Oggi, ciò significa l'uso dell'automazione ovunque sia pratica nelle operazioni, inclusi test e distribuzione di modifiche, aggiunta o rimozione di capacità e migrazione dei dati. AWS CodePipeline consente di gestire le fasi necessarie per rilasciare il carico di lavoro. Questo include uno stato di distribuzione che utilizza AWS CodeDeploy per automatizzare la distribuzione del codice dell'applicazione su istanze Amazon EC2, istanze in locale, funzioni Lambda serverless o servizi Amazon ECS.
**Consiglio**
Anche se la prassi comune suggerisce di includere le persone nelle procedure operative più difficili, suggeriamo di automatizzare le procedure più difficili proprio per questo motivo.
**Anti-pattern comuni:**
+ Eseguire le modifiche manualmente.
+ Ignorare le fasi dell'automazione attraverso i flussi di lavoro di emergenza.
+ Non seguire i piani.
**Vantaggi dell'adozione di questa best practice:** L'utilizzo dell'automazione per distribuire tutte le modifiche scongiura il rischio di introdurre errori umani e consente di effettuare test prima di modificare la produzione, così da garantire che i piani siano completi.
**Livello di rischio associato se questa best practice non fosse adottata:** Medium
## Guida all'implementazione
+ Automatizzazione della pipeline di distribuzione Le pipeline di distribuzione permettono di richiamare test automatici, rilevare le anomalie e interrompere la pipeline a una determinata fase prima della distribuzione in produzione o eseguire automaticamente il ripristino di una modifica.
+ [The Amazon Builders' Library: Garantire la sicurezza del rollback durante le distribuzioni](https://aws.amazon.com/builders-library/ensuring-rollback-safety-during-deployments)
+ [The Amazon Builders' Library: Più velocità con una consegna continua](https://aws.amazon.com/builders-library/going-faster-with-continuous-delivery/)
+ Utilizza AWS CodePipeline (o un prodotto di terze parti affidabile) per definire ed eseguire le tue pipeline.
+ Configura la pipeline in modo che inizi quando si effettua il commit di una modifica al repository del codice.
+ [Che cos'è AWS CodePipeline?](https://docs.aws.amazon.com/codepipeline/latest/userguide/welcome.html)
+ Utilizza Amazon Simple Notification Service (Amazon SNS) e Amazon Simple Email Service (Amazon SES) per inviare notifiche sui problemi nella pipeline o integrarti utilizzando uno strumento di chat per team, ad esempio Amazon Chime.
+ [Che cos'è Amazon Simple Notification Service?](https://docs.aws.amazon.com/sns/latest/dg/welcome.html)
+ [Che cos'è Amazon SES?](https://docs.aws.amazon.com/ses/latest/DeveloperGuide/Welcome.html)
+ [Che cos'è Amazon Chime?](https://docs.aws.amazon.com/chime/latest/ug/what-is-chime.html)
+ [Automatizza i messaggi delle chat con webhook.](https://docs.aws.amazon.com/chime/latest/ug/webhooks.html)
## Risorse
**Documenti correlati:**
+ [Partner APN: partner per la creazione di soluzioni di distribuzione automatizzate](https://aws.amazon.com/partners/find/results/?keyword=devops)
+ [Marketplace AWS: prodotti per l'automazione delle distribuzioni](https://aws.amazon.com/marketplace/search/results?searchTerms=DevOps)
+ [Automatizza i messaggi delle chat con webhook.](https://docs.aws.amazon.com/chime/latest/ug/webhooks.html)
+ [The Amazon Builders' Library: Garantire la sicurezza del rollback durante le distribuzioni](https://aws.amazon.com/builders-library/ensuring-rollback-safety-during-deployments)
+ [The Amazon Builders' Library: Più velocità con una consegna continua](https://aws.amazon.com/builders-library/going-faster-with-continuous-delivery/)
+ [Che cos'è AWS CodePipeline?](https://docs.aws.amazon.com/codepipeline/latest/userguide/welcome.html)
+ [Che cos'è CodeDeploy?](https://docs.aws.amazon.com/codedeploy/latest/userguide/welcome.html)
+ [AWS Systems Manager Patch Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-patch.html)
+ [Che cos'è Amazon SES?](https://docs.aws.amazon.com/ses/latest/DeveloperGuide/Welcome.html)
+ [Che cos'è Amazon Simple Notification Service?](https://docs.aws.amazon.com/sns/latest/dg/welcome.html)
**Video correlati:**
+ [AWS Summit 2019: CI/CD su AWS (AWS Summit: CI/CD su AWS)](https://youtu.be/tQcF6SqWCoY)
# Gestione degli errori
**Topics**
+ [REL 9 In che modo esegui il backup dei dati?](w2aac19b9c11b5.md)
+ [REL 10 In che modo utilizzi l'isolamento dei guasti per proteggere il carico di lavoro?](w2aac19b9c11b7.md)
+ [REL 11 In che modo progetti il carico di lavoro affinché resista ai guasti dei componenti?](w2aac19b9c11b9.md)
+ [REL 12 In che modo testi l'affidabilità?](w2aac19b9c11c11.md)
+ [REL 13 Come pianifichi il disaster recovery (DR)?](w2aac19b9c11c13.md)
# REL 9 In che modo esegui il backup dei dati?
Esegui il backup dei dati, delle applicazioni e della configurazione per soddisfare i tuoi requisiti relativi agli obiettivi di tempo di ripristino (recovery time objective, RTO) e agli obiettivi di punto di ripristino (recovery point objective, RPO).
**Topics**
+ [REL09-BP01 Identificazione e backup di tutti i dati che richiedono un backup o riproduzione dei dati dalle origini](rel_backing_up_data_identified_backups_data.md)
+ [REL09-BP02 Protezione e codifica dei backup](rel_backing_up_data_secured_backups_data.md)
+ [REL09-BP03 Esecuzione del backup dei dati in automatico](rel_backing_up_data_automated_backups_data.md)
+ [REL09-BP04 Ripristino periodico dei dati per verificare l'integrità e i processi di backup:](rel_backing_up_data_periodic_recovery_testing_data.md)
# REL09-BP01 Identificazione e backup di tutti i dati che richiedono un backup o riproduzione dei dati dalle origini
Tutti i data store AWS offrono funzionalità di backup. Servizi come Amazon RDS e Amazon DynamoDB supportano inoltre il backup automatico che consente il ripristino point-in-time (PITR), grazie al quale è possibile ripristinare un backup in qualsiasi momento fino a cinque minuti o meno rispetto all'ora corrente. Molti servizi AWS offrono la possibilità di copiare i backup su un'altra Regione AWS. AWS Backup è uno strumento che consente di centralizzare e automatizzare la protezione dei dati tra i vari servizi AWS.
Amazon S3 può essere utilizzato come destinazione di backup per le origini dei dati gestite dal cliente e gestite da AWS. I servizi AWS come Amazon EBS, Amazon RDS e Amazon DynamoDB hanno funzionalità incorporate per creare i backup. È anche possibile utilizzare software di backup di terze parti.
È possibile eseguire il backup dei dati on-premise in Cloud AWS utilizzando [Gateway di archiviazione AWS](https://docs.aws.amazon.com/storagegateway/latest/vgw/WhatIsStorageGateway.html) oppure [AWS DataSync](https://docs.aws.amazon.com/datasync/latest/userguide/what-is-datasync.html). I bucket Amazon S3 possono essere utilizzati per archiviare questi dati su AWS. Amazon S3 offre più livelli di archiviazione, quali [Amazon Glacier oppure S3 Glacier Deep Archive](https://docs.aws.amazon.com/prescriptive-guidance/latest/backup-recovery/amazon-s3-glacier.html) per ridurre i costi di archiviazione dei dati.
Potresti essere in grado di soddisfare le esigenze di recupero dei dati riproducendo i dati da altre origini. Ad esempio, [I nodi di replica Amazon Elasticache](https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/Replication.Redis.Groups.html) oppure [Repliche di lettura RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ReadRepl.html) possono essere utilizzati per riprodurre i dati in caso di perdita dei dati primari. Nei casi in cui origini di questo tipo possono essere utilizzate per raggiungere [l'Obiettivo del punto di ripristino (RPO) e l'Obiettivo del tempo di ripristino (RTO),](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/disaster-recovery-dr-objectives.html)potrebbe non essere necessario un backup. Un altro esempio: se con Amazon EMR, potrebbe non essere necessario eseguire il backup del data store HDFS, [purché sia possibile riprodurre i dati in EMR da S3](https://aws.amazon.com/premiumsupport/knowledge-center/copy-s3-hdfs-emr/).
Quando scegli una strategia di backup, devi considerare il tempo necessario per il ripristino dei dati. Il tempo necessario per il ripristino dei dati dipende dal tipo di backup (nel caso di una strategia di backup) o dalla complessità del meccanismo di riproduzione dei dati. Questo tempo deve rientrare nell'RTO per il carico di lavoro.
**Risultato desiderato: **
le origini dei dati sono state identificate e classificate in base alla criticità. Quindi, stabilisci una strategia per il recupero dei dati in base all'RPO. Questa strategia prevede il backup di queste origini dei dati o la possibilità di riprodurre i dati da altre origini. In caso di perdita di dati, la strategia implementata consente il recupero o la riproduzione dei dati entro i termini RPO e RTO definiti.
**Fase di maturità del cloud:** Foundational
**Anti-pattern comuni:**
+ Mancata conoscenza di tutte le origini dei dati per il carico di lavoro e della loro criticità.
+ Non si eseguono backup delle origini dei dati critiche.
+ Esecuzione di backup solo di alcune origini dei dati senza utilizzare la criticità come criterio.
+ Non esiste un RPO definito o la frequenza di backup non può soddisfare l'RPO.
+ Nessuna valutazione della necessità di un backup o della possibilità di riprodurre i dati da altre origini.
**Vantaggi dell'adozione di questa best practice:** L'identificazione dei punti in cui sono necessari i backup e l'implementazione di un meccanismo per la creazione di backup, o la possibilità di riprodurre i dati da una fonte esterna, migliorano la capacità di ripristinare e recuperare i dati durante un'interruzione.
**Livello di rischio associato se questa best practice non fosse adottata:** Alta
## Guida all'implementazione
Scopri e utilizza le funzionalità di backup dei servizi e delle risorse AWS utilizzati dal carico di lavoro. La maggior parte dei servizi AWS offre funzionalità per eseguire il backup dei dati del carico di lavoro.
**Passaggi dell'implementazione**
1. **Identificazione di tutte le origini dei dati per il carico di lavoro**. I dati possono essere memorizzati su diverse risorse, come ad esempio [database](https://aws.amazon.com/products/databases/), [volumi](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-volume-types.html), [filesystem](https://docs.aws.amazon.com/efs/latest/ug/whatisefs.html), [sistemi di registrazione](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/WhatIsCloudWatchLogs.html)e [archiviazione di oggetti](https://docs.aws.amazon.com/AmazonS3/latest/userguide/Welcome.html). Consulta la sezione **Risorse** per trovare **Documenti correlati** ai diversi servizi AWS in cui vengono archiviati i dati e la capacità di backup che questi servizi offrono.
1. **Classificazione delle origini dei dati in base alla criticità**. I diversi set di dati avranno diversi livelli di criticità per un carico di lavoro e quindi diversi requisiti di resilienza. Ad esempio, alcuni dati possono essere critici e richiedere un RPO prossimo allo zero, mentre altri dati possono essere meno critici e tollerare un RPO più elevato e una certa perdita di dati. Allo stesso modo, anche i diversi set di dati possono avere requisiti RTO diversi.
1. **Utilizza i servizi AWS o di terze parti per creare i backup dei dati**. [AWS Backup](https://docs.aws.amazon.com/aws-backup/latest/devguide/whatisbackup.html) è un servizio gestito che permette di creare backup di varie origini dei dati su AWS. La maggior parte di questi servizi dispone anche di funzionalità native per la creazione di backup. Marketplace AWS ha molte soluzioni che offrono anche queste funzionalità. Consulta lo **Risorse** elencate di seguito per informazioni su come creare backup dei dati da vari servizi AWS.
1. **Per i dati non sottoposti a backup, stabilire un meccanismo di riproduzione dei dati**. Puoi decidere di non eseguire il backup di dati riproducibili da altre origini per vari motivi. Potrebbe essere più conveniente riprodurre i dati dalle origini, quando necessario, piuttosto che creare un backup, dato che l'archiviazione dei backup può comportare dei costi. Un altro esempio è quello in cui il ripristino da un backup richiede più tempo rispetto alla riproduzione dei dati dalle origini, con conseguente violazione dell'RTO. In queste situazioni, è necessario considerare i compromessi e stabilire un processo ben definito per la riproduzione dei dati da queste origini quando è necessario il ripristino dei dati. Ad esempio, se hai caricato dati da Amazon S3 su un data warehouse (come Amazon Redshift) o su un cluster MapReduce (come Amazon EMR) per compiere analisi, ottieni un esempio pratico di riproduzione dati da oltre origini. Finché i risultati di queste analisi vengono archiviati o sono riproducibili, non subirai una perdita di dati a causa di un guasto nel data warehouse o nel cluster MapReduce. Altri esempi che possono essere riprodotti dalle origini includono le cache (ad esempio Amazon ElastiCache) o le repliche di lettura RDS.
1. **Stabilisci una cadenza per il backup dei dati**. La creazione di backup delle origini dei dati è un processo periodico e la frequenza deve dipendere dall'RPO.
**Livello di impegno per il piano di implementazione:** Moderato
## Risorse
**Best practice correlate:**
[REL13-BP01 Definizione degli obiettivi di ripristino in caso di downtime e perdita di dati](rel_planning_for_recovery_objective_defined_recovery.md)
[REL13-BP02 Utilizzo di strategie di ripristino definite per conseguire gli obiettivi di ripristino](rel_planning_for_recovery_disaster_recovery.md)
**Documenti correlati:**
+ [Che cos'è AWS Backup?](https://docs.aws.amazon.com/aws-backup/latest/devguide/whatisbackup.html)
+ [What is AWS DataSync? (Che cos'è AWS DataSync?)](https://docs.aws.amazon.com/datasync/latest/userguide/what-is-datasync.html)
+ [What is Volume Gateway? (Che cos'è il Gateway di volumi?)](https://docs.aws.amazon.com/storagegateway/latest/vgw/WhatIsStorageGateway.html)
+ [Partner APN: partner per il backup](https://aws.amazon.com/partners/find/results/?keyword=Backup)
+ [Marketplace AWS: prodotti che possono essere utilizzati per il backup](https://aws.amazon.com/marketplace/search/results?searchTerms=Backup)
+ [Snapshot Amazon EBS](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSSnapshots.html)
+ [Backing Up Amazon EFS (Backup di Elastic File System)](https://docs.aws.amazon.com/efs/latest/ug/efs-backup-solutions.html)
+ [Backup di Amazon FSx per Windows File Server](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/using-backups.html)
+ [Backup e ripristino di ElastiCache for Redis](https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/backups.html)
+ [Creating a DB Cluster Snapshot in Neptune (Creazione di uno snapshot cluster DB in Neptune)](https://docs.aws.amazon.com/neptune/latest/userguide/backup-restore-create-snapshot.html)
+ [Creazione di uno snapshot DB](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_CreateSnapshot.html)
+ [Creating an EventBridge Rule That Triggers on a Schedule (Creazione di una regola EventBridge che viene eseguita in base a una pianificazione)](https://docs.aws.amazon.com/eventbridge/latest/userguide/create-eventbridge-scheduled-rule.html)
+ [Replica tra Regioni](https://docs.aws.amazon.com/AmazonS3/latest/dev/crr.html) con Amazon S3
+ [EFS-to-EFS AWS Backup (Backup da EFS a EFS)](https://aws.amazon.com/solutions/efs-to-efs-backup-solution/)
+ [Esportazione di dati di registro in Amazon S3](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/S3Export.html)
+ [Gestione del ciclo di vita dell'applicazione](https://docs.aws.amazon.com/AmazonS3/latest/dev/object-lifecycle-mgmt.html)
+ [Backup e ripristino on demand per DynamoDB](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/backuprestore_HowItWorks.html)
+ [Point-in-time recovery for DynamoDB (Ripristino point-in-time per DynamoDB)](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/PointInTimeRecovery.html)
+ [Gestione di snapshot degli indici Amazon OpenSearch Service](https://docs.aws.amazon.com/elasticsearch-service/latest/developerguide/es-managedomains-snapshots.html)
**Video correlati:**
+ [AWS re:Invent 2021 - Backup, disaster recovery, and ransomware protection with AWS (Backup, ripristino di emergenza e protezione ransomware con AWS)](https://www.youtube.com/watch?v=Ru4jxh9qazc)
+ [AWS Backup Demo: Cross-Account and Cross-Region Backup (Backup trasversale tra account e tra regioni)](https://www.youtube.com/watch?v=dCy7ixko3tE)
+ [AWS re:Invent 2019: Deep dive on AWS Backup(Approfondimento si AWS Backup), ft. Rackspace (STG341) ](https://youtu.be/av8DpL0uFjc)
**Esempi correlati:**
+ [Well-Architected lab: Implementing Bi-Directional Cross-Region Replication (CRR) for Amazon S3 (Laboratorio Well-Architected: Implementazione della replica bi-direzionale tra regioni (CRR) per Amazon S3) ](https://wellarchitectedlabs.com/reliability/200_labs/200_bidirectional_replication_for_s3/)
+ [Corso Well-Architected: Testing Backup and Restore of Data](https://wellarchitectedlabs.com/reliability/200_labs/200_testing_backup_and_restore_of_data/)
+ [Well-Architected lab: Backup and Restore with Failback for Analytics Workload (Laboratorio Well-Architected: Backup e ripristino con failback per il carico di lavoro analitico)](https://wellarchitectedlabs.com/reliability/200_labs/200_backup_restore_failback_analytics/)
+ [Well-Architected lab: Disaster Recovery - Backup and Restore (Laboratorio Well-Architected: Ripristino di emergenza – Backup e ripristino)](https://wellarchitectedlabs.com/reliability/disaster-recovery/workshop_1/)
# REL09-BP02 Protezione e codifica dei backup
Controlla e rileva l'accesso ai backup utilizzando l'autenticazione e l'autorizzazione, come ad esempio AWS IAM. Previeni e rileva se l'integrità dei dati dei backup è compromessa utilizzando la crittografia.
Amazon S3 supporta diversi metodi di crittografia dei dati archiviati. Utilizzando la crittografia lato server, Amazon S3 accetta anche dati non crittografati e li crittografa man mano che vengono memorizzati. Utilizzando la crittografia lato client, l'applicazione del carico di lavoro è responsabile della crittografia dei dati prima che vengano inviati a Amazon S3. Entrambi i metodi ti consentono di utilizzare AWS Key Management Service (AWS KMS) per creare ed archiviare la chiave di crittografia dei dati, oppure di utilizzarne una personalizzata (della quale sarai responsabile). Tramite AWS KMS puoi impostare delle policy utilizzando IAM per regolare l'accesso alle chiavi dei dati, oltre che ai dati privi di crittografia.
Per Amazon RDS, se hai scelto di crittografare i database, anche i backup verranno crittografati. I backup di DynamoDB sono sempre crittografati.
**Anti-pattern comuni:**
+ Disporre di un accesso identico sia per i backup e l'automazione del ripristino sia per i dati.
+ Non codificare i backup.
**Vantaggi dell'adozione di questa best practice:** La protezione dei backup previene la manomissione dei dati, mentre la crittografia dei dati impedisce l'accesso in caso di esposizione accidentale.
**Livello di rischio associato se questa best practice non fosse adottata:** Alta
## Guida all'implementazione
+ Utilizzo della crittografia su ciascuno dei datastore. Se i dati di origine sono crittografati, lo sarà anche il backup.
+ Abilitazione della crittografia in RDS. Puoi configurare la crittografia dei dati inattivi utilizzando AWS Key Management Service al momento della creazione di un'istanza RDS.
+ [Crittografia delle risorse Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Overview.Encryption.html)
+ Abilitazione della crittografia sui volumi EBS. Puoi configurare la crittografia predefinita o specificare una chiave univoca al momento della creazione del volume.
+ [Crittografia Amazon EBS](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSEncryption.html)
+ Utilizza la crittografia Amazon DynamoDB richiesta. DynamoDB crittografa tutti i dati a riposo. Puoi utilizzare una chiave AWS KMS di proprietà di AWS o una chiave KMS gestita da AWS specificando una chiave archiviata nel tuo account.
+ [Crittografia a riposo per DynamoDB](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/EncryptionAtRest.html)
+ [Gestione di tabelle crittografate](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/encryption.tutorial.html)
+ Codifica dei dati archiviati in Amazon EFS. Configura la crittografia al momento della creazione del file system.
+ [Crittografia dei dati e dei metadati in EFS](https://docs.aws.amazon.com/efs/latest/ug/encryption.html)
+ Configura la crittografia nelle regioni di origine e di destinazione. Puoi configurare la crittografia dei dati inattivi in Amazon S3 utilizzando le chiavi archiviate in KMS, ma le chiavi sono specifiche per regione. Puoi specificare le chiavi di destinazione quando configuri la replica.
+ [Configurazione aggiuntiva CRR: replica di oggetti creati con crittografia lato server (SSE) utilizzando le chiavi di crittografia archiviate in AWS KMS](https://docs.aws.amazon.com/AmazonS3/latest/dev/crr-replication-config-for-kms-objects.html)
+ Implementazione delle autorizzazioni con privilegi minimi per accedere ai backup. Segui le best practice per limitare l'accesso a backup, snapshot e repliche in conformità con le best practice di sicurezza.
+ [Pilastro della sicurezza – AWS Well-Architected](./wat.pillar.security.en.html)
## Risorse
**Documenti correlati:**
+ [Marketplace AWS: prodotti che possono essere utilizzati per il backup](https://aws.amazon.com/marketplace/search/results?searchTerms=Backup)
+ [Crittografia Amazon EBS](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSEncryption.html)
+ [Amazon S3: protezione dei dati tramite la crittografia](https://docs.aws.amazon.com/AmazonS3/latest/dev/UsingEncryption.html)
+ [Configurazione aggiuntiva CRR: replica di oggetti creati con crittografia lato server (SSE) utilizzando le chiavi di crittografia archiviate in AWS KMS](https://docs.aws.amazon.com/AmazonS3/latest/dev/crr-replication-config-for-kms-objects.html)
+ [Crittografia a riposo per DynamoDB](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/EncryptionAtRest.html)
+ [Crittografia delle risorse Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Overview.Encryption.html)
+ [Crittografia dei dati e dei metadati in EFS](https://docs.aws.amazon.com/efs/latest/ug/encryption.html)
+ [Encryption for Backups in AWS (Crittografia per i backup in AWS Backup)](https://docs.aws.amazon.com/aws-backup/latest/devguide/encryption.html)
+ [Gestione di tabelle crittografate](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/encryption.tutorial.html)
+ [Pilastro della sicurezza – AWS Well-Architected](./wat.pillar.security.en.html)
**Esempi correlati:**
+ [Well-Architected lab: Implementing Bi-Directional Cross-Region Replication (CRR) for Amazon S3 (Laboratorio Well-Architected: Implementazione della replica bi-direzionale tra regioni (CRR) per Amazon S3) ](https://wellarchitectedlabs.com/reliability/200_labs/200_bidirectional_replication_for_s3/)
# REL09-BP03 Esecuzione del backup dei dati in automatico
Configura i backup in modo che vengano eseguiti automaticamente in base a una pianificazione periodica informata dall'Obiettivo del punto di ripristino (RPO) o dalle modifiche apportate al set di dati. I set di dati critici con bassi requisiti di perdita di dati devono essere sottoposti a backup automatico su base frequente, mentre i dati meno critici, per i quali è accettabile una certa perdita, possono essere sottoposti a backup meno frequenti.
AWS Backup può essere utilizzato per creare backup automatici di varie origini dei dati AWS. Il backup delle istanze Amazon RDS può essere eseguito quasi ininterrottamente ogni cinque minuti e quello degli oggetti Amazon S3 quasi ininterrottamente ogni quindici minuti, consentendo il ripristino point-in-time (PITR) a un punto specifico della cronologia di backup. Per altre origini dei dati AWS, come volumi Amazon EBS, tabelle Amazon DynamoDB o file system Amazon FSx, AWS Backup può eseguire il backup automatico con una frequenza di un'ora. Questi servizi offrono anche funzionalità di backup nativo. I servizi AWS che offrono un backup automatizzato con ripristino point-in-time includono [Amazon DynamoDB](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/PointInTimeRecovery_Howitworks.html), [Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_PIT.html)e [Amazon Keyspaces (per Apache Cassandra)](https://docs.aws.amazon.com/keyspaces/latest/devguide/PointInTimeRecovery.html) ; questi possono essere ripristinati a un punto specifico della cronologia di backup. La maggior parte degli altri servizi di archiviazione di dati AWS offre la possibilità di programmare backup periodici, anche ogni ora.
Amazon RDS e Amazon DynamoDB offrono un backup continuo con ripristino point-in-time. Una volta abilitato, il controllo delle versioni Amazon S3 è automatico. [Amazon Data Lifecycle Manager](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/snapshot-lifecycle.html) può essere utilizzato per automatizzare la creazione, la copia e l'eliminazione degli snapshot Amazon EBS. Può anche automatizzare la creazione, la copia, la rimozione e la cancellazione di Amazon Machine Images (AMI) con backup Amazon EBS e dei relativi snapshot Amazon EBS sottostanti.
Per una visualizzazione centralizzata dell'automazione e della cronologia dei backup, AWS Backup fornisce una soluzione di backup completamente gestita basata su policy. Centralizza e automatizza il backup dei dati su più servizi AWS nel cloud e on-premise utilizzando Gateway di archiviazione AWS.
Oltre a quella di controllo delle versioni, Amazon S3 offre tutte le funzioni di replica. L'intero bucket S3 può essere replicato automaticamente in un altro bucket in una Regione AWS diversa.
**Risultato desiderato: **
un processo automatizzato che crea backup delle origini dei dati con una cadenza stabilita.
**Anti-pattern comuni:**
+ Eseguire i backup manualmente.
+ Utilizzare risorse che dispongono di funzionalità di backup, ma non includere il backup nell'automazione.
**Vantaggi dell'adozione di questa best practice:** L'automazione dei backup garantisce che vengano eseguiti regolarmente in base all'RPO e avvisa se non vengono eseguiti.
**Livello di rischio associato se questa best practice non fosse adottata:** Medium
## Guida all'implementazione
1. **Identifica le origini dei dati** al momento sottoposte a backup manuale. Consulta [REL09-BP01 Identificazione e backup di tutti i dati che richiedono un backup o riproduzione dei dati dalle origini](rel_backing_up_data_identified_backups_data.md) per avere una guida.
1. **Determina l'RPO** per il carico di lavoro. Consulta [REL13-BP01 Definizione degli obiettivi di ripristino in caso di downtime e perdita di dati](rel_planning_for_recovery_objective_defined_recovery.md) per avere una guida.
1. **Utilizza una soluzione di backup automatico o un servizio gestito**. AWS Backup è un servizio completamente gestito che semplifica [la centralizzazione e l'automazione della protezione dei dati tra i servizi AWS, nel cloud e on-premise](https://docs.aws.amazon.com/aws-backup/latest/devguide/creating-a-backup.html#creating-automatic-backups). I piani di backup sono una funzionalità di AWS Backup che consente di creare regole che definiscono le risorse da sottoporre a backup e la frequenza con cui questi backup devono essere creati. Questa frequenza deve essere informata dall'RPO stabilito al punto 2. [Questo laboratorio WA](https://wellarchitectedlabs.com/reliability/200_labs/200_testing_backup_and_restore_of_data/) fornisce una guida pratica su come creare backup automatizzati utilizzando AWS Backup. La maggior parte dei servizi AWS di archiviazione dei dati offre funzionalità di backup native. Ad esempio, RDS può essere sfruttato per backup automatici con ripristino point-in-time (PITR).
1. **Per le origini dei dati non supportate** da una soluzione di backup automatico o da un servizio gestito, come le origini dei dati on-premise o le code di messaggi, è consigliabile utilizzare una soluzione di terze parti affidabile per creare backup automatici. In alternativa, puoi creare un'automazione utilizzando la AWS CLI o gli SDK. Puoi utilizzare le funzioni AWS Lambda o AWS Step Functions per definire la logica di creazione di un backup dei dati e utilizzare Amazon EventBridge per eseguirlo con una frequenza basata sull'RPO (come stabilito nel passaggio 2).
**Livello di impegno per il piano di implementazione:** Bassa
## Risorse
**Documenti correlati:**
+ [Partner APN: partner per il backup](https://aws.amazon.com/partners/find/results/?keyword=Backup)
+ [Marketplace AWS: prodotti che possono essere utilizzati per il backup](https://aws.amazon.com/marketplace/search/results?searchTerms=Backup)
+ [Creating an EventBridge Rule That Triggers on a Schedule (Creazione di una regola EventBridge che viene eseguita in base a una pianificazione)](https://docs.aws.amazon.com/eventbridge/latest/userguide/create-eventbridge-scheduled-rule.html)
+ [Che cos'è AWS Backup?](https://docs.aws.amazon.com/aws-backup/latest/devguide/whatisbackup.html)
+ [Che cos'è AWS Step Functions?](https://docs.aws.amazon.com/step-functions/latest/dg/welcome.html)
**Video correlati:**
+ [AWS re:Invent 2019: Deep dive on AWS Backup(Approfondimento si AWS Backup), ft. Rackspace (STG341)](https://youtu.be/av8DpL0uFjc)
**Esempi correlati:**
+ [Corso Well-Architected: Testing Backup and Restore of Data](https://wellarchitectedlabs.com/reliability/200_labs/200_testing_backup_and_restore_of_data/)
# REL09-BP04 Ripristino periodico dei dati per verificare l'integrità e i processi di backup:
Esegui un test di ripristino per verificare che l'implementazione del processo di backup soddisfi gli obiettivi di tempo di ripristino (recovery time objective, RTO) e gli obiettivi di punto di ripristino (recovery point objective, RPO).
Con AWS, puoi creare un ambiente di test e ripristinare i backup per valutare le funzionalità RTO e RPO ed eseguire test sul contenuto e l'integrità dei dati.
Inoltre, Amazon RDS e Amazon DynamoDB consentono il ripristino point-in-time (PITR). Utilizzando il backup continuo, puoi ripristinare il set di dati allo stato in cui si trovava in una data e un'ora specificate.
**Risultato desiderato:** I dati dei backup vengono ripristinati periodicamente utilizzando meccanismi ben definiti per garantire che il ripristino sia possibile entro l'Obiettivo del tempo di ripristino (RTO) stabilito per il carico di lavoro. Verifica che il ripristino da un backup porti a una risorsa che contiene i dati originali senza che questi siano danneggiati o inaccessibili e con una perdita di dati entro l'Obiettivo del punto di ripristino (RPO).
**Anti-pattern comuni:**
+ Ripristinare un backup, senza però eseguire query o recuperare dati per garantire che il ripristino sia utilizzabile.
+ Presupporre l'esistenza di un backup.
+ Presupporre che il backup di un sistema sia pienamente operativo e che i dati possano essere recuperati da esso.
+ Presupporre che il tempo di ripristino o di recupero dei dati da un backup rientri nell'RTO del carico di lavoro.
+ Presupporre che i dati contenuti nel backup rientrino nell'RPO del carico di lavoro.
+ Ripristino ad hoc, senza l'utilizzo di un runbook o al di fuori di una procedura automatizzata consolidata.
**Vantaggi dell'adozione di questa best practice:** la verifica del ripristino dei backup assicura che i dati possano essere ripristinati quando necessario senza preoccuparsi che possano essere mancanti o danneggiati, che il ripristino e il recupero siano possibili entro l'RTO per il carico di lavoro e che qualsiasi perdita di dati rientri nell'RPO per il carico di lavoro.
**Livello di rischio associato se questa best practice non fosse adottata:** Medium
## Guida all'implementazione
La verifica delle capacità di backup e ripristino aumenta la fiducia nella capacità di eseguire queste azioni durante un'interruzione. Ripristina periodicamente i backup in una nuova posizione ed esegui test per verificare l'integrità dei dati. Alcuni test comuni da eseguire sono la verifica che
tutti i dati siano disponibili, non siano danneggiati, siano accessibili e che qualsiasi perdita di dati rientri nell'RPO del carico di lavoro. Questi test possono anche aiutare a verificare se i meccanismi di ripristino sono sufficientemente veloci per soddisfare l'RTO del carico di lavoro.
1. **Identifica le origini dei dati** di cui si sta eseguendo il backup e dove sono archiviati i backup. Consulta [REL09-BP01 Identificazione e backup di tutti i dati che richiedono un backup o riproduzione dei dati dalle origini](rel_backing_up_data_identified_backups_data.md) per una guida all'implementazione.
1. **Stabilisci i criteri per la convalida dei dati** per ogni origine dei dati. Tipi di dati differenti avranno proprietà diverse che potrebbero richiedere meccanismi di convalida diversi. Considera il modo in cui potrebbero essere convalidati questi dati prima di poterli utilizzare in produzione. Alcuni modi comuni per convalidare i dati sono l'uso delle loro proprietà dei dati e del backup, come il tipo di dati, il formato, la somma di controllo, la dimensione o la combinazione di questi elementi con una logica di convalida personalizzata. Ad esempio, può trattarsi di un confronto dei valori di checksum tra la risorsa ripristinata e l'origine dei dati al momento della creazione del backup.
1. **Stabilisci l'RTO e l'RPO** per il ripristino dei dati in base alla loro criticità. Consulta [REL13-BP01 Definizione degli obiettivi di ripristino in caso di downtime e perdita di dati](rel_planning_for_recovery_objective_defined_recovery.md) per una guida all'implementazione.
1. **Valuta la capacità di ripristino dei dati**. Rivedi la strategia di backup e ripristino per capire se è in grado di soddisfare RTO e RPO e modifica la strategia se necessario. Utilizzando [Hub di resilienza AWS](https://docs.aws.amazon.com/resilience-hub/latest/userguide/create-policy.html), puoi eseguire una valutazione del carico di lavoro. La valutazione esamina la configurazione dell'applicazione rispetto alle policy sulla resilienza e indica se gli obiettivi RTO e RPO possono essere raggiunti.
1. **Esegui un ripristino di prova** utilizzando i processi attualmente in uso in produzione per il ripristino dei dati. Questi processi dipendono dal modo in cui è stato eseguito il backup dell'origine dei dati iniziale, dal formato e dalla posizione di archiviazione del backup stesso o dalla riproduzione dei dati da altre fonti. Ad esempio, utilizzi un servizio gestito come [AWS Backup, questo potrebbe essere semplice come il ripristino del backup in una nuova risorsa](https://docs.aws.amazon.com/aws-backup/latest/devguide/restoring-a-backup.html). Se hai utilizzato il Ripristino di emergenza elastico AWS, puoi [avviare un'analisi di ripristino](https://docs.aws.amazon.com/drs/latest/userguide/failback-preparing.html).
1. **Convalida il ripristino dei dati** dalla risorsa ripristinata (dal passo precedente) in base ai criteri stabiliti in precedenza per la convalida dei dati al passo 2. I dati ripristinati e recuperati contengono il record/la voce più recente al momento del backup? Questi dati rientrano nell'RPO per il carico di lavoro?
1. **Misura il tempo richiesto** per il ripristino e il recupero e confrontalo con l'RTO stabilito in precedenza nel passaggio 3. Questo tempo deve rientrare nell'RTO per il carico di lavoro? Ad esempio, confronta i timestamp dell'inizio del processo di ripristino e del completamento della convalida del ripristino per calcolare la durata del processo. Tutte le chiamate API AWS hanno una datazione temporale e queste informazioni sono disponibili in [AWS CloudTrail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-user-guide.html). Sebbene queste informazioni possano fornire dettagli sull'inizio del processo di ripristino, la logica di convalida dovrebbe registrare il timestamp finale del completamento della convalida. Se utilizzi un processo automatizzato, puoi utilizzare servizi come [Amazon DynamoDB](https://aws.amazon.com/dynamodb/) per l'archiviazione di queste informazioni. Inoltre, molti servizi AWS offrono una cronologia degli eventi che fornisce informazioni con data e ora in cui si sono verificate determinate azioni. All'interno di AWS Backup, le azioni di backup e di ripristino sono denominate *processi*e questi processi contengono informazioni sulla data e l'ora come parte dei metadati che possono essere utilizzati per misurare il tempo necessario per il ripristino e il recupero.
1. **Invia notifica alle parti interessate (stakeholder)** se la convalida dei dati non riesce o se il tempo necessario per il ripristino e il recupero supera l'RTO stabilito per il carico di lavoro. Quando si implementa l'automazione per farlo, [come in questo laboratorio,](https://wellarchitectedlabs.com/reliability/200_labs/200_testing_backup_and_restore_of_data/)servizi come Amazon Simple Notification Service (Amazon SNS) possono essere utilizzati per inviare notifiche push, come e-mail o SMS, alle parti interessate. [Questi messaggi possono anche essere pubblicati su applicazioni di messaggistica come Amazon Chime, Slack o Microsoft Teams](https://aws.amazon.com/premiumsupport/knowledge-center/sns-lambda-webhooks-chime-slack-teams/) o utilizzati per [creare attività come OpsItem utilizzando OpsCenter di AWS Systems Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/OpsCenter-creating-OpsItems.html).
1. **Automatizzare questo processo per eseguirlo periodicamente**. Ad esempio, per automatizzare i processi di ripristino e recupero si possono utilizzare servizi come AWS Lambda o una State Machine in AWS Step Functions, mentre Amazon EventBridge può essere utilizzato per attivare periodicamente questo flusso di lavoro di automazione, come mostrato nel diagramma di architettura sottostante. Scopri come [automatizzare la convalida del ripristino dati con AWS Backup](https://aws.amazon.com/blogs/storage/automate-data-recovery-validation-with-aws-backup/). Inoltre, [questo laboratorio Well-Architected](https://wellarchitectedlabs.com/reliability/200_labs/200_testing_backup_and_restore_of_data/) fornisce un'esperienza pratica su come realizzare l'automazione di alcuni dei passaggi qui descritti.
![\[Diagramma che mostra un processo di backup e ripristino automatizzato\]](http://docs.aws.amazon.com/it_it/wellarchitected/2022-03-31/framework/images/automated-backup-restore-process.png)
**Livello di impegno per il piano di implementazione:** da moderato a elevato, a seconda della complessità dei criteri di convalida.
## Risorse
**Documenti correlati:**
+ [automatizzare la convalida del ripristino dati con AWS Backup](https://aws.amazon.com/blogs/storage/automate-data-recovery-validation-with-aws-backup/)
+ [Partner APN: partner per il backup](https://aws.amazon.com/partners/find/results/?keyword=Backup)
+ [Marketplace AWS: prodotti che possono essere utilizzati per il backup](https://aws.amazon.com/marketplace/search/results?searchTerms=Backup)
+ [Creating an EventBridge Rule That Triggers on a Schedule (Creazione di una regola EventBridge che viene eseguita in base a una pianificazione)](https://docs.aws.amazon.com/eventbridge/latest/userguide/create-eventbridge-scheduled-rule.html)
+ [Backup e ripristino on demand per DynamoDB](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/BackupRestore.html)
+ [Che cos'è AWS Backup?](https://docs.aws.amazon.com/aws-backup/latest/devguide/whatisbackup.html)
+ [Che cos'è AWS Step Functions?](https://docs.aws.amazon.com/step-functions/latest/dg/welcome.html)
+ [What is AWS Elastic Disaster Recovery (Che cos'è il ripristino di emergenza elastico AWS?)](https://docs.aws.amazon.com/drs/latest/userguide/what-is-drs.html)
+ [AWS Elastic Disaster Recovery (Ripristino di emergenza elastico AWS)](https://docs.aws.amazon.com/resilience-hub/latest/userguide/what-is.html)
**Esempi correlati:**
+ [Corso Well-Architected: Testing Backup and Restore of Data](https://wellarchitectedlabs.com/reliability/200_labs/200_testing_backup_and_restore_of_data/)
# REL 10 In che modo utilizzi l'isolamento dei guasti per proteggere il carico di lavoro?
Le barriere per l'isolamento dei guasti limitano l'effetto di un errore all'interno di un carico di lavoro a un numero limitato di componenti. I componenti al di fuori della barriera non subiscono gli effetti del guasto. Utilizzando più barriere per l'isolamento dei guasti, puoi limitare l'impatto sul carico di lavoro.
**Topics**
+ [REL10-BP01 Implementazione del carico di lavoro in diversi luoghi](rel_fault_isolation_multiaz_region_system.md)
+ [REL10-BP02 Selezione delle posizioni appropriate per la tua implementazione multiposizione](rel_fault_isolation_select_location.md)
+ [REL10-BP03 Ripristino automatico dei componenti vincolati a una singola posizione](rel_fault_isolation_single_az_system.md)
+ [REL10-BP04 Utilizzo di architetture a paratie per limitare la portata dell'impatto](rel_fault_isolation_use_bulkhead.md)
# REL10-BP01 Implementazione del carico di lavoro in diversi luoghi
Distribuisci i dati e le risorse del carico di lavoro su più zone di disponibilità o, se necessario, su diverse Regioni AWS. Questi luoghi possono essere diversi a seconda delle necessità.
Uno dei principi fondamentali per la progettazione di servizi su AWS è l'eliminazione di singoli punti di errore nell'infrastruttura fisica sottostante. Questo ci spinge a creare software e sistemi che utilizzano più zone di disponibilità e sono resistenti al fallimento di una singola zona. Allo stesso modo, i sistemi sono costruiti per resistere ai guasti di un singolo nodo di calcolo, singolo volume di archiviazione o singola istanza di un database. Quando si costruisce un sistema che si basa su componenti ridondanti, è importante garantire che i componenti funzionino in modo indipendente e, nel caso delle Regioni AWS, in modo autonomo. I vantaggi ottenuti dai calcoli di disponibilità teorica con componenti ridondanti sono validi solo se questo continua a essere vero.
**Zone di disponibilità (AZ)**
Le Regioni AWS sono composte da almeno due zone di disponibilità progettate per essere indipendenti. Ogni zona di disponibilità è separata da una distanza fisica significativa da altre zone per evitare scenari di guasto correlati, dovuti a rischi ambientali come incendi, inondazioni e tornado. Ogni zona di disponibilità ha anche un'infrastruttura fisica indipendente: connessioni dedicate di alimentazione di rete, fonti di alimentazione di backup autonome, servizi meccanici indipendenti e connettività di rete indipendente all'interno e all'esterno della zona di disponibilità. Questa struttura limita gli errori di uno qualsiasi di questi sistemi alla sola AZ interessata. Nonostante siano geograficamente separate, le zone di disponibilità sono situate nella stessa area regionale, il che consente una rete a velocità di trasmissione effettiva elevata e bassa latenza. L'intera Regione AWS (in tutte le zone di disponibilità, costituite da più data center fisicamente indipendenti) può essere trattata come un unico obiettivo logico di implementazione per il carico di lavoro, compresa la possibilità di replicare i dati in modo sincrono (ad esempio, tra i database). Ciò ti consente di utilizzare le zone di disponibilità in una configurazione attiva/attiva o attiva/standby.
Le zone di disponibilità sono indipendenti e pertanto la disponibilità del carico di lavoro aumenta quando il carico di lavoro è progettato per utilizzare più zone di disponibilità. Alcuni servizi AWS (tra cui il piano dati dell'istanza Amazon EC2) sono implementati come servizi strettamente zonali nei quali hanno un destino condiviso con la zona di disponibilità in cui si trovano. Le istanze Amazon EC2 nelle altre AZ non saranno, tuttavia, interessate e continueranno a funzionare. Allo stesso modo, se un errore in una zona di disponibilità causa l'errore di un database Amazon Aurora, un'istanza Aurora di lettura-replica in una AZ non interessata può essere automaticamente promossa a primaria. I servizi regionali AWS, ad esempio Amazon DynamoDB, utilizzano internamente più zone di disponibilità in una configurazione attiva/attiva per raggiungere gli obiettivi di progettazione della disponibilità per quel servizio, senza che sia necessario configurare il posizionamento delle AZ.
![\[Diagramma che mostra un'architettura multi-livello implementata su tre zone di disponibilità. Tieni presente che Amazon S3 e Amazon DynamoDB sono sempre Multi-AZ automaticamente. L'ELB viene inoltre distribuito in tutte e tre le zone.\]](http://docs.aws.amazon.com/it_it/wellarchitected/2022-03-31/framework/images/multi-tier-architecture.png)
Mentre i piani di controllo AWS in genere offrono la possibilità di gestire le risorse all'interno dell'intera Regione (più zone di disponibilità), alcuni piani di controllo (inclusi Amazon EC2 ed Amazon EBS) hanno la capacità di filtrare i risultati per una singola zona di disponibilità. Con questo approccio, la richiesta viene elaborata solo nella zona di disponibilità specificata, riducendo l'esposizione all'interruzione in altre zone di disponibilità. Questo esempio di AWS CLI illustra come ottenere informazioni su un'istanza Amazon EC2 dalla sola zona di disponibilità us-east-2c:
```
AWS ec2 describe-instances --filters Name=availability-zone,Values=us-east-2c
```
*Zone locali AWS*
Le Zone locali AWS agiscono in modo simile alle zone di disponibilità nella rispettiva Regione AWS, in quanto possono essere selezionate come ubicazione di posizionamento per le risorse AWS zonali come le sottoreti e le istanze EC2. Ciò che le rende speciali è che non si trovano nella Regione AWS associata, ma vicino a grandi popolazioni, settori e centri IT in cui al momento non esiste alcuna Regione AWS. Tuttavia, mantengono una connessione sicura e a larghezza di banda elevata tra i carichi di lavoro locali nella zona locale e quelli in esecuzione nella Regione AWS. È consigliabile utilizzare le Zone locali AWS per implementare i carichi di lavoro più vicini agli utenti per requisiti a bassa latenza.
**Amazon Global Edge Network**
Amazon Global Edge Network è costituito da posizioni edge in città di tutto il mondo. Amazon CloudFront utilizza questa rete per fornire contenuti agli utenti finali con una latenza inferiore. AWS Global Accelerator consente di creare gli endpoint del carico di lavoro in queste posizioni edge per fornire l'onboarding alla rete globale AWS vicino agli utenti. Amazon API Gateway permette agli endpoint API ottimizzati per l'edge che utilizzano una distribuzione CloudFront di facilitare l'accesso dei clienti attraverso la posizione edge più vicina.
*Regioni AWS*
Le Regioni AWS sono progettate per essere autonome; pertanto, per utilizzare un approccio multi-regione, puoi implementare copie dedicate dei servizi in ciascuna Regione.
Un approccio multi-regione è comune per *le strategie di ripristino di emergenza* per raggiungere gli obiettivi di ripristino quando si verificano eventi unici su larga scala. Consulta [https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/plan-for-disaster-recovery-dr.html](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/plan-for-disaster-recovery-dr.html) per ulteriori informazioni su queste strategie. Qui, tuttavia, si focalizza l'attenzione sulla *disponibilità*, che cerca di fornire un obiettivo medio di operatività nel tempo. Per gli obiettivi di alta disponibilità, un'architettura multi-regione sarà generalmente progettata per essere attiva/attiva, dove ogni copia del servizio (nelle rispettive Regioni) è attiva (serve le richieste).
**Consiglio**
Gli obiettivi di disponibilità per la maggior parte dei carichi di lavoro possono essere soddisfatti utilizzando una strategia multi-AZ all'interno di una singola Regione AWS. Considera le architetture multi-regione solo quando i carichi di lavoro hanno requisiti di disponibilità estremi o altri obiettivi aziendali che richiedono un'architettura multi-regione.
AWS offre ai clienti la possibilità di gestire servizi in più Regioni. Ad esempio, AWS fornisce una replica continua e asincrona dei dati utilizzando la replica Amazon Simple Storage Service (Amazon S3), le repliche di lettura Amazon RDS (incluse le repliche di lettura Aurora) e le tabelle globali Amazon DynamoDB. Con la replica continua, le versioni dei dati sono disponibili per un uso quasi immediato in ogni Regione attiva.
Utilizzando AWS CloudFormation, puoi definire l'infrastruttura e implementarla in modo coerente sugli Account AWS e sulle Regioni AWS. Invece, AWS CloudFormation StackSets estende questa funzionalità consentendo di creare, aggiornare o eliminare stack AWS CloudFormation su più account e regioni con un'unica operazione. Per le implementazioni di istanza Amazon EC2, si utilizza un'immagine AMI (Amazon Machine Image) per fornire informazioni quali la configurazione hardware e il software installato. È possibile implementare una pipeline di Amazon EC2 Image Builder che crea le AMI necessarie e le copia nelle regioni attive. Ciò garantisce che *le Golden AMI* abbiano tutto ciò che serve per implementare e dimensionare il carico di lavoro in ogni nuova regione.
Per instradare il traffico, sia Amazon Route 53 sia AWS Global Accelerator abilitano la definizione di criteri che determinano quali utenti indirizzare a ogni endpoint regionale attivo. Con Global Accelerator imposti un valore di traffico per controllare la percentuale di traffico diretta a ciascun endpoint dell'applicazione. Route 53 supporta questo approccio percentuale e anche diverse altre policy disponibili, tra cui quelle basate sulla geoprossimità e sulla latenza. Global Accelerator sfrutta automaticamente la vasta rete di server edge AWS per convogliare il traffico verso la dorsale di rete AWS il prima possibile, con conseguente riduzione delle latenze delle richieste.
Tutte queste capacità operano in modo da preservare l'autonomia di ogni Regione. Ci sono pochissime eccezioni a questo approccio, inclusi i nostri servizi che forniscono distribuzione edge globale (ad esempio Amazon CloudFront e Amazon Route 53), insieme al piano di controllo per il servizio AWS Identity and Access Management (IAM). La maggior parte dei servizi opera interamente all'interno di una singola Regione.
**Data center in locale**
Per i carichi di lavoro eseguiti in un data center on-premise, puoi progettare un'esperienza ibrida quando possibile. AWS Direct Connect fornisce una connessione di rete dedicata dalla tua sede ad AWS che consente l'esecuzione in entrambi.
Un'altra opzione è quella di eseguire l'infrastruttura AWS e i servizi on-premise utilizzando AWS Outposts. AWS Outposts è un servizio completamente gestito che estende l'infrastruttura AWS, i servizi AWS, le API e gli strumenti al tuo data center. La stessa infrastruttura hardware utilizzata nel Cloud AWS viene installata nel data center. AWS Outposts è, quindi, connesso alla Regione AWS più vicina. Puoi quindi utilizzare AWS Outposts per supportare i carichi di lavoro che hanno requisiti di bassa latenza o di elaborazione dei dati locali.
**Livello di rischio associato se questa best practice non fosse adottata:** Alta
## Guida all'implementazione
+ Utilizza zone di disponibilità multiple e Regioni AWS. Distribuisci i dati e le risorse del carico di lavoro su più zone di disponibilità o, se necessario, su diverse Regioni AWS. Questi luoghi possono essere diversi a seconda delle necessità.
+ I servizi regionali sono distribuiti intrinsecamente in zone di disponibilità.
+ Sono inclusi Amazon S3, Amazon DynamoDB e AWS Lambda (se non collegati a un VPC)
+ Distribuisci il tuo container, istanza e carichi di lavoro basati su funzioni in più zone di disponibilità. Utilizza datastore multi-zona, inclusi sistemi di cache. Utilizza le funzionalità di dimensionamento automatico EC2, posizionamento di attività ECS, configurazione della funzione AWS Lambda in esecuzione nel tuo VPC e i cluster ElastiCache.
+ Utilizza sottoreti che sono in zone di disponibilità separate nella distribuzione di gruppi Auto Scaling.
+ [Esempio: distribuzione di istanze in più zone di disponibilità](https://docs.aws.amazon.com/autoscaling/ec2/userguide/auto-scaling-benefits.html#arch-AutoScalingMultiAZ)
+ [Strategie di posizionamento dei processi di Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task-placement-strategies.html)
+ [Configurazione di una funzione AWS Lambda per accedere alle risorse in un Amazon VPC](https://docs.aws.amazon.com/lambda/latest/dg/vpc.html)
+ [Scelta di regioni e zone di disponibilità](https://docs.aws.amazon.com/AmazonElastiCache/latest/UserGuide/RegionsAndAZs.html)
+ Utilizza sottoreti in zone di disponibilità separate quando distribuisci gruppi Auto Scaling.
+ [Esempio: distribuzione di istanze in più zone di disponibilità](https://docs.aws.amazon.com/autoscaling/ec2/userguide/auto-scaling-benefits.html#arch-AutoScalingMultiAZ)
+ Utilizza parametri di posizionamento attività ECS, specificando i gruppi di sottorete DB.
+ [Strategie di posizionamento dei processi di Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task-placement-strategies.html)
+ Utilizza sottoreti in più zone di disponibilità quando configuri una funzione da eseguire nel tuo VPC.
+ [Configurazione di una funzione AWS Lambda per accedere alle risorse in un Amazon VPC](https://docs.aws.amazon.com/lambda/latest/dg/vpc.html)
+ Utilizza più zone di disponibilità con cluster ElastiCache.
+ [Scelta di regioni e zone di disponibilità](https://docs.aws.amazon.com/AmazonElastiCache/latest/UserGuide/RegionsAndAZs.html)
+ Se il carico di lavoro deve essere implementato in più Regioni, scegli una strategia multi-regione. La maggior parte delle esigenze di affidabilità può essere soddisfatta all'interno di una singola Regione AWS utilizzando una strategia a più zone di disponibilità. Quando necessario, utilizza una strategia multi-Regione per soddisfare le tue esigenze aziendali.
+ [AWS re:Invent 2018: Architecture Patterns for Multi-Region Active-Active Applications (Modelli architetturali per applicazioni attive-attive su più Regioni) (ARC209-R2)](https://youtu.be/2e29I3dA8o4)
+ Il backup in un'altra Regione AWS può garantire ulteriormente che i dati saranno disponibili quando necessario.
+ Alcuni carichi di lavoro hanno requisiti normativi che prevedono l'utilizzo di una strategia multi-regione.
+ Valuta AWS Outposts per il tuo carico di lavoro. Se il carico di lavoro richiede bassa latenza nel data center locale o ha requisiti di elaborazione dei dati locali. In tal caso esegui l'infrastruttura e i servizi AWS on-premise utilizzando AWS Outposts.
+ [Che cos'è AWS Outposts?](https://docs.aws.amazon.com/outposts/latest/userguide/what-is-outposts.html)
+ Stabilisci se le Zone locali AWS ti aiutano a fornire il servizio ai tuoi utenti. Se hai requisiti di bassa latenza, verifica se le Zone locali AWS si trovano vicino ai tuoi utenti. Se sì, utilizzale per implementare carichi di lavoro più vicini a tali utenti.
+ [Domande frequenti sulle Zone locali AWS](https://aws.amazon.com/about-aws/global-infrastructure/localzones/faqs/)
## Risorse
**Documenti correlati:**
+ [Infrastruttura globale di AWS](https://aws.amazon.com/about-aws/global-infrastructure)
+ [Domande frequenti sulle Zone locali AWS](https://aws.amazon.com/about-aws/global-infrastructure/localzones/faqs/)
+ [Strategie di posizionamento dei processi di Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task-placement-strategies.html)
+ [Scelta di regioni e zone di disponibilità](https://docs.aws.amazon.com/AmazonElastiCache/latest/UserGuide/RegionsAndAZs.html)
+ [Esempio: distribuzione di istanze in più zone di disponibilità](https://docs.aws.amazon.com/autoscaling/ec2/userguide/auto-scaling-benefits.html#arch-AutoScalingMultiAZ)
+ [Tabelle globali: replica multi-regione con DynamoDB](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/GlobalTables.html)
+ [Using Amazon Aurora global databases (Utilizzo di database Amazon Aurora globali)](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-global-database.html)
+ [Creating a Multi-Region Application with AWS Services blog series (Creazione di un'applicazione multi-regione con la serie di blog sui servizi AWS)](https://aws.amazon.com/blogs/architecture/tag/creating-a-multi-region-application-with-aws-services-series/)
+ [Che cos'è AWS Outposts?](https://docs.aws.amazon.com/outposts/latest/userguide/what-is-outposts.html)
**Video correlati:**
+ [AWS re:Invent 2018: Architecture Patterns for Multi-Region Active-Active Applications (Modelli architetturali per applicazioni attive-attive su più Regioni) (ARC209-R2)](https://youtu.be/2e29I3dA8o4)
+ [AWS re:Invent 2019: Innovation and operation of the AWS global network infrastructure (Innovazione e gestione dell'infrastruttura di rete globale AWS) (NET339)](https://youtu.be/UObQZ3R9_4c)
# REL10-BP02 Selezione delle posizioni appropriate per la tua implementazione multiposizione
## Risultato desiderato
Per ottenere un'elevata disponibilità, distribuisci sempre (quando possibile) i componenti del carico di lavoro in più zone di disponibilità (AZ), come illustrato nella Figura 10. Per i carichi di lavoro con requisiti di resilienza estremi, valuta attentamente le opzioni per un'architettura multiregione.
![\[Diagramma che mostra un'implementazione resiliente di database multi-AZ con backup in un'altra regione AWS\]](http://docs.aws.amazon.com/it_it/wellarchitected/2022-03-31/framework/images/multi-az-architecture.png)
## Anti-pattern comuni
+ Scelta di progettare un'architettura multi-regione quando un'architettura multi-AZ soddisferebbe i requisiti.
+ Non si tiene conto delle dipendenze tra i componenti dell'applicazione se i requisiti di resilienza e multi-sede differiscono tra questi componenti.
## Vantaggi dell'adozione di questa best practice
Per la resilienza, devi utilizzare un approccio che costruisca livelli di difesa. Un livello protegge dalle interruzioni più piccole e più comuni costruendo un'architettura ad alta disponibilità utilizzando più AZ. Un altro livello di difesa è destinato a proteggere da eventi rari come disastri naturali diffusi e interruzioni a livello regionale. Questo secondo livello implica l'architettura dell'applicazione in modo che si estenda su più Regioni AWS.
+ La differenza tra una disponibilità del 99,5% e una del 99,99% è di oltre 3,5 ore al mese. La disponibilità prevista di un carico di lavoro può raggiungere i "quattro nove" solo se si trova in più AZ.
+ Eseguendo il carico di lavoro in più AZ, puoi isolare gli errori di alimentazione, raffreddamento e rete e la maggior parte dei disastri naturali come incendi e inondazioni.
+ L'implementazione di una strategia multi-regione per il tuo carico di lavoro aiuta a proteggerlo da disastri naturali diffusi che colpiscono un'ampia regione geografica di un paese o da guasti tecnici di portata regionale. Tieni presente che l'implementazione di un'architettura multi-regione può essere molto complessa e di solito non è necessaria per la maggior parte dei carichi di lavoro.
**Livello di rischio associato se questa best practice non fosse adottata:** Alta
## Guida all'implementazione
Per un evento disastroso basato sull'interruzione o la perdita parziale di una zona di disponibilità, l'implementazione di un carico di lavoro a disponibilità elevata in più zone di disponibilità all'interno di una singola Regione AWS aiuta a mitigare i disastri naturali e tecnici. Ogni Regione AWS è composta da più zone di disponibilità, ciascuna isolata dagli errori nelle altre zone e separate da una distanza significativa. Tuttavia, per un evento di disastro che include il rischio di perdere più componenti della zona di disponibilità, che si trovano a una distanza significativa l'uno dall'altro, è necessario implementare opzioni di ripristino di emergenza per mitigare gli errori di portata regionale. Per i carichi di lavoro che richiedono un'estrema resilienza (infrastrutture critiche, applicazioni sanitarie, infrastrutture di sistemi finanziari e così via), può essere necessaria una strategia multi-regione.
## Passaggi dell'implementazione
1. Valutare il carico di lavoro e determinare se le esigenze di resilienza possono essere soddisfatte da un approccio multi-AZ (Regione AWS singola) o se richiedono un approccio multi-regione. L'implementazione di un'architettura multi-regione per soddisfare questi requisiti introdurrà un'ulteriore complessità, quindi considera attentamente il tuo caso d'uso e i suoi requisiti. I requisiti di resilienza possono quasi sempre essere soddisfatti utilizzando un singolo Regione AWS. Per stabilire se è necessario utilizzare più Regioni, considera i seguenti possibili requisiti:
1. **Ripristino di emergenza**: per un evento disastroso basato sull'interruzione o la perdita parziale di una zona di disponibilità, l'implementazione di un carico di lavoro a disponibilità elevata in più zone di disponibilità all'interno di una singola Regione AWS aiuta a mitigare i disastri naturali e tecnici. In caso di eventi disastrosi che comportano il rischio di perdere più componenti della zone di disponibilità, che si trovano a una distanza significativa l'uno dall'altro, è necessario implementare il ripristino di emergenza in più regioni per mitigare i disastri naturali o gli errori tecnici di portata regionale.
1. **Alta disponibilità**: è possibile utilizzare un'architettura multi-regione (utilizzando più AZ in ogni regione) per ottenere una disponibilità superiore a quattro 9 (> 99,99%).
1. **Localizzazione delle risorse**: quando si distribuisce un carico di lavoro a un pubblico globale, è possibile distribuire stack localizzati in diverse Regioni AWS per servire il pubblico di quelle regioni. La localizzazione può includere la lingua, la valuta e i tipi di dati memorizzati.
1. **Prossimità agli utenti:** quando si distribuisce un carico di lavoro a un pubblico globale, è possibile ridurre la latenza distribuendo gli stack alle regioni Regioni AWS in prossimità degli utenti finali.
1. **Posizione fisica dei dati**: alcuni carichi di lavoro sono soggetti a requisiti di residenza dei dati, in base ai quali i dati di determinati utenti devono rimanere all'interno dei confini di un determinato Paese. In base alla normativa in questione, è possibile scegliere di distribuire un intero stack o solo i dati nella Regione AWS all'interno di tali confini.
1. Ecco alcuni esempi di funzionalità multi-AZ fornite dai servizi AWS:
1. Per proteggere i carichi di lavoro che utilizzano EC2 o ECS, è necessario distribuire un Elastic Load Balancer davanti alle risorse di calcolo. Elastic Load Balancing quindi fornisce la soluzione per rilevare le istanze nelle zone non integre e instradare il traffico verso quelle integre.
1. [Nozioni di base su Application Load Balancers](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/application-load-balancer-getting-started.html)
1. [Nozioni di base su Network Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/network-load-balancer-getting-started.html)
1. Nel caso di istanze EC2 che eseguono software commerciale pronto all'uso e che non supportano il bilanciamento del carico, puoi ottenere una forma di tolleranza ai guasti implementando una metodologia di ripristino di emergenza multi-AZ.
1. [REL13-BP02 Utilizzo di strategie di ripristino definite per conseguire gli obiettivi di ripristino](rel_planning_for_recovery_disaster_recovery.md)
1. Per le attività Amazon ECS, distribuire il servizio in modo uniforme su tre AZ per ottenere un equilibrio tra disponibilità e costi.
1. [Amazon ECS availability best practices \$1 Containers (Best practice di disponibilità ECS \$1 Container)](https://aws.amazon.com/blogs/containers/amazon-ecs-availability-best-practices/)
1. Per non Aurora Amazon RDS, puoi scegliere multi-AZ come opzione di configurazione. In caso di errore dell'istanza del database primario, Amazon RDS promuove automaticamente un database standby per ricevere il traffico in un'altra zona di disponibilità. Puoi inoltre creare repliche di lettura multi-regione per migliorare la resilienza.
1. [Implementazioni Multi-AZ Amazon RDS](https://aws.amazon.com/rds/features/multi-az/)
1. [Creazione di una replica di lettura in un'altra Regione AWS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ReadRepl.XRgn.html)
1. Ecco alcuni esempi di funzionalità multi-AZ fornite dai servizi AWS:
1. Per i carichi di lavoro Amazon S3 in cui la disponibilità multi-AZ è fornita automaticamente dal servizio, considera i punti di accesso multi-regione se è necessaria un'implementazione multi-regione.
1. [Punti di accesso multi-regione in Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/MultiRegionAccessPoints.html)
1. Per le tabelle DynamoDB in cui la disponibilità multi-AZ è fornita automaticamente dal servizio, è possibile convertire facilmente le tabelle esistenti in tabelle globali per sfruttare più regioni.
1. [Convert Your Single-Region Amazon DynamoDB Tables to Global Tables (Convertire le tabelle Amazon DynamoDB di una singola regione in tabelle globali)](https://aws.amazon.com/blogs/aws/new-convert-your-single-region-amazon-dynamodb-tables-to-global-tables/)
1. Se il carico di lavoro è gestito da Application Load Balancers o da Network Load Balancer, utilizza AWS Global Accelerator per migliorare la disponibilità dell'applicazione indirizzando il traffico verso più regioni che contengono endpoint integri.
1. [Endpoints for standard accelerators in AWS Global Accelerator - AWS Global Accelerator (Endpoint per acceleratori standard in AWS Global Accelerator) (amazon.com)](https://docs.aws.amazon.com/global-accelerator/latest/dg/about-endpoints.html)
1. Per le applicazioni che sfruttano AWS EventBridge, considera i bus tre regioni per inoltrare gli eventi ad altre regioni selezionate.
1. [Sending and receiving Amazon EventBridge events between Regioni AWS (Invio e ricezione di eventi Amazon EventBridge tra regioni AWS)](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-cross-region.html)
1. Per i database Amazon Aurora, considera i database globali Aurora, che si estendono su più regioni AWS. I cluster esistenti possono essere modificati per aggiungere anche nuove Regioni.
1. [Nozioni di base sui database globali Amazon Aurora](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-global-database-getting-started.html)
1. Se il carico di lavoro include chiavi di crittografia AWS Key Management Service (AWS KMS), valuta se le chiavi multi-regione sono adatte all'applicazione.
1. [Chiavi multi-regione in AWS KMS](https://docs.aws.amazon.com/kms/latest/developerguide/multi-region-keys-overview.html)
1. Per altre funzionalità del servizio AWS, vedi questa serie di blog su [Creating a Multi-Region Application with AWS Services series (Creazione di un'applicazione multi-regione con la serie di servizi AWS)](https://aws.amazon.com/blogs/architecture/tag/creating-a-multi-region-application-with-aws-services-series/)
**Livello di impegno per il piano di implementazione: **da moderato ad alto
## Risorse
**Documenti correlati:**
+ [Creating a Multi-Region Application with AWS Services series (Creazione di un'applicazione multi-regione con la serie di servizi AWS)](https://aws.amazon.com/blogs/architecture/tag/creating-a-multi-region-application-with-aws-services-series/)
+ [Disaster Recovery (DR) Architecture on AWS, Part IV: Multi-site Active/Active (Architettura di ripristino di emergenza su AWS, parte IV: attiva/attiva multi-sito)](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-iv-multi-site-active-active/)
+ [Infrastruttura globale di AWS](https://aws.amazon.com/about-aws/global-infrastructure)
+ [Domande frequenti su AWS Local Zones](https://aws.amazon.com/about-aws/global-infrastructure/localzones/faqs/)
+ [Disaster Recovery (DR) Architecture on AWS, Part I: Strategies for Recovery in the Cloud (Architettura di ripristino di emergenza su AWS parte I: strategie per il ripristino nel cloud)](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-i-strategies-for-recovery-in-the-cloud/)
+ [Il ripristino di emergenza è differente nel cloud](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/disaster-recovery-is-different-in-the-cloud.html)
+ [Tabelle globali: replica multi-regione con DynamoDB](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/GlobalTables.html)
**Video correlati:**
+ [AWS re:Invent 2018: Architecture Patterns for Multi-Region Active-Active Applications (Modelli di architettura per applicazioni attive-attive multiregione) (ARC209-R2)](https://youtu.be/2e29I3dA8o4)
+ [Auth0: architettura ad alta disponibilità multi-Regione che raggiunge più di 1,5 miliardi di accessi al mese con failover automatico](https://www.youtube.com/watch?v=vGywoYc_sA8)
**Esempi correlati:**
+ [Disaster Recovery (DR) Architecture on AWS, Part I: Strategies for Recovery in the Cloud (Architettura di ripristino di emergenza su AWS parte I: strategie per il ripristino nel cloud)](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-i-strategies-for-recovery-in-the-cloud/)
+ [DTCC raggiunge livelli di resilienza superiori a quelli che raggiunge on-premise](https://aws.amazon.com/solutions/case-studies/DTCC/)
+ [Expedia Group utilizza un'architettura multi-regione, a più zone di disponibilità con un servizio DNS proprietario per aggiungere resilienza alle applicazioni](https://aws.amazon.com/solutions/case-studies/expedia/)
+ [Uber: ripristino di emergenza per Kafka multi-Regione](https://eng.uber.com/kafka/)
+ [Netflix: attivo-attivo per la resilienza multi-regione](https://netflixtechblog.com/active-active-for-multi-regional-resiliency-c47719f6685b)
+ [Come costruiamo la posizione fisica dei dati per Atlassian Cloud](https://www.atlassian.com/engineering/how-we-build-data-residency-for-atlassian-cloud)
+ [Intuit TurboTax funziona in due regioni](https://www.youtube.com/watch?v=286XyWx5xdQ)
# REL10-BP03 Ripristino automatico dei componenti vincolati a una singola posizione
Se i componenti del carico di lavoro possono essere eseguiti solo in una singola zona di disponibilità o in un data center on-premise, è necessario implementare la capacità di eseguire una ricostruzione completa del carico di lavoro entro gli obiettivi di ripristino definiti.
Se, a causa di vincoli tecnologici, non è possibile seguire le linee guida per distribuire il carico di lavoro in più posizioni, è necessario implementare un percorso alternativo mirato alla resilienza. È necessario automatizzare la possibilità di ricreare l'infrastruttura necessaria, ridistribuire le applicazioni e ricreare i dati necessari per questi casi.
Ad esempio, Amazon EMR lancia tutti i nodi per un determinato cluster nella stessa zona di disponibilità: eseguire un cluster nella stessa zona migliora le prestazioni dei flussi di lavoro poiché fornisce una velocità di accesso ai dati più elevata. Se questo componente è necessario per la resilienza del carico di lavoro, è necessario disporre di un modo per implementare nuovamente il cluster e i relativi dati. Inoltre, per Amazon EMR è necessario effettuare il provisioning della ridondanza in modi diversi dall'utilizzo di Multi-AZ. È possibile effettuare il provisioning di [nodi multipli](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-plan-ha-launch.html). Utilizzando [EMR File System (EMRFS)](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-fs.html), i dati in EMR possono essere memorizzati in Amazon S3, che a sua volta può essere replicato su più zone di disponibilità o Regioni AWS.
Analogamente, Amazon Redshift per impostazione predefinita effettua il provisioning del cluster in una zona di disponibilità casuale all'interno della Regione AWS selezionata. Tutti i nodi del cluster vengono assegnati nella stessa zona.
**Livello di rischio associato se questa best practice non fosse adottata:** Medium
## Guida all'implementazione
+ Implementa l'autoriparazione. Distribuisci le tue istanze o container utilizzando, quando possibile, il ridimensionamento automatico. Se non è possibile utilizzare il ridimensionamento automatico, utilizza il ripristino automatico per istanze EC2 o implementa l'automazione di autoriparazione in base agli eventi del ciclo di vita di container Amazon EC2 o ECS.
+ Utilizza gruppi Auto Scaling per carichi di lavoro di container e istanze che non richiedono un indirizzo IP di una singola istanza, un indirizzo IP privato, un indirizzo IP elastico o metadati di istanza.
+ [Che cos'è EC2 Auto Scaling?](https://docs.aws.amazon.com/autoscaling/ec2/userguide/what-is-amazon-ec2-auto-scaling.html)
+ [Scalabilità automatica del servizio](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/service-auto-scaling.html)
+ È possibile impiegare i dati utente di configurazione del lancio per implementare l'automazione capace di autoriparare la maggior parte dei carichi di lavoro.
+ Utilizza il ripristino automatico delle istanze EC2 per carichi di lavoro che richiedono un indirizzo ID di una singola istanza, indirizzo IP privato, indirizzo IP elastico e metadati di istanza.
+ [Recover your instance.](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-recover.html)
+ Il ripristino automatico invierà avvisi sullo stato del ripristino a un argomento SNS quando viene rilevato l'errore dell'istanza.
+ Utilizza eventi del ciclo di vita di istanze EC2 o eventi ECS per automatizzare l'autoriparazione dove non è possibile utilizzare l'Auto Scaling o il ripristino EC2.
+ [EC2 Auto Scaling lifecycle hooks](https://docs.aws.amazon.com/autoscaling/ec2/userguide/lifecycle-hooks.html)
+ [Eventi Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs_cwe_events.html)
+ Utilizza gli eventi per invocare l'automazione che riparerà il tuo componente secondo la logica di processo richiesta.
## Risorse
**Documenti correlati:**
+ [Eventi Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs_cwe_events.html)
+ [EC2 Auto Scaling lifecycle hooks](https://docs.aws.amazon.com/autoscaling/ec2/userguide/lifecycle-hooks.html)
+ [Recover your instance.](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-recover.html)
+ [Scalabilità automatica del servizio](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/service-auto-scaling.html)
+ [Che cos'è EC2 Auto Scaling?](https://docs.aws.amazon.com/autoscaling/ec2/userguide/what-is-amazon-ec2-auto-scaling.html)
# REL10-BP04 Utilizzo di architetture a paratie per limitare la portata dell'impatto
Come per le paratie su una nave, questo modello garantisce il contenimento di un guasto in un piccolo sottoinsieme di richieste o clienti, in modo che il numero di richieste danneggiate sia limitato e si possa comunque continuare senza errori. Le paratie per i dati sono spesso chiamate partizioni, mentre le paratie per i servizi sono note come celle.
In una *architettura basata su celle*, ogni cella è un'istanza completa e indipendente del servizio e ha una dimensione massima fissa. Con l'aumentare del carico, i carichi di lavoro aumentano aggiungendo più celle. Una chiave di partizione viene utilizzata sul traffico in entrata per determinare quale cella elaborerà la richiesta. Qualsiasi guasto è contenuto nella singola cella in cui si verifica, in modo che il numero di richieste danneggiate sia limitato man mano che le altre celle continuano senza errori. È importante identificare la chiave di partizione corretta per ridurre al minimo le interazioni tra celle ed evitare la necessità di coinvolgere servizi di mappatura complessi in ogni richiesta. I servizi che richiedono una mappatura complessa finiscono semplicemente per spostare il problema ai servizi di mappatura, là dove i servizi che richiedono interazioni cross-cell creano dipendenze tra celle (e questo riduce i miglioramenti della disponibilità che ne deriverebbero).
![\[Diagramma che mostra un'architettura basata su celle\]](http://docs.aws.amazon.com/it_it/wellarchitected/2022-03-31/framework/images/cell-based-architecture.png)
In un post del suo blog AWS, Colm MacCarthaigh spiega in che modo Amazon Route 53 utilizza il concetto di [https://aws.amazon.com/blogs/architecture/shuffle-sharding-massive-and-magical-fault-isolation/](https://aws.amazon.com/blogs/architecture/shuffle-sharding-massive-and-magical-fault-isolation/) per isolare le richieste dei clienti negli shard. Uno shard in questo caso è costituito da due o più celle. In base alla chiave di partizione, il traffico da un cliente (o risorse o qualsiasi altra cosa desideri isolare) viene instradato allo shard assegnato. Nel caso di otto celle con due celle per shard e clienti divisi tra i quattro shard, il 25% dei clienti riscontrerebbe un impatto in caso di problema.
![\[Diagramma che mostra un servizio suddiviso in partizioni tradizionali\]](http://docs.aws.amazon.com/it_it/wellarchitected/2022-03-31/framework/images/service-divided-into-traditional-shards.png)
Con lo sharding casuale, puoi creare shard virtuali di due celle ciascuno e assegnare i clienti a uno di questi shard virtuali. Quando si verifica un problema, puoi comunque perdere un quarto dell'intero servizio, ma il modo in cui vengono assegnati i clienti o le risorse significa che l'ambito dell'impatto con lo sharding casuale è notevolmente inferiore al 25%. Con otto celle, ci sono 28 combinazioni univoche di due celle, il che significa che ci sono 28 possibili shard casuali (shard virtuali). Se disponi di centinaia o migliaia di clienti e assegni ogni cliente a uno shard casuale, l'impatto causato da un problema è di solo 1/28. Questo è sette volte superiore rispetto allo sharding normale.
![\[Diagramma che mostra un servizio suddiviso in partizioni casuali.\]](http://docs.aws.amazon.com/it_it/wellarchitected/2022-03-31/framework/images/service-divided-into-shuffle-shards.png)
Uno shard può essere utilizzato per server, code o altre risorse in aggiunta alle celle.
**Livello di rischio associato se questa best practice non fosse adottata:** Medium
## Guida all'implementazione
+ Utilizzo di architetture paratie Come per le paratie su una nave, questo modello garantisce il contenimento di un guasto in un piccolo sottoinsieme di richieste/utenti, in modo che il numero di richieste danneggiate sia limitato e si possa comunque continuare senza errori. Le paratie per i dati sono spesso chiamate partizioni, mentre le paratie per i servizi sono note come celle.
+ [Well-Architected lab: Fault isolation with shuffle sharding](https://wellarchitectedlabs.com/reliability/300_labs/300_fault_isolation_with_shuffle_sharding/)
+ [Shuffle-sharding: AWS re:Invent 2019: Introducing The Amazon Builders' Library (Introduzione alla libreria dei costruttori di Amazon) (DOP328)](https://youtu.be/sKRdemSirDM?t=1373)
+ [AWS re:Invent 2018: How AWS Minimizes the Blast Radius of Failures (Come AWS riduce al minimo il raggio di esplosione dei guasti) (ARC338)](https://youtu.be/swQbA4zub20)
+ Valutazione dell'architettura basata su celle per il carico di lavoro In un'architettura basata su celle, ogni cella è un'istanza completa e indipendente del servizio e ha una dimensione massima fissa. Con l'aumentare del carico, i carichi di lavoro aumentano aggiungendo più celle. Una chiave di partizione viene utilizzata sul traffico in entrata per determinare quale cella elaborerà la richiesta. Qualsiasi guasto è contenuto nella singola cella in cui si verifica, in modo che il numero di richieste danneggiate sia limitato man mano che le altre celle continuano senza errori. È importante identificare la chiave di partizione corretta per ridurre al minimo le interazioni tra celle ed evitare la necessità di coinvolgere servizi di mappatura complessi in ogni richiesta. I servizi che richiedono una mappatura complessa finiscono semplicemente per spostare il problema ai servizi di mappatura, mentre i servizi che richiedono interazioni tra celle riducono l'autonomia delle celle (e quindi i presunti miglioramenti della disponibilità che ne deriverebbero).
+ Nel suo post del blog AWS, Colm MacCarthaigh spiega in che modo Amazon Route 53 utilizza il concetto di partizione casuale per isolare le richieste dei clienti nelle partizioni
+ [Shuffle Sharding: Massive and Magical Fault Isolation](https://aws.amazon.com/blogs/architecture/shuffle-sharding-massive-and-magical-fault-isolation)
## Risorse
**Documenti correlati:**
+ [Shuffle Sharding: Massive and Magical Fault Isolation](https://aws.amazon.com/blogs/architecture/shuffle-sharding-massive-and-magical-fault-isolation)
+ [The Amazon Builders' Library: Isolamento del carico di lavoro utilizzando lo sharding casuale](https://aws.amazon.com/builders-library/workload-isolation-using-shuffle-sharding/)
**Video correlati:**
+ [AWS re:Invent 2018: How AWS Minimizes the Blast Radius of Failures (Come AWS riduce al minimo il raggio di esplosione dei guasti) (ARC338)](https://youtu.be/swQbA4zub20)
+ [Shuffle-sharding: AWS re:Invent 2019: Introducing The Amazon Builders' Library (Introduzione alla libreria dei costruttori di Amazon) (DOP328)](https://youtu.be/sKRdemSirDM?t=1373)
**Esempi correlati:**
+ [Well-Architected lab: Fault isolation with shuffle sharding](https://wellarchitectedlabs.com/reliability/300_labs/300_fault_isolation_with_shuffle_sharding/)
# REL 11 In che modo progetti il carico di lavoro affinché resista ai guasti dei componenti?
I carichi di lavoro con requisiti di disponibilità elevata e MTTR (Mean Time To Recovery) basso devono essere progettati per garantire la resilienza.
**Topics**
+ [REL11-BP01 Monitoraggio di tutti i componenti del carico di lavoro per la rilevazione dei guasti](rel_withstand_component_failures_monitoring_health.md)
+ [REL11-BP02 Failover e passaggio a risorse integre](rel_withstand_component_failures_failover2good.md)
+ [REL11-BP03 Automatizzazione della riparazione a tutti i livelli](rel_withstand_component_failures_auto_healing_system.md)
+ [REL11-BP04 Fare affidamento al piano dati invece che al piano di controllo durante il ripristino](rel_withstand_component_failures_avoid_control_plane.md)
+ [REL11-BP05 Utilizzo della stabilità statica per evitare un comportamento bimodale](rel_withstand_component_failures_static_stability.md)
+ [REL11-BP06 Invio di notifiche quando gli eventi influiscono sulla disponibilità](rel_withstand_component_failures_notifications_sent_system.md)
# REL11-BP01 Monitoraggio di tutti i componenti del carico di lavoro per la rilevazione dei guasti
Monitora continuamente lo stato del carico di lavoro, in modo che tu e i tuoi sistemi automatizzati siate consapevoli del deterioramento o del guasto non appena questo si verifica. Monitora gli indicatori chiave di prestazioni (KPI) in base al valore aziendale.
Tutti i meccanismi di ripristino e correzione devono essere in grado di rilevare rapidamente i problemi. I guasti tecnici devono essere rilevati prima in modo che possano essere risolti. Tuttavia, la disponibilità si basa sulla capacità del carico di lavoro di fornire valore aziendale, quindi gli indicatori chiave di prestazione (KPI) che misurano questo aspetto devono far parte della strategia di rilevamento e correzione.
**Anti-pattern comuni:**
+ Non sono stati configurati allarmi, pertanto le interruzioni si verificano senza notifica.
+ Gli allarmi esistono, ma a soglie che non forniscono tempo adeguato per reagire.
+ I parametri non vengono raccolti abbastanza spesso da soddisfare l'obiettivo di tempo di ripristino (RTO, recovery time objective).
+ Solo il livello del carico di lavoro rivolto al cliente viene monitorato attivamente.
+ Viene effettuata solo la raccolta di parametri tecnici, senza includere quelli delle funzioni aziendali.
+ Non è presente alcun parametro che misuri l'esperienza utente del carico di lavoro.
**Vantaggi dell'adozione di questa best practice:** Eseguire un monitoraggio appropriato a tutti i livelli consente di ridurre i tempi di ripristino riducendo i tempi di rilevamento.
**Livello di rischio associato se questa best practice non fosse adottata:** Alta
## Guida all'implementazione
+ Determina l'intervallo di raccolta per i componenti in base agli obiettivi di ripristino.
+ L'intervallo di monitoraggio dipende dalla velocità con cui è necessario ripristinare Il tempo di ripristino dipende dal tempo necessario a ripristinare, perciò è necessario determinare la frequenza della raccolta considerando tale tempo e l'obiettivo di tempo di ripristino (RTO, recovery time objective).
+ Configura il monitoraggio dettagliato per i componenti.
+ Determinare se è necessario un monitoraggio dettagliato per le istanze EC2 e l'Auto Scaling Il monitoraggio dettagliato fornisce parametri con un intervallo di 1 minuto, mentre il monitoraggio predefinito fornisce parametri con un intervallo di 5 minuti.
+ [Abilitare o disabilitare il monitoraggio dettagliato della propria istanza](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-cloudwatch-new.html)
+ [Monitoraggio di gruppi con scalabilità automatica e istanze con Amazon CloudWatch](https://docs.aws.amazon.com/autoscaling/ec2/userguide/as-instance-monitoring.html)
+ Determinare se è necessario un monitoraggio avanzato per RDS Il monitoraggio avanzato utilizza un agente sulle istanze RDS per ottenere informazioni utili su diversi processi o thread in un'istanza RDS.
+ [Monitoraggio avanzato](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_Monitoring.OS.html)
+ Creazione di parametri personalizzati per misurare indicatori chiave di prestazione (KPI) aziendali I carichi di lavoro implementano funzioni aziendali chiave. Queste funzioni devono essere utilizzate come KPI che aiutano a identificare quando si verifica un problema indiretto.
+ [Pubblicazione di parametri personalizzati](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/publishingMetrics.html)
+ Monitoraggio della presenza di errori nell'esperienza utente tramite le canary degli utenti Il test sintetico delle transazioni (noto anche come "test canary", ma da non confondere con le distribuzioni canary) in grado di eseguire e simulare il comportamento dei clienti è uno dei processi di test più importanti. Esegui questi test costantemente sugli endpoint del carico di lavoro da diverse posizioni remote.
+ [Amazon CloudWatch Synthetics consente di creare i Canary dell'utente](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html)
+ Creazione di parametri personalizzati che monitorino l'esperienza dell'utente Dotare l'esperienza del cliente di strumenti consente di determinare quando essa peggiora.
+ [Pubblicazione di parametri personalizzati](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/publishingMetrics.html)
+ Imposta gli allarmi per rilevare quando una qualsiasi parte del carico di lavoro non funziona correttamente e per indicare quando effettuare l'Auto Scaling delle risorse. Gli allarmi possono essere visualizzati sui pannelli di controllo, possono essere inviati avvisi tramite Amazon SNS o e-mail e il dimensionamento automatico può essere utilizzato per aumentare o ridurre le risorse per un carico di lavoro.
+ [Utilizzo degli allarmi di Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html)
+ Crea pannelli di controllo per visualizzare i parametri. I pannelli di controllo possono essere utilizzati per visualizzare tendenze, valori anomali e altri indicatori di potenziali problemi, oppure per fornire un'indicazione dei problemi che potresti voler esaminare.
+ [Utilizzo dei pannelli di controllo CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html)
## Risorse
**Documenti correlati:**
+ [Amazon CloudWatch Synthetics consente di creare i Canary dell'utente](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html)
+ [Abilitare o disabilitare il monitoraggio dettagliato della propria istanza](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-cloudwatch-new.html)
+ [Monitoraggio avanzato](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_Monitoring.OS.html)
+ [Monitoraggio di gruppi con scalabilità automatica e istanze con Amazon CloudWatch](https://docs.aws.amazon.com/autoscaling/ec2/userguide/as-instance-monitoring.html)
+ [Pubblicazione di parametri personalizzati](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/publishingMetrics.html)
+ [Utilizzo degli allarmi di Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html)
+ [Utilizzo dei pannelli di controllo CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html)
**Esempi correlati:**
+ [Corso Well-Architected: Level 300: Implementing Health Checks and Managing Dependencies to Improve Reliability](https://wellarchitectedlabs.com/Reliability/300_Health_Checks_and_Dependencies/README.html)
# REL11-BP02 Failover e passaggio a risorse integre
Garantisce che laddove si verifichi un errore con una risorsa, le risorse integre possano continuare a soddisfare le richieste. Per gli errori legati alle posizioni (ad esempio una zona di disponibilità o una Regione AWS), assicurati di disporre di sistemi che possano eseguire il failover e passare a risorse integre in posizioni non danneggiate.
I servizi AWS, come Elastic Load Balancing e AWS Auto Scaling, aiutano a distribuire il carico tra le risorse e le zone di disponibilità. Pertanto, il guasto di una singola risorsa (come un'istanza EC2) o la compromissione di una zona di disponibilità possono essere mitigati spostando il traffico sulle risorse integre rimanenti. Per i carichi di lavoro multi-regione, questa operazione è più complicata. Ad esempio, le repliche di lettura tra Regioni consentono di implementare i dati in più Regioni AWS, ma è comunque necessario promuovere la replica di lettura a primaria e indirizzare il traffico verso di essa in caso di failover. Amazon Route 53 e AWS Global Accelerator possono aiutare a instradare il traffico tra Regioni AWS.
Se il carico di lavoro utilizza servizi AWS, ad esempio Amazon S3 o Amazon DynamoDB, questi vengono automaticamente implementati in più zone di disponibilità. In caso di errore, il piano di controllo AWS instrada automaticamente il traffico verso le posizioni integre per te. I dati sono archiviati in modo ridondante in più zone di disponibilità e rimangono disponibili. Per Amazon RDS, è necessario scegliere l'opzione di configurazione Multi-AZ; quindi, in caso di errore, AWS indirizzerà automaticamente il traffico verso l'istanza integra. Per le istanze Amazon EC2, le attività Amazon ECS o i pod Amazon EKS, puoi scegliere le zone di disponibilità in cui implementarli. Elastic Load Balancing, quindi, fornisce la soluzione per rilevare le istanze nelle zone non integre e instradare il traffico verso quelle integre. Elastic Load Balancing può anche instradare il traffico verso i componenti del data center on-premise.
Per gli approcci multi-regione (che potrebbero includere anche data center on-premise), Amazon Route 53 offre un modo per definire domini Internet e assegnare policy di instradamento che possono includere controlli dell'integrità per garantire che il traffico venga instradato verso regioni integre. In alternativa, AWS Global Accelerator fornisce indirizzi IP statici che fungono da punto di ingresso fisso alla tua applicazione, quindi, instrada verso endpoint nelle Regioni AWS a tua scelta, utilizzando la rete globale AWS, anziché Internet, per migliorare le prestazioni e l'affidabilità.
AWS si avvicina alla progettazione dei servizi pensando al ripristino degli errori. Progettiamo servizi per ridurre al minimo i tempi di recupero da guasti e l'impatto sui dati. I nostri servizi utilizzano principalmente archivi di dati che riconoscono le richieste solo dopo che queste sono state archiviate in modo duraturo su più repliche in una Regione. Questi servizi e risorse includono Amazon Aurora, istanze database Multi-AZ Amazon Relational Database Service (Amazon RDS), Amazon S3, Amazon DynamoDB, Amazon Simple Queue Service (Amazon SQS) e Amazon Elastic File System (Amazon EFS). Sono costruiti con il criterio dell'isolamento basato sulle celle ed utilizzano l'isolamento dei guasti fornito dalle zone di disponibilità. Facciamo ampio uso dell'automazione nelle nostre procedure operative. Ottimizziamo anche la nostra funzionalità di sostituzione e riavvio per un ripristino rapidamente dalle interruzioni.
**Livello di rischio associato se questa best practice non fosse adottata:** Alta
## Guida all'implementazione
+ Failover su risorse integre. Garantisce che laddove si verifichi un errore con una risorsa, le risorse integre possano continuare a soddisfare le richieste. Per gli errori legati alle posizioni (ad esempio una zona di disponibilità o una Regione AWS), assicurati di disporre di sistemi che possano eseguire il failover e passare a risorse integre in posizioni non danneggiate.
+ Se il carico di lavoro utilizza servizi AWS, ad esempio Amazon S3 o Amazon DynamoDB, questi vengono automaticamente implementati in più zone di disponibilità. In caso di errore, il piano di controllo AWS instrada automaticamente il traffico verso le posizioni integre per te.
+ Per Amazon RDS, è necessario scegliere l'opzione di configurazione Multi-AZ; quindi, in caso di errore, AWS indirizzerà automaticamente il traffico verso l'istanza integra.
+ [Alta disponibilità (Multi-AZ) per Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Concepts.MultiAZ.html)
+ Per le istanze Amazon EC2 o le attività Amazon ECS, puoi scegliere le zone di disponibilità su cui effettuare la distribuzione.Elastic Load Balancing quindi rileverà le istanze in zone non integre e instraderà il traffico verso quelle integre. Elastic Load Balancing può persino instradare il traffico ai componenti nel tuo data center locale.
+ Per approcci multi-regione (che potrebbero includere anche data center in locale), assicurati che i dati e le risorse provenienti da posizioni integre possano continuare a servire le richieste
+ Ad esempio, le repliche di lettura tra Regioni consentono di implementare i dati in più Regioni AWS, ma è comunque necessario promuovere la replica di lettura per dominare e indirizzare il traffico verso di essa in caso di guasto di una posizione primaria.
+ [Panoramica delle repliche di lettura Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ReadRepl.html)
+ Amazon Route 53 offre un modo per definire domini Internet e assegnare policy di instradamento, che potrebbero includere controlli dell'integrità, per garantire che il traffico venga instradato verso Regioni integre. In alternativa, AWS Global Accelerator fornisce indirizzi IP statici che fungono da punto di ingresso fisso alla tua applicazione, quindi, instrada verso endpoint nelle Regioni AWS a tua scelta, utilizzando la rete globale AWS, anziché Internet, per migliorare le prestazioni e l'affidabilità.
+ [Amazon Route 53: scelta di una policy di instradamento](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-policy.html)
+ [Che cos'è AWSGlobal Accelerator?](https://docs.aws.amazon.com/global-accelerator/latest/dg/what-is-global-accelerator.html)
## Risorse
**Documenti correlati:**
+ [Partner APN: partner che possono essere d'aiuto con l'automazione della tua tolleranza ai guasti](https://aws.amazon.com/partners/find/results/?keyword=automation)
+ [Marketplace AWS: prodotti utilizzabili per la tolleranza ai guasti](https://aws.amazon.com/marketplace/search/results?searchTerms=fault+tolerance)
+ [AWS OpsWorks: Using Auto Healing to Replace Failed Instances (Utilizzo della riparazione automatica per sostituire le istanze in errore)](https://docs.aws.amazon.com/opsworks/latest/userguide/workinginstances-autohealing.html)
+ [Amazon Route 53: scelta di una policy di instradamento](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-policy.html)
+ [Alta disponibilità (Multi-AZ) per Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Concepts.MultiAZ.html)
+ [Panoramica delle repliche di lettura Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ReadRepl.html)
+ [Strategie di posizionamento dei processi di Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task-placement-strategies.html)
+ [Creating Kubernetes Auto Scaling Groups for Multiple Availability Zones (Creazione di gruppi con scalabilità automatica Kubernetes per più zone di disponibilità)](https://aws.amazon.com/blogs/containers/amazon-eks-cluster-multi-zone-auto-scaling-groups/)
+ [Che cos'è AWS Global Accelerator?](https://docs.aws.amazon.com/global-accelerator/latest/dg/what-is-global-accelerator.html)
**Esempi correlati:**
+ [Corso Well-Architected: Level 300: Implementing Health Checks and Managing Dependencies to Improve Reliability](https://wellarchitectedlabs.com/Reliability/300_Health_Checks_and_Dependencies/README.html)
# REL11-BP03 Automatizzazione della riparazione a tutti i livelli
Al rilevamento di un guasto, utilizza funzionalità automatizzate per eseguire azioni da correggere.
*La capacità di riavvio* è uno strumento importante per risolvere gli errori. Come illustrato in precedenza per i sistemi distribuiti, una best practice consiste nel rendere i servizi stateless laddove possibile. In questo modo si evita la perdita di dati o la disponibilità al riavvio. Nel cloud, puoi (e generalmente dovresti) sostituire l'intera risorsa (ad esempio, l'istanza EC2 o la funzione Lambda) come parte del riavvio. Il riavvio stesso è un modo semplice e affidabile per eseguire il ripristino in caso di guasto. Molti tipi diversi di guasto si verificano nei carichi di lavoro. Possono verificarsi guasti a livello di hardware, software, comunicazione e operazioni. Anziché creare nuovi meccanismi per intrappolare, identificare e correggere ciascuno dei diversi tipi di guasto, mappa diverse categorie di guasto alla stessa strategia di ripristino. Un'istanza può restituire un guasto causato da un guasto hardware, da un bug del sistema operativo, da una memory leak o da altre cause. Anziché creare una correzione personalizzata per ogni situazione, considera una di esse come un guasto dell'istanza. Termina l'istanza e consenti ad AWS Auto Scaling di sostituirla. In un secondo momento, esegui l'analisi sulla risorsa guasta fuori banda.
Un altro esempio è la possibilità di riavviare una richiesta di rete. Adotta lo stesso approccio di ripristino sia a un timeout di rete sia a un guasto di dipendenza in cui la dipendenza restituisce un guasto. Entrambi gli eventi hanno un effetto simile sul sistema, quindi piuttosto che tentare di trasformare entrambi gli eventi in un "caso speciale", adotta una strategia analoga di nuovi tentativi limitati con un back-off e un jitter esponenziali.
*La capacità di riavvio* è un meccanismo di ripristino presente nelle architetture di cluster ROC (Recovery Oriented Computing) e ad alta disponibilità.
Amazon EventBridge può essere utilizzato per monitorare e filtrare eventi come allarmi CloudWatch o cambiamenti di stato in altri servizi AWS. In base alle informazioni sugli eventi, può quindi attivare AWS Lambda, AWS Systems Manager Automation o altri target per eseguire una logica di riparazione sul carico di lavoro.
Amazon EC2 Auto Scaling può essere configurato per verificare lo stato dell'istanza EC2. Se l'istanza è in uno stato diverso da quello in esecuzione o se lo stato del sistema è danneggiato, Amazon EC2 Auto Scaling considera l'istanza come non integra e ne avvia una sostitutiva. Se utilizzi AWS OpsWorks, puoi configurare la riparazione automatica delle istanze EC2 a livello del layer OpsWorks.
Per le sostituzioni su larga scala (ad esempio la perdita di un'intera zona di disponibilità), anziché cercare di ottenere nuove risorse contemporaneamente è preferibile adottare la stabilità statica per trarre vantaggio dall'elevata disponibilità.
**Anti-pattern comuni:**
+ Implementazione individuale di applicazioni in istanze/container.
+ Distribuzione di applicazioni che non possono essere distribuite in più posizioni senza utilizzare il ripristino automatico.
+ Riparazione manuale delle applicazioni che il dimensionamento e il ripristino automatici non sono stati in grado di riparare.
**Vantaggi dell'adozione di questa best practice:** Il risanamento automatico, anche se il carico di lavoro può essere distribuito in una sola posizione alla volta, ridurrà il tempo medio di ripristino e garantirà la disponibilità del carico di lavoro.
**Livello di rischio associato se questa best practice non fosse adottata:** Alta
## Guida all'implementazione
+ Utilizzo dei gruppi con scalabilità automatica per implementare livelli in un carico di lavoro. Auto Scaling è in grado di eseguire il risanamento automatico sulle applicazioni stateless e aggiungere e rimuovere capacità.
+ [Come funziona AWS Auto Scaling](https://docs.aws.amazon.com/autoscaling/plans/userguide/how-it-works.html)
+ Implementa il ripristino automatico sulle istanze EC2 che includono applicazioni distribuite non distribuibili in più posizioni e possono tollerare il riavvio in caso di guasti. Il ripristino automatico può essere utilizzato per sostituire l'hardware guasto e riavviare l'istanza quando l'applicazione non è in grado di essere distribuita in più posizioni. Vengono conservati i metadati dell'istanza e gli indirizzi IP associati, nonché i volumi Amazon EBS e i punti di montaggio su Elastic File System o file system per Lustre e Windows.
+ [Ripristino automatico Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-recover.html)
+ [Amazon Elastic Block Store (Amazon EBS)](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AmazonEBS.html)
+ [Amazon Elastic File System (Amazon EFS)](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AmazonEFS.html)
+ [What is Amazon FSx for Lustre? Che cos'è Amazon FSx for Lustre?)](https://docs.aws.amazon.com/fsx/latest/LustreGuide/what-is.html)
+ [What is Amazon FSx for Windows File Server? (Che cos'è What is FSx for Windows File Server?)](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/what-is.html)
+ Se utilizzi AWS OpsWorks, puoi configurare il la riparazione automatica delle istanze EC2 a livello del layer.
+ [AWS OpsWorks: Using Auto Healing to Replace Failed Instances (Utilizzo della riparazione automatica per sostituire le istanze in errore)](https://docs.aws.amazon.com/opsworks/latest/userguide/workinginstances-autohealing.html)
+ Implementa il ripristino automatico utilizzando AWS Step Functions e AWS Lambda quando non è possibile utilizzare il dimensionamento automatico o il ripristino automatico oppure quando il ripristino automatico non riesce. Quando non puoi utilizzare il dimensionamento automatico né il ripristino automatico o il ripristino automatico non riesce, puoi automatizzare la riparazione utilizzando AWS Step Functions e AWS Lambda.
+ [What is AWS Step Functions? (Che cos'è AWS Step Functions?)](https://docs.aws.amazon.com/step-functions/latest/dg/welcome.html)
+ [Cos'è AWS Lambda?](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html)
+ Amazon EventBridge può essere utilizzato per monitorare e filtrare eventi come allarmi CloudWatch o cambiamenti di stato in altri servizi AWS. In base alle informazioni sugli eventi, può quindi attivare AWS Lambda (o altri target) per eseguire una logica di riparazione personalizzata sul tuo carico di lavoro.
+ [Che cos'è Amazon EventBridge?](https://docs.aws.amazon.com/eventbridge/latest/userguide/what-is-amazon-eventbridge.html)
+ [Utilizzo degli allarmi di Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html)
## Risorse
**Documenti correlati:**
+ [Partner APN: partner che possono essere d'aiuto con l'automazione della tua tolleranza ai guasti](https://aws.amazon.com/partners/find/results/?keyword=automation)
+ [Marketplace AWS: prodotti utilizzabili per la tolleranza ai guasti](https://aws.amazon.com/marketplace/search/results?searchTerms=fault+tolerance)
+ [AWS OpsWorks: Using Auto Healing to Replace Failed Instances (Utilizzo della riparazione automatica per sostituire le istanze in errore)](https://docs.aws.amazon.com/opsworks/latest/userguide/workinginstances-autohealing.html)
+ [Ripristino automatico Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-recover.html)
+ [Amazon Elastic Block Store (Amazon EBS)](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AmazonEBS.html)
+ [Amazon Elastic File System (Amazon EFS)](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AmazonEFS.html)
+ [Come funziona AWS Auto Scaling](https://docs.aws.amazon.com/autoscaling/plans/userguide/how-it-works.html)
+ [Utilizzo degli allarmi di Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html)
+ [Che cos'è Amazon EventBridge?](https://docs.aws.amazon.com/eventbridge/latest/userguide/what-is-amazon-eventbridge.html)
+ [Cos'è AWS Lambda?](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html)
+ [AWS Systems Manager Automation](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html)
+ [What is AWS Step Functions? (Che cos'è AWS Step Functions?)](https://docs.aws.amazon.com/step-functions/latest/dg/welcome.html)
+ [What is Amazon FSx for Lustre? Che cos'è Amazon FSx for Lustre?)](https://docs.aws.amazon.com/fsx/latest/LustreGuide/what-is.html)
+ [What is Amazon FSx for Windows File Server? (Che cos'è What is FSx for Windows File Server?)](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/what-is.html)
**Video correlati:**
+ [Static stability in AWS: AWS re:Invent 2019: Introducing The Amazon Builders' Library (Introduzione alla libreria dei costruttori di Amazon) (DOP328)](https://youtu.be/sKRdemSirDM?t=704)
**Esempi correlati:**
+ [Corso Well-Architected: Level 300: Implementing Health Checks and Managing Dependencies to Improve Reliability](https://wellarchitectedlabs.com/Reliability/300_Health_Checks_and_Dependencies/README.html)
# REL11-BP04 Fare affidamento al piano dati invece che al piano di controllo durante il ripristino
Il piano di controllo è utilizzato per configurare le risorse, mentre il piano dati fornisce servizi. I piani dati hanno tipicamente obiettivi di progettazione della disponibilità più elevati rispetto ai piani di controllo e sono solitamente meno complessi. Quando si implementano risposte di ripristino o mitigazione a eventi potenzialmente dannosi per la resilienza, l'utilizzo di operazioni sul piano di controllo può ridurre la resilienza complessiva della tua architettura. Per esempio, puoi fare affidamento sul piano dati di Amazon Route 53 per instradare in modo affidabile le query DNS basate sui controlli dell'integrità, ma l'aggiornamento delle policy di instradamento Route 53 utilizza il piano di controllo, quindi non fare affidamento su di esso per il ripristino.
I piani dati di Route 53 rispondono alle query DNS ed eseguono e valutano i controlli di integrità. Sono distribuiti a livello globale e progettati per un [accordo sul livello di servizio (SLA) con disponibilità al 100%.](https://aws.amazon.com/route53/sla/) Le API e le console di gestione di Route 53, dove si creano, aggiornano ed eliminano le risorse di Route 53, funzionano su piani di controllo progettati per privilegiare la forte coerenza e la durata necessarie per la gestione del DNS. A tal fine, i piani di controllo sono situati in un'unica regione, US East (N. Virginia). Sebbene entrambi i sistemi siano costruiti per essere molto affidabili, i piani di controllo non sono inclusi nello SLA. Possono verificarsi eventi rari in cui la progettazione resiliente del piano dati consente di mantenere la disponibilità mentre i piani di controllo non lo fanno. Per i meccanismi di ripristino di emergenza e failover, utilizzare le funzioni del piano dati per garantire la migliore affidabilità possibile.
Per ulteriori informazioni sui piani dati, sui piani di controllo e come AWS costruisce i servizi per soddisfare gli obiettivi di alta disponibilità, consulta il documento [stabilità statica utilizzando le zone di disponibilità](https://aws.amazon.com/builders-library/static-stability-using-availability-zones) e la Libreria [degli sviluppatori di Amazon.](https://aws.amazon.com/builders-library/)
**Livello di rischio associato se questa best practice non fosse adottata:** Alta
## Guida all'implementazione
+ Affidati al piano dati e non al piano di controllo quando utilizzi Amazon Route 53 per il ripristino di emergenza. Route 53 Application Recovery Controller aiuta a gestire e coordinare il failover utilizzando i controlli di disponibilità e i controlli di instradamento. Queste funzionalità monitorano continuamente la capacità dell'applicazione di riprendersi dai guasti e permettono di controllarne il ripristino su più Regioni AWS, zone di disponibilità e on-premise.
+ [What is Route 53 Application Recovery Controller (What is Amazon Route 53 Application Recovery Controller?)](https://docs.aws.amazon.com/r53recovery/latest/dg/what-is-route53-recovery.html)
+ [Creating Disaster Recovery Mechanisms Using Amazon Route 53 (Creazione di meccanismi di ripristino di emergenza con Amazon Route 53)](https://aws.amazon.com/blogs/networking-and-content-delivery/creating-disaster-recovery-mechanisms-using-amazon-route-53/)
+ [Building highly resilient applications using Amazon Route 53 Application Recovery Controller, Part 1: Single-Region stack (Creazione di applicazioni altamente resilienti con Amazon Route 53 Application Recovery Controller, parte 1: stack a singola regione)](https://aws.amazon.com/blogs/networking-and-content-delivery/building-highly-resilient-applications-using-amazon-route-53-application-recovery-controller-part-1-single-region-stack/)
+ [Building highly resilient applications using Amazon Route 53 Application Recovery Controller, Part 2: Multi-Region stack (Creazione di applicazioni altamente resilienti con Amazon Route 53 Application Recovery Controller, parte 2: stack multi-regione)](https://aws.amazon.com/blogs/networking-and-content-delivery/building-highly-resilient-applications-using-amazon-route-53-application-recovery-controller-part-2-multi-region-stack/)
+ Capire quali operazioni sono sul piano dati e quali sul piano di controllo.
+ [The Amazon Builders' Library: Avoiding overload in distributed systems by putting the smaller service in control](https://aws.amazon.com/builders-library/avoiding-overload-in-distributed-systems-by-putting-the-smaller-service-in-control/)
+ [API Amazon DynamoDB (piano di controllo e piano dati)](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/HowItWorks.API.html)
+ [AWS Lambda Executions (Esecuzioni Lambda )](https://docs.aws.amazon.com/whitepapers/latest/security-overview-aws-lambda/lambda-executions.html) (suddivise in piano di controllo e piano dati)
+ [AWS Lambda Executions (Esecuzioni Lambda )](https://docs.aws.amazon.com/whitepapers/latest/security-overview-aws-lambda/lambda-executions.html) (suddivise in piano di controllo e piano dati)
## Risorse
**Documenti correlati:**
+ [Partner APN: partner che possono essere d'aiuto con l'automazione della tua tolleranza ai guasti](https://aws.amazon.com/partners/find/results/?keyword=automation)
+ [Marketplace AWS: prodotti utilizzabili per la tolleranza ai guasti](https://aws.amazon.com/marketplace/search/results?searchTerms=fault+tolerance)
+ [The Amazon Builders' Library: Avoiding overload in distributed systems by putting the smaller service in control](https://aws.amazon.com/builders-library/avoiding-overload-in-distributed-systems-by-putting-the-smaller-service-in-control/)
+ [API Amazon DynamoDB (piano di controllo e piano dati)](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/HowItWorks.API.html)
+ [AWS Lambda Executions (Esecuzioni Lambda )](https://docs.aws.amazon.com/whitepapers/latest/security-overview-aws-lambda/lambda-executions.html) (suddivise in piano di controllo e piano dati)
+ [Piano dati AWS Elemental MediaStore](https://docs.aws.amazon.com/mediastore/latest/apireference/API_Operations_AWS_Elemental_MediaStore_Data_Plane.html)
+ [Building highly resilient applications using Amazon Route 53 Application Recovery Controller, Part 1: Single-Region stack (Creazione di applicazioni altamente resilienti con Amazon Route 53 Application Recovery Controller, parte 1: stack a singola regione)](https://aws.amazon.com/blogs/networking-and-content-delivery/building-highly-resilient-applications-using-amazon-route-53-application-recovery-controller-part-1-single-region-stack/)
+ [Building highly resilient applications using Amazon Route 53 Application Recovery Controller, Part 2: Multi-Region stack (Creazione di applicazioni altamente resilienti con Amazon Route 53 Application Recovery Controller, parte 2: stack multi-regione)](https://aws.amazon.com/blogs/networking-and-content-delivery/building-highly-resilient-applications-using-amazon-route-53-application-recovery-controller-part-2-multi-region-stack/)
+ [Creating Disaster Recovery Mechanisms Using Amazon Route 53 (Creazione di meccanismi di ripristino di emergenza con Amazon Route 53)](https://aws.amazon.com/blogs/networking-and-content-delivery/creating-disaster-recovery-mechanisms-using-amazon-route-53/)
+ [What is Route 53 Application Recovery Controller (What is Amazon Route 53 Application Recovery Controller?)](https://docs.aws.amazon.com/r53recovery/latest/dg/what-is-route53-recovery.html)
**Esempi correlati:**
+ [Introduzione a Amazon Route 53 Application Recovery Controller (Introduzione ad Amazon Route 53 Application Recovery Controller)](https://aws.amazon.com/blogs/aws/amazon-route-53-application-recovery-controller/)
# REL11-BP05 Utilizzo della stabilità statica per evitare un comportamento bimodale
Si ha un comportamento bimodale quando il carico di lavoro mostra un comportamento diverso in modalità normale e di guasto, ad esempio facendo affidamento sull'avvio di nuove istanze se una zona di disponibilità ha esito negativo. Devi invece creare carichi di lavoro che siano staticamente stabili e operino in una sola modalità. In questo caso, effettua il provisioning di istanze sufficienti in ciascuna zona di disponibilità per gestire il carico di lavoro se una zona di disponibilità è stata rimossa, quindi utilizza i controlli dello stato di Elastic Load Balancing o Amazon Route 53 per spostare il carico dalle istanze danneggiate.
La stabilità statica per la distribuzione di calcolo (ad esempio istanze EC2 o container) determinerà la massima affidabilità. Questa operazione deve essere valutata in base ai problemi relativi ai costi. Eseguire il provisioning di minore capacità di elaborazione e affidarsi all'avvio di nuove istanze in caso di guasto è meno costoso. Tuttavia, per i guasti su larga scala (ad esempio un errore nella zona di disponibilità), questo approccio è meno efficace perché si basa sulla reazione ai guasti nel momento in cui si verificano, piuttosto che prepararsi a tali problemi prima che accadano. La soluzione deve valutare l'affidabilità rispetto alle esigenze di costo per il carico di lavoro. Utilizzando più zone di disponibilità, la quantità di elaborazione aggiuntiva necessaria per la stabilità statica diminuisce.
![\[Diagramma che mostra la stabilità statica delle istanze EC2 nelle varie zone di disponibilità\]](http://docs.aws.amazon.com/it_it/wellarchitected/2022-03-31/framework/images/static-stability.png)
Dopo il trasferimento del traffico, utilizza AWS Auto Scaling per sostituire in modo asincrono le istanze dalla zona interessata dal guasto e avviarle nelle zone integre.
Un altro esempio di comportamento bimodale potrebbe essere un timeout di rete che potrebbe causare un tentativo di aggiornamento dello stato di configurazione dell'intero sistema. Ciò aggiungerebbe un carico imprevisto a un altro componente, che potrebbe quindi causare un errore, innescando altre conseguenze impreviste. Questo loop di feedback negativo influisce sulla disponibilità del tuo carico di lavoro. Al contrario, è necessario creare sistemi che siano staticamente stabili e funzionino in una sola modalità. Un progetto staticamente stabile sarebbe quello di eseguire un lavoro costante e aggiornare sempre, con cadenze fisse, lo stato di configurazione. Quando una chiamata non riesce, il carico di lavoro utilizza il valore precedentemente memorizzato nella cache e attiva un allarme.
Un altro esempio di comportamento bimodale è consentire ai client di bypassare la cache del carico di lavoro quando si verificano guasti. Potrebbe sembrare una soluzione che soddisfi le esigenze del client, ma non dovrebbe essere consentita perché modifica in modo significativo le richieste sul carico di lavoro e potrebbe causare guasti.
**Livello di rischio associato se questa best practice non fosse adottata:** Medium
## Guida all'implementazione
+ Utilizzo della stabilità statica per evitare un comportamento bimodale. Si ha un comportamento bimodale quando il carico di lavoro mostra un comportamento diverso in modalità normale e di guasto, ad esempio facendo affidamento sull'avvio di nuove istanze se una zona di disponibilità ha esito negativo.
+ [Minimizing Dependencies in a Disaster Recovery Plan](https://aws.amazon.com/blogs/architecture/minimizing-dependencies-in-a-disaster-recovery-plan/)
+ [The Amazon Builders' Library: Stabilità statica con le zone di disponibilità](https://aws.amazon.com/builders-library/static-stability-using-availability-zones)
+ [Static stability in AWS: AWS re:Invent 2019: Introducing The Amazon Builders' Library (Introduzione alla libreria dei costruttori di Amazon) (DOP328)](https://youtu.be/sKRdemSirDM?t=704)
+ Devi invece creare sistemi che siano staticamente stabili e operino in una sola modalità. In questo caso, effettua il provisioning di istanze sufficienti in ciascuna zona di disponibilità per gestire il carico di lavoro se una zona di disponibilità è stata rimossa, quindi utilizza i controlli dell'integrità di Elastic Load Balancing o Amazon Route 53 per spostare il carico dalle istanze danneggiate.
+ Un altro esempio di comportamento bimodale è consentire ai client di bypassare la cache del carico di lavoro quando si verificano guasti. Potrebbe sembrare una soluzione per soddisfare le esigenze del client, ma non dovrebbe essere consentita perché modifica in modo significativo le richieste sul carico di lavoro e potrebbe causare guasti.
## Risorse
**Documenti correlati:**
+ [Minimizing Dependencies in a Disaster Recovery Plan](https://aws.amazon.com/blogs/architecture/minimizing-dependencies-in-a-disaster-recovery-plan/)
+ [The Amazon Builders' Library: Stabilità statica con le zone di disponibilità](https://aws.amazon.com/builders-library/static-stability-using-availability-zones)
**Video correlati:**
+ [Static stability in AWS: AWS re:Invent 2019: Introducing The Amazon Builders' Library (Introduzione alla libreria dei costruttori di Amazon) (DOP328)](https://youtu.be/sKRdemSirDM?t=704)
# REL11-BP06 Invio di notifiche quando gli eventi influiscono sulla disponibilità
Le notifiche vengono inviate al rilevamento di eventi significativi, anche se il problema causato dall'evento è stato risolto automaticamente.
Il ripristino automatizzato consente al tuo carico di lavoro di essere affidabile. Tuttavia, potrebbe anche oscurare problemi sottostanti che hanno bisogno di essere risolti. Implementa il monitoraggio e gli eventi appropriati in modo da poter rilevare i modelli di problemi, inclusi quelli risolti dalla diagnostica automatica e risolvere così i problemi della causa principale. Gli allarmi di Amazon CloudWatch possono essere attivati in base ai guasti che si verificano. Possono anche attivarsi in base alle operazioni di ripristino automatizzato eseguite. Gli allarmi CloudWatch possono essere configurati per l'invio di e-mail o per la registrazione di file di log nei sistemi di monitoraggio di terze parti tramite l'integrazione con Amazon SNS.
**Anti-pattern comuni:**
+ Invio di allarmi su cui nessuno agisce.
+ Esecuzione dell'automazione del risanamento automatico, ma senza la notifica della necessità di una correzione.
**Vantaggi dell'adozione di questa best practice:** Le notifiche degli eventi di ripristino ti consentiranno di non ignorare i problemi che si verificano di rado.
**Livello di rischio associato se questa best practice non fosse adottata:** Medium
## Guida all'implementazione
+ Allarmi su indicatori chiave di prestazione aziendali al superamento di una soglia minima Un allarme su indicatori chiave di prestazione aziendali consente di sapere quando il carico di lavoro non è disponibile o non funziona.
+ [Creare un allarme CloudWatch basato su una soglia statica](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/ConsoleAlarms.html)
+ Allarme su eventi che invocano l'automazione della riparazione Puoi invocare direttamente un'API SNS per inviare notifiche con qualsiasi automazione creata.
+ [Che cos'è Amazon Simple Notification Service?](https://docs.aws.amazon.com/sns/latest/dg/welcome.html)
## Risorse
**Documenti correlati:**
+ [Creare un allarme CloudWatch basato su una soglia statica](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/ConsoleAlarms.html)
+ [Che cos'è Amazon EventBridge?](https://docs.aws.amazon.com/eventbridge/latest/userguide/what-is-amazon-eventbridge.html)
+ [Che cos'è Amazon Simple Notification Service?](https://docs.aws.amazon.com/sns/latest/dg/welcome.html)
# REL 12 In che modo testi l'affidabilità?
Dopo aver progettato il carico di lavoro in modo da essere resiliente alle sollecitazioni della produzione, i test sono l'unico modo per garantire il funzionamento corretto e offrire la resilienza prevista.
**Topics**
+ [REL12-BP01 Utilizzo dei playbook per analizzare gli errori](rel_testing_resiliency_playbook_resiliency.md)
+ [REL12-BP02 Esecuzione di analisi post-incidente](rel_testing_resiliency_rca_resiliency.md)
+ [REL12-BP03 Test dei requisiti funzionali](rel_testing_resiliency_test_functional.md)
+ [REL12-BP04 Test dei requisiti di dimensionamento e prestazioni](rel_testing_resiliency_test_non_functional.md)
+ [REL12-BP05 Test della resilienza tramite l'utilizzo dell'ingegneria del caos](rel_testing_resiliency_failure_injection_resiliency.md)
+ [REL12-BP06 Esecuzione regolare di giornate di gioco](rel_testing_resiliency_game_days_resiliency.md)
# REL12-BP01 Utilizzo dei playbook per analizzare gli errori
Abilita risposte coerenti e tempestive a scenari di guasto che non sono ben compresi, documentando il processo di analisi nei playbook. I playbook sono le fasi predefinite eseguite per identificare i fattori che contribuiscono a uno scenario di guasto. I risultati provenienti da un passaggio del processo vengono utilizzati per stabilire i passaggi successivi da intraprendere fino all'identificazione o alla risoluzione del problema.
Il playbook è una pianificazione proattiva che è necessario eseguire, in modo da potere intraprendere azioni reattive in modo efficace. Quando durante la produzione si verificano scenari di guasto non coperti dal playbook, risolvi innanzitutto il problema (spegni l'incendio). Quindi torna indietro e osserva le fasi intraprese per risolvere il problema e utilizzale per aggiungere una nuova voce al playbook.
Tieni presente che i playbook vengono utilizzati in risposta a specifici incidenti, mentre i runbook vengono utilizzati per ottenere esiti specifici. Spesso, i runbook vengono utilizzati per le attività di routine e i playbook vengono utilizzati per rispondere a eventi non di routine.
**Anti-pattern comuni:**
+ Pianificare la distribuzione di un carico di lavoro senza conoscere i processi per diagnosticare i problemi o rispondere agli incidenti.
+ Decisioni non pianificate sui sistemi da cui raccogliere log e parametri durante l'analisi di un evento.
+ Non conservare parametri e eventi abbastanza a lungo da poter recuperare i dati.
**Vantaggi dell'adozione di questa best practice:** L'acquisizione di playbook garantisce l'esecuzione coerente dei processi. La codifica dei playbook limita l'introduzione di errori derivanti dall'attività manuale. L'automazione dei playbook riduce il tempo necessario per rispondere a un evento eliminando il requisito per l'intervento dei membri del team o fornendo loro informazioni aggiuntive quando inizia l'intervento.
**Livello di rischio associato se questa best practice non fosse adottata:** Alta
## Guida all'implementazione
+ Utilizza playbook per identificare i problemi. I playbook sono processi documentati per eseguire indagini sui problemi. Abilita risposte coerenti e tempestive agli scenari di errore documentando i processi nei playbook. I playbook devono contenere le informazioni e le istruzioni necessarie affinché una persona adeguatamente qualificata possa raccogliere le informazioni applicabili, identificare potenziali fonti di errore, isolare i guasti e stabilire i fattori che contribuiscono all'origine di un problema (eseguire l'analisi post-incidente).
+ Implementazione dei playbook come codice. Esegui le operazioni come codice mediante lo scripting dei playbook per assicurare coerenza e ridurre gli errori causati dai processi manuali. I playbook possono essere composti da più script che rappresentano le diverse fasi che potrebbero essere necessarie per identificare i fattori che contribuiscono all'origine di un problema. Le attività dei runbook possono essere attivate o eseguite nell'ambito delle attività dei playbook oppure possono richiedere l'esecuzione di un playbook in risposta agli eventi identificati.
+ [Automazione dei playbook operativi con AWS Systems Manager](https://aws.amazon.com/about-aws/whats-new/2019/11/automate-your-operational-playbooks-with-aws-systems-manager/)
+ [AWS Systems Manager Run Command](https://docs.aws.amazon.com/systems-manager/latest/userguide/execute-remote-commands.html)
+ [AWS Systems Manager Automation](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html)
+ [Cos'è AWS Lambda?](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html)
+ [Che cos'è Amazon EventBridge?](https://docs.aws.amazon.com/eventbridge/latest/userguide/what-is-amazon-eventbridge.html)
+ [Utilizzo degli allarmi di Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html)
## Risorse
**Documenti correlati:**
+ [AWS Systems Manager Automation](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html)
+ [AWS Systems Manager Run Command](https://docs.aws.amazon.com/systems-manager/latest/userguide/execute-remote-commands.html)
+ [Automazione dei playbook operativi con AWS Systems Manager](https://aws.amazon.com/about-aws/whats-new/2019/11/automate-your-operational-playbooks-with-aws-systems-manager/)
+ [Utilizzo degli allarmi di Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html)
+ [Utilizzo di Canary (Amazon CloudWatch Synthetics)](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html)
+ [Che cos'è Amazon EventBridge?](https://docs.aws.amazon.com/eventbridge/latest/userguide/what-is-amazon-eventbridge.html)
+ [Cos'è AWS Lambda?](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html)
**Esempi correlati:**
+ [Automating operations with Playbooks and Runbooks (Automazione delle operazioni con Playbook e Runbook)](https://wellarchitectedlabs.com/operational-excellence/200_labs/200_automating_operations_with_playbooks_and_runbooks/)
# REL12-BP02 Esecuzione di analisi post-incidente
Esamina gli eventi che influiscono sui clienti e identifica i fattori che vi hanno contribuito e gli elementi di azione preventivi. Utilizza queste informazioni per sviluppare modi per limitare o prevenire il ripetersi degli imprevisti. Sviluppa procedure per attivare risposte rapide ed efficaci. Comunica i fattori che hanno contribuito al presentarsi dell'imprevisto e le azioni correttive secondo necessità, specificamente mirate per il pubblico di destinazione. All'occorrenza, adotta un metodo per comunicare queste cause ad altri.
Valuta perché i test esistenti non hanno individuato il problema. Aggiungi i test per questo caso se i test non esistono già.
**Anti-pattern comuni:**
+ Individuare i fattori che hanno contribuito al verificarsi dell'incidente, ma non continuare a cercare in maniera più approfondita altri potenziali problemi e approcci da mitigare.
+ Identificare le cause degli errori umani senza fornire alcuna formazione o automazione che potrebbe prevenirli.
**Vantaggi dell'adozione di questa best practice:** L'esecuzione di analisi post-incidente e la condivisione dei risultati consente ad altri carichi di lavoro di mitigare il rischio se hanno implementato gli stessi fattori che hanno contribuito al verificarsi dell'incidente e consente loro di implementare la mitigazione o il ripristino automatico prima che si verifichi un incidente.
**Livello di rischio associato se questa best practice non fosse adottata:** Alta
## Guida all'implementazione
+ Definizione di uno standard per l'analisi post-incidente. Una buona analisi post-incidente fornisce opportunità per proporre soluzioni comuni a problemi con modelli di architettura utilizzati in altri punti nei tuoi sistemi.
+ Assicurati che i fattori che hanno contribuito al verificarsi dell'incidente siano onesti e non presentino colpe.
+ Se non documenti i tuoi problemi, non puoi correggerli.
+ Assicurati che l'analisi post-incidente sia esente da colpe, in modo da poter essere obiettivo riguardo alle azioni correttive proposte e promuovere autovalutazione e collaborazione oneste nei team applicativi.
+ Utilizza un processo per determinare i fattori che concorrenti. Predisponi un processo per identificare e documentare i fattori che contribuiscono al verificarsi di un evento, in modo da sviluppare azioni di mitigazione in grado di limitare o impedire il suo ripetersi e per sviluppare procedure che consentano risposte rapide ed efficaci. Comunica i fattori che hanno contribuito al verificarsi dell'incidente in maniera appropriata, specificamente mirati al pubblico di destinazione.
+ [Che cos'è l'analisi dei log?](https://aws.amazon.com/log-analytics/)
## Risorse
**Documenti correlati:**
+ [Che cos'è l'analisi dei log?](https://aws.amazon.com/log-analytics/)
+ [Why you should develop a correction of error (COE) (Perché sviluppare una correzione dell'errore)](https://aws.amazon.com/blogs/mt/why-you-should-develop-a-correction-of-error-coe/)
# REL12-BP03 Test dei requisiti funzionali
Utilizza tecniche come i test unitari e i test di integrazione per convalidare le funzionalità richieste.
Puoi ottenere i migliori risultati quando questi test vengono eseguiti automaticamente come parte delle operazioni di sviluppo e distribuzione. Ad esempio, utilizzando AWS CodePipeline, gli sviluppatori affidano le modifiche a un repository di origine in cui CodePipeline rileva automaticamente le modifiche. Queste modifiche vengono create e vengono eseguiti test. Una volta completati i test, il codice creato viene distribuito ai server temporaneo per il test. Dal server temporaneo, CodePipeline esegue più test, come quelli di integrazione o caricamento. Una volta completati con successo i test, CodePipeline distribuisce il codice testato e approvato alle istanze di produzione.
Inoltre, l'esperienza dimostra che i test sintetici delle transazioni (noti anche come *test canary*, ma da non confondere con le implementazioni canary) in grado di eseguire e simulare il comportamento dei clienti sono uno dei processi di test più importanti. Esegui questi test costantemente sugli endpoint del carico di lavoro da diverse posizioni remote. Amazon CloudWatch Synthetics ti consente di [creare "canary"](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html) per monitorare gli endpoint e le API.
**Livello di rischio associato se questa best practice non fosse adottata:** Alta
## Guida all'implementazione
+ Test dei requisiti funzionali. Includono test delle unità e test di integrazione che convalidano la funzionalità richiesta.
+ [Utilizzo di CodePipeline con AWS CodeBuild per testare il codice ed eseguire compilazioni](https://docs.aws.amazon.com/codebuild/latest/userguide/how-to-create-pipeline.html)
+ [AWS CodePipeline Adds Support for Unit and Custom Integration Testing with AWS CodeBuild (AWS CodePipeline aggiunge il supporto per i test di unità e integrazione personalizzati con AWS CodeBuild)](https://aws.amazon.com/about-aws/whats-new/2017/03/aws-codepipeline-adds-support-for-unit-testing/)
+ [Distribuzione continua e integrazione continua](https://docs.aws.amazon.com/codepipeline/latest/userguide/concepts-continuous-delivery-integration.html)
+ [Utilizzo di Canary (Amazon CloudWatch Synthetics)](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html)
+ [Automazione e test del software](https://aws.amazon.com/marketplace/solutions/devops/software-test-automation)
## Risorse
**Documenti correlati:**
+ [Partner APN: partner che possono essere d'aiuto nell'implementazione di una pipeline di integrazione continua](https://aws.amazon.com/partners/find/results/?keyword=Continuous+Integration)
+ [AWS CodePipeline Adds Support for Unit and Custom Integration Testing with AWS CodeBuild (AWS CodePipeline aggiunge il supporto per i test di unità e integrazione personalizzati con AWS CodeBuild)](https://aws.amazon.com/about-aws/whats-new/2017/03/aws-codepipeline-adds-support-for-unit-testing/)
+ [Marketplace AWS: prodotti utilizzabili per l'integrazione continua](https://aws.amazon.com/marketplace/search/results?searchTerms=Continuous+integration)
+ [Distribuzione continua e integrazione continua](https://docs.aws.amazon.com/codepipeline/latest/userguide/concepts-continuous-delivery-integration.html)
+ [Automazione e test del software](https://aws.amazon.com/marketplace/solutions/devops/software-test-automation)
+ [Utilizzo di CodePipeline con AWS CodeBuild per testare il codice ed eseguire compilazioni](https://docs.aws.amazon.com/codebuild/latest/userguide/how-to-create-pipeline.html)
+ [Utilizzo di Canary (Amazon CloudWatch Synthetics)](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html)
# REL12-BP04 Test dei requisiti di dimensionamento e prestazioni
Utilizza tecniche come i test di carico per convalidare che il carico di lavoro soddisfi i requisiti di dimensionamento e prestazioni.
Nel cloud, puoi creare un ambiente di test su scala di produzione on demand per il tuo carico di lavoro. Se esegui questi test su un'infrastruttura ridotta, devi dimensionare i risultati osservati in base a ciò che pensi accadrà in produzione. I test di carico e prestazioni possono essere eseguiti anche in produzione se si fa attenzione a non influire sugli utenti effettivi e si contrassegna con tag i dati di test in modo da non utilizzare dati utente reali e non danneggiare le statistiche di utilizzo o i report di produzione.
Con i test, assicurati che le risorse di base, le impostazioni di dimensionamento, le quote di servizio e la progettazione di resilienza funzionino come previsto sotto carico.
**Livello di rischio associato se questa best practice non fosse adottata:** Alta
## Guida all'implementazione
+ Test dei requisiti di dimensionamento e prestazioni. Esegui test del carico per verificare che il carico di lavoro soddisfi i requisiti di dimensionamento e prestazioni.
+ [Distributed Load Testing on AWS (Test di carico distribuito su AWS): simula migliaia di utenti connessi](https://aws.amazon.com/solutions/distributed-load-testing-on-aws/)
+ [Apache JMeter](https://github.com/apache/jmeter?ref=wellarchitected)
+ Distribuisci la tua applicazione in un ambiente identico al tuo ambiente di produzione ed esegui un test di carico.
+ Utilizza un'infrastruttura come code concept per creare un ambiente il più simile possibile al tuo ambiente di produzione.
## Risorse
**Documenti correlati:**
+ [Distributed Load Testing on AWS (Test di carico distribuito su AWS): simula migliaia di utenti connessi](https://aws.amazon.com/solutions/distributed-load-testing-on-aws/)
+ [Apache JMeter](https://github.com/apache/jmeter?ref=wellarchitected)
# REL12-BP05 Test della resilienza tramite l'utilizzo dell'ingegneria del caos
Esegui regolarmente esperimenti di ingegneria del caos in ambienti di produzione o per quanto possibile ambienti analoghi per capire in che modo il sistema risponde a condizioni avverse.
** Risultato desiderato: **
La resilienza del carico di lavoro viene regolarmente verificata mediante l'applicazione dell'ingegneria del caos sotto forma di esperimenti di iniezione di errori o di inserimento di carichi imprevisti, nonché mediante il test della resilienza che convalida i comportamenti previsti noti del carico di lavoro durante un evento. Combina l'ingegneria del caos e i test della resilienza per verificare se il carico di lavoro è in grado di superare i guasti dei componenti ed eseguire il ripristino da interruzioni del servizio impreviste con un impatto minimo o nullo.
** Anti-pattern comuni: **
+ Progettazione della resilienza, ma mancata verifica del funzionamento del carico di lavoro nel suo complesso in caso di errori.
+ Mancata sperimentazione in scenari reali e con carichi previsti.
+ Mancato trattamento degli esperimenti come codice o loro conservazione durante il ciclo di sviluppo.
+ Mancata esecuzione degli esperimenti di ingegneria del caos sia nella pipeline CI/CD che esternamente alle implementazioni.
+ Mancato utilizzo delle precedenti analisi post-incidente durante la determinazione degli errori su cui eseguire i test.
** Vantaggi dell'adozione di questa best practice:** l'introduzione di errori per verificare la resilienza del carico di lavoro consente di verificare che le procedure di ripristino della progettazione resiliente funzionerà se viene generato un vero e proprio errore.
**Livello di rischio associato se questa best practice non fosse adottata:** Medio
## Guida all'implementazione
L'ingegneria del caos offre ai team la possibilità di continuare a inserire scenari di errore reali (simulazioni) in modo controllato a livello di fornitore di servizi, infrastruttura, carico di lavoro e componente con un impatto minimo o nullo per i clienti. Consente inoltre ai team di imparare dagli errori e osservare, misurare e migliorare la resilienza dei carichi di lavoro, nonché verificare l'attivazione degli avvisi e se tali avvisi vengono recapitati ai team se si verifica un evento definito.
Se applicata in modo continuativo, l'ingegneria del caos può mettere in evidenza i difetti del carico di lavoro che, se non risolti, possono avere ripercussioni negative sulla disponibilità e sulle operazioni.
**Nota**
L'ingegneria del caos è la disciplina che sperimenta un sistema per creare fiducia nella capacità del sistema di affrontare condizioni turbolenti nella produzione. – [Principi di ingegneria del caos](https://principlesofchaos.org/)
Se un sistema è in grado di sopportare queste interruzioni, l'esperimento di ingegneria del caos deve essere convertito in test automatico di regressione. In questo modo, gli esperimenti di ingegneria del caos devono essere eseguiti nell'ambito del ciclo di vita dello sviluppo dei sistemi (SDLC) e della pipeline CI/CD.
Per garantire che il carico di lavoro sia in grado di gestire un guasto del componente, esegui l'iniezione di eventi di errore reali durante l'esecuzione degli esperimenti. Ad esempio, esegui esperimenti relativi alla perdita di istanze Amazon EC2 o a eventi di failover delle istanze database Amazon RDS primario e quindi verifica che il carico di lavoro non sia stato compromesso oppure o che si stato interessato solo in minima parte. Utilizza una combinazione di errori dei componenti per simulare gli eventi che possono essere causati da un'interruzione del servizio in una zona di disponibilità.
Per gli errori a livello di applicazione, ad esempio gli arresti anomali, puoi iniziare utilizzando fattori di stress, ad esempio l'esaurimento della memoria o della CPU.
Per convalidare i [meccanismi di fallback o failover](https://aws.amazon.com/builders-library/avoiding-fallback-in-distributed-systems/) per le dipendenze esterne causate da interruzioni intermittenti dei servizi di rete, i componenti devono simulare tale evento bloccando l'accesso ai fornitori di terze parti per una durata specificata, che può durare da pochi secondi ad alcune ore.
Altre modalità di degrado possono causare funzionalità ridotte e risposte lente, spesso con conseguente interruzione dei servizi. Le fonti comuni di questo degrado sono una maggiore latenza nei servizi critici e una comunicazione di rete inaffidabile (pacchetti persi). Gli esperimenti basati su questi errori, inclusi gli effetti a livello di rete come latenza, messaggi eliminati ed errori DNS, possono prevedere l'incapacità di risolvere un nome, raggiungere il servizio DNS o stabilire connessioni a servizi dipendenti.
**Strumenti dell'ingegneria del caos**
AWS Fault Injection Service (AWS FIS) è un servizio completamente gestito per l'esecuzione di esperimenti di iniezione di errori che possono essere utilizzati come parte della pipeline di CD o al suo esterno. AWS FIS è una soluzione estremamente valida da utilizzare durante i giorni di gioco dell'ingegneria del caos. Supporta l'introduzione simultanea di errori in diversi tipi di risorse, ad esempio Amazon EC2, Amazon Elastic Container Service (Amazon ECS), Amazon Elastic Kubernetes Service (Amazon EKS) e Amazon RDS. Questi errori includono la cessazione delle risorse, la forzatura dei failover, l'applicazione di fattori di stress a CPU o memoria, la limitazione della lunghezza di banda della rete, la latenza e la perdita di pacchetti. Poiché è integrato con gli allarmi Amazon CloudWatch, è possibile impostare condizioni di arresto come guardrail per eseguire il rollback di un esperimento se causa un impatto inatteso.
![\[Diagramma che mostra AWS Fault Injection Service integrato con le risorse AWS per consentire l'esecuzione di esperimenti di iniezione di errori per i carichi di lavoro.\]](http://docs.aws.amazon.com/it_it/wellarchitected/2022-03-31/framework/images/fault-injection-simulator.png)
Esistono anche diverse opzioni di terze parti per gli esperimenti di iniezione di errori. Queste includono strumenti open source, ad esempio [Chaos Toolkit](https://chaostoolkit.org/), [Chaos Mesh](https://chaos-mesh.org/)e [Litmus Chaos](https://litmuschaos.io/), nonché opzioni commerciali come Gremlin. Per ampliare l'ambito degli errori che possono essere inseriti in AWS, AWS FIS [si integra con Chaos Mesh e Litmus Chaos](https://aws.amazon.com/about-aws/whats-new/2022/07/aws-fault-injection-simulator-supports-chaosmesh-litmus-experiments/)e ciò consente di coordinare i flussi di lavoro relativi all'iniezione di errori tra più strumenti. Ad esempio, puoi eseguire un test di stress sulla CPU di un pod utilizzando gli errori di Chaos Mesh o Litmus Chaos durante la cessazione di una percentuale casualmente selezionata di nodi di cluster mediante le operazioni di errore di AWS FIS.
## Passaggi dell'implementazione
+ Determinazione degli errori da utilizzare per gli esperimenti.
Valutazione della progettazione del carico di lavoro a livello di resilienza. Tali progettazioni, create mediante le best practice del [Canone di architettura AWS](https://docs.aws.amazon.com/wellarchitected/latest/framework/welcome.html)) giustificano i rischi in base alle dipendenze critiche, agli eventi pregressi, alle problematiche note e ai requisiti di conformità. Elenca i singoli elementi della progettazione che devono conservare la resilienza e gli errori per mitigare i quali è stata sviluppata. Per ulteriori informazioni su questi elenchi, consulta [il whitepaper relativo alla prontezza operativa](https://docs.aws.amazon.com/wellarchitected/latest/operational-readiness-reviews/wa-operational-readiness-reviews.html) , contenente linee guida su come creare un processo per impedire che si verifichino di nuovo incidenti già noti. Il processo FMEA (Failure Modes and Effects Analysis) fornisce un framework per l'esecuzione di un'analisi degli errori a livello di componente e del relativo impatto sul carico di lavoro. Il processo FMEA è descritto più in dettaglio nell'articolo di Adrian Cockcroft su [modalità di errore e resilienza continua](https://adrianco.medium.com/failure-modes-and-continuous-resilience-6553078caad5).
+ Assegna una priorità a ogni errore.
Comincia con una categorizzazione approssimativa, ad esempio alta, media o bassa. Per assegnare la priorità, considera la frequenza dell'errore e l'impatto dell'errore sul carico di lavoro nel suo complesso.
Durante la valutazione della frequenza di un errore specifico, analizza i precedenti dati per lo stesso carico di lavoro, se disponibili. Se non sono disponibili, utilizza i dati di altri carichi di lavoro eseguiti in un ambiente simile.
Durante la valutazione dell'impatto di un errore specifico, in genere maggiore è l'ambito dell'errore, maggiore sarà l'impatto. Considera la progettazione e lo scopo del carico di lavoro. Ad esempio, la capacità di accedere ai datastore di origine è di cruciale importanza per un carico di lavoro responsabile della trasformazione e dell'analisi dei dati. In questo caso, darai la precedenza agli esperimenti relativi agli errori di accesso, nonché a quelli con accesso limitato a livello di larghezza di banda e inserimento di latenza.
Le analisi post-incidente rappresentano un'ottima fonte di dati per la comprensione della frequenza e dell'impatto delle modalità di errore.
Utilizza la priorità assegnata per determinare il primo errore su cui eseguire l'esperimento e l'ordine in cui sviluppare i nuovi esperimenti di iniezione di errori.
+ Per ogni esperimento eseguito, attieniti ai principi del volano dell'ingegneria del caos e della resilienza continua.
![\[Diagramma del volano dell'ingegneria del caos e della resilienza continua, con le fasi relative a miglioramento, stato stazionario, ipotesi, esecuzione dell'esperimento e verifica.\]](http://docs.aws.amazon.com/it_it/wellarchitected/2022-03-31/framework/images/chaos-engineering-flywheel.png)
+ Definisci lo stato stazionario come output misurabile di un carico di lavoro che indica un comportamento normale.
Il carico di lavoro è associato allo stato stazionario se il suo funzionamento è affidabile e conforme a quanto previsto. Verifica pertanto che il carico di lavoro sia integro prima di definire lo stato stazionario. Lo stato stazionario non necessariamente indica l'assenza di impatto sul carico di lavoro se si verifica un errore in quanto una data percentuale di errori può rientrare nei limiti di valori accettabili. Lo stato stazionario rappresenta il punto di riferimento che verrà osservato durante l'esperimento e che metterà in evidenza le anomalie se le ipotesi definite nel passaggio successivo non sono conformi alle previsioni.
Ad esempio, lo stato stazionario di un sistema di pagamento può essere definito come elaborazione di 300 TPS con una percentuale di successo pari al 99% e un tempo di round trip pari a 500 ms.
+ Definisci un'ipotesi in merito alle reazioni del carico di lavoro all'errore.
Un'ipotesi ottimale fa riferimento al modo in cui il carico di lavoro presumibilmente è in grado di ridurre l'impatto dell'errore e salvaguardare lo stato stazionario. Nell'ipotesi è definito che, dato un errore di un tipo specifico, il sistema o il carico di lavoro rimarrà nello stato stazionario perché la progettazione del carico di lavoro ha previsto sistemi specifici di attenuazione degli errori. Il tipo di errore specifico e i sistemi di attenuazione devono essere specificati nell'ipotesi.
Per l'ipotesi è possibile utilizzare il seguente modello, anche se è accettabile una formulazione diversa:
**Nota**
Se si verifica un *errore specifico* , il carico di lavoro *nome del carico di lavoro* descriverà *i controlli di attenuazione* per controbilanciare *l'impatto sulle metriche aziendali o tecniche*.
Ad esempio:
+ In caso di arresto del 20% dei nodi nel gruppo di nodi Amazon EKS, l'API di creazione delle transazioni continua a servire il 99° percentile delle richieste in meno di 100 ms (stato stazionario). Verrà eseguito il ripristino dei nodi Amazon EKS entro cinque minuti; i pod verranno riprogrammati ed elaboreranno il traffico entro otto minuti dall'inizio dell'esperimento. Gli avvisi verranno attivati entro tre minuti.
+ Se si verifica un errore in un'istanza Amazon EC2, il controllo dell'integrità Elastic Load Balancing del sistema degli ordini farà sì che Elastic Load Balancing si limiti a inviare richieste alle rimanenti istanze integre, mentre la funzionalità Amazon EC2 Auto Scaling sostituirà l'istanza in errore, garantendo un incremento inferiore allo 0,01% degli errori (5xx) lato server (stato stazionario).
+ Se l'istanza database primario Amazon RDS restituisce un errore, il carico di lavoro della raccolta di dati della catena di approvvigionamento eseguirà il failover e si connetterà all'istanza database in standby Amazon RDS per mantenere meno di un minuto di errori di lettura o scrittura del database (stato stazionario).
+ Esegui l'esperimento inserendo l'errore.
Per impostazione predefinita, un esperimento deve essere a prova di errore e tollerato dal carico di lavoro. Se sei consapevole del fatto che il carico di lavoro avrà esito negativo, non eseguire l'esperimento. L'ingegneria del caos deve essere utilizzata per individuare scenari noti sconosciuti o scenari completamente sconosciuti. *"Scenari noti sconosciuti"* fanno riferimento a quegli scenari di cui sei consapevole, ma non ne comprendi completamente la natura, mentre con *"scenari completamente sconosciuti"* si intendono quegli scenari a te non noti e di cui non ne comprendi la natura o i motivi. L'esecuzione di esperimenti su un carico di lavoro non funzionante non può fornire nuovi approfondimenti chiarificatori. L'esperimento deve infatti essere pianificato con attenzione, essere caratterizzato da un ambito ben definito relativamente al suo impatto, nonché fornire un meccanismo di rollback applicabile in caso di esiti negativi imprevisti. Se il criterio di due diligence indica che il carico di lavoro è in grado di sostenere l'esperimento, procedi ed esegui l'esperimento. Sono disponibili varie opzioni per l'inserimento degli errori. Per i carichi di lavoro in AWS, [AWS FIS](https://docs.aws.amazon.com/fis/latest/userguide/what-is.html) fornisce numerose simulazioni di errore predefinite denominate [operazioni](https://docs.aws.amazon.com/fis/latest/userguide/actions.html). Puoi anche definire operazioni personalizzate eseguibili in AWS FIS utilizzando i [documenti AWS Systems Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/sysman-ssm-docs.html).
È sconsigliato l'uso di script personalizzati per gli esperimenti di ingegneria del caos, a meno che gli script non siano in grado di rilevare lo stato corrente del carico di lavoro, generare log e fornire meccanismi di rollback e condizioni di arresto, laddove possibile.
Un framework o set di strumenti efficace che supporta l'ingegneria del caos deve tenere traccia dello stato corrente di un esperimento, generare log e fornire meccanismi di rollback a supporto dell'esecuzione controllata di un esperimento. Inizia utilizzando un servizio noto, ad esempio AWS FIS, che consente di eseguire esperimenti con ambiti e meccanismi di sicurezza ben definiti in grado di eseguire il rollback dell'esperimento in caso di esiti negativi imprevisti. Per ulteriori informazioni sull'intera gamma di esperimenti che utilizzano AWS FIS, consulta anche la sezione relativa al [laboratorio relativo alle app Well-Architected resilienti con ingegneria del caos](https://catalog.us-east-1.prod.workshops.aws/workshops/44e29d0c-6c38-4ef3-8ff3-6d95a51ce5ac/en-US). Inoltre, [AWS Resilience Hub](https://docs.aws.amazon.com/resilience-hub/latest/userguide/what-is.html) analizzerà il carico di lavoro e creerà gli esperimenti che potrai scegliere di implementare ed eseguire in AWS FIS.
**Nota**
Per ogni esperimento, devi essere consapevole del suo ambito e del relativo impatto. È consigliabile eseguire la simulazione dell'errore in un ambiente non di produzione prima di eseguirla in un ambiente di produzione vero e proprio.
Gli esperimenti devono essere eseguiti in ambienti di produzione con un carico reale mediante [implementazioni canary](https://medium.com/the-cloud-architect/chaos-engineering-q-a-how-to-safely-inject-failure-ced26e11b3db) , che attivano sistemi sperimentali e di controllo, laddove possibile. L'esecuzione degli esperimenti durante gli orari non di punta è altamente consigliata al fine di ridurre al massimo potenziali eventi negativi durante la prima esecuzione dell'esperimento negli ambienti di produzione. Inoltre, se l'utilizzo dell'effettivo traffico clienti costituisce un rischio eccessivo, puoi eseguire gli esperimenti utilizzando una sintesi del traffico nell'infrastruttura di produzione utilizzando implementazioni sperimentali e di controllo. Se l'utilizzo di un ambiente di produzione non è possibile, esegui gli esperimenti in ambienti di pre-produzione il più simili possibile agli effettivi ambienti di produzione.
Devi definire e monitorare i guardrail per essere sicuro che l'esperimento non abbia un impatto sul traffico di produzione o sugli altri sistemi che superi i limiti accettabili. Definisci condizioni di arresto per interrompere l'esperimento se viene raggiunta la soglia definita nella metrica del guardrail. In tali condizioni devono essere incluse le metriche relative allo stato stazionario del carico di lavoro e le metriche riferite ai componenti in cui inserisci l'errore. Un [monitor sintetico](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html) (definito anche canary utente) è una metrica che in genere deve essere inclusa come proxy utente. [Le condizioni di arresto per AWS FIS](https://docs.aws.amazon.com/fis/latest/userguide/stop-conditions.html) sono supportate nel modello di esperimento, nella misura di un massimo di cinque condizioni di arresto per modello.
Uno dei principi dell'ingegneria del caos prevede la riduzione dell'ambito dell'esperimento e del relativo impatto.
Se da un lato deve essere prevista la possibilità di un determinato impatto negativo a breve termine, dall'altro il contenimento e la riduzione delle conseguenze negative degli esperimenti sono una responsabilità esclusiva dell'addetto all'ingegneria del caos.
Un metodo per verificare l'ambito e il potenziale impatto prevede l'esecuzione dell'esperimento dapprima in un ambiente non di produzione, la verifica che le soglie delle condizioni di arresto vengano attivate come previsto durante lo svolgimento di un esperimento e l'utilizzo effettivo delle misure di osservabilità finalizzate all'acquisizione di un'eccezione, anziché eseguire l'esperimento direttamente in produzione.
Durante l'esecuzione di esperimenti di iniezione di errori, verifica che tutte le parti responsabili ne siano a conoscenza. Comunica ai team appropriati, ad esempio i team responsabili delle operazioni, dell'affidabilità dei servizi e del supporto clienti, quando verranno eseguiti gli esperimenti e l'impatto previsto. Metti a disposizione di questi team strumenti di comunicazione che consentano loro di informare i responsabili dell'esperimento di eventuali effetti avversi.
È necessario ripristinare lo stato originario del carico di lavoro e dei relativi sistemi sottostanti. La progettazione resiliente del carico di lavoro è spesso caratterizzata da funzionalità di riparazione automatica. Tuttavia, alcune progettazioni difettose o alcuni esperimenti non riusciti possono compromettere in modo imprevisto lo stato del carico di lavoro. Entro la fine dell'esperimento dovrai essere consapevole di questa situazione e ripristinare il carico di lavoro e i sistemi. Con AWS FIS puoi impostare una configurazione di rollback, definita anche post-operazione, all'interno dei parametri operativi. Una post-operazione ripristina una destinazione allo stato in cui si trovava prima dell'esecuzione dell'operazione stessa. Indipendentemente dal fatto che vengano eseguite in modalità automatica, ad esempio utilizzando AWS FIS, o manuale, queste post-operazioni devono essere incluse in un playbook in cui vengono descritte le procedure di rilevamento e gestione degli errori.
+ Verifica l'ipotesi.
[Principi di ingegneria del caos](https://principlesofchaos.org/) è un documento contenente le linee guida su come verificare lo stato stazionario del carico di lavoro.
È necessario concentrarsi sull'output misurabile di un sistema e non sugli attributi interni del sistema. Le misurazioni di tale output in un breve periodo di tempo costituiscono un'attestazione dello stato stazionario del sistema. La velocità di trasmissione effettiva del sistema nel suo complesso, le percentuali di errori e i percentili della latenza possono essere considerati metriche di interesse che rappresentano il comportamento di uno stato stazionario. Sulla base dei rilevamenti dei modelli di comportamento sistematico durante gli esperimenti, l'ingegneria del caos verifica che il sistema funzioni correttamente anziché tentare di convalidare il modo in cui funziona.
Nei due esempi precedenti sono state incluse le metriche dello stato stazionario relative a un incremento inferiore allo 0,01% di errori (5xx) lato server e inferiore a un minuto di errori di lettura e scrittura del database.
Gli errori 5xx rappresentano una buona metrica perché sono la conseguenza della modalità di errore che un client del carico di lavoro sperimenterà direttamente. La misurazione degli errori del database risulta valida come conseguenza diretta dell'errore, ma deve essere supportata da una misurazione diretta dell'impatto, ad esempio le richieste cliente non riuscite o gli errori restituiti a livello di client. Includi anche un monitor sintetico, definito canary utente, in qualsiasi API o URI a cui il client del carico di lavoro ha accesso diretto.
+ Migliora la progettazione del carico di lavoro con un occhio di riguardo per la resilienza.
Se lo stato stazionario non è stato preservato, analizza in che modo puoi migliorare la progettazione del flusso di lavoro per azzerare l'impatto dell'errore applicando le best practice descritte nel [Pilastro AWS Well-Architected relativo all'affidabilità](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/welcome.html). Ulteriori linee guida e risorse sono disponibili nella [libreria di AWS Builder](https://aws.amazon.com/builders-library/), dove sono contenuti articoli su come [migliorare i controlli dell'integrità](https://aws.amazon.com/builders-library/implementing-health-checks/) oppure [impiegare nuovi tentativi con backoff nel codice dell'applicazione](https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/).
Dopo aver implementato queste modifiche, esegui di nuovo l'esperimento (rappresentato dalla linea punteggiata nel volano relativo all'ingegneria del caos) per determinare la relativa efficacia. Se nella fase di verifica risulta che l'ipotesi è vera, il carico di lavoro sarà in stato stazionario e il ciclo continuerà.
+ Esegui gli esperimenti con regolarità.
Un esperimento di ingegneria del caos è un ciclo e gli esperimenti devono essere eseguiti regolarmente nell'ambito dell'ingegneria del caos. Se un carico di lavoro è conforme all'ipotesi dell'esperimento, l'esperimento deve essere automatizzato affinché venga eseguito continuamente come fase di regressione della pipeline CI/CD. Per ulteriori informazioni in merito, consulta questo blog relativamente alle [procedure di esecuzione degli esperimenti AWS FIS utilizzando AWS CodePipeline](https://aws.amazon.com/blogs/architecture/chaos-testing-with-aws-fault-injection-simulator-and-aws-codepipeline/). Questo laboratorio relativo a esperimenti [AWS FIS ricorrenti in una pipeline CI/CD](https://chaos-engineering.workshop.aws/en/030_basic_content/080_cicd.html) ti consente di fare esperienza pratica.
Gli esperimenti di iniezione di errori fanno inoltre parte delle giornate di gioco (consulta [REL12-BP06 Esecuzione regolare di giornate di gioco](rel_testing_resiliency_game_days_resiliency.md)). Le giornate di gioco simulano un errore o un evento per verificare sistemi, processi e risposte dei team. Lo scopo è di eseguire effettivamente le azioni che compirebbe il team come se si verificasse un evento eccezionale.
+ Acquisisci e archivia i risultati degli esperimenti.
I risultati degli esperimenti di iniezione di errori devono essere acquisiti e resi persistenti. Includi tutti i dati necessari, ad esempio orari, carico di lavoro e condizioni, in modo da essere in grado di analizzare i risultati e i trend in un secondo momento. I risultati potrebbero includere, ad esempio, screenshot dei pannelli di controllo, dump in formato CSV del database delle metriche oppure appunti scritti a mano relativi a eventi e osservazioni associati all'esperimento. [La registrazione degli esperimenti mediante AWS FIS](https://docs.aws.amazon.com/fis/latest/userguide/monitoring-logging.html) può rientrare nel processo di acquisizione dei dati.
## Risorse
**Best practice correlate:**
+ [REL08-BP03 Esecuzione di test di resilienza come parte integrante dell'implementazione](rel_tracking_change_management_resiliency_testing.md)
+ [REL13-BP03 Esecuzione di test sull'implementazione del ripristino di emergenza per convalidare l'implementazione](rel_planning_for_recovery_dr_tested.md)
**Documenti correlati:**
+ [What is AWS Fault Injection Service? (Che cos'è AWS Fault Injection Service?)](https://docs.aws.amazon.com/fis/latest/userguide/what-is.html)
+ [What is AWS Resilience Hub? (Che cos'è AWS Resilience Hub?)](https://docs.aws.amazon.com/resilience-hub/latest/userguide/what-is.html)
+ [Principi di ingegneria del caos](https://principlesofchaos.org/)
+ [Chaos Engineering: Planning your first experiment (Ingegneria del caos: pianificazione del primo esperimento)](https://medium.com/the-cloud-architect/chaos-engineering-part-2-b9c78a9f3dde)
+ [Resilience Engineering: Learning to Embrace Failure](https://queue.acm.org/detail.cfm?id=2371297)
+ [Chaos Engineering stories (Storie relative all'ingegneria del caso)](https://github.com/ldomb/ChaosEngineeringPublicStories)
+ [Evitare fallback nei sistemi distribuiti](https://aws.amazon.com/builders-library/avoiding-fallback-in-distributed-systems/)
+ [Canary Deployment for Chaos Experiments (Implementazione canary per gli esperimenti di ingegneria del caos)](https://medium.com/the-cloud-architect/chaos-engineering-q-a-how-to-safely-inject-failure-ced26e11b3db)
**Video correlati:**
+ [AWS re:Invent 2020: Testing resiliency using chaos engineering (ARC316) (Esecuzione di test di resilienza mediante l'ingegneria del caos [ARC316])](https://www.youtube.com/watch?v=OlobVYPkxgg)
+ [AWS re:Invent 2019: migliorare la resilienza con l'ingegneria del caos (DOP309-R1)](https://youtu.be/ztiPjey2rfY)
+ [AWS re:Invent 2019: Performing chaos engineering in a serverless world (CMY301) (Esecuzione dell'ingegneria del caos in uno scenario serverless [CMY301])](https://www.youtube.com/watch?v=vbyjpMeYitA)
**Esempi correlati:**
+ [Well-Architected lab: Level 300: Testing for Resiliency of Amazon EC2, Amazon RDS, and Amazon S3 (Test della resilienza di Amazon EC2, Amazon RDS e Amazon S3)](https://wellarchitectedlabs.com/reliability/300_labs/300_testing_for_resiliency_of_ec2_rds_and_s3/)
+ [Chaos Engineering on AWS lab (Laboratorio relativo all'ingegneria del caos in AWS)](https://chaos-engineering.workshop.aws/en/)
+ [Resilient and Well-Architected Apps with Chaos Engineering lab (Laboratorio relativo alle app Well-Architected resilienti con ingegneria del caos)](https://catalog.us-east-1.prod.workshops.aws/workshops/44e29d0c-6c38-4ef3-8ff3-6d95a51ce5ac/en-US)
+ [Serverless Chaos lab (Laboratorio relativi a esperimenti di ingegneria del caos per architetture serverless)](https://catalog.us-east-1.prod.workshops.aws/workshops/3015a19d-0e07-4493-9781-6c02a7626c65/en-US/serverless)
+ [Measure and Improve Your Application Resilience with AWS Resilience Hub lab (Laboratorio di misurazione e ottimizzazione della resilienza dell'applicazione con AWS Resilience Hub)](https://catalog.us-east-1.prod.workshops.aws/workshops/2a54eaaf-51ee-4373-a3da-2bf4e8bb6dd3/en-US/200-labs/1wordpressapplab)
** Strumenti correlati: **
+ [AWS Fault Injection Service](https://aws.amazon.com/fis/)
+ Marketplace AWS: [Gremlin Chaos Engineering Platform (Piattaforma di ingegneria del caos di Gremlin)](https://aws.amazon.com/marketplace/pp/prodview-tosyg6v5cyney)
+ [Chaos Toolkit](https://chaostoolkit.org/)
+ [Chaos Mesh](https://chaos-mesh.org/)
+ [Litmus](https://litmuschaos.io/)
# REL12-BP06 Esecuzione regolare di giornate di gioco
Utilizza le giornate di gioco per provare regolarmente le procedure per rispondere a eventi ed errori nel modo più vicino possibile alla produzione (anche negli ambienti di produzione) con le persone che si occuperanno di eventuali scenari di errore reali. Le giornate di gioco applicano misure per garantire che gli eventi di produzione non influiscano sugli utenti.
Le giornate di gioco simulano un errore o un evento per testare sistemi, processi e risposte dei team. Lo scopo è di eseguire effettivamente le azioni che compirebbe il team come se si verificasse un evento eccezionale. Questi ti aiuta a capire dove puoi apportare dei miglioramenti e ti può aiutare a sviluppare un'esperienza organizzativa nella gestione degli eventi. Tali azioni devono essere svolte regolarmente in modo che il team costruisca *una memoria muscolare* su come rispondere.
Quando la progettazione per la resilienza è in loco ed è stata testata in ambienti non di produzione, un game day è il modo per garantire che tutto funzioni come pianificato in produzione. Una giornata di gioco, soprattutto la prima, è un'attività di duro lavoro per tutti, in cui tutti gli ingegneri e i team operativi vengono informati in merito a quando accadrà e cosa accadrà. I runbook sono in loco. Gli eventi simulati, compresi i possibili eventi di guasto, vengono eseguiti nei sistemi di produzione nel modo prescritto e ne viene valutato l'impatto. Se tutti i sistemi funzionano come progettato, il rilevamento e la correzione automatica avvengono con un impatto minimo o nullo. Tuttavia, se si osserva un impatto negativo, viene eseguito il rollback del test e i problemi relativi al carico di lavoro vengono risolti, se necessario manualmente (utilizzando il runbook). Poiché le giornate di gioco hanno spesso luogo in produzione, è necessario prendere tutte le precauzioni per garantire che non vi sia alcun impatto sulla disponibilità per i clienti.
**Anti-pattern comuni:**
+ Documentare le procedure senza mai esercitarle.
+ Non includere i responsabili delle decisioni aziendali negli esercizi di test.
**Vantaggi dell'adozione di questa best practice:** Eseguire giornate di gioco garantisce che tutto il personale segua le policy e le procedure quando si verifica un incidente reale e convalida che tali policy e procedure siano appropriate.
**Livello di rischio associato se questa best practice non fosse adottata:** Medium
## Guida all'implementazione
+ Programma giornate di gioco per provare regolarmente i tuoi runbook e playbook. Le giornate di gioco devono coinvolgere tutte le persone implicate in un evento di produzione: proprietari di aziende, personale addetto allo sviluppo, personale operativo e team di risposta agli incidenti.
+ Esegui i test di carico o delle prestazioni e successivamente esegui l'iniezione degli errori.
+ Ricerca anomalie nei tuoi runbook e opportunità di provare i tuoi playbook.
+ In caso di deviazione dai tuoi runbook, perfeziona il runbook o correggi il comportamento. Se ti eserciti sul tuo playbook, identifica il runbook che avrebbe dovuto essere usato, oppure creane uno nuovo.
## Risorse
**Documenti correlati:**
+ [Che cos'è AWS GameDay?](https://aws.amazon.com/gameday/)
**Video correlati:**
+ [AWS re:Invent 2019: migliorare la resilienza con l'ingegneria del caos (DOP309-R1)](https://youtu.be/ztiPjey2rfY)
**Esempi correlati:**
+ [AWS Well-Architected Labs – Test di resilienza](https://wellarchitectedlabs.com/reliability/300_labs/300_testing_for_resiliency_of_ec2_rds_and_s3/)
# REL 13 Come pianifichi il disaster recovery (DR)?
Avere backup e componenti del carico di lavoro ridondanti in loco è l'inizio della strategia di disaster recovery. [RTO e RPO sono i tuoi obiettivi](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/disaster-recovery-dr-objectives.html) per il ripristino del carico di lavoro. Imposta questi valori in base alle esigenze aziendali. Implementa una strategia per raggiungere questi obiettivi, prendendo in considerazione le posizioni e la funzione delle risorse e dei dati del carico di lavoro. La probabilità di interruzione e il costo del ripristino sono fattori chiave che aiutano a comunicare il valore aziendale che può avere il ripristino di emergenza per un carico di lavoro.
**Topics**
+ [REL13-BP01 Definizione degli obiettivi di ripristino in caso di downtime e perdita di dati](rel_planning_for_recovery_objective_defined_recovery.md)
+ [REL13-BP02 Utilizzo di strategie di ripristino definite per conseguire gli obiettivi di ripristino](rel_planning_for_recovery_disaster_recovery.md)
+ [REL13-BP03 Esecuzione di test sull'implementazione del ripristino di emergenza per convalidare l'implementazione](rel_planning_for_recovery_dr_tested.md)
+ [REL13-BP04 Gestione della deviazione di configurazione nel sito o nella Regione del ripristino di emergenza](rel_planning_for_recovery_config_drift.md)
+ [REL13-BP05 Automatizzazione del ripristino](rel_planning_for_recovery_auto_recovery.md)
# REL13-BP01 Definizione degli obiettivi di ripristino in caso di downtime e perdita di dati
Il carico di lavoro ha un Recovery Time Objective (RTO) e Recovery Point Objective (RPO).
*Il Recovery Time Objective (RTO)* è il ritardo massimo accettabile tra l'interruzione del servizio e il suo ripristino. Questo determina ciò che viene considerato un intervallo di tempo accettabile quando il servizio non è disponibile.
*Recovery Point Objective (RPO)* è il periodo di tempo massimo accettabile dall'ultimo punto di ripristino dei dati. Questo determina ciò che viene considerato una perdita di dati accettabile tra l'ultimo punto di ripristino e l'interruzione del servizio.
RTO e RPO sono valori importanti quando si seleziona una strategia adeguata di ripristino di emergenza per il proprio carico di lavoro. Tali obiettivi sono stabiliti dall'azienda e poi vengono utilizzati dai team tecnici per selezionare e implementare una strategia di ripristino di emergenza.
**Risultato desiderato:**
Ogni carico di lavoro ha un RTO e un RPO assegnati, definiti in base all'impatto aziendale. Il carico di lavoro viene assegnato a un livello predefinito, che stabilisce la disponibilità del servizio e la perdita accettabile di dati, con un RTO e un RPO associati. Se tale livello non è raggiungibile, è possibile assegnare un livello personalizzato per carico di lavoro, con l'obiettivo di creare i livelli in un secondo momento. RTO e RPO sono valori fondamentali per la selezione di una strategia di ripristino di emergenza da implementare per il carico di lavoro. Altre riflessioni nel momento della scelta di una strategia di ripristino di emergenza sono i vincoli economici, le dipendenze del carico di lavoro e i requisiti operativi.
Per l'RTO è necessario comprendere l'impatto in base alla durata di un'interruzione. È lineare o ci sono implicazioni non lineari? (Ad esempio, dopo 4 ore, chiudi una linea di produzione fino l'inizio del turno successivo).
Una matrice di ripristino di emergenza, come quella seguente, può aiutarti a capire come la criticità del carico di lavoro sia collegata agli obiettivi di ripristino. (Da notare che i valori reali per gli assi X e Y devono essere personalizzati in base alle esigenze della tua organizzazione).
![\[Grafico che mostra la matrice del ripristino di emergenza\]](http://docs.aws.amazon.com/it_it/wellarchitected/2022-03-31/framework/images/disaster-recovery-matrix.png)
**Anti-pattern comuni:**
+ Nessun obiettivo di ripristino definito.
+ Selezione di obiettivi di ripristino arbitrari.
+ Selezione di obiettivi di ripristino troppo tolleranti e che non soddisfano gli obiettivi di business.
+ Mancanza di comprensione dell'impatto dei tempi di inattività e perdita dei dati.
+ Selezione di obiettivi di ripristino non realistici, come tempo zero di ripristino e nessuna perdita di dati, che potrebbero non essere raggiungibili per la configurazione del tuo carico di lavoro.
+ Selezione di obiettivi di ripristino più severi rispetto agli obiettivi aziendali effettivi. Questo costringe a effettuare implementazioni di ripristino di emergenza più costose e complicate rispetto alle esigenze del carico di lavoro.
+ Selezione di obiettivi di ripristino non compatibili con quelli di un carico di lavoro dipendente.
+ I tuoi obiettivi di ripristino non considerano i requisiti di conformità normativa.
+ RTO e RPO definiti per un carico di lavoro, ma mai testati.
**Vantaggi dell'adozione di questa best practice:** Gli obiettivi di ripristino in termini di tempo e perdita di dati sono necessari per guidare l'implementazione del disaster recovery.
**Livello di rischio associato se questa best practice non fosse adottata:** Alta
## Guida all'implementazione
Per un dato carico di lavoro devi considerare l'impatto dei tempi di inattività e della perdita dei dati per la tua azienda. L'impatto generalmente aumenta all'aumentare dei tempi di inattività o della perdita dei dati, ma il ritmo di tale crescita cambia in base al tipo di carico di lavoro. Ad esempio, potresti tollerare l'inattività per massimo un'ora con conseguenze minime, ma successivamente l'impatto diventerebbe rapidamente più serio. L'impatto sull'azienda si manifesta in forme diverse, tra cui costi economici (come perdita di fatturato), fiducia del cliente (e impatto sulla reputazione), problematiche operative (come stipendi in ritardo o diminuzione della produttività) e rischi normativi. Usa i passaggi seguenti per comprendere questi aspetti e impostare i valori RTO e RPO per il tuo carico di lavoro.
**Passaggi dell'implementazione**
1. Individua gli stakeholder aziendali per questo carico di lavoro e collabora con loro per implementare questi passaggi. Gli obiettivi di ripristino di un carico di lavoro sono il frutto di una decisione aziendale. I team tecnici, quindi, lavorano con gli stakeholder aziendali e usano questi obiettivi per selezionare una strategia di ripristino di emergenza.
**Nota**
Per i passaggi 2 e 3 puoi usare [Foglio di lavoro di implementazione](#implementation-worksheet).
1. Raccogli le informazioni necessarie per prendere una decisione rispondendo alle domande qui di seguito.
1. Hai categorie o livelli di criticità in termini di impatto del tuo carico di lavoro nella tua organizzazione?
1. Se sì, assegna questo carico di lavoro a una categoria
1. Se no, definisci queste categorie. Crea al massimo cinque categorie e perfeziona l'intervallo del tuo Obiettivo del tempo di ripristino (RTO) per ognuna. Ecco alcune categorie di esempio: critico, alto, medio, basso. Per capire come mappare i carichi di lavoro rispetto alle categorie devi considerare se il carico di lavoro è mission-critical, importante per l'azienda o non trainante.
1. Imposta i valori RTO e RPO del carico di lavoro in base alla categoria. Scegli sempre una categoria più severa (RTO e RPO inferiori) rispetto ai valori grezzi calcolati in questa fase. Se ciò comporta una variazione significativa di valore non rispondente alle esigenze, prendi in considerazione la possibilità di creare una nuova categoria.
1. In base alle risposte assegna i valori RTO e RPO al carico di lavoro. Puoi farlo direttamente o assegnando il carico di lavoro a un livello predefinito di servizio.
1. Crea un documento con il piano di ripristino di emergenza (DRP) per questo carico di lavoro, che sarà parte del [piano di continuità aziendale della tua organizzazione (BCP)](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/business-continuity-plan-bcp.html), in un punto accessibile al team del carico di lavoro e agli stakeholder.
1. Registra i valori RTO e RPO e le informazioni usate per definire questi valori. Includi la strategia utilizzata per valutare l'impatto del carico di lavoro sull'azienda.
1. Registra altre metriche, oltre ai valori RTO e RPO che stai monitorando o che pensi di monitorare per gli obiettivi di ripristino di emergenza.
1. Dopo aver creato questi valori, potrai aggiungere i dettagli della tua strategia di ripristino di emergenza e il runbook.
1. Osservando le criticità del carico di lavoro in una matrice come quella della Figura 15, puoi iniziare a stabilire livelli predefiniti di servizio per la tua organizzazione.
1. Dopo aver implementato una strategia di ripristino di emergenza (o un proof of concept per una strategia di ripristino di emergenza) secondo quanto stabilito da [REL13-BP02 Utilizzo di strategie di ripristino definite per conseguire gli obiettivi di ripristino](rel_planning_for_recovery_disaster_recovery.md), testa questa strategia per stabilire i valori reali di RTC (Recovery Time Capability) e di RPC (Recovery Point Capability) del carico di lavoro. Se questi valori non sono in linea con gli obiettivi target di ripristino, puoi collaborare con gli stakeholder della tua azienda per modificarli o cambiare la strategia di ripristino di emergenza in modo che possa soddisfare tali obiettivi.
**Domande principali**
1. Qual è il tempo massimo durante il quale il carico di lavoro può essere inattivo prima che questo abbia un impatto grave sull'attività?
1. Definisci il costo monetario (impatto finanziario diretto) sull'attività al minuto se il carico di lavoro è inattivo.
1. Considera che l'impatto non è sempre lineare. L'impatto può essere limitato all'inizio e poi aumentare rapidamente oltre un punto critico specifico.
1. Qual è la quantità massima di dati che possiamo perdere prima che questo abbia un impatto grave sull'attività?
1. Considera questo valore per gli archivi di dati più strategici. identifica le criticità relative ad altri archivi di dati.
1. I dati del carico di lavoro possono essere ricreati se persi? Se questo è operativamente più facile rispetto al backup e al ripristino, scegli il valore RPO in base alla criticità dei dati di origine utilizzati per ricreare i dati del carico di lavoro.
1. Quali sono gli obiettivi di ripristino e le aspettative di disponibilità dei carichi di lavoro da cui questo valore dipende (downstream) o i carichi di lavoro che dipendono da questo valore (upstream)?
1. Scegli obiettivi di ripristino che consentono a questo carico di lavoro di soddisfare i requisiti delle dipendenze upstream.
1. Scegli obiettivi di ripristino che sono raggiungibili considerate le funzionalità di ripristino delle dipendenze downstream. Possono essere escluse le dipendenze downstream non critiche (quelle che puoi "aggirare"). In alternativa, lavora con dipendenze downstream critiche per migliorare le funzionalità di ripristino, laddove necessario.
**Domande aggiuntive**
Considera queste domande e come possono essere applicate a questo carico di lavoro:
1. Hai RTO e RPO diversi a seconda del tipo di interruzione (Regione rispetto ad AZ e così via)?
1. Esiste un periodo specifico (stagionalità, eventi commerciali, lanci di prodotto) in cui RTO/RPO possono cambiare? Se sì, qual è la misurazione diversa e il vincolo temporale?
1. Se il carico di lavoro viene perturbato, quanti clienti ne subiranno l'impatto?
1. Qual è l'impatto sulla reputazione se il carico di lavoro è perturbato?
1. Quali altri impatti operativi possono verificarsi se il carico di lavoro subisce perturbazioni? Ad esempio, l'impatto sulla produttività dei dipendenti se i sistemi e-mail non sono disponibili o sei i sistemi di buste paga non sono in grado di inviare le transazioni.
1. In che modo il carico di lavoro e i valori RTO e RPO si allineano alla linea di business e alla strategia di ripristino di emergenza dell'organizzazione?
1. Esistono obblighi contrattuali interni per fornire un servizio? Esistono delle penali nel caso in cui non siano soddisfatti?
1. Quali sono i limiti normativi o di conformità dei dati?
## Foglio di lavoro di implementazione
Puoi usare questo foglio di lavoro per le fasi 2 e 3 dell'implementazione. Adegua questo foglio di lavoro in base alle tue esigenze specifiche, aggiungendo, ad esempio, altre domande.
![\[Foglio di lavoro\]](http://docs.aws.amazon.com/it_it/wellarchitected/2022-03-31/framework/images/worksheet.png)
**Livello di impegno per il piano di implementazione: **Bassa
## Risorse
**Best practice correlate:**
+ [REL09-BP04 Ripristino periodico dei dati per verificare l'integrità e i processi di backup:](rel_backing_up_data_periodic_recovery_testing_data.md)
+ [REL13-BP02 Utilizzo di strategie di ripristino definite per conseguire gli obiettivi di ripristino](rel_planning_for_recovery_disaster_recovery.md)
+ [REL13-BP03 Esecuzione di test sull'implementazione del ripristino di emergenza per convalidare l'implementazione](rel_planning_for_recovery_dr_tested.md)
**Documenti correlati:**
+ [AWS Architecture Blog: Disaster Recovery Series](https://aws.amazon.com/blogs/architecture/tag/disaster-recovery-series/)
+ [Ripristino di emergenza dei carichi di lavoro su AWS: ripristino nel cloud (whitepaper di AWS)](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/disaster-recovery-workloads-on-aws.html)
+ [Gestire le policy di resilienza con AWS Resilience Hub](https://docs.aws.amazon.com/resilience-hub/latest/userguide/resiliency-policies.html)
+ [Partner APN: partner che possono assistere con disaster recovery](https://aws.amazon.com/partners/find/results/?keyword=Disaster+Recovery)
+ [Marketplace AWS: prodotti utilizzabili per il disaster recovery](https://aws.amazon.com/marketplace/search/results?searchTerms=Disaster+recovery)
**Video correlati:**
+ [AWS re:Invent 2018: Architecture Patterns for Multi-Region Active-Active Applications (Modelli architetturali per applicazioni attive-attive su più Regioni) (ARC209-R2)](https://youtu.be/2e29I3dA8o4)
+ [Ripristino di emergenza di carichi di lavoro su AWS](https://www.youtube.com/watch?v=cJZw5mrxryA)
# REL13-BP02 Utilizzo di strategie di ripristino definite per conseguire gli obiettivi di ripristino
Definisci una strategia di ripristino di emergenza (DR) che soddisfi gli obiettivi di ripristino del carico di lavoro. Scegli una strategia come: backup e ripristino, standby (attivo/passivo) o attivo/attivo.
Una strategia di ripristino di emergenza si basa sulla capacità di creare il tuo carico di lavoro in un sito di ripristino se la tua sede principale non è disponibile per eseguire il carico di lavoro. Gli obiettivi di ripristino più comuni sono RTO e RPO, come discusso in [REL13-BP01 Definizione degli obiettivi di ripristino in caso di downtime e perdita di dati](rel_planning_for_recovery_objective_defined_recovery.md).
Una strategia di ripristino di emergenza (DR) su più zone di disponibilità (AZ) all'interno di un singolo Regione AWS può offrire la mitigazione rispetto a eventi disastrosi come incendi, alluvioni e interruzioni gravi dell'energia. Se è un requisito implementare una protezione rispetto a un evento improbabile che impedisca al tuo carico di lavoro di poter essere eseguito in un determinato Regione AWS, puoi usare una strategia di ripristino di emergenza basata su più regioni.
Quando pianifichi una strategia di ripristino di emergenza su più regioni, devi scegliere una delle seguenti strategie. Sono elencate in ordine crescente di complessità e di costi e in ordine decrescente di RTO e RPO. *La regione di ripristino* si riferisce a una Regione AWS diversa da quella principale utilizzata per il tuo carico di lavoro.
![\[Diagramma che mostra le strategie di ripristino di emergenza\]](http://docs.aws.amazon.com/it_it/wellarchitected/2022-03-31/framework/images/disaster-recovery-strategies.png)
+ **Backup e ripristino** (RPO in poche ore, RTO in 24 ore o meno): esegui il backup dei dati e delle applicazioni nella regione di ripristino. Adottando backup continui o automatizzati otterrai un ripristino point-in-ime che può ridurre il valore dell'RPO fino a raggiungere in alcuni casi 5 minuti. Nel caso in cui si verifichi un disastro, distribuirai l'infrastruttura (usando l'infrastruttura come codice per ridurre l'RTO), distribuirai il codice e ripristinerai i dati del backup dopo un disastro nella regione di ripristino.
+ **Pilot light** (RPO in minuti, RTO in decine di minuti): fornisci una copia dell'infrastruttura del carico di lavoro di base nella regione di ripristino. Replica i dati nella regione di ripristino e crea un backup in essa. Le risorse necessarie per supportare la replica dei dati e il backup, come database e archiviazione di oggetti, sono sempre attive. Altri elementi come i server applicativi o il calcolo serverless non vengono distribuiti, ma possono essere creati quando necessari con la configurazione e il codice applicativo richiesti.
+ **Warm standby** (RPO in secondi, RTO in minuti): mantieni sempre una versione ridotta del carico di lavoro completamente funzionante in esecuzione nella regione di ripristino. I sistemi business critical sono completamente duplicati e sono sempre accesi, ma con un parco istanze ridimensionato. I dati vengono replicati e si trovano nella regione di ripristino. Quando viene il momento del ripristino, il sistema viene dimensionato rapidamente per gestire il carico di produzione. Più il Warm standby è dimensionato verso l'alto e più bassi saranno l'RTO e l'affidamento al piano di controllo. Quando il dimensionamento è completo ci troviamo nello **Standby a caldo**.
+ **Multi-regione (multi-sito) attivo-attivo** (RPO vicino a zero, RTO uguale potenzialmente a zero): il carico di lavoro viene distribuito in più regioni Regioni AWS e serve attivamente il traffico da esse proveniente. Questa strategia comporta la sincronizzazione dei dati tra le regioni. È necessario evitare o gestire possibili conflitti causati da scritture sullo stesso record in due diverse repliche regionali, un'attività che potrebbe rivelarsi complessa. La replica dei dati è utile per la sincronizzazione dei dati e ti proteggerà da alcuni tipi di disastri, ma non dalla corruzione o dalla distruzione dei dati, a meno che la tua soluzione non includa opzioni per il ripristino point-in-time.
**Nota**
La differenza tra Pilot Light e Warm Standby può talvolta essere difficile da comprendere. Entrambe prevedono un ambiente nella tua regione di ripristino con copie degli asset della tua regione principale. La differenza è che Pilot Light non può elaborare le richieste senza aver prima intrapreso altre azioni, mentre Warm Standby può gestire immediatamente il traffico (a livelli ridotti di capacità). Pilot Light ti richiederà di attivare i server, distribuire possibilmente un'infrastruttura aggiuntiva (non di base) e aumentare il dimensionamento, mentre Warm Standby richiede solo di aumentare il dimensionamento (tutto è già stato distribuito ed è in esecuzione). Scegli tra queste opzioni in base alle tue esigenze di RTO e RPO.
**Risultato desiderato:**
Per ogni carico di lavoro esiste una strategia di ripristino di emergenza definita e implementata che consente a quel carico di lavoro di raggiungere gli obiettivi di ripristino. Le strategie di ripristino di emergenza tra carichi di lavoro utilizzano modelli riutilizzabili (come strategie descritte in precedenza),
**Anti-pattern comuni:**
+ Implementazione di procedure di ripristino incoerenti per carichi di lavoro con obiettivi di ripristino simili.
+ Implementazione di una strategia di ripristino di emergenza ad-hoc quando si verifica un disastro.
+ Assenza di un piano per il ripristino di emergenza.
+ Dipendenza dalle operazioni del piano di controllo durante il ripristino.
**Vantaggi dell'adozione di questa best practice:**
+ L'utilizzo di strategie di ripristino definite consente di utilizzare strumenti e procedure di test comuni.
+ L'utilizzo di strategie di ripristino definite consente una condivisione più efficiente delle conoscenze tra i team e un'implementazione più facile del ripristino di emergenza sui carichi di lavoro proprietari.
**Livello di rischio associato se questa best practice non fosse adottata:** Alto
+ Senza una strategia di ripristino di emergenza pianificata, implementata e testata, è poco probabile riuscire a raggiungere gli obiettivi di ripristino in caso di eventi disastrosi.
## Guida all'implementazione
Per ognuno di questi passaggi guarda i dettagli qui di seguito.
1. Definisci una strategia di ripristino di emergenza in linea con i requisiti di ripristino di questo carico di lavoro.
1. Esamina i modelli con cui la strategia di ripristino di emergenza selezionata può essere implementata.
1. Valuta le risorse del tuo carico di lavoro e quale sarà la loro configurazione nella regione di ripristino prima del failover (durante la normale operatività).
1. Stabilisci e implementa le modalità con cui preparerai la tua regione al failover nel momento in cui sarà necessario (durante un evento disastroso).
1. Stabilisci e implementa le modalità con cui reindirizzerai il traffico al failover nel momento in cui sarà necessario (durante un evento disastroso).
1. Progetta un piano per il failback del carico di lavoro.
**Passaggi dell'implementazione**
1. **Definisci una strategia di ripristino di emergenza in linea con i requisiti di ripristino di questo carico di lavoro.**
Scegliere una strategia di ripristino di emergenza significa raggiungere un compromesso tra la riduzione dei tempi di inattività e della perdita di dati (RTO e RPO) e costi e complessità di implementazione. Dovresti evitare di implementare una strategia che sia più severa del necessario, in quanto questo comporterebbe costi aggiuntivi.
Ad esempio, nel diagramma seguente, l'azienda ha stabilito l'RTO massimo concesso e il limite di spesa per la strategia di ripristino del servizio. Considerati gli obiettivi dell'azienda, le strategie di ripristino di emergenza Pilot Light o Warm Standby soddisfano i criteri sui costi e l'RTO.
![\[Grafico che mostra la scelta di una strategia di ripristino di emergenza in base all'RTO e ai costi\]](http://docs.aws.amazon.com/it_it/wellarchitected/2022-03-31/framework/images/choosing-a-dr-strategy.png)
Per saperne di più consulta il [piano di continuità aziendale (BCP)](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/business-continuity-plan-bcp.html).
1. **Esamina i modelli con cui la strategia di ripristino di emergenza selezionata può essere implementata.**
Questo passaggio consiste nel capire come implementare la strategia selezionata. Le strategie vengono spiegate con Regioni AWS come siti principali e di ripristino. Tuttavia, puoi anche decidere di utilizzare le zone di disponibilità in una singola regione come strategia di ripristino di emergenza, utilizzando aspetti di più strategie.
Nei passaggi successivi a questo, applicherai la strategia per il tuo carico di lavoro specifico.
**Backup e ripristino**
*Backup e ripristino* è la strategia meno complessa da implementare, ma richiederà più tempo e impegno per ripristinare il carico di lavoro, generando così valori RTO e RPO più elevati. È buona pratica creare sempre backup dei dati e copiarli in un altro sito (ad esempio, un altro Regione AWS).
![\[Diagramma che mostra un'architettura di backup e ripristino\]](http://docs.aws.amazon.com/it_it/wellarchitected/2022-03-31/framework/images/backup-restore-architecture.png)
Per maggiori dettagli su questa strategia consulta [Disaster Recovery (DR) Architecture on AWS, Part II: Backup and Restore with Rapid Recovery (Architettura di ripristino di emergenza (DR) su AWS, Parte II: backup e ripristino con recupero rapido)](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-ii-backup-and-restore-with-rapid-recovery/).
**Pilot light**
Con l'approccio *Pilot light* , replichi i dati dalla tua regione principale alla regione di ripristino. Le risorse di base utilizzate per l'infrastruttura del carico di lavoro vengono distribuite nella regione di ripristino; tuttavia sono comunque necessarie risorse aggiuntive ed eventuali dipendenze per rendere funzionale questo stack. Ad esempio, nella Figura 20, non vengono distribuite istanze di calcolo.
![\[Diagramma che mostra un'architettura pilot light\]](http://docs.aws.amazon.com/it_it/wellarchitected/2022-03-31/framework/images/pilot-light-architecture.png)
Per maggiori dettagli su questa strategia consulta [Disaster Recovery (DR) Architecture on AWS, Part III: Pilot Light and Warm Standby (Architettura di ripristino di emergenza (DR) su AWS, Parte III: Pilot Light e Warm Standby)](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-iii-pilot-light-and-warm-standby/).
**Warm standby**
L'approccio *warm standby* implica la verifica della presenza di una copia ridotta, ma comunque funzionale, dell'ambiente di produzione in un'altra regione. Questo approccio estende il concetto di Pilot Light e diminuisce il tempo di ripristino, poiché il carico di lavoro è sempre attivo in un'altra regione. Se la regione di ripristino ha raggiunto il massimo della capacità, allora viene definita come *Standby a caldo*.
![\[Figura 21: Diagramma che mostra un'architettura Warm standby\]](http://docs.aws.amazon.com/it_it/wellarchitected/2022-03-31/framework/images/warm-standby-architecture.png)
Se si utilizza Warm Standby o Pilot Light è necessario un aumento delle risorse nella regione di ripristino. Per garantire che la capacità sia disponibile quando necessario, valuta l'uso di [prenotazioni delle capacità](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-capacity-reservations.html) per le istanze EC2. Se utilizzi AWS Lambda, la [concorrenza fornita](https://docs.aws.amazon.com/lambda/latest/dg/provisioned-concurrency.html) può garantire gli ambienti di esecuzione, in modo che siano pronti a rispondere immediatamente ai richiami della funzione.
Per maggiori dettagli su questa strategia consulta [Disaster Recovery (DR) Architecture on AWS, Part III: Pilot Light and Warm Standby (Architettura di ripristino di emergenza (DR) su AWS, Parte III: Pilot Light e Warm Standby)](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-iii-pilot-light-and-warm-standby/).
**Attivo/attivo multi-sito**
Puoi eseguire il carico di lavoro simultaneamente in più regioni come parte di una *strategia attivo/attivo multi-sito* . La strategia attivo/attivo multi-sito serve il traffico da tutte le regioni in cui è distribuita. I clienti possono selezionare questa strategia per motivi diversi dal ripristino di emergenza. Può essere utilizzata per aumentare la disponibilità o nella distribuzione di un carico di lavoro a un pubblico globale (per posizionare l'endpoint più vicino agli utenti e/o per distribuire stack localizzati al pubblico di quella regione). Come strategia di ripristino di emergenza, se il carico di lavoro non può essere supportato in una delle Regioni AWS in cui è stato distribuito, allora quella regione viene evacuata e le regioni rimanenti vengono utilizzate per garantire la disponibilità. Attivo/attivo multi-sito è la strategia di ripristino operativamente più complessa e dovrebbe essere selezionata solo quando lo richiedono i requisiti aziendali.
![\[Diagramma che mostra un'architettura attivo/attivo multi-sito\]](http://docs.aws.amazon.com/it_it/wellarchitected/2022-03-31/framework/images/multi-site-active-active-architecture.png)
Per maggiori dettagli su questa strategia consulta [Disaster Recovery (DR) Architecture on AWS, Part IV: Multi-site Active/Active (Architettura di ripristino di emergenza su AWS, parte IV: attiva/attiva multi-sito)](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-iv-multi-site-active-active/).
**Procedure aggiuntive per la protezione dei dati**
Con tutte le strategie devi anche mitigare un disastro relativo ai dati. La replica continua dei dati ti proteggerà da alcuni tipi di disastri, ma non dalla corruzione o dalla distruzione dei dati, a meno che la tua soluzione non includa opzioni per il ripristino point-in-time o il controllo delle versioni dei dati archiviati. Devi anche creare un backup dei dati replicati nel sito di ripristino per creare backup point-in-time in aggiunta alle repliche.
**Utilizzo di più zone di disponibilità all'interno di una singola Regione AWS**
Quando si usano più zone di disponibilità all'interno di un'unica regione, l'implementazione della strategia di ripristino di emergenza usa più elementi delle strategie precedenti. Per prima cosa devi creare un'architettura con disponibilità elevata (HA), usando più zone di disponibilità come mostrato nella Figura 23. Questa architettura utilizza un approccio attivo/attivo multi-sito, poiché le [istanze Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-regions-availability-zones.html#concepts-availability-zones) ed [Elastic Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/how-elastic-load-balancing-works.html#availability-zones) hanno risorse distribuite in più zone di disponibilità che gestiscono attivamente le richieste. L'architettura dimostra anche lo standby a caldo e se l'istanza [Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Concepts.MultiAZ.html) primaria fallisce (o la zona di disponibilità stessa fallisce), l'istanza in standby viene promossa a principale.
![\[Figura 23: Diagramma che mostra un'architettura con più zone di disponibilità\]](http://docs.aws.amazon.com/it_it/wellarchitected/2022-03-31/framework/images/multi-az-architecture2.png)
Oltre a questa architettura HA, devi aggiungere i backup di tutti i dati richiesti per eseguire il tuo carico di lavoro. Questo aspetto è importante soprattutto per i dati limitati a una singola zona come [i volumi Amazon EBS](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-volumes.html) oppure [i cluster Amazon Redshift](https://docs.aws.amazon.com/redshift/latest/mgmt/working-with-clusters.html). Se fallisce una zona di disponibilità, dovrai ripristinare i dati in un'altra zona di disponibilità. Laddove possibile, devi anche copiare i backup di dati su un'altra Regione AWS come livello di protezione aggiuntivo.
Un approccio alternativo meno comune a una strategia di ripristino di emergenza con una singola regione e più zone di disponibilità è illustrata nel post del blog, [Building highly resilient applications using Amazon Route 53 Application Recovery Controller, Part 1: Single-Region stack (Creazione di applicazioni altamente resilienti con Amazon Route 53 Application Recovery Controller, parte 1: stack a singola regione)](https://aws.amazon.com/blogs/networking-and-content-delivery/building-highly-resilient-applications-using-amazon-route-53-application-recovery-controller-part-1-single-region-stack/). In questo caso la strategia adottata è quella di garantire il più possibile l'isolamento tra le zone di disponibilità, ossia come le regioni operano. Usando questa strategia alternativa puoi scegliere un approccio attivo/attivo o attivo/passivo.
Nota: alcuni carichi di lavoro hanno requisiti normativi di residenza dei dati. Se questo si applica a un carico di lavoro in una località che attualmente ha solo una Regione AWS, la multi-regione non soddisferà i requisiti aziendali. Le strategie con più zone di disponibilità offrono una buona protezione dalla maggior parte dei disastri.
1. **Valuta le risorse del tuo carico di lavoro e quale sarà la loro configurazione nella regione di ripristino prima del failover (durante la normale operatività).**
Per infrastrutture e risorse AWS usa l'infrastruttura come codice come [AWS CloudFormation](https://aws.amazon.com/cloudformation) o strumenti di terze parti come Hashicorp Terraform. Per distribuire in più account e regioni con una singola operazione puoi usare [AWS CloudFormation StackSets](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/what-is-cfnstacksets.html). Per le strategie multi-sito attivo/attivo e standby a caldo, l'infrastruttura distribuita nella tua regione di ripristino ha le stesse risorse della regione principale. Per le strategie Pilot Light e Warm Standby l'infrastruttura distribuita richiederà azioni aggiuntive per essere pronta per la produzione. Con l'utilizzo dei parametri di [CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/parameters-section-structure.html) e [della logica condizionale](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/intrinsic-function-reference-conditions.html), puoi verificare se uno stack distribuito è attivo o in standby con un singolo modello. Un esempio di tale modello CloudFormation è incluso in [questo post del blog](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-iii-pilot-light-and-warm-standby/).
Tutte le strategie di ripristino di emergenza richiedono un backup delle origini dei dati all'interno della Regione AWS e una copia di tali backup nella regione di ripristino. [AWS Backup](https://aws.amazon.com/backup/) offre una visualizzazione centralizzata dove puoi configurare, pianificare e monitorare i backup di queste risorse. Per Pilot Light, Warm Standby e Multi-sito attivo/attivo, you should also replicate data from the primary devi anche replicare i dati dalla regione principale alle risorse di dati nella regione di ripristino, come [istanze DB Amazon Relational Database Service (Amazon RDS)](https://aws.amazon.com/rds) o tabelle [Amazon DynamoDB](https://aws.amazon.com/dynamodb) . Queste risorse di dati sono pertanto attive e pronte per servire le richieste nella regione di ripristino.
Per saperne di più su come i servizi AWS operano nelle regioni, guarda questa serie di blog su [Creazione di un'applicazione multiregione con i servizi AWS](https://aws.amazon.com/blogs/architecture/tag/creating-a-multi-region-application-with-aws-services-series/).
1. **Stabilisci e implementa le modalità con cui preparerai la tua regione al failover nel momento in cui sarà necessario (durante un evento disastroso).**
Per la strategia attivo/attivo multi-sito, il failover significa evacuare una regione e affidarsi alle regioni attive rimanenti. In generale, tali regioni sono pronte per accettare il traffico. Per le strategie Pilot Light e Warm Standby, le azioni di ripristino devono distribuire le risorse mancanti, come le istanze EC2 nella Figura 20, oltre ad risorse mancanti aggiuntive.
Per tutte le strategie precedenti potresti dover promuovere istanze di database i sola lettura a istanze di lettura/scrittura principali.
Per il backup e il ripristino, il ripristino dei dati dai backup crea risorse per tali dati, come volumi EBS, istanze DB RDS e tabelle DynamoDB. Devi anche ripristinare l'infrastruttura e distribuire il codice. Puoi usare AWS Backup per ripristinare i dati nella regione di ripristino. Consulta [REL09-BP01 Identificazione e backup di tutti i dati che richiedono un backup o riproduzione dei dati dalle origini](rel_backing_up_data_identified_backups_data.md) per ulteriori dettagli. Ricreare l'infrastruttura significa anche creare risorse come istanze EC2 oltre a [Amazon Virtual Private Cloud (Amazon VPC)](https://aws.amazon.com/vpc), sottoreti e i gruppi di sicurezza necessari. Puoi automatizzare gran parte del processo di ripristino. Per scoprire come guarda [questo post del blog](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-ii-backup-and-restore-with-rapid-recovery/).
1. **Stabilisci e implementa le modalità con cui reindirizzerai il traffico al failover nel momento in cui sarà necessario (durante un evento disastroso).**
Questa operazione di failover può essere avviata automaticamente o manualmente. Il failover avviato automaticamente in base a controlli dell'integrità o allarmi deve essere usato con attenzione, poiché un failover non necessario (falso allarme) comporta dei costi in termini di non disponibilità e perdita dei dati. Pertanto si usa spesso il failover avviato manualmente. In questo caso, devi comunque automatizzare i passaggi del failover, in modo che l'avvio manuale si limiti al clic su un pulsante.
Esistono diverse opzioni di gestione del traffico da considerare quando si usano i servizi AWS. Un'opzione consiste nell'utilizzare [Amazon Route 53](https://aws.amazon.com/route53). Con Amazon Route 53 puoi associare più endpoint IP in una o più Regioni AWS con un nome di dominio Route 53. Per implementare un failover avviato manualmente puoi usare [Amazon Route 53 Application Recovery Controller](https://aws.amazon.com/route53/application-recovery-controller/), che offre un'API del piano dati altamente disponibile per reindirizzare il traffico alla regione di ripristino. Nella fase di implementazione del failover, usa le operazioni di piano dati ed evita quelle del piano di controllo come descritto in [REL11-BP04 Fare affidamento al piano dati invece che al piano di controllo durante il ripristino](rel_withstand_component_failures_avoid_control_plane.md).
Per saperne di più su questa e su altre opzioni consulta [questa sezione del whitepaper sul Ripristino di emergenza](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/disaster-recovery-options-in-the-cloud.html#pilot-light).
1. **Progetta un piano per il failback del carico di lavoro.**
Si parla di failback quando un'operazione del carico di lavoro torna alla regione principale, dopo che un vento disastroso è diminuito di intensità. Il provisioning di infrastruttura e codice alla regione principale in genere segue gli stessi passaggi usati inizialmente, affidandosi all'infrastruttura come codice e alle pipeline di distribuzione del codice. La sfida del failback è il ripristino dei data store e la garanzia della loro coerenza con la regione di ripristino attiva.
Nello stato di failover i database nella regione di ripristino sono attivi e hanno dati aggiornati. L'obiettivo è eseguire una nuova sincronizzazione tra la regione di ripristino e la regione principale, per garantire il suo aggiornamento.
Alcuni servizi AWS eseguono questa operazione in automatico. Se si utilizzano [tabelle globali Amazon DynamoDB](https://aws.amazon.com/dynamodb/global-tables/), anche se la tabella nella regione principale era diventata non disponibile, quando torna di nuovo online, DynamoDB ripristina la propagazione di scritture in sospeso. Se si utilizzano [Database globale Amazon Aurora](https://aws.amazon.com/rds/aurora/global-database/) e [failover pianificato gestito](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-global-database-disaster-recovery.html#aurora-global-database-disaster-recovery.managed-failover), viene mantenuta la topologia di replica esistente del database globale Aurora. Pertanto, l'istanza precedente in lettura/scrittura nella regione principale diventa una replica e riceve gli aggiornamenti dalla regione di ripristino.
Nei casi in cui questo non è automatico devi ristabilire il database nella regione principale come replica del database nella regione di ripristino. In molti casi questo comporterà l'eliminazione del database principale precedente e la creazione di nuove repliche. Ad esempio, per istruzioni su come procedere con il Database globale Amazon Aurora in caso di failover *non pianificato* , consulta questa scheda: [Failback di un database globale](https://awsauroralabsmy.com/global/failback/).
Dopo un failover, se puoi proseguire l'esecuzione nella tua regione di ripristino, valuta la possibilità di farlo nella tua regione principale. Compieresti comunque tutte le operazioni precedenti per trasformare la precedente regione principale in una regione di ripristino. Alcune organizzazioni eseguono una rotazione pianificata, scambiando periodicamente le regioni principale e di ripristino (ad esempio, ogni tre mesi).
Tutti i passaggi richiesti per failover e failback devono essere inseriti in un playbook disponibile a tutti i membri del team, sottoposto periodicamente a revisione.
**Livello di impegno per il piano di implementazione**: elevato
## Risorse
**Best practice correlate:**
+ [REL09-BP01 Identificazione e backup di tutti i dati che richiedono un backup o riproduzione dei dati dalle origini](rel_backing_up_data_identified_backups_data.md)
+ [REL11-BP04 Fare affidamento al piano dati invece che al piano di controllo durante il ripristino](rel_withstand_component_failures_avoid_control_plane.md)
+ [REL13-BP01 Definizione degli obiettivi di ripristino in caso di downtime e perdita di dati](rel_planning_for_recovery_objective_defined_recovery.md)
**Documenti correlati:**
+ [AWS Architecture Blog: Disaster Recovery Series](https://aws.amazon.com/blogs/architecture/tag/disaster-recovery-series/)
+ [Ripristino di emergenza dei carichi di lavoro su AWS: ripristino nel cloud (whitepaper di AWS)](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/disaster-recovery-workloads-on-aws.html)
+ [Opzioni di ripristino di emergenza nel cloud](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/disaster-recovery-options-in-the-cloud.html)
+ [Build a serverless multi-region, active-active backend solution in an hour](https://read.acloud.guru/building-a-serverless-multi-region-active-active-backend-36f28bed4ecf)
+ [Multi-region serverless backend — reloaded](https://medium.com/@adhorn/multi-region-serverless-backend-reloaded-1b887bc615c0)
+ [RDS: creazione di una replica di lettura in una regione AWS diversa](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ReadRepl.html#USER_ReadRepl.XRgn)
+ [Route 53: configurazione del failover DNS](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/dns-failover-configuring.html)
+ [S3: replica tra regioni](https://docs.aws.amazon.com/AmazonS3/latest/dev/crr.html)
+ [Che cos'è AWS Backup?](https://docs.aws.amazon.com/aws-backup/latest/devguide/whatisbackup.html)
+ [What is Route 53 Application Recovery Controller? (Che cos'è Amazon Route 53 Application Recovery Controller?)](https://docs.aws.amazon.com/r53recovery/latest/dg/what-is-route53-recovery.html)
+ [AWS Elastic Disaster Recovery (Ripristino di emergenza elastico AWS)](https://docs.aws.amazon.com/drs/latest/userguide/what-is-drs.html)
+ [HashiCorp Terraform: inizia subito - AWS](https://learn.hashicorp.com/collections/terraform/aws-get-started)
+ [Partner APN: partner che possono assistere con disaster recovery](https://aws.amazon.com/partners/find/results/?keyword=Disaster+Recovery)
+ [Marketplace AWS: prodotti utilizzabili per il disaster recovery](https://aws.amazon.com/marketplace/search/results?searchTerms=Disaster+recovery)
**Video correlati:**
+ [Ripristino di emergenza di carichi di lavoro su AWS](https://www.youtube.com/watch?v=cJZw5mrxryA)
+ [AWS re:Invent 2018: Architecture Patterns for Multi-Region Active-Active Applications (Modelli di architettura per applicazioni attive-attive multiregione) (ARC209-R2)](https://youtu.be/2e29I3dA8o4)
+ [Get Started with AWS Elastic Disaster Recovery \$1 Amazon Web Services (Nozioni di base sul ripristino di emergenza elastico AWS \$1 Amazon Web Services)](https://www.youtube.com/watch?v=GAMUCIJR5as)
**Esempi correlati:**
+ [AWS Well-Architected Labs - Ripristino di emergenza](https://wellarchitectedlabs.com/reliability/disaster-recovery/) - Serie di workshop che illustrano le strategie di ripristino di emergenza
# REL13-BP03 Esecuzione di test sull'implementazione del ripristino di emergenza per convalidare l'implementazione
Testa con regolarità il failover nella tua sede di ripristino per verificare la correttezza delle operazioni e l'allineamento ai valori RPO e RTO.
Un modello da evitare è lo sviluppo di percorsi di ripristino eseguiti raramente. Ad esempio, è possibile che si disponga di un archivio dati secondario utilizzato per query di sola lettura. Quando scrivi in un archivio dati e quello principale ha un guasto, puoi eseguire il failover verso l'archivio dati secondario. Se non testi frequentemente questo failover, è possibile che i presupposti relativi alle funzionalità dell'archivio dati secondario non siano corretti. La capacità dell'archivio dati secondario, che potrebbe essere stata sufficiente durante l'ultimo test, potrebbe non essere più in grado di tollerare il carico in questo scenario. La nostra esperienza ha dimostrato che l'unico ripristino da errore che funziona è il percorso sottoposto a frequenti test. Per questo è preferibile avere un numero ridotto di percorsi di ripristino. Puoi stabilire dei modelli di ripristino e testarli regolarmente. Se disponi di un percorso di ripristino complesso o critico, devi comunque riprodurre regolarmente il guasto specifico in produzione per convincerti che il percorso di ripristino funzioni. Nell'esempio appena discusso, è necessario eseguire il failover regolarmente in standby, indipendentemente dalle necessità.
**Anti-pattern comuni:**
+ Non eseguire mai failover di prova in produzione.
**Vantaggi dell'adozione di questa best practice:** Testare regolarmente il piano di disaster recovery assicura che funzioni quando necessario e che il tuo team sappia come eseguire la strategia.
**Livello di rischio associato se questa best practice non fosse adottata:** Alto
## Guida all'implementazione
+ Progetta i carichi di lavoro per il ripristino. Testa con regolarità se l'informatica orientata al ripristino (ROC, Recovery Oriented Computing) identifica le caratteristiche nei sistemi che migliorano il ripristino. Queste caratteristiche sono: isolamento e ridondanza, capacità a livello di sistema di ripristinare le modifiche, capacità di monitorare e determinare lo stato, capacità di fornire diagnostica, ripristino automatizzato, progettazione modulare e possibilità di riavvio. Esegui il percorso di ripristino per assicurarti di poter realizzare il ripristino nel tempo specificato allo stato specificato. Usa i tuoi runbook durante questo ripristino per documentare i problemi e trovare le loro soluzioni prima del test successivo.
+ [Il progetto di informatica orientata al ripristino Berkeley/Stanford](http://roc.cs.berkeley.edu/)
+ Usa il ripristino di emergenza CloudEndure per implementare e testare la tua strategia di ripristino di emergenza.
+ [Testing the Disaster Recovery Solution with CloudEndure](https://docs.cloudendure.com/Content/Configuring_and_Running_Disaster_Recovery/Testing_the_Distaster_Recovery_Solution/Testing_the_Disaster_Recovery_Solution.htm)
+ [CloudEndure Disaster Recovery](https://aws.amazon.com/cloudendure-disaster-recovery/)
+ [Ripristino di emergenza CloudEndure in AWS](https://aws.amazon.com/marketplace/pp/B07XQNF22L)
## Risorse
**Documenti correlati:**
+ [Partner APN: partner che possono assistere con disaster recovery](https://aws.amazon.com/partners/find/results/?keyword=Disaster+Recovery)
+ [AWS Architecture Blog: Disaster Recovery Series](https://aws.amazon.com/blogs/architecture/tag/disaster-recovery-series/)
+ [Marketplace AWS: prodotti utilizzabili per il disaster recovery](https://aws.amazon.com/marketplace/search/results?searchTerms=Disaster+recovery)
+ [CloudEndure Disaster Recovery](https://aws.amazon.com/cloudendure-disaster-recovery/)
+ [Ripristino di emergenza dei carichi di lavoro su AWS: ripristino nel cloud (whitepaper di AWS)](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/disaster-recovery-workloads-on-aws.html)
+ [Testing the Disaster Recovery Solution with CloudEndure](https://docs.cloudendure.com/Content/Configuring_and_Running_Disaster_Recovery/Testing_the_Distaster_Recovery_Solution/Testing_the_Disaster_Recovery_Solution.htm)
+ [Il progetto di informatica orientata al ripristino Berkeley/Stanford](http://roc.cs.berkeley.edu/)
+ [Che cos'è AWS Fault Injection Simulator?](https://docs.aws.amazon.com/fis/latest/userguide/what-is.html)
**Video correlati:**
+ [AWS re:Invent 2018: Architecture Patterns for Multi-Region Active-Active Applications (Modelli di architettura per applicazioni attive-attive multiregione) (ARC209-R2)](https://youtu.be/2e29I3dA8o4)
+ [AWS re:Invent 2019: Backup-and-restore and disaster-recovery solutions with AWS (STG208)](https://youtu.be/7gNXfo5HZN8)
**Esempi correlati:**
+ [AWS Well-Architected Labs - Test di resilienza](https://wellarchitectedlabs.com/reliability/300_labs/300_testing_for_resiliency_of_ec2_rds_and_s3/)
# REL13-BP04 Gestione della deviazione di configurazione nel sito o nella Regione del ripristino di emergenza
Assicurati che l'infrastruttura, i dati e la configurazione soddisfino le esigenze del sito o nella Regione del ripristino di emergenza. Ad esempio, controlla che le AMI e le quote di servizio siano aggiornate.
AWS Config monitora e registra in modo continuo le configurazioni delle risorse AWS. È in grado di rilevare le deviazioni e attivare [AWS Systems Manager Automation](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html) per risolverle e attivare allarmi. AWS CloudFormation è inoltre in grado di rilevare le deviazioni negli stack distribuiti.
**Anti-pattern comuni:**
+ Non eseguire aggiornamenti nelle sedi di ripristino, quando esegui modifiche di configurazione o di infrastruttura nelle tue sedi principali.
+ Ignorare le limitazioni potenziali (ad esempio le differenze di servizio) nelle sedi di disaster recovery e principali.
**Vantaggi dell'adozione di questa best practice:** Assicurarsi che l'ambiente di disaster recovery sia coerente con quello esistente garantisce il ripristino completo.
**Livello di rischio associato se questa best practice non fosse adottata:** Medio
## Guida all'implementazione
+ Assicurati che le tue pipeline di distribuzione riforniscano sia i siti principali che di backup. Le pipeline per la distribuzione di applicazioni in produzione devono essere distribuite in tutte le posizioni della strategia di disaster recovery specificate, inclusi gli ambienti di sviluppo e test.
+ Abilitazione di AWS Config per monitorare le potenziali posizioni di deviazione. Utilizza le regole AWS Config per creare sistemi in grado di applicare le strategie di disaster recovery e generare avvisi quando rilevano una deviazione.
+ [Correzione di risorse AWS non conformi in base alle regole di Regole di AWS Config](https://docs.aws.amazon.com/config/latest/developerguide/remediation.html)
+ [AWS Systems Manager Automation](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html)
+ Utilizza AWS CloudFormation per distribuire la tua infrastruttura. AWS CloudFormation è in grado di rilevare le deviazioni tra ciò che i modelli di CloudFormation specificano e ciò che viene effettivamente distribuito.
+ [AWS CloudFormation: rilevamento delle deviazioni su un intero stack CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/detect-drift-stack.html)
## Risorse
**Documenti correlati:**
+ [Partner APN: partner che possono assistere con disaster recovery](https://aws.amazon.com/partners/find/results/?keyword=Disaster+Recovery)
+ [AWS Architecture Blog: Disaster Recovery Series](https://aws.amazon.com/blogs/architecture/tag/disaster-recovery-series/)
+ [AWS CloudFormation: rilevamento delle deviazioni su un intero stack CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/detect-drift-stack.html)
+ [Marketplace AWS: prodotti utilizzabili per il disaster recovery](https://aws.amazon.com/marketplace/search/results?searchTerms=Disaster+recovery)
+ [AWS Systems Manager Automation](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html)
+ [Ripristino di emergenza dei carichi di lavoro su AWS: ripristino nel cloud (whitepaper di AWS)](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/disaster-recovery-workloads-on-aws.html)
+ [In che modo è possibile implementare una soluzione di gestione della configurazione dell'infrastruttura in AWS?](https://aws.amazon.com/answers/configuration-management/aws-infrastructure-configuration-management/?ref=wellarchitected)
+ [Correzione di risorse AWS non conformi in base alle regole di Regole di AWS Config](https://docs.aws.amazon.com/config/latest/developerguide/remediation.html)
**Video correlati:**
+ [AWS re:Invent 2018: Architecture Patterns for Multi-Region Active-Active Applications (Modelli di architettura per applicazioni attive-attive multiregione) (ARC209-R2)](https://youtu.be/2e29I3dA8o4)
# REL13-BP05 Automatizzazione del ripristino
Utilizza AWS o strumenti di terze parti per automatizzare il ripristino del sistema e instradare il traffico verso il sito o la Regione del ripristino di emergenza.
In base ai controlli di integrità configurati, i servizi AWS, come Elastic Load Balancing e AWS Auto Scaling, possono distribuire il carico a zone di disponibilità integre, mentre i servizi, come Amazon Route 53 e AWS Global Accelerator, instradano il carico a Regioni AWS integre. Amazon Route 53 Application Recovery Controller aiuta a gestire e coordinare il failover utilizzando i controlli di disponibilità e le funzionalità di controlli di routing. Queste funzionalità monitorano continuamente la capacità dell'applicazione di riprendersi dai guasti e permettono di controllarne il ripristino delle applicazioni su più Regioni AWS, zone di disponibilità e on-premise.
Per i carichi di lavoro su data center fisici o virtuali o cloud privati, [Ripristino di emergenza elastico AWS](https://aws.amazon.com/cloudendure-disaster-recovery/), disponibile tramite Marketplace AWS, consente alle organizzazioni di organizzare una strategia di ripristino di emergenza su AWS. CloudEndure supporta, inoltre, il ripristino di emergenza tra Regioni e zone di disponibilità in AWS.
**Anti-pattern comuni:**
+ L'implementazione di failover e failback automatici identici può causare flapping quando si verifica un errore.
**Vantaggi dell'adozione di questa best practice:** Il ripristino automatico riduce i tempi di ripristino eliminando la possibilità di errori manuali.
**Livello di rischio associato se questa best practice non fosse adottata:** Medio
## Guida all'implementazione
+ Automatizzazione dei percorsi di ripristino. Per tempi di ripristino brevi, non è possibile servirsi del giudizio umano e dell'azione per scenari di disponibilità elevata. Il sistema dovrebbe ripristinarsi automaticamente in ogni situazione.
+ Usa il ripristino di emergenza CloudEndure per failover e failback automatizzati. Il ripristino di emergenza CloudEndure replica in modo continuo le macchine (tra cui sistema operativo, configurazione dello stato del sistema, database, applicazioni e file) in un'area di gestione temporanea a basso costo nell'Account AWS di destinazione e nella Regione preferita. In caso di emergenza, è possibile indicare a CloudEndure Disaster Recovery di avviare automaticamente migliaia di macchine nello stato di provisioning completo in pochi minuti.
+ [Performing a Disaster Recovery Failover and Failback](https://docs.cloudendure.com/Content/Configuring_and_Running_Disaster_Recovery/Performing_a_Disaster_Recovery_Failover/Performing_a_Disaster_Recovery_Failover.htm)
+ [CloudEndure Disaster Recovery](https://aws.amazon.com/cloudendure-disaster-recovery/)
## Risorse
**Documenti correlati:**
+ [Partner APN: partner che possono assistere con disaster recovery](https://aws.amazon.com/partners/find/results/?keyword=Disaster+Recovery)
+ [AWS Architecture Blog: Disaster Recovery Series](https://aws.amazon.com/blogs/architecture/tag/disaster-recovery-series/)
+ [Marketplace AWS: prodotti utilizzabili per il disaster recovery](https://aws.amazon.com/marketplace/search/results?searchTerms=Disaster+recovery)
+ [AWS Systems Manager Automation](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html)
+ [Ripristino di emergenza CloudEndure in AWS](https://aws.amazon.com/marketplace/pp/B07XQNF22L)
+ [Ripristino di emergenza dei carichi di lavoro su AWS: ripristino nel cloud (whitepaper di AWS)](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/disaster-recovery-workloads-on-aws.html)
**Video correlati:**
+ [AWS re:Invent 2018: Architecture Patterns for Multi-Region Active-Active Applications (Modelli architetturali per applicazioni attive-attive su più Regioni) (ARC209-R2)](https://youtu.be/2e29I3dA8o4)