Resiliência entre Regiões: preparar antes do incidente

Uma arquitetura mostra sua maturidade não apenas na forma como atende o tráfego em um dia normal, mas na quantidade de trabalho que já foi feita antes de um incidente. Foi essa a transição que fizemos na segunda parte da apresentação no AWS Summit São Paulo: sair da conversa sobre eficiência operacional e levar a mentalidade automation-first para a continuidade entre Regiões.

Este texto complementa Do crescimento à eficiência: uma jornada com Aurora Serverless. Lá, contei como isolamento por domínio, elasticidade e automação ajudaram a tornar a operação cotidiana mais sustentável. Aqui, o foco é outro: como preparar dados e aplicação para ativar, escalar e validar um ambiente existente, em vez de tentar reconstruir tudo quando o tempo já é o recurso mais escasso.

Não há uma arquitetura única de recuperação que sirva para todos. Há requisitos de negócio, risco aceitável, contratos, dados e decisões de operação. O que relato é uma maneira de estruturar esse raciocínio: separar proteção de dados de continuidade de serviço, preparar componentes críticos antes do incidente e manter clara a fronteira entre decisão humana e execução automatizada.

TL;DR

• Backup continua essencial, mas warm standby reduz o trabalho que precisaria começar depois de uma indisponibilidade.
• Aurora Global Database, DynamoDB Global Tables e uma camada de aplicação previamente preparada formam uma base regional já existente.
• O fluxo crítico deixa de ser reconstruir e passa a ser acionar o plano, promover, adequar capacidade, redirecionar tráfego e validar.
• Pessoas decidem quando acionar o plano; a automação executa passos repetíveis e auditáveis.

Backup protege o dado; warm standby protege o tempo

É fácil tratar backup e warm standby como alternativas. Não são. Backup é uma camada indispensável de proteção e recuperação de dados. Ele permite restaurar informação quando necessário, mas pode exigir uma sequência longa de reconstrução antes que um ambiente volte a atender tráfego.

Warm standby parte de outra pergunta: o que precisa já existir antes de uma indisponibilidade para reduzir o caminho crítico da recuperação? A resposta não é “deixar uma segunda produção completa e ociosa”. É decidir quais dados precisam estar replicados, quais componentes de aplicação precisam estar implantados e qual capacidade mínima faz sentido para que a ativação comece de uma posição preparada.

Essa diferença muda a linguagem da operação. Em vez de pensar em criar infraestrutura sob pressão, passamos a pensar em promover, ajustar capacidade, escalar serviços e validar o comportamento ponta a ponta. Cada etapa continua exigindo cuidado, mas deixa de depender de reconstruir a base inteira no pior momento possível.

A mesma disciplina aplicada a outra classe de risco

Na primeira parte da jornada, aprendemos que escala pede decisões repetíveis: limites de capacidade observados, automações governadas e separação de responsabilidades. Para a resiliência entre Regiões, o princípio permaneceu o mesmo. Não se trata de escolher serviços porque eles soam sofisticados; trata-se de preparar uma sequência operacional coerente com o objetivo de continuidade.

No lado relacional, Aurora Global Database ajuda a manter uma cópia regional preparada para o momento em que a estratégia de recuperação precisar ser acionada. No lado não relacional, DynamoDB Global Tables disponibiliza a réplica local que a aplicação usará na Região secundária. Na camada de aplicação, um ambiente previamente implantado fica preparado em warm standby para ser ativado e ganhar capacidade quando necessário.

O desenho importa porque não há um único “botão de failover” que resolva tudo. Dados relacionais e não relacionais têm comportamentos próprios; a aplicação precisa estar pronta para apontar aos componentes adequados; o tráfego e a validação formam parte do mesmo processo. A arquitetura precisa expor essas dependências para que o time consiga raciocinar sobre elas com clareza.

Acionar, promover, adequar capacidade, redirecionar e validar

Em um cenário de indisponibilidade, a ordem das ações é parte da solução. Em nível conceitual, ela começa com a decisão de acionar o plano e confirmar a condição do incidente. Depois, promovemos os componentes necessários, adequamos a capacidade do ambiente e redirecionamos o tráfego de maneira controlada. Por fim, validamos os fluxos críticos ponta a ponta antes de tratar a recuperação como concluída.

Esses passos parecem simples, mas evitam um erro comum: considerar a promoção de um componente como se ela significasse recuperação completa. Um banco disponível sem capacidade adequada, uma aplicação em pé sem dependências verificadas ou um tráfego redirecionado sem validação podem criar uma falsa sensação de conclusão.

Por isso, o warm standby não é apenas um desenho de infraestrutura. É um compromisso operacional. Ele precisa de procedimentos que descrevam as transições, de observabilidade que permita verificar o estado de cada camada e de exercícios que encontrem lacunas antes de uma situação real. A meta não é automatizar uma narrativa bonita; é reduzir incerteza quando ela tem maior custo.

Pessoas decidem; automação executa

Uma das escolhas mais importantes dessa abordagem é não automatizar a decisão de negócio de forma opaca. Um incidente regional envolve contexto: extensão do impacto, segurança, comunicação, prioridades de clientes e avaliação do risco de cada mudança. Esse julgamento pertence às pessoas responsáveis pelo serviço.

Depois da decisão, a automação tem um papel muito claro. Ela executa os passos repetíveis, aplica mudanças previstas, registra ações, reduz variações manuais e oferece um caminho de auditoria. É a mesma ideia que usei para o autosserviço de capacidade: autonomia não significa ausência de controle; significa que a operação tem guardrails e um processo conhecido.

Essa separação também melhora o pós-incidente. Quando decisão e execução estão distinguíveis, fica mais fácil revisar o que foi observado, por que o plano foi acionado, quais automações foram executadas e onde houve necessidade de intervenção. A aprendizagem deixa de depender apenas da memória de uma sala de crise e pode voltar para os procedimentos e as ferramentas.

Continuidade é valor de negócio, não só disponibilidade

É comum falar de resiliência em termos estritamente técnicos. Para mim, ela se conecta diretamente ao negócio: reduzir o tempo de recuperação, preservar a confiança de quem depende da plataforma e permitir que times operem uma situação crítica com mais previsibilidade.

Uma base regional preparada ajuda a manter essa conversa honesta. Ela não elimina risco, não substitui backup e não transforma um incidente em uma rotina trivial. O que ela faz é trocar parte da improvisação por preparação. Ao ter dados replicados, aplicação previamente implantada e passos claros de ativação, a organização ganha mais opções para responder sem partir do zero.

Foi essa ligação entre engenharia e continuidade que quis levar ao AWS Summit. Meu papel, na prática, fica no encontro entre dados, operação e decisão arquitetural: traduzir necessidades de resiliência em componentes observáveis, processos exercitáveis e escolhas que façam sentido para quem precisa manter o serviço funcionando.

O que fica da jornada

Eficiência e resiliência nascem da mesma disciplina: observar, preparar processos repetíveis e manter a automação sob governança. Não esperamos o incidente para descobrir o que precisa existir; preparamos dados, aplicação, capacidade, observabilidade e decisões antes dele. Pessoas decidem; automação executa.

Para o contexto de eficiência operacional que sustenta essa estratégia, leia Do crescimento à eficiência: uma jornada com Aurora Serverless.