Sua região primária está degradada e o negócio quer fazer failover. Me explique como você conduziria.

Confirme o escopo da degradação e se o failover é genuinamente mais rápido que esperar, porque failover não é de graça e quedas parciais às vezes se recuperam antes. Consiga uma decisão explícita de um dono, e então siga o runbook: promova a réplica aceitando a perda de dados conhecida, mova o tráfego na camada de DNS ou de roteamento, verifique com requisições reais e comunique. Planeje o retorno deliberadamente depois, quando a primária estiver estável.

A primeira coisa é que fazer failover é uma decisão, não um reflexo. Eu quero saber o escopo, se é um serviço ou a região inteira, e o que o provedor está dizendo, porque se a estimativa é quinze minutos então um failover que leva trinta e perde dados é a pior opção. Então eu levo essa avaliação ao comandante do incidente ou ao dono do negócio e ele toma a decisão explicitamente, porque ninguém deveria estar aceitando perda de dados unilateralmente às três da manhã. Feita a decisão, eu sigo o runbook em vez de improvisar. Promovo a réplica na região secundária, sabendo que a gente está aceitando o atraso de replicação que existia no momento da falha, e eu anoto esse número para a conciliação depois. Movo o tráfego na camada de roteamento, e aqui eu confiro se os health checks e os tempos de vida dos registros são curtos o bastante para mover rápido, porque um registro cacheado por muito tempo faz isso demorar muito mais do que o esperado. Depois verifico com requisições reais em vez de com um dashboard. E o retorno é uma mudança planejada própria em horário comercial, nunca um segundo failover às pressas.