# REL 10. Come si utilizza l'isolamento dei guasti per proteggere il carico di lavoro?
L'isolamento dei guasti limita l'impatto di un guasto di un componente o di un sistema entro una determinata barriera. Con un isolamento adeguato, i componenti al di fuori della barriera non subiscono gli effetti del guasto. Utilizzando più barriere per l'isolamento dei guasti, è possibile rendere un carico di lavoro più resiliente ai guasti.
**Topics**
+ [REL10-BP01 Implementazione del carico di lavoro in diversi luoghi](rel_fault_isolation_multiaz_region_system.md)
+ [REL10-BP02 Ripristino automatico dei componenti vincolati a una singola posizione](rel_fault_isolation_single_az_system.md)
+ [REL10-BP03 Utilizzo di architetture a scomparti 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, in tutte le Regioni AWS.
Un principio fondamentale per la progettazione dei servizi in AWS è quello di evitare singoli punti di errore, inclusa l'infrastruttura fisica sottostante. AWS fornisce risorse e servizi di cloud computing a livello globale in più posizioni geografiche chiamate [Regioni](https://docs.aws.amazon.com/whitepapers/latest/aws-fault-isolation-boundaries/regions.html). Ogni Regione è fisicamente e logicamente indipendente ed è costituita da tre o più [zone di disponibilità (AZ)](https://docs.aws.amazon.com/whitepapers/latest/aws-fault-isolation-boundaries/availability-zones.html). Le zone di disponibilità sono geograficamente vicine ma fisicamente separate e isolate. Distribuendo i carichi di lavoro tra le zone di disponibilità e le Regioni, si riducono i rischi legati a minacce quali incendi, inondazioni, disastri meteorologici, terremoti ed errori umani.
Crea una strategia di localizzazione per fornire un'alta disponibilità adeguata ai carichi di lavoro.
**Risultato desiderato:** i carichi di lavoro di produzione sono distribuiti tra più zone di disponibilità (AZ) o Regioni per ottenere tolleranza ai guasti e alta disponibilità.
**Anti-pattern comuni:**
+ Il carico di lavoro di produzione esiste solo in una singola zona di disponibilità.
+ Viene implementata un'architettura multiregionale quando invece un'architettura multi-AZ è in grado di soddisfare i requisiti aziendali.
+ Le implementazioni o i dati vengono desincronizzati, con conseguenti deviazioni di configurazione o dati sottoreplicati.
+ Non tieni conto delle dipendenze tra i componenti dell'applicazione se i requisiti di resilienza e multi-posizione differiscono tra tali componenti.
**Vantaggi dell'adozione di questa best practice:**
+ Il carico di lavoro è più resiliente in caso di incidenti, come interruzioni di corrente, problemi con i controlli ambientali, disastri naturali, errori dei servizi upstream o problemi di rete che hanno un impatto su un'AZ o su un'intera Regione.
+ È possibile accedere a un inventario più ampio di istanze Amazon EC2 e ridurre le probabilità che si verifichino eccezioni InsufficientCapacityException (ICE) quando si avviano tipi specifici di istanze EC2.
**Livello di rischio associato se questa best practice non fosse adottata:** elevato
## Guida all'implementazione
Implementa e gestisci tutti i carichi di lavoro di produzione in almeno due zone di disponibilità (AZ) in una Regione.
**Utilizzo di più zone di disponibilità**
Le zone di disponibilità sono posizioni di hosting delle risorse fisicamente separate l'una dall'altra per evitare guasti correlati dovuti a rischi quali incendi, inondazioni e trombe d'aria. Ogni zona di disponibilità ha un'infrastruttura fisica indipendente, che include le connessioni alla rete elettrica, le fonti di alimentazione di backup, i servizi meccanici e la connettività di rete. Questa disposizione limita i guasti di uno qualsiasi di questi componenti alla sola zona di disponibilità interessata. Ad esempio, se un incidente a livello di AZ rende non disponibili le istanze EC2 nella zona di disponibilità interessata, è comunque possibile utilizzare le istanze in altre zone di disponibilità.
Nonostante siano fisicamente separate, le zone di disponibilità nella stessa Regione AWS sono sufficientemente vicine da garantire una rete a elevato throughput e bassa latenza (inferiore ai 10 millisecondi). Puoi replicare i dati in modo sincrono tra le zone di disponibilità per la maggior parte dei carichi di lavoro senza influire in modo significativo sull'esperienza dell'utente. Ciò significa che puoi utilizzare le zone di disponibilità in una Regione in una configurazione attiva/attiva o attiva/in standby.
Tutta l'elaborazione associata al carico di lavoro deve essere distribuita tra più zone di disponibilità. Sono incluse le istanze [Amazon EC2](https://aws.amazon.com/ec2/), le attività [AWS Fargate](https://aws.amazon.com/fargate/) e le funzioni [AWS Lambda](https://aws.amazon.com/lambda/) collegate al VPC. I servizi di elaborazione AWS, compresi [EC2 Auto Scaling](https://aws.amazon.com/ec2/autoscaling/), [Amazon Elastic Container Service (ECS)](https://aws.amazon.com/ecs/) e [Amazon Elastic Kubernetes Service (EKS)](https://aws.amazon.com/eks/), offrono la possibilità di avviare e gestire l'elaborazione nelle zone di disponibilità. Configurarli per sostituire automaticamente l'elaborazione, secondo necessità, in una zona di disponibilità diversa per mantenere la disponibilità. Per indirizzare il traffico verso zone di disponibilità integre, posiziona un bilanciatore del carico davanti al computer, ad esempio un Application Load Balancer o un Network Load Balancer. I bilanciatori del carico AWS possono reindirizzare il traffico verso le istanze disponibili in caso di compromissione della zona di disponibilità.
È inoltre necessario replicare i dati per il carico di lavoro e renderli disponibili in più zone di disponibilità. Alcuni servizi di dati gestiti da AWS, come [Amazon S3](https://aws.amazon.com/s3/), [Amazon Elastic File Service (EFS)](https://aws.amazon.com/efs/), [Amazon Aurora](https://aws.amazon.com/aurora/), [Amazon DynamoDB](https://aws.amazon.com/dynamodb/), [Amazon Simple Queue Service (SQS)](https://aws.amazon.com/sqs/) e [Flusso di dati Amazon Kinesis](https://aws.amazon.com/kinesis/data-streams/) replicano i dati in più zone di disponibilità per impostazione predefinita e sono robusti rispetto alla compromissione della zona di disponibilità. Con altri servizi dati gestiti da AWS, come [Amazon Relational Database Service (RDS)](https://aws.amazon.com/rds/), [Amazon Redshift](https://aws.amazon.com/redshift/) e [Amazon ElastiCache](https://aws.amazon.com/elasticache/), è necessario abilitare la replica multi-AZ. Una volta abilitati, questi servizi rilevano automaticamente la compromissione di una zona di disponibilità, reindirizzano le richieste verso una zona di disponibilità integra e replicano i dati in base alle esigenze dopo il ripristino senza l'intervento del cliente. Per comprendere le funzionalità, i comportamenti e le operazioni multi-AZ di ciascun servizio dati gestito da AWS utilizzato, consulta la guida per l'utente.
Se utilizzi un'archiviazione autogestita, come i volumi [Amazon Elastic Block Store (EBS)](https://aws.amazon.com/ebs/) o l'archiviazione di istanze Amazon EC2, devi gestire autonomamente la replica multi-AZ.
![\[Diagramma che mostra un'architettura multi-livello implementata su tre zone di disponibilità. Nota: Amazon S3 e Amazon DynamoDB sono sempre ad AZ multiple automaticamente. L'ELB viene inoltre distribuito in tutte e tre le zone.\]](http://docs.aws.amazon.com/it_it/wellarchitected/2024-06-27/framework/images/multi-tier-architecture.png)
**Utilizzo di più Regioni AWS**
In presenza di carichi di lavoro che richiedono una resilienza estrema (come infrastrutture critiche, applicazioni sanitarie o servizi con requisiti di disponibilità stringenti da parte dei clienti o imposti), potrebbe essere richiesta disponibilità aggiuntiva rispetto a quella che può fornire una singola Regione AWS. In questo caso, è necessario implementare e gestire il carico di lavoro su almeno due Regioni AWS (supponendo che ciò sia consentito dai requisiti di residenza dei dati).
Le Regioni AWS sono situate in diverse aree geografiche del mondo e in più continenti. Le Regioni AWS hanno una separazione fisica e un isolamento ancora maggiori rispetto alle sole zone di disponibilità. I servizi AWS, con poche eccezioni, sfruttano questa struttura per operare in modo completamente indipendente tra le diverse Regioni (noti anche come *servizi regionali*). Un guasto di un servizio in una Regione AWS, non vi è alcun impatto sul servizio in un'altra Regione.
Quando il carico di lavoro viene gestito in più Regioni, è necessario considerare ulteriori requisiti. Poiché le risorse in Regioni diverse sono separate e indipendenti l'una dall'altra, è necessario duplicare i componenti del carico di lavoro in ciascuna Regione. Questo include l'infrastruttura di base, come i VPC, oltre ai servizi dati e di elaborazione.
**NOTA:** se prendi in considerazione una progettazione multiregionale, verifica che sia possibile eseguire il carico di lavoro in una singola Regione. Se crei dipendenze tra le Regioni, in cui un componente di una Regione si affida a servizi o componenti di una Regione diversa, il rischio di errore potrebbe aumentare, indebolendo in maniera significativa la propria postura di affidabilità.
Per facilitare le implementazioni multiregionali e mantenere la coerenza, [AWS CloudFormation StackSets](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/what-is-cfnstacksets.html) può replicare l'intera infrastruttura AWS in più Regioni. [AWS CloudFormation](https://aws.amazon.com/cloudformation/) può anche rilevare deviazioni di configurazione e informare l'utente quando le risorse AWS in una Regione non sono sincronizzate. Molti servizi AWS offrono la replica in più Regioni per le risorse importanti del carico di lavoro. Ad esempio, [EC2 Image Builder](https://aws.amazon.com/image-builder/) può pubblicare Amazon Machine Image (AMI) EC2 dopo ogni compilazione su ogni Regione utilizzata. [Amazon Elastic Container Registry (ECR)](https://aws.amazon.com/ecr/) può replicare le immagini del container nelle Regioni selezionate.
È inoltre necessario replicare i dati in ciascuna delle Regioni scelte. Molti servizi dati gestiti da AWS offrono funzionalità di replica multiregionale, tra cui Amazon S3, Amazon DynamoDB, Amazon RDS, Amazon Aurora, Amazon Redshift, Amazon Elasticache e Amazon EFS. Le [tabelle globali di Amazon DynamoDB](https://aws.amazon.com/dynamodb/global-tables/) accettano scritture in qualsiasi Regione supportata e replicano i dati tra tutte le altre Regioni configurate. Con altri servizi, è necessario designare una Regione primaria per le scritture, mentre le altre Regioni contengono repliche di sola lettura. Per ogni servizio dati gestito da AWS utilizzato dal carico di lavoro, consulta la relativa guida per l'utente e la guida per gli sviluppatori per comprenderne le funzionalità e i limiti multiregionali. È opportuno prestare particolare attenzione a dove devono essere indirizzate le scritture, alle capacità e alle limitazioni transazionali, a come viene eseguita la replica e a come monitorare la sincronizzazione tra le Regioni.
AWS offre anche la possibilità di instradare il traffico delle richieste verso le implementazioni regionali con grande flessibilità. Ad esempio, puoi configurare i record DNS utilizzando [Amazon Route 53](https://aws.amazon.com/route53/) per indirizzare il traffico verso la Regione disponibile più vicina all'utente. In alternativa, puoi configurare i record DNS in una configurazione attiva/in standby, in cui una Regione viene designata come primaria e si ricorre a una replica regionale solo se la Regione primaria perde la propria integrità. Puoi configurare i [controlli dell'integrità di Route 53](https://docs.aws.amazon.com/Route 53/latest/DeveloperGuide/dns-failover.html) per rilevare gli endpoint non integri ed eseguire il failover automatico, nonché utilizzare [Amazon Application Recovery Controller (ARC)](https://aws.amazon.com/application-recovery-controller/) per fornire un controllo di instradamento ad alta disponibilità per reinstradare manualmente il traffico, se necessario.
Anche se scegli di non operare in più Regioni per l'alta disponibilità, considera più Regioni come parte della propria strategia di disaster recovery (DR). Se possibile, replica i componenti e i dati dell'infrastruttura del carico di lavoro in una configurazione *warm standby* o *fiamma pilota* in una Regione secondaria. In questa progettazione, si replica l'infrastruttura di base dalla Regione primaria come VPC, gruppi Auto Scaling, orchestratori di container e altri componenti, ma si configurano i componenti di dimensioni variabili nella Regione di standby (come il numero di istanze EC2 e le repliche di database) in modo che siano di dimensioni minimamente utilizzabili. Puoi anche organizzare la replica continua dei dati dalla Regione primaria alla Regione di standby. Se si verifica un incidente, puoi aumentare orizzontalmente, o incrementare, le risorse nella Regione di standby e quindi promuoverla a Regione primaria.
### Passaggi dell'implementazione
1. Collabora con le parti interessate aziendali e gli esperti in materia di residenza dei dati per determinare quali Regioni AWS possono essere utilizzate per ospitare le risorse e i dati.
1. Collabora con le parti interessate aziendali e tecniche per 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 multiregionale (se sono consentite più Regioni). L'uso di più Regioni può garantire maggiore disponibilità, ma può comportare complessità e costi aggiuntivi. Nella valutazione, considera i seguenti fattori:
1. **Obiettivi aziendali e requisiti dei clienti**: quanto tempo di inattività è consentito nel caso in cui si verifichi un incidente che impatta sul carico di lavoro in una zona di disponibilità o in una Regione? Valuta gli obiettivi dei punti di ripristino come descritto in [REL13-BP01 Definizione degli obiettivi di ripristino in caso di downtime e perdita di dati](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_planning_for_recovery_objective_defined_recovery.html).
1. **Requisiti per il disaster recovery (DR)**: contro quale tipo di potenziale disastro desideri assicurarti? Considera la possibilità di perdita di dati o di indisponibilità a lungo termine a livello di diversi ambiti di impatto, da una singola zona di disponibilità a un'intera Regione. Se si replicano i dati e le risorse tra le zone di disponibilità e in una singola zona di disponibilità si verifica un guasto prolungato, il servizio può essere ripristinato in un'altra zona di disponibilità. Se si replicano i dati e le risorse tra Regioni, puoi ripristinare il servizio in un'altra Regione.
1. Distribuisci le risorse di elaborazione in più zone di disponibilità.
1. Nel VPC, crea più sottoreti in diverse zone di disponibilità. Configura ciascuna di esse in modo che siano sufficientemente grandi da ospitare le risorse necessarie per servire il carico di lavoro, anche durante un incidente. Per ulteriori informazioni consulta [REL02-BP03 Verifica che l'allocazione delle sottoreti IP consenta l'espansione e la disponibilità](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_planning_network_topology_ip_subnet_allocation.html).
1. Se utilizzi istanze Amazon EC2, utilizza [EC2 Auto Scaling](https://aws.amazon.com/ec2/autoscaling/) per gestire le istanze. Specifica le sottoreti scelte nel passaggio precedente durante la creazione di gruppi Auto Scaling.
1. Se utilizzi l'elaborazione AWS Fargate per [Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/AWS_Fargate.html) o [Amazon EKS](https://docs.aws.amazon.com/eks/latest/userguide/fargate.html), seleziona le sottoreti che hai scelto nel primo passaggio durante l'operazione di creazione di un servizio ECS, l'avvio di un'attività ECS o la creazione di un [profilo Fargate](https://docs.aws.amazon.com/eks/latest/userguide/fargate-profile.html) per EKS.
1. Se utilizzi funzioni AWS Lambda che devono essere eseguite nel VPC, seleziona le sottoreti che hai scelto nel primo passaggio dell'operazione di creazione della funzione Lambda. Per tutte le funzioni che non dispongono di una configurazione VPC, AWS Lambda gestisce automaticamente la disponibilità.
1. Colloca i direttori del traffico, come i bilanciatori del carico, davanti alle risorse di elaborazione. Se il bilanciamento del carico tra zone è abilitato, [AWS Application Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/introduction.html) e [Network Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/introduction.html) rilevano quando destinazioni come istanze e container EC2 non sono raggiungibili a causa della compromissione della zona di disponibilità e reinstradano il traffico verso destinazioni in zone di disponibilità integre. Se il bilanciamento del carico tra zone è disabilitato, utilizza Amazon Application Recovery Controller (ARC) per fornire funzionalità di spostamento zonale. Se utilizzi un bilanciatore del carico di terze parti o hai implementato bilanciatori del carico personalizzati, configurali con più front-end in diverse zone di disponibilità.
1. Replica i dati del carico di lavoro in più zone di disponibilità.
1. Se utilizzi un servizio dati gestito da AWS come Amazon RDS, Amazon ElastiCache o Amazon FSx, consulta la relativa guida per l'utente per comprendere le relative funzionalità di replica dei dati e di resilienza. Se necessario, abilita la replica e il failover tra AZ.
1. Se utilizzi servizi di archiviazione gestiti da AWS come Amazon S3, Amazon EFS e Amazon FSx, evita di utilizzare configurazioni Single-AZ o One Zone per i dati che richiedono un'elevata durabilità. Utilizza una configurazione multi-AZ per questi servizi. Consulta la guida per l'utente del rispettivo servizio per determinare se la replica multi-AZ è abilitata per impostazione predefinita o se è necessario abilitarla.
1. Se esegui un database, una coda o un altro servizio di archiviazione autogestito, organizza la replica multi-AZ in base alle istruzioni o alle best practice dell'applicazione. Informati sulle procedure di failover della tua applicazione.
1. Configura il servizio DNS per rilevare compromissione dell'AZ e reinstrada il traffico verso una zona di disponibilità integra. Se utilizzato in combinazione con Elastic Load Balancer, Amazon Route 53 può eseguire questa operazione automaticamente. Route 53 può anche essere configurato con record di failover che utilizzano i controlli dell'integrità per rispondere alle query con soli indirizzi IP integri. Per tutti i record DNS utilizzati per il failover, specifica un valore TTL (time to live) breve (ad esempio, 60 secondi o meno) per evitare che la memorizzazione nella cache dei record impedisca il ripristino (i record alias di Route 53 forniscono i TTL appropriati).
**Passaggi aggiuntivi quando si utilizzano più Regioni AWS**
1. Replica tutto il sistema operativo (OS) e il codice dell'applicazione utilizzati dal carico di lavoro nelle Regioni selezionate. Se necessario, replica le Amazon Machine Image (AMI) utilizzate dalle istanze EC2 utilizzando soluzioni come Amazon EC2 Image Builder. Replica le immagini di container archiviate nei registri utilizzando soluzioni come la replica tra Regioni di Amazon ECR. Abilita la replica regionale per tutti i bucket Amazon S3 utilizzati per archiviare le risorse dell'applicazione.
1. Distribuisci le risorse di elaborazione e i metadati di configurazione (come i parametri archiviati in AWS Systems Manager Parameter Store) in più Regioni. Utilizza le stesse procedure descritte nei passaggi precedenti, ma replica la configurazione per ogni Regione utilizzata per il carico di lavoro. Utilizza soluzioni infrastructure as code, ad esempio AWS CloudFormation, per riprodurre in modo uniforme le configurazioni tra le Regioni. Se utilizzi una Regione secondaria in una configurazione fiamma pilota per il disaster recovery, puoi ridurre il numero di risorse di elaborazione a un valore minimo per risparmiare sui costi, con un corrispondente aumento del tempo di ripristino.
1. Replica i dati dalla Regione primaria alle Regioni secondarie.
1. Le tabelle globali di Amazon DynamoDB forniscono repliche globali dei dati in cui è possibile scrivere da qualsiasi Regione supportata. Con altri servizi dati gestiti da AWS, come Amazon RDS, Amazon Aurora e Amazon Elasticache, si designano una Regione primaria (lettura/scrittura) e Regioni di replica (sola lettura). Per informazioni dettagliate sulla replica regionale, consulta le guide per l'utente e per gli sviluppatori dei rispettivi servizi.
1. Se esegui un database autogestito, organizza la replica in più Regioni in base alle istruzioni o alle best practice dell'applicazione. Informati sulle procedure di failover della tua applicazione.
1. Se il carico di lavoro utilizza AWS EventBridge, potrebbe essere necessario inoltrare eventi selezionati dalla Regione primaria alle Regioni secondarie. A tal fine, specifica i bus di eventi nelle Regioni secondarie come destinazioni per gli eventi corrispondenti nella Regione primaria.
1. Considera se e in che misura usare chiavi di crittografia identiche tra le varie Regioni. Un approccio tipico, che consente di bilanciare sicurezza e facilità d'uso, consiste nell'utilizzare chiavi con ambito di Regione per i dati e l'autenticazione a livello di Regione e utilizzare chiavi con ambito globale per la crittografia dei dati replicati tra le diverse Regioni. [AWS Key Management Service (KMS)](https://aws.amazon.com/kms/) supporta [chiavi multiregionali](https://docs.aws.amazon.com/kms/latest/developerguide/multi-region-keys-overview.html) per distribuire e proteggere in modo sicuro le chiavi condivise tra le Regioni.
1. Prendi in considerazione AWS Global Accelerator per migliorare la disponibilità dell'applicazione indirizzando il traffico verso Regioni che contengono endpoint integri.
## Risorse
**Best practice correlate:**
+ [REL02-BP03 Verifica che l'allocazione delle sottoreti IP consenta l'espansione e la disponibilità](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_planning_network_topology_ip_subnet_allocation.html)
+ [REL11-BP05 Utilizzo della stabilità statica per evitare un comportamento bimodale](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_withstand_component_failures_static_stability.html)
+ [REL13-BP01 Definizione degli obiettivi di ripristino in caso di downtime e perdita di dati](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_planning_for_recovery_objective_defined_recovery.html)
**Documenti correlati:**
+ [Infrastruttura globale di AWS](https://aws.amazon.com/about-aws/global-infrastructure)
+ [White paper: AWS Fault Isolation Boundaries](https://docs.aws.amazon.com/whitepapers/latest/aws-fault-isolation-boundaries/availability-zones.html)
+ [Resilience in Amazon EC2 Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/disaster-recovery-resiliency.html)
+ [Amazon EC2 Auto Scaling: Example: Distribute instances across Availability Zones](https://docs.aws.amazon.com/autoscaling/ec2/userguide/auto-scaling-benefits.html#arch-AutoScalingMultiAZ)
+ [How EC2 Image Builder works](https://docs.aws.amazon.com/imagebuilder/latest/userguide/how-image-builder-works.html#image-builder-distribution)
+ [How Amazon ECS places tasks on container instances (includes Fargate)](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task-placement.html)
+ [Resilienza in AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/security-resilience.html)
+ [Amazon S3: Replicating objects overview](https://docs.aws.amazon.com/AmazonS3/latest/userguide/replication.html)
+ [Private image replication in Amazon ECR](https://docs.aws.amazon.com/AmazonECR/latest/userguide/replication.html)
+ [Global Tables: Multi-Region Replication with DynamoDB](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/GlobalTables.html)
+ [Amazon Elasticache for Redis OSS: Replication across Regioni AWS using global datastores](https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/Redis-Global-Datastore.html)
+ [Resilience in Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/disaster-recovery-resiliency.html)
+ [Using Amazon Aurora global databases](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-global-database.html)
+ [AWS Global Accelerator Developer Guide](https://docs.aws.amazon.com/global-accelerator/latest/dg/what-is-global-accelerator.html)
+ [Multi-Region keys in AWS KMS](https://docs.aws.amazon.com/kms/latest/developerguide/multi-region-keys-overview.html)
+ [Amazon Route 53: Configuring DNS failover](https://docs.aws.amazon.com/Route 53/latest/DeveloperGuide/dns-failover-configuring.html)
+ [Amazon Application Recovery Controller (ARC) Developer Guide](https://docs.aws.amazon.com/r53recovery/latest/dg/what-is-route53-recovery.html)
+ [Sending and receiving Amazon EventBridge events between Regioni AWS](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-cross-region.html)
+ [Creating a Multi-Region Application with AWS Services blog series](https://aws.amazon.com/blogs/architecture/tag/creating-a-multi-region-application-with-aws-services-series/)
+ [Disaster Recovery (DR) Architecture on AWS, Part I: Strategies for Recovery in the Cloud](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-i-strategies-for-recovery-in-the-cloud/)
+ [Disaster Recovery (DR) Architecture on AWS, Part III: Pilot Light and Warm Standby](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-iii-pilot-light-and-warm-standby/)
**Video correlati:**
+ [AWS re:Invent 2018: Architecture Patterns for Multi-Region Active-Active Applications](https://youtu.be/2e29I3dA8o4)
+ [AWS re:Invent 2019: Innovation and operation of the AWS global network infrastructure](https://youtu.be/UObQZ3R9_4c)
# REL10-BP02 Ripristino automatico dei componenti vincolati a una singola posizione
Se i componenti del carico di lavoro possono essere eseguiti in una sola zona di disponibilità o in un data center on-premises, devi rendere possibile la ricostruzione completa del carico di lavoro in base agli obiettivi di ripristino definiti.
**Livello di rischio associato se questa best practice non fosse adottata:** medio
## Guida all’implementazione
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à perché l'esecuzione di 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. Puoi effettuare il provisioning di [più nodi](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-plan-ha-launch.html). Utilizzando il [file system EMR (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. Viene effettuato il provisioning di tutti i nodi del cluster nella stessa zona.
Per carichi di lavoro basati su server stateful implementati in un data center on-premises, puoi usare AWS Elastic Disaster Recovery per proteggerli in AWS. Se il carico di lavoro è già ospitato in AWS, Elastic Disaster Recovery ti consente di proteggerlo in una zona di disponibilità o regione alternativa. Elastic Disaster Recovery sfrutta la replica a livello di blocco continua in un'area di gestione temporanea leggera per fornire il ripristino rapido e affidabile di applicazioni on-premises e basate sul cloud.
**Passaggi dell'implementazione**
1. Implementa l'autoriparazione. Implementa istanze o container utilizzando, quando possibile, il dimensionamento automatico. Se non è possibile utilizzare il dimensionamento 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 Amazon EC2 Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/what-is-amazon-ec2-auto-scaling.html) 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.
+ È possibile usare i dati utente del modello di avvio per implementare l'automazione per la riparazione automatica della maggior parte dei carichi di lavoro.
+ Utilizza il [ripristino delle istanze Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-recover.html) per carichi di lavoro che richiedono un indirizzo ID di una singola istanza, un indirizzo IP privato, un indirizzo IP elastico e metadati di istanza.
+ Il ripristino automatico invierà avvisi sullo stato del ripristino a un argomento SNS quando viene rilevato l'errore dell'istanza.
+ Utilizza gli [eventi del ciclo di vita di istanze Amazon EC2](https://docs.aws.amazon.com/autoscaling/ec2/userguide/lifecycle-hooks.html) o gli [eventi Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs_cwe_events.html) per automatizzare l'autoriparazione dove non è possibile utilizzare il dimensionamento automatico o il ripristino EC2.
+ Utilizza gli eventi per richiamare l'automazione che riparerà il tuo componente secondo la logica di processo richiesta.
+ Utilizza [AWS Elastic Disaster Recovery](https://docs.aws.amazon.com/drs/latest/userguide/what-is-drs.html) per proteggere i carichi di lavoro stateful limitati a una singola posizione.
## Risorse
**Documenti correlati:**
+ [Amazon ECS events](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs_cwe_events.html)
+ [Amazon EC2 Auto Scaling lifecycle hooks](https://docs.aws.amazon.com/autoscaling/ec2/userguide/lifecycle-hooks.html)
+ [Recupero di un'istanza](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-recover.html)
+ [Ridimensionamento automatico del servizio](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/service-auto-scaling.html)
+ [What Is Amazon EC2 Auto Scaling?](https://docs.aws.amazon.com/autoscaling/ec2/userguide/what-is-amazon-ec2-auto-scaling.html)
+ [AWS Elastic Disaster Recovery](https://docs.aws.amazon.com/drs/latest/userguide/what-is-drs.html)
# REL10-BP03 Utilizzo di architetture a scomparti per limitare la portata dell'impatto
Implementa architetture a scomparti (note anche come architetture basate su celle) per limitare l'effetto di un guasto all'interno di un carico di lavoro a un numero ridotto di componenti.
**Risultato desiderato:** un'architettura basata su celle utilizza più istanze isolate di un carico di lavoro, ciascuna delle quali è nota come cella. Ogni cella è indipendente, non condivide lo stato con altre celle e gestisce un sottoinsieme delle richieste complessive del carico di lavoro. Questo approccio riduce il possibile impatto di un errore, ad esempio un aggiornamento software non valido, a una singola cella e alle richieste elaborate. Se un carico di lavoro usa 10 celle per gestire 100 richieste e si verifica un errore, il 90% delle richieste complessive non sarà interessato dall'errore.
**Anti-pattern comuni:**
+ Aumento illimitato delle celle.
+ Applicazione di aggiornamenti o implementazioni del codice in tutte le celle contemporaneamente.
+ Condivisione dello stato dei componenti tra celle (con l'eccezione del livello di instradamento).
+ Aggiunta di logica di business o instradamento complessa al livello di instradamento.
+ Le interazioni tra celle non sono ridotte al minimo.
**Vantaggi dell'adozione di questa best practice:** limitazione alla cella stessa di molti tipi comuni di errori, a garanzia di un ulteriore isolamento dei guasti, grazie alle architetture basate su celle. Questi limiti relativi agli errori possono garantire resilienza in caso di determinati tipi di errori, altrimenti difficili da contenere, come implementazioni di codice non riuscite o richieste danneggiate o che richiamano una modalità di errore specifica (nota anche come *richieste poison pill*).
**Livello di rischio associato se questa best practice non fosse adottata:** elevato
## Guida all’implementazione
Su una nave gli scomparti permettono di limitare la falla di uno scafo a una sola sezione dello scafo. In sistemi complessi, questo modello viene spesso replicato per consentire l'isolamento degli errori. Le limitazioni per l'isolamento degli errori riducono 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. In AWS i clienti possono usare più zone di disponibilità e regioni per fornire l'isolamento degli errori, ma questo concetto può essere esteso anche all'architettura del carico di lavoro.
Il carico di lavoro complessivo viene partizionato in celle tramite una chiave di partizione. Questa chiave deve essere allineata alla *granularità* del servizio o al modo naturale in cui il carico di lavoro del servizio può essere suddiviso con interazioni minime tra celle. Esempi di chiavi di partizione sono un ID cliente, un ID risorsa o qualsiasi altro parametro facilmente accessibile nella maggior parte delle chiamate API. Un livello di instradamento alle celle distribuisce le richieste a singole celle in base alla chiave di partizione e presenta un unico endpoint ai client.
![\[Diagramma che mostra un'architettura basata su celle\]](http://docs.aws.amazon.com/it_it/wellarchitected/2024-06-27/framework/images/cell-based-architecture.png)
**Passaggi dell'implementazione**
Nel progettare un'architettura basata su celle, devi tenere conto di diversi aspetti della progettazione:
1. **Chiave di partizione**: presta particolare attenzione alla scelta della chiave di partizione.
+ Questa deve essere allineata alla granularità del servizio o al modo naturale in cui il carico di lavoro del servizio può essere suddiviso con interazioni minime tra celle. Alcuni esempi sono `customer ID` o `resource ID`.
+ La chiave di partizione deve essere disponibile in tutte le richieste, direttamente o in modo da poter essere facilmente dedotta in modo deterministico da altri parametri.
1. **Mappatura persistente delle celle**: i servizi a monte devono interagire solo con una singola cella per l'intero ciclo di vita delle risorse correlate.
+ A seconda del carico di lavoro, può essere necessaria una strategia di migrazione delle celle per la migrazione dei dati da una cella a un'altra. Un possibile scenario in cui è necessaria la migrazione delle celle è quando una risorsa o un utente specifico nel carico di lavoro diventa troppo grande e richiede una cella dedicata.
+ Le celle non devono condividere lo stato o i componenti.
+ Di conseguenza, l'interazione tra celle deve essere evitata o mantenuta al minimo, in quanto le interazioni creano dipendenze tra le celle e riducono quindi i vantaggi forniti dall'isolamento degli errori.
1. **Livello di instradamento**: il livello di instradamento è un componente condiviso tra celle, pertanto non può basarsi sulla stessa strategia di compartimentazione delle celle.
+ È consigliabile che il livello di instradamento distribuisca richieste a singole celle usando un algoritmo di mappatura delle partizioni efficiente in termini di risorse di calcolo, ad esempio combinando funzioni hash crittografiche e aritmetica modulare per mappare le chiavi di partizione alle celle.
+ Per evitare l'impatto su più celle, il livello di instradamento deve restare il più semplice e orizzontalmente scalabile possibile, evitando logica di business complessa in questo livello. Questo approccio offre il vantaggio aggiuntivo di semplificare la comprensione del suo comportamento previsto in ogni momento, permettendo test esaustivi. Come illustrato da Colm MacCárthaigh in [Reliability, constant work, and a good cup of coffee](https://aws.amazon.com/builders-library/reliability-and-constant-work/), progettazioni semplici e schemi di lavoro costanti si traducono in sistemi affidabili e nella riduzione dell'antifragilità.
1. **Dimensione delle celle**: le celle devono avere una dimensione massima che non deve essere superata
+ La dimensione massima va identificata attraverso l'esecuzione di test completi, fino a raggiungere i punti di rottura e definire i margini operativi. Per ulteriori informazioni su come implementare procedure di test, consulta [REL07-BP04 Load Testa il tuo carico di lavoro](rel_adapt_to_changes_load_tested_adapt.md).
+ L'aumento del carico di lavoro complessivo deve essere gestito tramite l'aggiunta di celle, in modo da poterlo dimensionare in base al crescere della domanda.
1. **Strategie multi-AZ o multi-regione**: si consiglia di utilizzare più livelli di resilienza per proteggersi da diversi domini di errore.
+ Per la resilienza, devi utilizzare un approccio che costruisca livelli di difesa. Un livello protegge dalle interruzioni minime e più comuni attraverso la creazione di un'architettura a disponibilità elevata tramite più zone di disponibilità. 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. 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. Per ulteriori dettagli, consulta [REL10-BP01 Implementazione del carico di lavoro in diversi luoghi](rel_fault_isolation_multiaz_region_system.md).
1. **Implementazione del codice**: è preferibile una strategia di implementazione del codice scaglionata rispetto all'implementazione simultanea di modifiche al codice in tutte le celle.
+ In questo modo, è possibile ridurre al minimo eventuali errori in più celle a causa di un'implementazione non corretta o dell'errore umano. Per ulteriori informazioni, consulta [Automatizzazione di distribuzioni pratiche e sicure](https://aws.amazon.com/builders-library/automating-safe-hands-off-deployments/).
## Risorse
**Best practice correlate:**
+ [REL07-BP04 Load Testa il tuo carico di lavoro](rel_adapt_to_changes_load_tested_adapt.md)
+ [REL10-BP01 Implementazione del carico di lavoro in diversi luoghi](rel_fault_isolation_multiaz_region_system.md)
**Documenti correlati:**
+ [Reliability, constant work, and a good cup of coffee](https://aws.amazon.com/builders-library/reliability-and-constant-work/)
+ [AWS and Compartmentalization ](https://aws.amazon.com/blogs/architecture/aws-and-compartmentalization/)
+ [ Isolamento del carico di lavoro utilizzando lo sharding casuale ](https://aws.amazon.com/builders-library/workload-isolation-using-shuffle-sharding/)
+ [Automatizzazione di distribuzioni pratiche e sicure](https://aws.amazon.com/builders-library/automating-safe-hands-off-deployments/)
**Video correlati:**
+ [AWS re:Invent 2018: Close Loops and Opening Minds: How to Take Control of Systems, Big and Small ](https://www.youtube.com/watch?v=O8xLxNje30M)
+ [AWS re:Invent 2018: How AWS Minimizes the Blast Radius of Failures (ARC338)](https://youtu.be/swQbA4zub20)
+ [Shuffle-sharding: AWS re:Invent 2019: Introducing The Amazon Builders' Library (DOP328)](https://youtu.be/sKRdemSirDM?t=1373)
+ [AWS Summit ANZ 2021 - Everything fails, all the time: Designing for resilience ](https://www.youtube.com/watch?v=wUzSeSfu1XA)