Porque interrupções não avisam quando chegam.
RPO e RTO definidos como requisito de negócio, implementados em uma das quatro estratégias de DR da AWS e testados periodicamente.
Quase toda empresa tem backup. Poucas sabem quanto tempo levaria para voltar a operar, e menos ainda testaram. A diferença entre backup e disaster recovery é essa: backup é uma cópia dos dados; DR é a capacidade comprovada de retomar a operação dentro de um prazo que o negócio aceita. Sem teste, você não tem DR — tem uma expectativa.
Tudo começa por dois números que são decisão de negócio, não de TI. O RPO (Recovery Point Objective) define quanto dado você aceita perder, medido em tempo. O RTO (Recovery Time Objective) define quanto tempo você aceita ficar fora do ar. Esses dois números determinam a arquitetura e o custo. A AWS recomenda definir um número pequeno de classes de RPO e RTO e encaixar as aplicações nelas, em vez de negociar caso a caso.
A AWS organiza DR em quatro estratégias, do menor para o maior custo e complexidade: backup e restauração; pilot light, com RPO em minutos e RTO em dezenas de minutos; warm standby, com RPO em segundos e RTO em minutos; e multi-site ativo/ativo. Um detalhe técnico que muda resultado: a AWS divide seus serviços em data plane e control plane, e recomenda usar apenas operações de data plane no procedimento de failover, porque o data plane tem meta de disponibilidade maior que o control plane.
Se você reconhece dois ou mais destes cenários, vale conversar.
Diagnóstico inicial sem custo
A composição exata depende do seu ambiente e dos requisitos levantados no diagnóstico. Esta é a base do que usamos nesta solução.
Ponto central para configurar, agendar e monitorar backup de EBS, EC2, RDS, Aurora, DynamoDB, EFS, Storage Gateway e famílias FSx, com cópia entre contas e entre regiões
Replicação contínua com recuperação em uma região secundária, base das estratégias pilot light e warm standby
Replicação assíncrona e contínua de objetos para a região de DR
Proteção contra exclusão e alteração indevida — mitigação direta para erro humano e ransomware
Infraestrutura como código, sem a qual reconstruir o ambiente na região de DR se torna lento e sujeito a erro
Redirecionamento de tráfego no failover com health checks e políticas de roteamento
Validação contínua se o ambiente realmente atende às metas de RTO e RPO declaradas
Automação de restaurações periódicas e de testes de recuperação
Retenção imutável, impedindo que backups sejam apagados mesmo por credencial privilegiada
Mapeamos as aplicações e definimos classes de RPO e RTO junto com as áreas de negócio. Nem tudo precisa de warm standby, e pagar por isso em todo o portfólio é desperdício.
Comparamos o RPO e RTO que o ambiente atual entrega com o que o negócio exige. A diferença entre os dois é o escopo real do projeto.
Atribuímos a cada classe uma das quatro estratégias AWS, equilibrando custo e risco. Sistemas de faturamento e um portal interno raramente merecem a mesma arquitetura.
Configuramos políticas de backup, replicação e o procedimento de failover. Onde é possível, usamos apenas operações de data plane no caminho crítico da recuperação.
Executamos o failover em ambiente controlado e medimos o RTO e RPO reais. Este é o passo que a maioria dos projetos pula e é justamente o que transforma plano em capacidade.
Estabelecemos calendário de testes e documentamos o procedimento de volta à região primária. Ambiente de DR sem teste periódico acumula desvio de configuração até deixar de funcionar.
Tempo real de retomada apurado em teste, não o número estimado em planilha
Perda de dados efetiva verificada no exercício de recuperação
Percentual de recursos críticos sob política ativa e verificada
Restaurações bem-sucedidas sobre o total tentado nos testes
Referências de mercado documentadas pela própria AWS em cenários equivalentes. Cada card leva à história original publicada no site da AWS.
O processo de failover manual da solução legada de identificação, mantida on-premises, deixava funcionários sem acesso aos sistemas por até 30 minutos. A empresa reconstruiu o mecanismo de failover com Amazon CloudWatch.
Resultado publicado
A AWS publicou a redução do tempo de failover de 30 minutos para 3 minutos.
No mesmo programa de migração apoiado pelo AWS MAP, a empresa tratou disaster recovery como parte do escopo, e não como projeto posterior.
Resultado publicado
Conforme a AWS, houve melhoria nas capacidades de segurança e de disaster recovery.
Os cases acima são histórias de clientes publicadas pela Amazon Web Services. Os resultados citados pertencem às empresas mencionadas e servem como referência do que é tecnicamente alcançável na AWS — não representam resultados entregues pela Núvoli nem garantia de desempenho equivalente, já que cada ambiente tem contexto próprio.
Nossa abordagem não é opinião. Segue prescrição documentada pela AWS — e você pode conferir a fonte.
O primeiro passo é um diagnóstico do cenário atual, sem custo e sem compromisso. Saímos dele com riscos mapeados e prioridades definidas — mesmo que você decida não seguir com a Núvoli.
