# REL 13 Como você planeja a recuperação de desastres (DR)?
Implementar backups e componentes redundantes de carga de trabalho é o ponto de partida da sua estratégia de DR. [RTO e RPO são os seus objetivos](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/disaster-recovery-dr-objectives.html) para restauração de sua workload. Defina-os de acordo com suas necessidades de negócios. Implemente uma estratégia para atender a esses objetivos, considerando os locais e a função dos recursos e dos dados da carga de trabalho. A probabilidade de interrupção e o custo de recuperação também são fatores principais que ajudam a determinar o valor empresarial de fornecer a recuperação de desastres para uma workload.
**Topics**
+ [REL13-BP01 Definir os objetivos de recuperação para tempo de inatividade e perda de dados](rel_planning_for_recovery_objective_defined_recovery.md)
+ [REL13-BP02 Usar estratégias de recuperação definidas para atender aos objetivos de recuperação](rel_planning_for_recovery_disaster_recovery.md)
+ [REL13-BP03 Testar a implementação de recuperação de desastres para validá-la](rel_planning_for_recovery_dr_tested.md)
+ [REL13-BP04 Gerenciar o desvio de configuração para o local ou a região de DR](rel_planning_for_recovery_config_drift.md)
+ [REL13-BP05 Automatizar a recuperação](rel_planning_for_recovery_auto_recovery.md)
# REL13-BP01 Definir os objetivos de recuperação para tempo de inatividade e perda de dados
A carga de trabalho tem um Recovery Time Objective (RTO – Objetivo do tempo de recuperação) e um Recovery Point Objective (RPO – Objetivo do ponto de recuperação).
*Recovery Time Objective (RTO – Objetivo do tempo de recuperação)* é o atraso máximo aceitável entre a interrupção do serviço e sua restauração. Isso determina o que é considerado uma janela de tempo aceitável quando o serviço está indisponível.
*Recovery Point Objective (RPO – Objetivo do ponto de recuperação)* é o tempo máximo aceitável desde o último ponto de recuperação de dados. Isso determina o que é considerado uma perda aceitável de dados entre o último ponto de recuperação e a interrupção do serviço.
Os valores de RTO e RPO são considerações importantes ao selecionar uma estratégia de recuperação de desastres (DR) apropriada para a workload. Esses objetivos são determinados pelo negócio e, em seguida, usados pelas equipes técnicas para selecionar e implementar uma estratégia de DR.
**Resultado desejado:**
Cada workload tem um RTO e um RPO atribuídos, definidos com base no impacto empresarial. A workload é atribuída a uma camada predefinida com um RTO e um RPO associados, estabelecendo a disponibilidade do serviço e a perda aceitável de dados. Se isso não for possível, poderá ser atribuído sob medida por workload com a intenção de criar camadas posteriormente. O RTO e o RPO são usados como uma das principais considerações para a seleção da implementação de uma estratégia de recuperação de desastres para a workload. São considerações adicionais na escolha de uma estratégia de DR as restrições de custo, as dependências da workload e os requisitos operacionais.
Para o RTO, compreenda o impacto com base na duração de uma interrupção. É linear ou há implicações não lineares? (Por exemplo, após quatro horas, você desliga uma linha de produção até o início do próximo turno).
Uma matriz de recuperação de desastres, como a seguinte, pode ajudar você a compreender como a criticidade da workload se relaciona com os objetivos de recuperação. (Observe que os valores reais dos eixos X e Y devem ser personalizados de acordo com as necessidades da sua organização).
![\[Gráfico mostrando a matriz de recuperação de desastres\]](http://docs.aws.amazon.com/pt_br/wellarchitected/2022-03-31/framework/images/disaster-recovery-matrix.png)
**Antipadrões comuns:**
+ Objetivos de recuperação não definidos.
+ Seleção de objetivos de recuperação arbitrários.
+ Seleção de objetivos de recuperação que são muito permissivos e não atendem aos objetivos de negócios.
+ Não compreender o impacto do tempo de inatividade e da perda de dados.
+ Seleção de objetivos de recuperação irreais, como nenhum tempo para recuperação e nenhuma perda de dados, que podem não ser alcançáveis para a configuração da workload.
+ Seleção de objetivos de recuperação mais rigorosos do que os objetivos de negócios reais. Isso força implementações de DR mais caras e complicadas do que as necessidades da workload.
+ Seleção de objetivos de recuperação incompatíveis com os da workload dependente.
+ Os objetivos de recuperação não consideram os requisitos regulamentares de conformidade.
+ RTO e RPO definidos para uma workload, mas nunca testados.
**Benefícios do estabelecimento dessa prática recomendada:** Os objetivos de recuperação referentes a tempo e perda de dados são necessários para orientar a implementação da DR.
**Nível de exposição a riscos quando esta prática recomendada não for estabelecida:** Alto
## Orientações para a implementação
Para a workload, você deve compreender o impacto do tempo de inatividade e da perda de dados em seus negócios. O impacto geralmente aumenta com maior tempo de inatividade ou perda de dados, mas a forma desse crescimento pode diferir com base no tipo de workload. Por exemplo, pode ser que você consiga tolerar o tempo de inatividade por até uma hora com pouco impacto, mas depois disso o impacto aumenta rapidamente. O impacto nos negócios se manifesta de diversas formas, incluindo custo monetário (como perda de receita), confiança do cliente (e impacto na reputação), problemas operacionais (como folha de pagamento ausente ou diminuição na produtividade) e risco regulatório. Use as etapas a seguir para compreender esses impactos e defina o RTO e o RPO para sua workload.
**Etapas da implementação**
1. Determine as partes interessadas do negócio para a workload e interaja com eles para implementar essas etapas. Os objetivos de recuperação para uma workload são uma decisão de negócios. As equipes técnicas trabalham com as partes interessadas do negócio para usar esses objetivos para selecionar uma estratégia de DR.
**nota**
Para as etapas 2 e 3, você pode usar o [Planilha de implementação](#implementation-worksheet).
1. Reúna as informações necessárias para tomar uma decisão respondendo às perguntas abaixo.
1. Você tem categorias ou níveis de criticidade para o impacto da workload na sua organização?
1. Se sim, atribua esta workload a uma categoria
1. Se não, estabeleça estas categorias. Crie cinco ou menos categorias e refine o intervalo do seu objetivo de tempo de recuperação para cada uma delas. Os exemplos de categorias incluem: crítica, alta, média, baixa. Para entender como uma workloads é mapeada para uma categoria, considere se ela é de missão crítica, importante para os negócios ou não comercial.
1. Defina o RTO e o RPO da workload com base na categoria. Sempre escolha uma categoria mais restrita (RTO e RPO mais baixos) do que os valores brutos calculados no começo desta etapa. Se isso resultar em uma mudança de valor inadequadamente grande, considere a criação de uma nova categoria.
1. Com base nessas respostas, atribua valores de RTO e RPO à workload. Isso pode ser feito diretamente ou atribuindo a workload a uma camada de serviço predefinida.
1. Documente o plano de recuperação de desastres (DRP) para esta workload, que faz parte [do plano de continuidade de negócios (BCP) da sua organização](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/business-continuity-plan-bcp.html), em um local acessível à equipe de workload e às partes interessadas
1. Registre o RTO, o RPO e as informações usadas para determinar esses valores. Inclua a estratégia usada para avaliar o impacto da workload nos negócios.
1. Registre outras métricas, além do RTO e do RPO que você está acompanhando ou planeja acompanhar, para os objetivos de recuperação de desastres
1. Você adicionará detalhes da sua estratégia de DR e runbook a este plano ao criá-los.
1. Ao pesquisar a criticidade da workload em uma matriz, como a da figura 15, você pode começar a estabelecer camadas predefinidas de serviço estabelecidos para sua organização.
1. Após implementar uma estratégia de DR (ou uma prova de conceito para uma estratégia de DR) conforme [REL13-BP02 Usar estratégias de recuperação definidas para atender aos objetivos de recuperação](rel_planning_for_recovery_disaster_recovery.md), teste a estratégia para determinar a capacidade de tempo de recuperação (RTC) e a capacidade de ponto de recuperação (RPC) reais da workload. Se elas não atenderem aos objetivos de recuperação de destino, trabalhe com as partes interessadas do negócio para ajustar esses objetivos ou faça alterações na estratégia de DR para atingir os objetivos de destino.
**Perguntas principais**
1. Qual é o tempo máximo que a workload pode ficar inativa antes que ocorra um impacto grave nos negócios?
1. Determine o custo monetário (impacto financeiro direto) para o negócio por minuto se a workload for interrompida.
1. Considere que o impacto nem sempre é linear. O impacto pode ser limitado no início e aumentar rapidamente após um ponto crítico.
1. Qual é a quantidade máxima de dados que podem ser perdidos antes que ocorra um impacto severo nos negócios?
1. Considere esse valor para seu armazenamento de dados mais crítico. Identifique a respectiva criticidade para outros armazenamentos de dados.
1. Os dados de workload podem ser recriados em caso de perda? Se isso for operacionalmente mais fácil do que fazer backup e restauração, escolha o RPO com base na criticidade dos dados de origem usados para recriar os dados da workload.
1. Quais são os objetivos de recuperação e as expectativas de disponibilidade das workloads das quais este depende (downstream) ou as workloads que dependem deste (upstream)?
1. Escolha objetivos de recuperação que permitam que essa workload atenda aos requisitos das dependências upstream.
1. Escolha objetivos de recuperação que possam ser alcançados com base nos recursos de recuperação das dependências downstream. Dependências downstream não críticas (aquelas que podem ser “contornadas”) podem ser excluídas. Ou trabalhe com dependências críticas downstream para melhorar os recursos de recuperação quando necessário.
**Perguntas adicionais**
Considere estas perguntas e como elas podem se aplicar a essa workload:
1. Você tem RTO e RPO diferentes dependendo do tipo de interrupção (região versus AZ etc.)?
1. Existe um momento específico (sazonalidade, eventos de vendas, lançamentos de produtos) em que seu RTO/RPO pode mudar? Se sim, quais são a medição e o limite de tempo diferentes?
1. Quantos clientes serão afetados se a workload for interrompida?
1. Qual será o impacto na reputação se a workload for interrompida?
1. Quais outros impactos operacionais poderão ocorrer se a workload for interrompida? Por exemplo, impacto na produtividade do funcionário se os sistemas de e-mail não estiverem disponíveis ou se os sistemas de folha de pagamento não puderem enviar transações.
1. Como o RTO e o RPO da workload se alinham à estratégia de DR da linha empresarial e organizacional?
1. Há obrigações contratuais internas para a prestação de um serviço? Há penalidades por não cumpri-las?
1. Quais são as restrições regulatórias ou de conformidade com os dados?
## Planilha de implementação
Você pode usar esta planilha para as etapas 2 e 3 de implementação. É possível ajustar esta planilha para atender às suas necessidades específicas, como adicionar perguntas.
![\[Planilha\]](http://docs.aws.amazon.com/pt_br/wellarchitected/2022-03-31/framework/images/worksheet.png)
**Nível de esforço para o plano de implementação: **Baixo
## Recursos
**Práticas recomendadas relacionadas:**
+ [REL09-BP04 Realizar a recuperação periódica dos dados para verificar a integridade e os processos de backup](rel_backing_up_data_periodic_recovery_testing_data.md)
+ [REL13-BP02 Usar estratégias de recuperação definidas para atender aos objetivos de recuperação](rel_planning_for_recovery_disaster_recovery.md)
+ [REL13-BP03 Testar a implementação de recuperação de desastres para validá-la](rel_planning_for_recovery_dr_tested.md)
**Documentos relacionados:**
+ [Blog de arquitetura da AWS: série de recuperação de desastres](https://aws.amazon.com/blogs/architecture/tag/disaster-recovery-series/)
+ [Recuperação de desastres de workloads na AWS: recuperação na nuvem (whitepaper da AWS)](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/disaster-recovery-workloads-on-aws.html)
+ [Gerenciamento de políticas de resiliência com o AWS Resilience Hub](https://docs.aws.amazon.com/resilience-hub/latest/userguide/resiliency-policies.html)
+ [Parceiro do APN: parceiros que podem ajudar com a recuperação de desastres](https://aws.amazon.com/partners/find/results/?keyword=Disaster+Recovery)
+ [AWS Marketplace: produtos que podem ser usados para recuperação de desastres](https://aws.amazon.com/marketplace/search/results?searchTerms=Disaster+recovery)
**Vídeos relacionados:**
+ [AWS re:Invent 2018: Architecture Patterns for Multi-Region Active-Active Applications (ARC209-R2)](https://youtu.be/2e29I3dA8o4)
+ [Recuperação de desastres de workloads na AWS](https://www.youtube.com/watch?v=cJZw5mrxryA)
# REL13-BP02 Usar estratégias de recuperação definidas para atender aos objetivos de recuperação
Defina uma estratégia de recuperação de desastres (DR) que atenda os objetivos de recuperação da workload. Escolha uma estratégia como: backup e restauração, standby (ativo-passivo) ou ativo-ativo.
Uma estratégia de DR depende da capacidade de manter a workload em um site de recuperação se seu local primário não puder executar a workload. Os objetivos de recuperação mais comuns são o RTO e o RPO, conforme discutido em [REL13-BP01 Definir os objetivos de recuperação para tempo de inatividade e perda de dados](rel_planning_for_recovery_objective_defined_recovery.md).
Uma estratégia de DR em várias zonas de disponibilidade (AZs) em uma única Região da AWS pode fornecer mitigação contra eventos de desastre, como incêndios, inundações e grandes interrupções de energia. Se for um requisito implementar proteção contra um evento improvável que impeça a execução da workload em uma determinada Região da AWS, você poderá optar por uma estratégia de DR que use várias regiões.
Ao arquitetar uma estratégia de DR em várias regiões, você deve escolher uma das seguintes estratégias. Elas estão listadas em ordem crescente de custo e complexidade e em ordem decrescente de RTO e RPO. *região de recuperação* refere-se a uma Região da AWS diferente da primária usada para a workload.
![\[Diagrama mostrando estratégias de DR\]](http://docs.aws.amazon.com/pt_br/wellarchitected/2022-03-31/framework/images/disaster-recovery-strategies.png)
+ **Backup e restauração** (RPO em horas, RTO em 24 horas ou menos): faça backup de seus dados e aplicações na região de recuperação. O uso de backups automatizados ou contínuos permitirá a recuperação a um ponto anterior no tempo, podendo reduzir o RPO para até 5 minutos em alguns casos. Em caso de desastre, você implantará a infraestrutura (usando a infraestrutura como código para reduzir o RTO), implantará o código e restaurará os dados salvos para se recuperar de um desastre na região de recuperação.
+ **Luz piloto** (RPO em minutos, RTO em dezenas de minutos): provisione uma cópia da infraestrutura de workload principal na região de recuperação. Replique seus dados na região de recuperação e crie backups deles lá. Os recursos necessários para oferecer suporte à replicação e ao backup, como bancos de dados e armazenamento de objetos, estão sempre ativos. Outros elementos, como servidores de aplicações ou computação com tecnologia sem servidor, não são implantados. Porém, podem ser criados com a configuração e o código da aplicação necessários.
+ **Modo de espera passivo** (RPO em segundos, RTO em minutos): mantenha uma versão reduzida, mas totalmente funcional, da workload sempre em execução na região de recuperação. Os sistemas críticos para os negócios são totalmente duplicados e estão sempre ativados, mas com uma frota reduzida. Os dados são replicados e vivem na região de recuperação. Quando chega o momento da recuperação, o sistema é dimensionado rapidamente para processar a carga de produção. Quanto mais a escala do modo de espera passivo for aumentada verticalmente, menor será a dependência do RTO e do ambiente de gerenciamento. Quando totalmente dimensionado, isso é conhecido como **standby a quente**.
+ **Multirregional (multissite) ativo-ativo** (RPO próximo a zero, RTO potencialmente zero): a workload é implantada em várias Regiões da AWS e processa ativamente o tráfego delas. Esta estratégia exige que você sincronize os dados entre regiões. Deve-se evitar ou processar possíveis conflitos causados por gravações no mesmo registro em duas réplicas regionais diferentes, o que pode ser complexo. A replicação de dados é útil para a sincronização de dados e protegerá você contra alguns tipos de desastre, mas não contra corrupção ou destruição de dados, a menos que sua solução também inclua opções para recuperação a um ponto anterior no tempo.
**nota**
Às vezes, a diferença entre luz piloto e modo de espera passivo pode ser difícil de entender. Ambos incluem um ambiente na região de recuperação com cópias dos ativos da região primária. A diferença é que a luz piloto não pode processar solicitações sem primeiro realizar uma ação adicional, enquanto o modo de espera passivo pode processar o tráfego (em níveis de capacidade reduzidos) imediatamente. A luz piloto exigirá que você ative os servidores, possivelmente implante infraestrutura adicional (não essencial) e aumente a escala verticalmente. Já o modo de espera passivo exige apenas que você aumente a escala verticalmente (tudo já está implantado e em execução). Escolha entre elas com base nas suas necessidades de RTO e RPO.
**Resultado desejado:**
Há uma estratégia de DR definida e implementada para cada workload, permitindo que ela atinja os objetivos de DR. As estratégias de DR entre workloads fazem uso de padrões reutilizáveis (como as estratégias descritas anteriormente).
**Antipadrões comuns:**
+ Implementar procedimentos de recuperação inconsistentes para workloads com objetivos de DR semelhantes.
+ Deixar que a estratégia de DR seja implementada ad hoc quando ocorrer um desastre.
+ Não tendo nenhum plano para DR.
+ Depender das operações do ambiente de gerenciamento durante a recuperação.
**Benefícios do estabelecimento dessa prática recomendada:**
+ O uso de estratégias de recuperação definidas permite que você adote ferramentas comuns e procedimentos de teste.
+ O uso de estratégias de recuperação definidas permite o compartilhamento de conhecimento eficiente entre as equipes e uma implementação mais fácil de DR nas workloads que elas possuem.
**Nível de exposição a riscos quando esta prática recomendada não for estabelecida:** Alto
+ Sem uma estratégia de DR planejada, implementada e testada, é improvável que você atinja os objetivos de recuperação em caso de desastre.
## Orientações para a implementação
Para cada uma dessas etapas, veja os detalhes abaixo.
1. Determine uma estratégia de DR que satisfaça os requisitos de recuperação para esta workload.
1. Revise os padrões de como a estratégia de DR selecionada pode ser implementada.
1. Avalie os recursos da workload e qual será sua configuração na região de recuperação antes do failover (durante a operação normal).
1. Determine e implemente como deixar sua região de recuperação pronta para failover quando necessário (durante um evento de desastre).
1. Determine e implemente como redirecionar o tráfego para failover quando necessário (durante um evento de desastre).
1. Projete um plano de como a workload retornará.
**Etapas da implementação**
1. **Determine uma estratégia de DR que satisfaça os requisitos de recuperação para esta workload.**
Escolher uma estratégia de DR é uma troca entre reduzir o tempo de inatividade e a perda de dados (RTO e RPO) versus o custo e a complexidade da sua implementação. Você deve evitar implementar uma estratégia mais rigorosa do que necessário, pois isso resulta em custos desnecessários.
Por exemplo, no diagrama a seguir, a empresa determinou seu RTO máximo permitido e o orçamento limite da estratégia de restauração de serviço. Considerando os objetivos do negócio, as estratégias de DR luz piloto e modo de espera passivo satisfarão tanto o RTO quanto os critérios de custo.
![\[Gráfico mostrando a escolha de uma estratégia de DR com base no RTO e no custo\]](http://docs.aws.amazon.com/pt_br/wellarchitected/2022-03-31/framework/images/choosing-a-dr-strategy.png)
Para saber mais, consulte [Plano de continuidade de negócios (BCP)](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/business-continuity-plan-bcp.html).
1. **Revise os padrões de como a estratégia de DR selecionada pode ser implementada.**
Esta etapa é para compreender como implementar a estratégia selecionada. As estratégias são explicadas usando as Regiões da AWS como locais primários e de recuperação. No entanto, também é possível optar por usar as zonas de disponibilidade em uma única região como sua estratégia de DR, que faz uso de elementos de várias dessas estratégias.
Nas etapas subsequentes, você aplicará a estratégia à sua workload específica.
**Backup e restauração**
*Backup e restauração* é a estratégia menos complexa de implementar. Porém, exigirá mais tempo e esforço para restaurar a workload, levando a RTO e RPO mais altos. É uma boa prática sempre fazer backups dos seus dados e copiá-los para outro local (como outra Região da AWS).
![\[Diagrama mostrando uma arquitetura de backup e restauração\]](http://docs.aws.amazon.com/pt_br/wellarchitected/2022-03-31/framework/images/backup-restore-architecture.png)
Para obter mais detalhes sobre esta estratégia, consulte [Arquitetura de recuperação de desastres (DR) na AWS, parte II: backup e restauração com recuperação rápida](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-ii-backup-and-restore-with-rapid-recovery/).
**Luz piloto**
Com a abordagem de *luz piloto* , você replica os dados da região primária para a região de recuperação. Os recursos principais usados para a infraestrutura de workload são implantados na região de recuperação. No entanto, recursos adicionais e quaisquer dependências ainda são necessários para tornar isso uma pilha funcional. Por exemplo, na figura 20, nenhuma instância de computação é implantada.
![\[Diagrama mostrando uma arquitetura de luz piloto\]](http://docs.aws.amazon.com/pt_br/wellarchitected/2022-03-31/framework/images/pilot-light-architecture.png)
Para obter mais detalhes sobre esta estratégia, consulte [Arquitetura de recuperação de desastres (DR) na AWS, parte III: luz piloto e modo de espera passivo](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-iii-pilot-light-and-warm-standby/).
**Modo de espera passivo**
O *standby passivo* envolve garantir que haja uma cópia com escala reduzida verticalmente, mas totalmente funcional, do seu ambiente de produção em outra região. Essa abordagem estende o conceito de luz piloto e diminui o tempo de recuperação já que a workload está sempre ativa em outra região. A implementação da região de recuperação com capacidade total é conhecido como *standby a quente*.
![\[Diagrama mostrando a Figura 21: uma arquitetura de modo de espera passivo\]](http://docs.aws.amazon.com/pt_br/wellarchitected/2022-03-31/framework/images/warm-standby-architecture.png)
O uso do modo de espera passivo ou luz piloto requer que a escala dos recursos seja aumentada verticalmente na região de recuperação. Para garantir que a capacidade esteja disponível quando necessário, considere o uso de [reservas de capacidade](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-capacity-reservations.html) para instâncias do EC2. Se estiver usando o AWS Lambda, [a concorrência provisionada](https://docs.aws.amazon.com/lambda/latest/dg/provisioned-concurrency.html) poderá garantir que ambientes de execução estejam preparados para responder imediatamente às invocações da sua função.
Para obter mais detalhes sobre esta estratégia, consulte [Arquitetura de recuperação de desastres (DR) na AWS, parte III: luz piloto e modo de espera passivo](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-iii-pilot-light-and-warm-standby/).
**Multissite ativo-ativo**
Você pode executar sua workload simultaneamente em várias regiões como parte de uma *estratégia de* multissite ativo-ativo. O multissite ativo-ativo atende ao tráfego de todas as regiões onde está implantado. Os clientes podem selecionar esta estratégia por outros motivos, além da DR. Ele pode ser usado para aumentar a disponibilidade ou ao implantar uma workload para um público global (para aproximar o endpoint dos usuários e/ou implantar pilhas localizadas para o público nessa região). Como uma estratégia de DR, se a workload não puder ser suportada em uma das Regiões da AWS onde está implantada, esta região será evacuada e as regiões restantes serão usadas para manter a disponibilidade. O multissite ativo-ativo é a estratégia de DR mais complexa operacionalmente e deve ser selecionada apenas quando os requisitos de negócios exigirem.
![\[Diagrama mostrando uma arquitetura de multissite ativo-ativo\]](http://docs.aws.amazon.com/pt_br/wellarchitected/2022-03-31/framework/images/multi-site-active-active-architecture.png)
Para obter mais detalhes sobre esta estratégia, consulte [Arquitetura de recuperação de desastres (DR) na AWS, parte IV: multissite ativo-ativo](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-iv-multi-site-active-active/).
**Práticas adicionais para proteção de dados**
Com todas as estratégias, você também deve atenuar um desastre de dados. A replicação contínua de dados protege você contra alguns tipos de desastre, mas não contra corrupção ou destruição de dados, a menos que sua solução também inclua o versionamento de dados armazenados ou opções para recuperação a um ponto anterior no tempo. Você também deve fazer backup dos dados replicados no local de recuperação para criar backups pontuais além das réplicas.
**O uso de várias zonas de disponibilidade (AZs) em uma única Região da AWS**
Ao utilizar várias AZs em uma única região, sua implementação de DR usa vários elementos das estratégias acima. Primeiro, você deve criar uma arquitetura de alta disponibilidade (HA), usando várias AZs, conforme mostrado na figura 23. Esta arquitetura faz uso de uma abordagem multissite ativo-ativo, já que as [instâncias do Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-regions-availability-zones.html#concepts-availability-zones) e a seção [Elastic Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/how-elastic-load-balancing-works.html#availability-zones) têm recursos implantados em várias AZs, processando solicitações ativamente. A arquitetura também demonstra standby a quente, no qual se a instância primária do [Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Concepts.MultiAZ.html) falhar (ou se a própria AZ falhar), a instância em espera será promovida a primária.
![\[Diagrama mostrando a Figura 23: uma arquitetura multi-A\]](http://docs.aws.amazon.com/pt_br/wellarchitected/2022-03-31/framework/images/multi-az-architecture2.png)
Além da arquitetura de alta disponibilidade, você precisa adicionar backups de todos os dados necessários para executar a workload. Isso é especialmente importante para dados restritos a uma única zona, como [volumes do Amazon EBS](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-volumes.html) ou [clusters do Amazon Redshift](https://docs.aws.amazon.com/redshift/latest/mgmt/working-with-clusters.html). Se uma AZ falhar, você precisará restaurar esses dados para outra AZ. Sempre que possível, você também deve copiar backups de dados para outra Região da AWS, como uma camada adicional de proteção.
Uma alternativa de abordagem menos comum para região única, DR multi-AZ é ilustrada na publicação do blog, [Criação de aplicações altamente resilientes usando o Amazon Route 53 Application Recovery Controller, parte 1: pilha de região única](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/). Aqui, a estratégia é manter o máximo de isolamento possível entre as AZs, assim como as regiões operam. Ao usar esta estratégia alternativa, você pode escolher uma abordagem ativa/ativa ou ativa/passiva.
Observação: algumas workloads têm requisitos regulamentares de residência de dados. Se isso se aplicar à sua workload em uma localidade que atualmente tem apenas uma Região da AWS, a multirregião não atenderá às suas necessidades de negócios. As estratégias multi-AZ fornecem boa proteção contra a maioria dos desastres.
1. **Avalie os recursos da workload e qual será sua configuração na região de recuperação antes do failover (durante a operação normal).**
Para infraestrutura e recursos da AWS, use a infraestrutura como código, como o [AWS CloudFormation](https://aws.amazon.com/cloudformation) ou ferramentas de terceiros como o Hashicorp Terraform. Para implantar em várias contas e regiões com uma única operação, você pode usar o [AWS CloudFormation StackSets](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/what-is-cfnstacksets.html). Para estratégias multissite ativo-ativo e standby a quente, a infraestrutura implantada na região de recuperação tem os mesmos recursos que a região primária. Para as estratégias luz piloto e modo de espera passivo, a infraestrutura implantada exigirá ações adicionais para ficar pronta para produção. Ao usar o CloudFormation [parâmetros](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/parameters-section-structure.html) e [a lógica condicional](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/intrinsic-function-reference-conditions.html), você pode controlar se uma pilha implantada está ativa ou em espera com um único modelo. Um exemplo desse modelo do CloudFormation está incluído [nesta publicação do blog](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-iii-pilot-light-and-warm-standby/).
Todas as estratégias de DR exigem que sejam feitos backup das fontes de dados dentro da Região da AWS e, em seguida, esses backups sejam copiados para a região de recuperação. [AWS Backup](https://aws.amazon.com/backup/) fornece uma visão centralizada na qual você pode configurar, programar e monitorar backups para esses recursos. Para luz piloto, modo de espera passivo e multissite ativo-ativo, você também deve replicar dados da região primária para recursos de dados na região de recuperação, como instâncias de banco de dados do [Amazon Relational Database Service (Amazon RDS)](https://aws.amazon.com/rds) ou tabelas do [Amazon DynamoDB](https://aws.amazon.com/dynamodb) . Esses recursos de dados estão ativos e prontos para atender a solicitações na região de recuperação.
Para saber mais sobre como os serviços da AWS operam entre as regiões, consulte esta série de blogs em [Criação de uma aplicação multirregional com os serviços da AWS](https://aws.amazon.com/blogs/architecture/tag/creating-a-multi-region-application-with-aws-services-series/).
1. **Determine e implemente como deixar sua região de recuperação pronta para failover quando necessário (durante um evento de desastre).**
Para multissite ativo-ativo, failover significa evacuar uma região e confiar nas regiões ativas restantes. No geral, essas regiões estão prontas para aceitar tráfego. Para as estratégias luz piloto e modo de espera passivo, as ações de recuperação precisarão implantar os recursos ausentes, como as instâncias do EC2 na figura 20, além de quaisquer outros recursos ausentes.
Para todas as estratégias acima, pode ser necessário promover instâncias somente leitura de bancos de dados para se tornar a instância primária de leitura/gravação.
Para backup e restauração, a restauração de dados do backup cria recursos para esses dados, como volumes do EBS, instâncias de banco de dados do RDS e tabelas do DynamoDB. Você também precisa restaurar a infraestrutura e implantar o código. É possível usar o AWS Backup para restaurar dados na região de recuperação. Perceber [REL09-BP01 Identificar e fazer backup de todos os dados que precisam de backup ou reproduzir os dados das fontes](rel_backing_up_data_identified_backups_data.md) para obter mais detalhes. A reconstrução da infraestrutura inclui a criação de recursos como instâncias do EC2, além do [Amazon Virtual Private Cloud (Amazon VPC)](https://aws.amazon.com/vpc), sub-redes e grupos de segurança necessários. Você pode automatizar grande parte do processo de restauração. Para saber mais, consulte [nesta publicação do blog](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-ii-backup-and-restore-with-rapid-recovery/).
1. **Determine e implemente como redirecionar o tráfego para failover quando necessário (durante um evento de desastre).**
Essa operação de failover pode ser iniciada automaticamente ou manualmente. O failover iniciado automaticamente com base em verificações de integridade ou alarmes deve ser usado com cautela, pois um failover desnecessário (alarme falso) resulta em custos como indisponibilidade e perda de dados. Portanto, o failover iniciado manualmente é geralmente usado. Nesse caso, você ainda deve automatizar as etapas para failover, para que a inicialização manual seja como apertar um botão.
Há várias opções de gerenciamento de tráfego a serem consideradas ao usar os serviços da AWS. Uma opção é usar o [Amazon Route 53](https://aws.amazon.com/route53). Ao usar o Amazon Route 53, você pode associar vários endpoints de IP em uma ou mais Regiões da AWS a um nome de domínio do Route 53. Para implementar o failover iniciado manualmente, você pode usar o [Amazon Route 53 Application Recovery Controller](https://aws.amazon.com/route53/application-recovery-controller/), que fornece uma API de plano de dados altamente disponível para redirecionar o tráfego para a região de recuperação. Ao implementar o failover, use as operações do plano de dados e evite as do ambiente de gerenciamento, conforme descrito em [REL11-BP04 Confiar no plano de dados e não no ambiente de gerenciamento durante a recuperação](rel_withstand_component_failures_avoid_control_plane.md).
Para saber mais sobre esta e outras opções, consulte [a seção de whitepaper sobre a recuperação de desastres](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/disaster-recovery-options-in-the-cloud.html#pilot-light).
1. **Projete um plano de como a workload retornará.**
Failback é quando você retorna a operação de workload para a região primária, após a redução de um evento de desastre. O provisionamento de infraestrutura e código para a região primária geralmente segue as mesmas etapas que foram usadas inicialmente, contando com a infraestrutura como código e pipelines de implantação de código. O desafio com o failback é restaurar os armazenamentos de dados e garantir sua consistência com a região de recuperação em operação.
No estado de failover, os bancos de dados na região de recuperação estão ativos e têm dados atualizados. O objetivo é ressincronizar da região de recuperação para a região primária, garantindo que ela esteja atualizada.
Alguns serviços da AWS farão isso automaticamente. Se usar [as tabelas globais do Amazon DynamoDB](https://aws.amazon.com/dynamodb/global-tables/), mesmo que a tabela na região primária tenha ficado indisponível, quando ela voltar a ficar online, o DynamoDB retomará a propagação das gravações pendentes. Se usar [o banco de dados global do Amazon Aurora](https://aws.amazon.com/rds/aurora/global-database/) e o [failover planejado e gerenciado](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-global-database-disaster-recovery.html#aurora-global-database-disaster-recovery.managed-failover), a topologia de replicação existente do banco de dados global do Aurora é mantida. Portanto, a antiga instância de leitura/gravação na região primária se tornará uma réplica e receberá atualizações da região de recuperação.
Em casos onde isso não for automático, você precisará restabelecer o banco de dados na região primária como uma réplica do banco de dados na região de recuperação. Em muitos casos, isso envolverá a exclusão do banco de dados primário antigo e a criação de novas réplicas. Por exemplo, para obter instruções sobre como fazer isso com o banco de dados global do Amazon Aurora presumindo um *failover* não planejado, consulte este laboratório: [Retornar um banco de dados global](https://awsauroralabsmy.com/global/failback/).
Após um failover, se você puder continuar executando na região de recuperação, considere torná-la a nova região primária. Você ainda seguiria todas as etapas acima para transformar a antiga região primária em uma região de recuperação. Algumas organizações fazem uma rotação programada, trocando suas regiões primárias e de recuperação periodicamente (por exemplo, a cada três meses).
Todas as etapas necessárias para failover e failback devem ser mantidas em um playbook disponível para todos os membros da equipe e que seja revisado periodicamente.
**Nível de esforço para o plano de implementação**: alto
## Recursos
**Práticas recomendadas relacionadas:**
+ [REL09-BP01 Identificar e fazer backup de todos os dados que precisam de backup ou reproduzir os dados das fontes](rel_backing_up_data_identified_backups_data.md)
+ [REL11-BP04 Confiar no plano de dados e não no ambiente de gerenciamento durante a recuperação](rel_withstand_component_failures_avoid_control_plane.md)
+ [REL13-BP01 Definir os objetivos de recuperação para tempo de inatividade e perda de dados](rel_planning_for_recovery_objective_defined_recovery.md)
**Documentos relacionados:**
+ [Blog de arquitetura da AWS: série de recuperação de desastres](https://aws.amazon.com/blogs/architecture/tag/disaster-recovery-series/)
+ [Recuperação de desastres de workloads na AWS: recuperação na nuvem (whitepaper da AWS)](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/disaster-recovery-workloads-on-aws.html)
+ [Opções de recuperação de desastres na nuvem](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/disaster-recovery-options-in-the-cloud.html)
+ [Crie uma solução de backend ativo-ativo multirregional sem servidor em uma hora](https://read.acloud.guru/building-a-serverless-multi-region-active-active-backend-36f28bed4ecf)
+ [Backend multirregional sem servidor: recarregado](https://medium.com/@adhorn/multi-region-serverless-backend-reloaded-1b887bc615c0)
+ [RDS: replicação de uma réplica de leitura entre regiões](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ReadRepl.html#USER_ReadRepl.XRgn)
+ [Route 53: configuração do failover de DNS](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/dns-failover-configuring.html)
+ [S3: replicação entre regiões](https://docs.aws.amazon.com/AmazonS3/latest/dev/crr.html)
+ [O que é o AWS Backup?](https://docs.aws.amazon.com/aws-backup/latest/devguide/whatisbackup.html)
+ [O que é o Route 53 Application Recovery Controller?](https://docs.aws.amazon.com/r53recovery/latest/dg/what-is-route53-recovery.html)
+ [AWS Elastic Disaster Recovery](https://docs.aws.amazon.com/drs/latest/userguide/what-is-drs.html)
+ [HashiCorp Terraform: Introdução; AWS](https://learn.hashicorp.com/collections/terraform/aws-get-started)
+ [Parceiro do APN: parceiros que podem ajudar com a recuperação de desastres](https://aws.amazon.com/partners/find/results/?keyword=Disaster+Recovery)
+ [AWS Marketplace: produtos que podem ser usados para recuperação de desastres](https://aws.amazon.com/marketplace/search/results?searchTerms=Disaster+recovery)
**Vídeos relacionados:**
+ [Recuperação de desastres de workloads na AWS](https://www.youtube.com/watch?v=cJZw5mrxryA)
+ [AWS re:Invent 2018: Architecture Patterns for Multi-Region Active-Active Applications (ARC209-R2)](https://youtu.be/2e29I3dA8o4)
+ [Introdução ao AWS Elastic Disaster Recovery \$1 Amazon Web Services](https://www.youtube.com/watch?v=GAMUCIJR5as)
**Exemplos relacionados:**
+ [Laboratórios do AWS Well-Architected: recuperação de desastres](https://wellarchitectedlabs.com/reliability/disaster-recovery/) : série de workshops que ilustram as estratégias de DR
# REL13-BP03 Testar a implementação de recuperação de desastres para validá-la
Teste regularmente o failover no site de recuperação para garantir a operação adequada e que o RTO e o RPO sejam atendidos.
Um padrão que deve ser evitado é o desenvolvimento de caminhos de recuperação que raramente são executados. Por exemplo, você pode ter um repositório de dados secundário utilizado para consultas somente leitura. Quando você grava em um repositório de dados e o repositório de dados primário falha, pode ser necessário fazer o failover para o repositório de dados secundário. Se você não testar esse failover com frequência, poderá descobrir que suas suposições sobre as capacidades do armazenamento de dados secundário são incorretas. A capacidade do secundário, que talvez tenha sido suficiente quando testado pela última vez, pode não conseguir mais tolerar a carga neste cenário. Nossa experiência mostrou que a única recuperação de erro que funciona é o caminho que você testa com frequência. É por isso que é melhor ter um pequeno número de caminhos de recuperação. Você pode estabelecer padrões de recuperação e testá-los regularmente. Se você tiver um caminho de recuperação complexo ou crítico, ainda precisará executar regularmente essa falha na produção para garantir o funcionamento desse caminho. No exemplo que acabamos de discutir, você deve realizar o failover para o standby regularmente, não importa a necessidade.
**Antipadrões comuns:**
+ Nunca execute failovers em produção.
**Benefícios do estabelecimento desta prática recomendada:** Teste regularmente seu plano de recuperação de desastres para garantir que ele funcione quando necessário e que sua equipe saiba como executar a estratégia.
**Nível de exposição a riscos quando esta prática recomendada não for estabelecida:** Alto
## Orientações para a implementação
+ Projete suas cargas de trabalho para recuperação. Teste regularmente os caminhos de recuperação. A computação orientada à recuperação identifica as características nos sistemas que aprimoram a recuperação. Essas características são: isolamento e redundância, capacidade de reverter alterações em todo o sistema, capacidade de monitorar e determinar a integridade, capacidade de realizar diagnósticos, recuperação automatizada, design modular e recurso de reinicialização. Pratique o caminho de recuperação para garantir que possa realizá-la no tempo especificado para o estado determinado. Use seus runbooks durante essa recuperação para documentar problemas e encontrar soluções para eles antes do próximo teste.
+ [O projeto de computação orientado por recuperação de Berkeley/Stanford](http://roc.cs.berkeley.edu/)
+ Use o CloudEndure Disaster Recovery para implementar e testar sua estratégia de DR.
+ [Teste da solução de recuperação de desastres com o 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/)
+ [CloudEndure Disaster Recovery para AWS](https://aws.amazon.com/marketplace/pp/B07XQNF22L)
## Recursos
**Documentos relacionados:**
+ [Parceiro do APN: parceiros que podem ajudar com a recuperação de desastres](https://aws.amazon.com/partners/find/results/?keyword=Disaster+Recovery)
+ [Blog de arquitetura da AWS: série de recuperação de desastres](https://aws.amazon.com/blogs/architecture/tag/disaster-recovery-series/)
+ [AWS Marketplace: produtos que podem ser usados para recuperação de desastres](https://aws.amazon.com/marketplace/search/results?searchTerms=Disaster+recovery)
+ [CloudEndure Disaster Recovery](https://aws.amazon.com/cloudendure-disaster-recovery/)
+ [Recuperação de desastres de workloads na AWS: recuperação na nuvem (whitepaper da AWS)](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/disaster-recovery-workloads-on-aws.html)
+ [Teste da solução de recuperação de desastres com o CloudEndure](https://docs.cloudendure.com/Content/Configuring_and_Running_Disaster_Recovery/Testing_the_Distaster_Recovery_Solution/Testing_the_Disaster_Recovery_Solution.htm)
+ [O projeto de computação orientado por recuperação de Berkeley/Stanford](http://roc.cs.berkeley.edu/)
+ [O que é o AWS Fault Injection Simulator?](https://docs.aws.amazon.com/fis/latest/userguide/what-is.html)
**Vídeos relacionados:**
+ [AWS re:Invent 2018: Architecture Patterns for Multi-Region Active-Active Applications (ARC209-R2)](https://youtu.be/2e29I3dA8o4)
+ [AWS re:Invent 2019: Backup-and-restore and disaster-recovery solutions with AWS (STG208)](https://youtu.be/7gNXfo5HZN8)
**Exemplos relacionados:**
+ [Laboratórios do AWS Well-Architected: testes de resiliência](https://wellarchitectedlabs.com/reliability/300_labs/300_testing_for_resiliency_of_ec2_rds_and_s3/)
# REL13-BP04 Gerenciar o desvio de configuração para o local ou a região de DR
Certifique-se de que a infraestrutura, os dados e a configuração estejam conforme necessário no local ou na região de DR. Por exemplo, verifique se as AMIs e as cotas de serviço estão atualizadas.
O AWS Config monitora e registra continuamente as configurações dos recursos da AWS. Ele pode detectar desvios e acionar o [AWS Systems Manager Automation](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html) para corrigi-lo e gerar alarmes. O AWS CloudFormation também pode detectar desvios nas pilhas que você implantou.
**Antipadrões comuns:**
+ Falhar ao atualizar os locais de recuperação, ao fazer alterações de configuração ou infraestrutura nos locais primários.
+ Não considerar possíveis limitações (como diferenças de serviço) nos locais primários e de recuperação.
**Benefícios do estabelecimento desta prática recomendada:** Garantir que o ambiente de DR seja consistente com seu ambiente existente para assegurar a recuperação completa.
**Nível de exposição a riscos quando esta prática recomendada não for estabelecida:** Médio
## Orientações para a implementação
+ Garanta que seus pipelines de entrega enviem para seus locais primário e de backup. Os pipelines de entrega para implantação de aplicativos em produção devem ser distribuídos para todos os locais de estratégia de recuperação de desastres especificados, incluindo os ambientes de desenvolvimento e de teste.
+ Habilite o AWS Config para acompanhar possíveis locais de desvio. Use as regras do AWS Config para criar sistemas que aplicam suas estratégias de recuperação de desastres e geram alertas ao detectar desvios.
+ [Correção de recursos não compatíveis do Regras do AWS Config pela AWS](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)
+ Use o AWS CloudFormation para implantar a infraestrutura. O AWS CloudFormation pode detectar desvios entre as especificações dos modelos do CloudFormation e o que é realmente implantado.
+ [AWS CloudFormation: detectar desvios em uma pilha inteira do CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/detect-drift-stack.html)
## Recursos
**Documentos relacionados:**
+ [Parceiro do APN: parceiros que podem ajudar com a recuperação de desastres](https://aws.amazon.com/partners/find/results/?keyword=Disaster+Recovery)
+ [Blog de arquitetura da AWS: série de recuperação de desastres](https://aws.amazon.com/blogs/architecture/tag/disaster-recovery-series/)
+ [AWS CloudFormation: detectar desvios em uma pilha inteira do CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/detect-drift-stack.html)
+ [AWS Marketplace: produtos que podem ser usados para recuperação de desastres](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)
+ [Recuperação de desastres de workloads na AWS: recuperação na nuvem (whitepaper da AWS)](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/disaster-recovery-workloads-on-aws.html)
+ [Como faço para implementar uma solução de gerenciamento de configuração de infraestrutura na AWS?](https://aws.amazon.com/answers/configuration-management/aws-infrastructure-configuration-management/?ref=wellarchitected)
+ [Correção de recursos não compatíveis do Regras do AWS Config pela AWS](https://docs.aws.amazon.com/config/latest/developerguide/remediation.html)
**Vídeos relacionados:**
+ [AWS re:Invent 2018: Architecture Patterns for Multi-Region Active-Active Applications (ARC209-R2)](https://youtu.be/2e29I3dA8o4)
# REL13-BP05 Automatizar a recuperação
Use ferramentas da AWS ou de terceiros para automatizar a recuperação do sistema e rotear o tráfego para o local ou a região de DR.
Com base em verificações de integridade configuradas, os serviços da AWS, como o Elastic Load Balancing e o AWS Auto Scaling, podem distribuir a carga para zonas de disponibilidade íntegras, enquanto outros serviços, como o Amazon Route 53 e o AWS Global Accelerator, podem rotear a carga para Regiões da AWS íntegras. O Amazon Route 53 Application Recovery Controller ajuda a gerenciar e coordenar o failover usando verificações de prontidão e recursos de controle de roteamento. Esses recursos monitoram continuamente a capacidade da aplicação de se recuperar de falhas, permitindo que você controle a recuperação da aplicação em várias Regiões da AWS, zonas de disponibilidade e ambientes on-premises.
Para workloads em datacenters físicos ou virtuais existentes ou nuvens privadas, o [AWS Elastic Disaster Recovery](https://aws.amazon.com/cloudendure-disaster-recovery/), disponível por meio do AWS Marketplace, permite que as organizações configurem uma estratégia automatizada de recuperação de desastres para a AWS. O CloudEndure também oferece suporte à recuperação de desastres entre regiões e entre AZs na AWS.
**Antipadrões comuns:**
+ A implementação de failover e failback automatizados idênticos pode causar oscilação quando uma falha ocorre.
**Benefícios do estabelecimento dessa prática recomendada:** A recuperação automatizada reduz o tempo de recuperação ao eliminar a oportunidade de erros manuais.
**Nível de exposição a riscos quando esta prática recomendada não for estabelecida:** Médio
## Orientações para a implementação
+ Automatize caminhos de recuperação. No caso de tempos de recuperação curtos, não é possível adotar critério e ação humanos em cenários de alta disponibilidade. O sistema deve recuperar-se automaticamente sob qualquer situação.
+ Use o CloudEndure Disaster Recovery para automatizar failover e failback. Ele replica continuamente suas máquinas (incluindo sistema operacional, configuração de estado do sistema, bancos de dados, aplicações e arquivos) em uma área de preparação de baixo custo na Conta da AWS de destino e na região de preferência. Em caso de desastre, você pode instruir o CloudEndure Disaster Recovery a executar automaticamente milhares de máquinas em seu estado totalmente provisionado em minutos.
+ [Realizar um failover e failback de recuperação de desastres](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/)
## Recursos
**Documentos relacionados:**
+ [Parceiro do APN: parceiros que podem ajudar com a recuperação de desastres](https://aws.amazon.com/partners/find/results/?keyword=Disaster+Recovery)
+ [Blog de arquitetura da AWS: série de recuperação de desastres](https://aws.amazon.com/blogs/architecture/tag/disaster-recovery-series/)
+ [AWS Marketplace: produtos que podem ser usados para recuperação de desastres](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)
+ [CloudEndure Disaster Recovery para AWS](https://aws.amazon.com/marketplace/pp/B07XQNF22L)
+ [Recuperação de desastres de workloads na AWS: recuperação na nuvem (whitepaper da AWS)](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/disaster-recovery-workloads-on-aws.html)
**Vídeos relacionados:**
+ [AWS re:Invent 2018: Architecture Patterns for Multi-Region Active-Active Applications (ARC209-R2)](https://youtu.be/2e29I3dA8o4)