Multi-cloud te deixa menos resiliente, não mais (e dá para provar na conta)

🇺🇸 Also available in English: Multi-cloud makes you less resilient, not more

Depois de todo apagão grande de cloud, ele volta. E quase sempre chega pelo mesmo caminho: um C-level que almoçou com um fornecedor, ouviu que a solução mágica existe, e entra na reunião com a frase pronta. "Precisamos ir para multi-cloud, aí se a AWS cair a gente continua de pé na Google." A sala inteira balança a cabeça. Parece óbvio. Dois fornecedores, o dobro de segurança, certo?

Errado. E sim, isso é opinião minha. Só que a minha vem com a conta aberta.

E se você acha que é implicância minha, guarda um nome: Snap. A dona do Snapchat, aquele app de visualização curta, assinou com as duas maiores clouds do planeta. Bilhões de dólares em contrato, a palavra "REDUNDÂNCIA" em letras garrafais e carimbada no documento do IPO, advogado revisando, o mercado inteiro aplaudindo, e a diretoria lendo aquilo e pensando "tá vendo, agora sim, assim é que se faz". Tudo nos conformes, certo? Pois bem: em outubro de 2025 ela caiu junto com o resto da internet, igualzinho a uma startup de três pessoas rodando numa região só. O porquê está escrito pela própria Snap, na seção de risco dos relatórios que ela manda para o mercado, e eu volto nisso lá na frente.

A intuição que engana no multi-cloud: redundância em paralelo

Antes da conta, vamos combinar o que os números querem dizer, porque disponibilidade é fácil de citar e chato de traduzir.

Quando alguém fala em 99,9% de disponibilidade, está dizendo que o sistema pode ficar fora do ar umas 8 horas e 46 minutos por ano. É um número bem realista para uma aplicação bem feita rodando numa cloud só.

Agora a mágica que todo mundo faz de cabeça na reunião. Se um sistema fica fora 0,1% do tempo, e eu tenho DOIS sistemas independentes, a chance dos dois estarem fora no mesmo instante é minúscula. É a lógica das duas lanternas na gaveta: a chance de as duas queimarem exatamente no mesmo segundo é muito menor do que a de uma queimar. Basta uma acender e você enxerga.

Na teoria da confiabilidade isso tem nome, redundância em paralelo, e a conta é essa:

Paralelo (a intuição):  1 - (0,001 x 0,001) = 99,9999%

Seis noves. Uns 30 segundos de downtime por ano. É lindo, e a matemática está certíssima, pode conferir. A conta não mente. Ela só responde uma pergunta bem específica: qual é a disponibilidade de dois sistemas suficientes, independentes e realmente paralelos? Guarda essas três palavras, porque é nelas que o projeto multi-cloud costuma desmontar.

O detalhe que precisa entrar na conta: o que está em série

Só que, para o "basta uma funcionar" sair do slide e virar realidade, alguém precisa decidir qual cloud atende cada request, alguém precisa manter os dados coerentes dos dois lados, e alguém precisa dizer quem é o usuário nos dois lados. Esses "alguéns" não são funcionários dedicados: são camadas novas, que VOCÊ constrói, opera e mantém de pé.

Volta para as lanternas por um segundo. Elas são independentes de verdade: você acende uma, a outra fica na gaveta, e nenhuma depende da outra para funcionar. Agora imagina que, para as duas lanternas servirem de par, você precisou ligar as duas num mesmo interruptor, com um fio que decide qual acende. Adivinha o que acontece se o interruptor queimar? Você fica no escuro com duas lanternas boas na mão.

O interruptor é a dependência que o slide não mostra. E ela quase nunca vem sozinha.

Essas camadas entram em série com o serviço, série no sentido do circuito mesmo, uma peça depois da outra no caminho do request. E componente em série faz o oposto do paralelo: ele multiplica a disponibilidade para baixo.

Imagina um desenho em que o roteamento global, a consistência síncrona entre as duas clouds e uma identidade compartilhada precisam funcionar para o request ser concluído. Se cada peça entrega 99,9%, a conta fica assim:

