As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.
# Introdução
Sua carga de trabalho deve desempenhar a função pretendida de forma correta e consistente. Para conseguir isso, você deve arquitetar a *resiliência.* Resiliência é a capacidade de uma carga de trabalho se recuperar de interrupções na infraestrutura, nos serviços ou nos aplicativos, adquirir dinamicamente recursos de computação para atender à demanda e mitigar interrupções, como configurações incorretas ou problemas transitórios de rede.
A recuperação de desastres (DR) é uma parte importante de sua estratégia de resiliência e diz respeito à forma como sua carga de trabalho responde quando ocorre um desastre (um [desastre](what-is-a-disaster.md) é um evento que causa um sério impacto negativo em seus negócios). Essa resposta deve ser baseada nos objetivos de negócios de sua organização, que especificam a estratégia de sua carga de trabalho para evitar a perda de dados, conhecida como [Objetivo de Ponto de Recuperação (RPO)](business-continuity-plan-bcp.md#recovery-objectives-rto-and-rpo), e reduzir o tempo de inatividade quando sua carga de trabalho não está disponível para uso, conhecida como [Objetivo de Tempo de Recuperação](business-continuity-plan-bcp.md#recovery-objectives-rto-and-rpo) (RTO). Portanto, você deve implementar resiliência no design de suas cargas de trabalho na nuvem para atender aos seus objetivos de recuperação ([RPO e RTO](business-continuity-plan-bcp.md#recovery-objectives-rto-and-rpo)) para um determinado evento de desastre único. Essa abordagem ajuda sua organização a manter a continuidade dos negócios como parte do [Planejamento de Continuidade de Negócios (BCP)](business-continuity-plan-bcp.md).
Este paper se concentra em como planejar, projetar e implementar arquiteturas AWS que atendam aos objetivos de recuperação de desastres da sua empresa. As informações compartilhadas aqui são destinadas a pessoas em funções de tecnologia, como diretores de tecnologia (CTOs), arquitetos, desenvolvedores, membros da equipe de operações e pessoas encarregadas de avaliar e mitigar riscos.
## Recuperação e disponibilidade de desastres
A recuperação de desastres pode ser comparada à *disponibilidade*, que é outro componente importante da sua estratégia de resiliência. Enquanto a recuperação de desastres mede os objetivos para eventos únicos, os objetivos de disponibilidade medem os valores médios em um período de tempo.
![\[Imagem mostrando os objetivos de resiliência para recuperação de desastres (RTO, RPO) e disponibilidade (MTBF, MTTR).\]](http://docs.aws.amazon.com/pt_br/whitepapers/latest/disaster-recovery-workloads-on-aws/images/resiliency-objectives.png)
*Figura 1 - Objetivos de resiliência*
A disponibilidade é calculada usando o tempo médio entre falhas (MTBF) e o tempo médio de recuperação (MTTR):
![\[Disponibilidade é igual ao tempo disponível para uso dividido pelo tempo total igual ao MTBF dividido pelo MTBF mais MTTR.\]](http://docs.aws.amazon.com/pt_br/whitepapers/latest/disaster-recovery-workloads-on-aws/images/availability-calculation-time-based.png)
Essa abordagem geralmente é chamada de “nove”, em que uma meta de disponibilidade de 99,9% é chamada de “três noves”.
Para sua carga de trabalho, pode ser mais fácil contar solicitações bem-sucedidas e malsucedidas em vez de usar uma abordagem baseada em tempo. Nesse caso, o seguinte cálculo pode ser usado:
![\[Disponibilidade é igual a respostas bem-sucedidas divididas por solicitações válidas.\]](http://docs.aws.amazon.com/pt_br/whitepapers/latest/disaster-recovery-workloads-on-aws/images/availability-calculation-successful-failed-requests.png)
A recuperação de desastres se concentra em eventos de desastre, enquanto a disponibilidade se concentra em interrupções mais comuns de menor escala, como falhas de componentes, problemas de rede, bugs de software e picos de carga. O objetivo da recuperação de desastres é a continuidade dos negócios, enquanto a disponibilidade diz respeito à maximização do tempo em que uma carga de trabalho está disponível para realizar a funcionalidade comercial pretendida. Ambos devem fazer parte da sua estratégia de resiliência.
## Você é Well-Architected?
O [AWS Well-Architected Framework](https://aws.amazon.com/architecture/well-architected/) ajuda você a entender os prós e os contras das decisões que você toma ao criar sistemas na nuvem. Os seis pilares do framework permitem a você conhecer as melhores práticas de arquitetura para criar e operar sistemas confiáveis, seguros, econômicos e sustentáveis na nuvem. Usando a [AWS Well-Architected Tool](https://aws.amazon.com/well-architected-tool/), disponível gratuitamente no [AWS Management Console](https://console.aws.amazon.com/wellarchitected), você pode analisar suas cargas de trabalho em relação a essas melhores práticas respondendo a um conjunto de perguntas para cada pilar.
Os conceitos abordados neste whitepaper expandem as melhores práticas contidas no [whitepaper do Pilar de Confiabilidade](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/welcome.html), especificamente na pergunta [REL 13](https://docs.aws.amazon.com/wellarchitected/latest/framework/a-failure-management.html), “Como você planeja a recuperação de desastres (DR)?”. Depois de implementar as práticas neste whitepaper, certifique-se de revisar (ou revisar novamente) sua carga de trabalho usando o AWS Well-Architected Tool.