# REL11-BP02 Failover e passaggio a risorse integre
Se si verifica un errore in una risorsa, le risorse integre dovrebbero continuare a soddisfare le richieste. Per posizioni compromesse (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.
Durante la progettazione di un servizio, distribuisci il carico tra risorse, zone di disponibilità o regioni. Pertanto, il guasto o la compromissione di una singola risorsa può essere mitigato spostando il traffico sulle risorse integre rimanenti. Considera come vengono rilevati e indirizzati i servizi in caso di guasto.
Progetta i tuoi servizi tenendo a mente il recupero dai guasti. In AWS, 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. 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.
I modelli e i progetti che consentono il failover variano a seconda dei servizi della AWS. Molti servizi AWS gestiti nativi si trovano in più zone di disponibilità (come Lambda oAPI Gateway) in modo nativo. Altri servizi AWS (come EC2 ed EKS) richiedono procedure ottimali specifiche per supportare il failover delle risorse o l'archiviazione di dati tra le zone di disponibilità.
Il monitoraggio deve essere impostato per verificare che la risorsa di failover sia integra, tenere traccia dell'avanzamento del failover delle risorse e monitorare il ripristino dei processi aziendali.
**Risultato desiderato:** I sistemi sono in grado di utilizzare automaticamente o manualmente nuove risorse per il ripristino dopo un evento di deterioramento.
**Anti-pattern comuni:**
+ La pianificazione degli errori non fa parte della fase di pianificazione e progettazione.
+ L'obiettivo del tempo di ripristino (RTO) e l'obiettivo del punto di ripristino (RPO) non sono stabiliti.
+ Monitoraggio insufficiente per rilevare risorse difettose.
+ Isolamento adeguato dei domini di errore.
+ Il failover multi-regione non è considerato.
+ Il rilevamento dei guasti è troppo sensibile o aggressivo quando si decide di eseguire il failover.
+ Non è possibile testare o convalidare il progetto di failover.
+ Esecuzione dell'automazione del risanamento automatico, ma senza la notifica della necessità di una correzione.
+ Mancanza di un periodo di mitigazione per evitare che l'errore si ripresenti troppo presto.
**Vantaggi dell'adozione di questa best practice:** È possibile creare sistemi più resilienti che mantengano l'affidabilità in caso di guasti eseguendo prima un deterioramento lento e poi un ripristino rapido.
**Livello di rischio associato se questa best practice non fosse adottata:** alto
## Guida all'implementazione
I servizi AWS, come [Elastic Load Balancing](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-subnets.html) e [Amazon EC2 Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/auto-scaling-groups.html), aiutano a distribuire il carico tra risorse e 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, i progetti sono più complicati. Ad esempio, le repliche di lettura multi-regione consentono di implementare i dati su Regioni AWS multiple. Tuttavia, il failover è ancora necessario per promuovere la replica di lettura a principale e quindi indirizzare il traffico verso il nuovo endpoint. Amazon Route 53, Route 53 ARC, CloudFront e AWS Global Accelerator possono aiutare a instradare il traffico tra le Regioni AWS.
Servizi AWS come Amazon S3, Lambda, API Gateway, Amazon SQS, Amazon SNS, Amazon SES, Amazon Pinpoint, Amazon ECR, AWS Certificate Manager, EventBridge o Amazon DynamoDB vengono implementati automaticamente in più zone di disponibilità da AWS. In caso di guasto, questi servizi AWS instradano automaticamente il traffico verso posizioni integre. I dati sono archiviati in modo ridondante in più zone di disponibilità e rimangono disponibili.
Per Amazon RDS, Amazon Aurora, Amazon Redshift, Amazon EKS o Amazon ECS, l'implementazione Multi-AZ è un'opzione di configurazione. AWS può indirizzare il traffico verso l'istanza integra se viene avviato il failover. Questa azione di failover può essere intrapresa direttamente da AWS o su richiesta del cliente.
Per istanze Amazon EC2, Amazon Redshift, attività Amazon ECS o pod Amazon EKS, sei tu a scegliere in quali zone di disponibilità eseguire la distribuzione. Per alcuni progetti, Elastic Load Balancing fornisce la soluzione per rilevare istanze in zone corrotte e instradare il traffico verso quelle integre. Elastic Load Balancing può anche indirizzare il traffico verso i componenti del data center on-premise.
Per il failover del traffico multi-regione, il reindirizzamento può sfruttare Amazon Route 53, ARC, AWS Global Accelerator, Route 53 Private DNS for VPCs o CloudFront per fornire una modalità per definire domini Internet e assegnare policy di routing, compresi i controlli dell'integrità, per instradare il traffico verso regioni integre. AWS Global Accelerator fornisce indirizzi IP statici che operano come punto di ingresso fisso all'applicazione, che indirizzano il traffico verso gli endpoint delle Regioni AWS di tua scelta utilizzando la rete AWS globale anziché Internet per prestazioni e affidabilità migliori.
### Passaggi dell'implementazione
+ Crea progetti di failover per tutte le applicazioni e i servizi appropriati. Isola ogni componente dell'architettura e crea progetti di failover che soddisfino l'RTO e l'RPO per ogni componente.
+ Configura ambienti inferiori (come sviluppo o test) con tutti i servizi necessari per disporre di un piano di failover. Implementa le soluzioni utilizzando l'infrastruttura come codice (IaC) per garantire la ripetibilità.
+ Configura un sito di ripristino, ad esempio una seconda regione, per implementare e testare i progetti di failover. Se necessario, le risorse per i test possono essere configurate temporaneamente per limitare i costi aggiuntivi.
+ Determina quali piani di failover sono automatizzati da AWS, quali possono essere automatizzati da un processo DevOps e quali possono essere manuali. Documenta e misura l'RTO e l'RPO di ogni servizio.
+ Crea un playbook per il failover e includi tutti i passaggi necessari per eseguire il failover di ogni risorsa, applicazione e servizio.
+ Crea un playbook di failback e includi tutti i passaggi per eseguire il failback (con tempistiche) di ogni risorsa, applicazione e servizio.
+ Crea un piano per avviare e testare il playbook. Usa simulazioni e test del caos per testare i passaggi e l'automazione del playbook.
+ Per posizioni compromesse (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. Verifica la quota, i livelli di dimensionamento automatico e le risorse in esecuzione prima dei test di failover.
## Risorse
**Best practice Well-Architected correlate:**
+ [REL13- Pianificazione per il disaster recovery (DR)](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/plan-for-disaster-recovery-dr.html)
+ [REL10 - Utilizzo dell'isolamento dei guasti per proteggere il carico di lavoro](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/use-fault-isolation-to-protect-your-workload.html)
**Documenti correlati:**
+ [Setting RTO and RPO Targets](https://aws.amazon.com/blogs/mt/establishing-rpo-and-rto-targets-for-cloud-applications/)
+ [Set up ARC with application loadbalancers](https://www.wellarchitectedlabs.com/reliability/disaster-recovery/workshop_5/)
+ [Failover using Route 53 Weighted routing](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)
+ [DR with ARC](https://catalog.us-east-1.prod.workshops.aws/workshops/4d9ab448-5083-4db7-bee8-85b58cd53158/en-US/)
+ [EC2 with autoscaling](https://github.com/adriaanbd/aws-asg-ecs-starter)
+ [EC2 Deployments - Multi-AZ](https://github.com/awsdocs/amazon-ec2-auto-scaling-user-)
+ [ECS Deployments - Multi-AZ](https://github.com/aws-samples/ecs-refarch-cloudformation)
+ [Switch traffic using ARC](https://docs.aws.amazon.com/r53recovery/latest/dg/routing-control.failover-different-accounts.html)
+ [Lambda with an Application Load Balancer and Failover](https://docs.aws.amazon.com/lambda/latest/dg/services-alb.html)
+ [ACM Replication and Failover](https://github.com/aws-samples/amazon-ecr-cross-region-replication)
+ [Parameter Store Replication and Failover](https://medium.com/devops-techable/how-to-design-an-ssm-parameter-store-for-multi-region-replication-support-aws-infrastructure-db7388be454d)
+ [ECR cross region replication and Failover](https://docs.aws.amazon.com/AmazonECR/latest/userguide/registry-settings-configure.html)
+ [Secrets manager cross region replication configuration](https://disaster-recovery.workshop.aws/en/labs/basics/secrets-manager.html)
+ [Enable cross region replication for EFS and Failover](https://aws.amazon.com/blogs/aws/new-replication-for-amazon-elastic-file-system-efs/)
+ [EFS Cross Region Replication and Failover](https://aws.amazon.com/blogs/storage/transferring-file-data-across-aws-regions-and-accounts-using-aws-datasync/)
+ [Networking Failover](https://docs.aws.amazon.com/whitepapers/latest/hybrid-connectivity/aws-dx-dxgw-with-vgw-multi-regions-and-aws-public-peering.html)
+ [S3 Endpoint failover using MRAP](https://catalog.workshops.aws/s3multiregionaccesspoints/en-US/0-setup/1-review-mrap)
+ [Crea una replica tra regioni per S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/replication.html)
+ [Failover Regional API Gateway with ARC](https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=&ved=2ahUKEwjat_TNvev_AhVLlokEHaUeDSUQFnoECAYQAQ&url=https%3A%2F%2Fd1.awsstatic.com%2Fsolutions%2Fguidance%2Farchitecture-diagrams%2Fcross-region-failover-and-graceful-failback-on-aws.pdf&usg=AOvVaw0czthdzWiGlN9I-Dt0lAu3&opi=89978449)
+ [Failover using multi-region global accelerator](https://aws.amazon.com/blogs/networking-and-content-delivery/deploying-multi-region-applications-in-aws-using-aws-global-accelerator/)
+ [Failover with DRS](https://docs.aws.amazon.com/drs/latest/userguide/failback-overview.html)
+ [Creating Disaster Recovery Mechanisms Using Amazon Route 53](https://amazon.awsapps.com/workdocs/index.html#/document/2501b1ab648225c2d50ab420c4626ef143834fd0d646978629e5ea4e9b8f014b)
**Esempi correlati:**
+ [Disaster Recovery on AWS](https://disaster-recovery.workshop.aws/en/)
+ [Elastic Disaster Recovery on AWS](https://catalog.us-east-1.prod.workshops.aws/workshops/080af3a5-623d-4147-934d-c8d17daba346/en-US)