Série (neste desenho):  0,999  (roteamento global de tráfego)
                      x 0,999  (consistência síncrona cross-cloud)
                      x 0,999  (identidade compartilhada)
                      = 99,7%   <- pior que uma cloud sozinha

Sacou a ironia? Você gastou uma fortuna para colocar duas clouds em paralelo e terminou em 99,7% por causa do que ficou em série. Cada peça que você adicionou para "ganhar resiliência" virou um novo single point of failure. Se uma peça do caminho crítico entrega 99,9%, esse vira o teto do sistema inteiro, não importa quão boas sejam as duas clouds embaixo.

Agora, sendo justo com a conta, porque eu prefiro te dar a munição antes que você a use contra mim. Os 99,9% de cada peça são um número ilustrativo, escolhido para a ideia ficar visível; o seu desenho pode ter peças melhores, piores ou fora do request path. E olha a ressalva mais importante: se a replicação for assíncrona, ela sai dessa conta. A cloud A confirma a escrita e manda a cópia para a B logo depois, então, quando a replicação quebra, o serviço continua no ar e o estrago vai todo para o dado. O problema muda de lugar e vira RPO, que é papo lá na frente.

Ou seja, a conta não prova que todo multi-cloud é menos disponível. Ela prova uma coisa mais modesta e mais incômoda: a segunda cloud não apaga a cola que faz as duas trabalharem como um serviço só, e essa cola tem disponibilidade própria.

Tem também um jeito de tirar peça da série, e ele tem nome: static stability, que a própria AWS documenta na Builders' Library. A ideia é que o sistema continue servindo mesmo quando o control plane (a peça que decide as coisas) morre. Na prática: os dois lados já ficam ativos e recebendo tráfego, com capacidade pré-provisionada dos dois lados, e o health check apenas tira um endpoint doente do balanceamento em vez de precisar "ligar" o lado que estava dormindo. Se a orquestração de failover cair, o tráfego continua fluindo pelo que está de pé.

Quer dizer, um arquiteto bom consegue, sim, tirar peças da série, e deveria tentar. Só que static stability de verdade custa caro, porque exige capacidade ociosa pré-provisionada dos dois lados, o tempo todo. Você tira a peça da conta de disponibilidade e ela reaparece na conta de custo, agora dobrada, porque são duas clouds ociosas em vez de uma.

Não tem almoço grátis. Tem cardápio, e alguém sempre paga.

O número exato varia com o seu projeto. A direção é o que importa: cada dependência que você adiciona ao caminho crítico multiplica a disponibilidade para baixo. O roteamento é a mais teimosa delas, porque alguém sempre precisa escolher o destino do request, mas mesmo ela dá para distribuir, cachear e deixar statically stable. A pergunta que resolve é uma só: se essa camada parar de decidir agora, o tráfego que já está funcionando continua fluindo? Some a isso a complexidade operacional de manter tudo de pé e você entende por que a promessa dos seis noves nunca chega.

Independência é ficção

Tem um detalhe ainda mais fundo. A conta do paralelo só vale se as duas falhas forem independentes. E quase nunca são.

Pensa em dois navios porta-contêineres gigantes navegando lado a lado, ligados por uma ponte. É essa a imagem que te vendem: se um afundar, o outro segue viagem com a sua carga. Bonito. Só que os dois navios têm o mesmo capitão, e é ele que decide a rota. Se o capitão erra o mapa, os dois vão para o mesmo banco de areia, juntinhos. E a ponte, que existe só para manter a carga dos dois idêntica, é a parte mais cara e mais frágil da história: ela balança em toda tempestade, cobra pedágio nos dois sentidos e, no dia em que cai, você não fica com dois navios iguais. Fica com dois navios diferentes, cada um com uma carga, e ninguém a bordo sabe qual das duas é a verdadeira.

As duas clouds compartilham dependências que você nem lembra que existem: o mesmo DNS, a mesma autoridade certificadora do seu TLS, o mesmo provedor de identidade, e, principalmente, o mesmo pipeline de deploy. Adivinha o que acontece quando o time empurra uma config errada? Ela vai para as duas clouds ao mesmo tempo.

