Definir a estratégia de DR - AWS Orientação prescritiva

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á.

Definir a estratégia de DR

Dependendo da importância das aplicações em sua organização para seus negócios, é possível decidir por uma estratégia uniforme para todas as aplicações ou desenvolver uma estratégia de DR mais complexa com base na criticidade de cada aplicação. Sua organização pode tolerar um tempo de inatividade de várias horas antes que todas as aplicações sejam disponibilizadas no site de DR. Nesse caso, você poderá optar por uma estratégia econômica de DR baseada em backup e restauração para todos os bancos de dados. Por outro lado, os negócios de sua organização podem depender da rápida disponibilização de alguns serviços ou aplicações essenciais, com requisitos mais agressivos de RPO e RTO, enquanto outras aplicações podem tolerar necessidades menos rigorosas de RPO e RTO. Nesse caso, será necessário atribuir a estratégia de DR correta para cada nível de aplicações e bancos de dados.

A tabela a seguir descreve quatro opções de DR para workloads executadas no Nuvem AWS para ajudar você a determinar e definir a estratégia de DR da sua organização. O RPO e o RTO documentados nesta tabela referem-se a uma pilha completa que inclui componentes de aplicação e de banco de dados. Para obter mais informações, consulte Opções de recuperação de desastres na nuvem na Documentação do AWS Well-Architected Framework. A próxima seção aborda as opções de RPO e RTO que são específicas para bancos de dados.

Opção de recuperação RPO RTO Tarefas de infraestrutura na região de DR Custo
Backup e restauração Horas Menos de 24 horas

Provisione todos os recursos de aplicações necessários na região de DR e restaure o banco de dados a partir de um snapshot copiado.

Baixo
Luz piloto Dezenas de minutos Dezenas de minutos

Provisione uma cópia da sua infraestrutura de aplicações e desative os recursos na pilha de aplicações.

Replique seus dados de uma região para outra. Mantenha os bancos de dados sempre ativos e sincronizados com os bancos de dados primários. Provisione os recursos sob demanda durante o evento de failover e teste.

Também é necessário implantar alterações na infraestrutura e nas aplicações nas duas regiões simultaneamente. É possível simplificar isso por meio da criação pipelines de automação que podem sincronizar código e infraestrutura nas regiões primária e de DR.

Médio
Standby morno Minutos Minutos

Provisione uma cópia de toda a infraestrutura de aplicações na região de DR, mas mantenha a cópia reduzida em comparação com a região principal. A região de DR poderá aceitar tráfego em um volume menor em comparação com a região primária.

Alto
Vários sites ou ativo/ativo Perto de zero Zero ou quase zero

Provisione uma cópia completa da infraestrutura na região de DR. Todos os recursos na região de DR serão equivalentes aos recursos da região principal e poderão atender ao tráfego na mesma escala da região principal. Como não há interrupção no fluxo de tráfego, essa opção não exige uma tarefa de failover como parte do plano de DR.

Mais alto