Atualização editorial em : atribuições, limites e orientações corrigidos com fontes; a data da publicação original foi preservada.

Ter recursos em dois provedores não basta para demonstrar que uma aplicação resiste à perda de um deles. Antes de contratar uma segunda nuvem, é preciso identificar quais operações continuam dependendo do mesmo serviço e como o usuário será atendido durante a recuperação.

O incidente que motivou a revisão

No relatório da AWS sobre 19 e 20 de outubro de 2025, a empresa atribui a falha inicial do DynamoDB em us-east-1 a uma condição de corrida na automação de DNS. O impacto se propagou a serviços dependentes. A recuperação do DNS não encerrou imediatamente os problemas de criação de instâncias EC2 e de conectividade. Esse é um evento histórico, não um aviso de indisponibilidade atual.

Mapa de dependências antes de escolher multicloud

Este roteiro é uma proposta de análise para uma aplicação, não um teste executado:

  1. Escolha uma operação: por exemplo, consultar um pedido. Desenhe o caminho desde o DNS público até a leitura do banco, incluindo autenticação e obtenção de segredos.
  2. Marque o domínio de falha: região, conta, provedor e serviço compartilhado. Dois servidores não são independentes se ambos precisam da mesma identidade ou descoberta de serviços para atender.
  3. Descreva o comportamento degradado: consulta somente leitura, resposta temporariamente indisponível ou fila. Defina também o que não pode ser feito com dados possivelmente desatualizados.
  4. Estabeleça critérios de recuperação: tempo máximo de interrupção, perda de dados aceitável e responsável pela decisão de alternar o tráfego. Esses valores devem vir do negócio, não de uma promessa genérica de alta disponibilidade.
  5. Planeje o retorno: como reconciliar escritas, evitar executar um pedido duas vezes e encerrar a contingência? Inclua esse trabalho no custo da alternativa.

Compare a segunda nuvem com opções de menor escopo, como eliminar uma dependência compartilhada ou preparar um modo degradado. A decisão só fica sustentada quando cada opção explica qual falha cobre, qual continua descoberta e como isso será verificado em ambiente autorizado.

O caso Railway de maio de 2026 permite examinar outra dependência: a atualização de rotas, mesmo com cargas de trabalho ainda ativas.

Análise baseada em documentação pública. Não houve participação no incidente, teste de failover nem comparação de custos entre provedores. O roteiro não comprova disponibilidade da sua aplicação.