E olha o tamanho desse buraco: o Uptime Institute estima, com base em 25 anos de dados, que erro humano tem algum papel em algo entre dois terços e quatro quintos de todos os outages. Repara na palavra que eles escolheram, porque ela é honesta: "algum papel". Erro humano raramente aparece como causa raiz sozinho, ele é o fio que atravessa o incidente. E o pedaço mais teimoso é sempre o mesmo: gente não seguindo o procedimento, ou o procedimento já nascendo ruim. Adivinha o quanto trocar de fornecedor ajuda nisso? Nada.

E aí mora a piada: se tem uma coisa que a cultura DevOps entregou com maestria nesses anos todos, é a capacidade de propagar besteira em segundos, com pipeline verde, aprovação de dois reviewers e um emoji de foguete no canal. Automatizamos tudo, inclusive o erro. Só que agora, com duas clouds, ele chega nos dois lugares ao mesmo tempo e você paga em dobro pelo privilégio. Deploy é a coisa mais confiável da sua stack, e é justamente por isso que ele leva a config errada aos dois destinos sem falhar nenhuma vez.

Falha correlacionada quebra a premissa de independência, e sem independência a conta do paralelo simplesmente não existe.

O preço escondido: o menor denominador comum

Para rodar de verdade em AWS e Google ao mesmo tempo, em active-active, você precisa de tudo portável entre as duas. Aí você abre mão dos managed services que são a parte mais resiliente da cloud (DynamoDB, S3, SQS, testados em escala absurda) e cai no que roda em qualquer lugar: Kubernetes e um monte de open source que VOCÊ instala, opera e mantém de pé.

E olha que esse dilema não é abstrato, eu já destrinchei um caso dele. No post de data streaming na AWS, a escolha entre Kinesis e MSK é exatamente essa: o nativo que casa com o resto da casa contra o Kafka que roda em qualquer lugar. Lá a portabilidade é uma escolha legítima, feita de olhos abertos, num serviço só, porque o time já vive de Kafka. Aqui no active-active ela deixa de ser escolha e vira imposição, de uma vez, em cima da stack inteira.

E aqui vai uma pergunta desconfortável, sem desmerecer ninguém: a sua equipe opera esse stack com mais confiabilidade do que a AWS opera o DynamoDB? O time que segura esses managed services em escala global é enorme, dedicado e faz só isso há mais de uma década. Apostar que o seu time, dividido entre mil prioridades, entrega mais uptime na unha do que eles entregam gerenciado é uma aposta e tanto. Longe de julgar a competência de ninguém, é só o paralelo de quem está na arena contra quem fez disso a vida inteira.

Você trocou resiliência gerenciada por resiliência que virou o seu celular tocando às 3 da manhã. Como o Werner Vogels martela, "everything fails, all the time". Então a pergunta que importa vira outra: quem está de plantão quando falhar? O multi-cloud active-active coloca você nesse plantão, em dobro. E repara que não basta ter alguém que saiba AWS de um lado e alguém que saiba Google Cloud do outro. Alguém precisa dominar justamente a cola entre as duas, aquela peça que só existe dentro da sua empresa, que não tem botão de suporte, não tem tutorial pronto e não tem ninguém no Stack Overflow que já passou por isso. Plantão custa, e esse plantão custa mais ainda. É uma linha gorda na conta que raramente aparece no business case.

E o custo? Você paga para o dado sair, dos dois lados

Tem um item que a planilha do projeto costuma ignorar: egress. A cloud cobra barato (ou de graça) para o dado entrar, e cobra para o dado sair. Num active-active de verdade, você vive sincronizando dados entre AWS e Google para manter as duas pontas iguais, então paga data transfer out dos dois lados, o tempo todo, só para manter as cópias coerentes. É uma torneira aberta, todo mês, para sempre.

Já ouço a objeção: "mas o egress ficou de graça em 2024". Cuidado com essa. O que AWS, Google e Microsoft passaram a zerar naquele ano, empurrados pelo EU Data Act, é o egress de quem está indo embora da cloud, e mesmo assim com regra: conta em bom estado, levar tudo, avisar o suporte e fechar as subscriptions dentro do prazo. Isso é um subsídio de divórcio, não de casamento aberto. A replicação contínua entre duas clouds, que é justo o que o active-active exige, continua passando no caixa todo mês.

E soma o resto: você duplica os managed services, duplica a stack de observability, duplica a superfície de security e compliance, e precisa de um time com profundidade nas duas clouds. O custo não dobra, ele faz mais que dobrar, porque a cola que integra as duas é um centro de custo por si só.

O Werner Vogels resume isso no Frugal Architect: custo é requisito de arquitetura, e quem só descobre o número na fatura descobriu tarde demais. Multi-cloud quase sempre reprova nesse teste, você paga uma conta contínua e gorda por um seguro contra um evento que quase nunca acontece.

E deixa eu confessar uma coisa. Toda vez que esse slide aparece numa reunião, tem um arquiteto em algum canto da sala com vontade de deitar em posição fetal embaixo da mesa (assim como eu). Enquanto todo mundo comemora a decisão corajosa, ele está fazendo a conta de cabeça e vendo o tanto de dinheiro que vai ser queimado para comprar proteção contra um evento raro, dinheiro esse que resolveria, sei lá, a multi-região que a empresa adia há dois anos. Se você é essa pessoa, respira: esse post é o teu argumento por escrito, com a conta na mão. E se você é quem está aprovando o projeto, olha de novo para os números lá de cima antes de assinar.

E antes que alguém feche a aba com raiva: calma, eu não estou dizendo que multi-cloud nunca presta. Existe hora em que ele é a resposta certa, e eu tenho uma seção inteira sobre isso mais para o fim. Só que essa hora tem nome, tem contexto e quase nunca é "resiliência". Segura a emoção que a gente chega lá.

O que o multi-cloud protege, e que quase nunca acontece

Pensa nos apagões reais que você viu. Foram regionais, zonais ou de um serviço específico (o us-east-1 de outubro de 2025 foi exatamente isso). Quase nunca é "a AWS global inteira morreu". Quem ficou fora do ar naquele dia estava preso a uma única região, e o que teria segurado a maioria era multi-região na mesma cloud, não uma segunda nuvem. Multi-AZ e multi-região dentro da MESMA cloud cobrem a esmagadora maioria dos casos, com uma fração da complexidade. E olha que nem sou eu dizendo: a própria orientação de multi-region da AWS recomenda confirmar que os seus objetivos não cabem dentro de uma região só antes de partir para várias.

Então vamos fazer a lição de casa antes de desenhar duas clouds no quadro: Multi-AZ resolve? Multi-região resolve? Ou a gente está fazendo overengineering para comprar uma sensação de segurança? Quanto custa cada um desses degraus, e por que essa conta é decisão de negócio antes de ser de tecnologia, eu abri no post sobre o custo da alta disponibilidade. Se o requisito cabe dentro de uma cloud, botar um segundo fornecedor não é maturidade automática. Às vezes é só complexidade usando roupa social.

Isso tem nome de pattern: Bulkhead e cell-based architecture, isolar o blast radius dentro do próprio fornecedor, em compartimentos que não afundam juntos. O multi-cloud te protege contra o evento raríssimo (o provedor inteiro sumir do mapa) e, em troca, te expõe a uma porção de falhas comuns que você mesmo introduziu.

E antes que eu te venda multi-região como bala de prata, a letra miúda: naquele mesmo apagão, muita arquitetura multi-região caiu junto, porque dependia de control plane global (IAM, STS) ou tinha uma dependência escondida em us-east-1 que ninguém tinha mapeado. Isso não é teoria: o post-event summary da própria AWS registra que o STS engasgou, e que quem usava federação de identidade apontando para signin.aws.amazon.com tomou erro no console em outras regiões também. Remédio nenhum vem sem bula. A diferença é que a bula da multi-região cabe num parágrafo e a do multi-cloud active-active é um projeto de dois anos.

O caso Snap: multi-cloud no papel, tombo na prática

Prometi voltar na Snap, então vamos lá.

Ela fez exatamente o que todo board sonha: assinou com as duas. Google Cloud como principal, e no S-1 do IPO em 2017 apareceu um compromisso de um bilhão de dólares com a AWS, com a frase que todo executivo adora ler, "for redundant infrastructure support of our business operations". Multi-cloud de livro, as duas maiores nuvens do planeta na mesma fatura.

Aí, em 20 de outubro de 2025, o us-east-1 da AWS engasgou. E o Snapchat caiu junto com o resto da internet.

E o resto da história está escrito pela própria Snap. Ano após ano, na seção de risco dos relatórios que ela manda para o mercado, aparece o aviso de que os sistemas dela não são totalmente redundantes. Repara na data: esse alerta já estava lá muito antes do tombo, na mesma pilha de papel em que o contrato bilionário dizia "redundant". Ninguém escreveu aquilo depois, para se explicar. A redundância existia no contrato e no slide do investidor. No caminho crítico da aplicação, não.

Esse é o soco do argumento, e ele vale para qualquer empresa, não só para a Snap: duas clouds na fatura não te dão duas clouds na arquitetura. Se o caminho crítico depende de uma região que caiu, o contrato com o outro fornecedor guardado na gaveta não levanta o seu serviço. E se nem uma empresa desse tamanho, com bilhões alocados e times de elite, transformou dois contratos em redundância real, vale a pergunta desconfortável: por que o seu projeto transformaria?

Mas e se eu já tiver o failover pronto para a outra cloud?

Aqui o leitor atento levanta a mão: "beleza, mas se a cloud A cair e eu tiver o DR pronto para virar na B, o multi-cloud me salvou, não?". Pode salvar, sim. E repara que esse cenário é active-passive (uma cloud quente, a outra de prontidão), não o active-active que a conta lá em cima destrói. São coisas diferentes, e essa é a versão legítima da história.

Só que três pegadinhas derrubam o "eu tenho o failover" na prática.

A primeira: ter o failover não é o mesmo que o failover funcionar. O caminho de DR é o trecho menos testado do seu sistema, e você só aciona ele no pior momento, sob pressão. DR que nunca foi exercitado é backup de Schrödinger, você descobre se presta na hora que precisa. É o filme clássico do DR não testado: na hora de virar a chave, a capacidade não está provisionada do outro lado, os secrets estão dessincronizados, o IAM é diferente. O plano existia, o failover não veio.

A segunda: o failover demora e você perde dado no caminho. Replicação síncrona entre duas clouds (aquela em que a escrita só é confirmada depois que chegou nos dois lados) é cara e lenta demais, então na prática todo mundo usa assíncrona: a cloud A confirma a escrita para o usuário e manda a cópia para a B logo depois, com um atraso de alguns segundos.

Repara no buraco que isso abre. Se a A cai justo naquele intervalo, tudo que ela confirmou e ainda não tinha copiado para a B some. O pedido que o cliente viu na tela, o pagamento que apareceu como aprovado, simplesmente não existe do outro lado. Esse é o tal do RPO (Recovery Point Objective), o quanto de dado você aceita perder, medido em tempo. E tem o RTO (Recovery Time Objective), o tempo até o serviço voltar, que no cross-cloud vai de minutos a horas: subir o lado passivo, propagar DNS, esquentar cache. Não é apertar um botão.

A terceira: para o apagão que de fato acontece, multi-região na mesma cloud entrega o mesmo DR sem a dor cross-cloud. O us-east-1 caiu, não a AWS global. Um Warm Standby ou um Pilot Light em outra região da mesma cloud te levanta com os managed services nativos, o mesmo IAM e a mesma tooling (a AWS documenta as quatro estratégias, com os RTOs e os custos de cada uma, no whitepaper de Disaster Recovery). No cross-cloud você joga tudo isso fora para se proteger de um evento bem mais raro.

Ou seja: failover cross-cloud pode existir e até funcionar, mas é caro, frágil quando não é testado, e quase sempre perde para multi-região na mesma cloud no tipo de apagão que realmente bate na porta.

Então multi-cloud nunca presta?

Presta. Só que quase nunca por resiliência técnica, e é aqui que a maioria erra o argumento. Multi-cloud se justifica por motivos de negócio:

• Soberania de dados e regulação: a lei manda o dado morar em tal nuvem ou país.

• Alavanca contra vendor lock-in: poder de barganha comercial (o uptime nem entra nessa conta).

• SaaS que precisa rodar onde o cliente exige.

• DR exigido por compliance, às vezes existindo só no papel para passar na auditoria, não porque a arquitetura faz failover de verdade.

E repare que, quando vale, quase sempre é active-passive (uma cloud quente, outra fria só para disaster recovery), não o active-active que detona a sua disponibilidade. A decisão é de negócio e risco, registrada num ADR, sem nenhuma promessa de nove extra.

Já que a gente chegou até aqui, deixa eu cravar a minha posição, e ela é uma opinião, não um teorema. Toda decisão de arquitetura tem dois lados, e a pergunta que resolve essa aqui não é técnica: qual é a sua dor de verdade e quanto ela custa se acontecer? Se a resposta vem do regulador, do contrato ou da soberania de dado, multi-cloud entra, geralmente active-passive, e o ROI justifica a complexidade. Fora disso, para mim, active-active dói no peito: você compra dois navios, uma ponte, um plantão em dobro e um capitão sobrecarregado para se proteger de um evento que provavelmente não vem, enquanto a multi-região que resolveria o seu caso real segue esperando budget. Resiliência não é o que você compra. É o que você decide, e depois sustenta.

Esse é o coração do post sobre o custo da alta disponibilidade: resiliência começa numa decisão estratégica, e o stack vem depois, como consequência. Multi-cloud é o jeito mais caro que existe de inverter essa ordem.

O que você leva

• A conta do paralelo (99,9999%) só vale para sistemas suficientes, independentes e realmente paralelos. Roteamento global, consistência síncrona e identidade compartilhada entram em série e derrubam o número para baixo do que uma cloud só entrega.

• Replicação assíncrona sai da conta de uptime e reaparece no RPO: o serviço continua de pé e engole as últimas escritas.

• Falha correlacionada (config, deploy, DNS, CA) quebra a premissa de independência que a conta exige.

• Active-active força o menor denominador comum: você troca managed service maduro por stack que vira o seu plantão.

• O custo não dobra, faz mais que dobrar: egress dos dois lados para sincronizar dados, infra duplicada e time com profundidade em duas clouds.

• Multi-AZ e multi-região na mesma cloud (Bulkhead, cells) resolvem o caso real com uma fração da complexidade.

• Multi-cloud vale por negócio (regulatório, lock-in), não por resiliência. E aí é active-passive, documentado num ADR.

Pergunta sincera para você: já foi obrigado a um projeto de multi-cloud "por resiliência" e descobriu na prática que ganhou dois plantões no lugar de um? Conta aí como foi. E se você discorda, melhor ainda, joga a sua conta de disponibilidade nos comentários que eu quero ver onde a minha fura. Manda aquele joinha, compartilha com quem está prestes a aprovar esse projeto, e bora trocar ideia. Valeu demais! BUILD. SCALE. REPEAT. =D

Para ir mais fundo

As fontes que valem a sua próxima meia hora (as outras estão linkadas ao longo do texto, no ponto onde importam):

• Static stability using Availability Zones, na Amazon Builders' Library. A fonte do conceito que tira o control plane do caminho do request, com a separação control plane x data plane explicada por quem construiu o EC2.

• Disaster recovery options in the cloud, do whitepaper de DR da AWS. Pilot Light, Warm Standby e a nota que explica a diferença entre os dois. É a alternativa que resolve o seu caso real sem cross-cloud.

• Post-event summary do apagão de outubro de 2025, pela própria AWS. A race condition no DNS do DynamoDB e o efeito cascata: a fonte primária do caso que abre este post.

• The Frugal Architect, do Werner Vogels. A lei I é "Make Cost a Non-functional Requirement", e é o teste que o multi-cloud reprova.

• Resiliência em arquitetura: a decisão é estratégica, não apenas técnica, aqui do blog. O pillar deste post: o custo dos noves, RTO/RPO e ADRs.