Multicloud não é resiliência: o que os apagões de AWS, Azure e Cloudflare ensinaram sobre continuidade

O apagão que ninguém queria ver chegar

Nos últimos meses o mercado assistiu a uma sequência de panes nos maiores provedores de nuvem do planeta. Amazon Web Services (AWS), Microsoft Azure e Cloudflare, cada um a seu tempo, deixaram serviços fora do ar e arrastaram consigo uma quantidade impressionante de empresas que dependiam deles sem sequer perceber. No Brasil, banco, varejo, logística e serviço público sentiram o baque em cascata, muitas vezes sem entender de imediato o que havia acontecido, porque o problema não estava dentro de casa, estava lá longe, num data center de outro continente.

O que mais me chama atenção nesses episódios não é a falha técnica em si. Sistemas complexos falham, isso é fato conhecido de qualquer um que trabalhe com tecnologia há tempo suficiente. O que chama atenção é o nível de surpresa e despreparo das organizações afetadas. Muita gente descobriu, no pior momento possível, que sua arquitetura tinha um ponto único de falha camuflado de resiliência, e que o plano de continuidade guardado na gaveta não previa exatamente o cenário que estava acontecendo na tela.

Depois de anos trabalhando com governança e gestão de riscos em organizações brasileiras, aprendi que crise revela verdade. E a verdade que esses apagões revelaram é desconfortável: boa parte do que chamamos de resiliência é retórica. Neste artigo quero destrinchar por que multicloud, sozinho, não resolve nada, o que separa redundância real de redundância de papel, e por que continuidade deixou de ser documento de auditoria para se tornar requisito de arquitetura e de governança.

Por que a nuvem virou risco sistêmico

Existe um paradoxo na adoção massiva de nuvem pública. Quanto mais empresas migram para os mesmos poucos provedores, mais eficiente e barata a operação fica, e ao mesmo tempo mais frágil o ecossistema como um todo se torna. A concentração de mercado em três ou quatro gigantes significa que uma falha em um único serviço de infraestrutura, um sistema de DNS, um mecanismo de autenticação, uma região inteira, pode derrubar simultaneamente milhares de empresas que não têm relação alguma entre si.

Isso é a definição de risco sistêmico. Não estamos mais falando de um problema isolado de uma empresa, estamos falando de um problema que atinge setores inteiros da economia ao mesmo tempo. Quando a AWS teve instabilidade em uma de suas regiões principais, o efeito foi sentido em aplicativos de mobilidade, plataformas de streaming, sistemas bancários e serviços corporativos, tudo junto. A dependência compartilhada transforma a falha de um fornecedor em um evento de mercado.

Para quem responde por governança, essa é uma mudança de natureza do risco que precisa ser compreendida. O risco de terceiros, que antes tratávamos de forma pontual em contratos e due diligence, hoje é um risco de infraestrutura crítica que a organização não controla e mal enxerga. E o mais perigoso é que esse risco costuma ficar invisível justamente porque tudo funciona bem na esmagadora maioria dos dias. A raridade do evento cria uma falsa sensação de segurança que se dissolve em minutos quando o apagão acontece.

Multicloud não é sinônimo de resiliência

Aqui está o equívoco mais comum que vejo em conversas com times de tecnologia e com a alta gestão. A ideia de que ter contrato com dois ou três provedores de nuvem, por si só, garante continuidade. Isso é falso e perigoso. Ter presença em múltiplas nuvens não significa que sua aplicação continua funcionando quando uma delas cai. Significa apenas que você tem faturas de mais de um fornecedor.

Multicloud sem arquitetura de failover real é o que chamo de redundância de papel. A empresa contrata dois provedores, roda a produção inteira em um deles e mantém o outro para um projeto isolado ou para uma eventual negociação comercial futura. Quando o provedor principal cai, o segundo não assume carga nenhuma, porque nunca foi projetado para isso. Não há replicação de dados em tempo hábil, não há redirecionamento automático de tráfego, não há paridade de configuração entre os ambientes. O segundo provedor está lá de enfeite.

Pior ainda são as dependências ocultas. Muitas arquiteturas ditas multicloud dependem de um único serviço compartilhado que amarra tudo: um provedor de DNS, uma solução de gerenciamento de identidade, um gateway de conteúdo. Quando esse elo compartilhado falha, e foi mais ou menos isso que aconteceu em alguns dos apagões recentes, não importa em quantas nuvens sua aplicação roda. O ponto único de falha estava fora do escopo que você achava que tinha coberto. Resiliência de verdade exige mapear essas dependências transversais, não apenas somar contratos de fornecedores.

A diferença entre redundância real e redundância de papel

Redundância real custa dinheiro, exige disciplina de engenharia e impõe complexidade operacional. Redundância de papel custa uma linha no relatório de riscos e dá a sensação confortável de que o problema está resolvido. A diferença entre as duas só aparece no dia do apagão, e nesse dia é tarde demais para descobrir de que lado você estava.

Para entender se sua redundância é real, vale examinar de forma honesta alguns pontos concretos da sua operação. Vou usar aqui uma das poucas listas deste texto justamente porque a clareza ajuda:

• Seus dados estão replicados em tempo real ou quase real para um ambiente independente, ou você depende de backups que levam horas para restaurar?
• O ambiente secundário roda a mesma versão de aplicação e configuração que o primário, ou existe uma defasagem que só será descoberta na hora do estresse?
• O redirecionamento de tráfego para o ambiente alternativo é automático e testado, ou depende de alguém executar um procedimento manual sob pressão em plena madrugada?
• Você já executou um teste real de failover em produção, ou toda a sua confiança vem de um diagrama bonito e de uma reunião de arquitetura?
• As dependências externas críticas, como DNS e autenticação, também têm alternativa, ou são pontos únicos disfarçados?

Se as respostas honestas tendem para o lado pessimista dessas perguntas, você tem redundância de papel. E não há vergonha nisso, a maioria das organizações está nesse estágio. A vergonha estaria em saber disso e não fazer nada. O primeiro passo para construir resiliência real é abandonar a ilusão de que já a possuímos.

O custo invisível da falsa continuidade

Existe um custo perverso na continuidade que só existe no papel, e ele é psicológico antes de ser financeiro. Quando a liderança acredita que a empresa está protegida, ela para de investir, para de testar e para de questionar. O plano de continuidade vira um documento morto que se atualiza uma vez por ano para satisfazer a auditoria e depois volta para a gaveta. A falsa segurança é mais perigosa que a insegurança reconhecida, porque desliga o instinto de precaução.

No contexto brasileiro, esse custo se agrava por uma característica cultural que observo com frequência: a tendência a tratar continuidade como despesa e não como investimento. Em ambientes de orçamento apertado, e temos muitos, o ambiente redundante é o primeiro item a ser cortado, porque parece que não gera valor. Ele não gera valor nenhum, até o dia em que gera todo o valor do mundo. A dificuldade de justificar esse gasto para quem controla o caixa é um dos grandes desafios de quem trabalha com risco.

Quando o apagão finalmente chega, o custo invisível se torna dolorosamente visível. Receita perdida durante horas de indisponibilidade, contratos com cláusulas de nível de serviço acionadas por clientes, danos à reputação que levam meses para se recuperar, e o custo humano de uma equipe operando em pânico sem procedimento claro. Some tudo isso e compare com o valor do ambiente redundante que foi cortado do orçamento. A conta quase sempre mostra que a economia foi ilusória.

SLA não é garantia de disponibilidade

Muita gente confunde Acordo de Nível de Serviço (SLA) com garantia de que o serviço vai funcionar. Não é isso. Um SLA é um compromisso comercial que define o que o fornecedor considera aceitável e o que ele deve pagar caso não cumpra. A famosa promessa de disponibilidade de vários noves não significa que o serviço nunca vai cair, significa que, se cair além de certo limite, você recebe um crédito na próxima fatura. Esse crédito raramente cobre o prejuízo real do seu negócio.

O que vejo com frequência é a empresa se apoiar no SLA do provedor como se fosse a sua própria estratégia de continuidade. Isso é terceirizar a responsabilidade por algo que continua sendo seu. O provedor cumpre o contrato dele, paga o crédito devido, e você fica com o cliente irritado, a receita perdida e a reputação arranhada. O SLA transfere um pouco de dinheiro, mas não transfere o risco de negócio. Esse permanece integralmente com você.

Ao negociar contratos de nuvem, é preciso ler o SLA com olhos de gestor de risco, não de comprador. Quais eventos estão excluídos da cobertura? Como a indisponibilidade é medida e por quem? O crédito é automático ou depende de você abrir um chamado e provar o prejuízo dentro de um prazo curto? E, mais importante, o SLA cobre o serviço específico que é crítico para você, ou apenas a infraestrutura geral? Nos apagões recentes, muitos dos serviços que falharam estavam tecnicamente dentro dos limites contratuais, o que deixou clientes sem qualquer compensação e sem qualquer serviço.

Desenhando arquitetura que sobrevive ao próximo apagão

Continuidade de verdade nasce no desenho da arquitetura, não no plano de resposta. Isso muda tudo, porque significa que decisões tomadas por engenheiros e arquitetos, muitas vezes sem participação da governança, determinam a resiliência do negócio inteiro. O princípio fundamental é assumir que qualquer componente pode falhar a qualquer momento, e projetar para que essa falha não derrube o todo. É a mentalidade de projetar para a falha, e não contra ela.

Na prática, isso envolve isolar domínios de falha, garantir que a queda de uma região ou de um provedor não se propague, e construir mecanismos de degradação graciosa. Um sistema resiliente não precisa funcionar perfeitamente durante o apagão, ele precisa continuar funcionando de forma reduzida. É melhor operar com funcionalidades limitadas do que ficar completamente fora do ar. Essa distinção, entre falha total e degradação controlada, é o que separa a empresa que perde algumas vendas da empresa que sai nos jornais.

Também é preciso repensar o dogma de que tudo deve estar na nuvem pública. Para algumas cargas críticas, uma arquitetura híbrida, com parte da capacidade em ambiente próprio ou em provedor independente, oferece um isolamento que o multicloud dentro do mesmo ecossistema não oferece. Não estou pregando volta ao passado, estou defendendo diversidade genuína de infraestrutura. A monocult

Perguntas frequentes

O que é multicloud e por que empresas brasileiras adotam essa estratégia?
Multicloud é a prática de usar dois ou mais provedores de nuvem simultaneamente para evitar dependência de um único fornecedor. Empresas brasileiras adotam essa abordagem buscando reduzir riscos de indisponibilidade, aproveitar melhores preços entre provedores e atender exigências de conformidade regulatória. Porém, ter múltiplas nuvens não elimina automaticamente os riscos de continuidade de negócio.

Multicloud realmente garante resiliência nos negócios?
Não necessariamente. Os apagões recentes da AWS, Azure e Cloudflare mostraram que mesmo com múltiplos provedores, empresas sofreram interrupções em cascata porque suas aplicações dependiam de serviços específicos desses fornecedores. Multicloud é apenas uma camada da estratégia de resiliência, não a solução completa. É preciso redesenhar arquiteturas, processos e planos de contingência para garantir continuidade real.

Quais foram os principais impactos dos apagões recentes nas empresas brasileiras?
As indisponibilidades da AWS, Azure e Cloudflare causaram perdas financeiras significativas, interrupção de operações críticas, degradação de serviços aos clientes e danos à reputação de instituições financeiras, e-commerce e startups. Muitas empresas descobriram que seus planos de recuperação eram ineficazes ou inexistentes quando enfrentaram falhas reais. O custo da inação se mostrou muito maior que o investimento em resiliência adequada.

Como implementar uma verdadeira estratégia de continuidade além de multicloud?
Uma estratégia robusta combina multicloud com redundância geográfica, backup distribuído, failover automático, testes regulares de recuperação e documentação atualizada. É essencial diversificar não apenas provedores, mas também arquiteturas, sistemas de cache, DNS e bancos de dados. Empresas devem investir em automação para detectar falhas e recuperar serviços em minutos, não em horas.

Qual é o impacto financeiro de uma interrupção de serviço para uma empresa?
O custo varia conforme o setor, tamanho e duração da falha, mas pesquisas indicam perdas de R$ 10 mil a R$ 1 milhão por minuto em instituições financeiras e e-commerce. Além do faturamento perdido, há custos com comunicação crise, reputação abalada, multas regulatórias e retenção de clientes. Um plano de continuidade bem estruturado se paga rapidamente após a primeira falha evitada.

Como medir o nível de resiliência da infraestrutura de TI?
As métricas principais são RTO (Recovery Time Objective), quanto tempo leva para restaurar um serviço, e RPO (Recovery Point Objective), quanto tempo de dados você tolera perder. Outras indicadores incluem disponibilidade medida em percentuais (99,9 por cento, 99,99 por cento), frequência de testes de recuperação e tempo de resposta a incidentes. É essencial estabelecer metas realistas por serviço e monitorá-las continuamente.

Quais setores brasileiros foram mais afetados pelos apagões de nuvem?
Instituições financeiras, plataformas de pagamento, e-commerce e startups de tecnologia sofreram impactos mais severos porque dependem fortemente de disponibilidade contínua. Empresas de telecom, saúde digital e governo também registraram perturbações em serviços essenciais. O denominador comum foi a falta de planos de contingência adequados ou arquiteturas que não contemplavam falhas totais de provedores.

Quanto custa implementar uma estratégia completa de continuidade?
Os investimentos variam entre 5 a 15 por cento do orçamento anual de TI, dependendo do nível de resiliência desejado e da criticidade dos serviços. Inclui custos de infraestrutura redundante, licenças de software de recuperação, testes regulares, pessoal especializado e seguros. Para empresas críticas, o retorno positivo ocorre rapidamente, pois o custo de uma falha geralmente supera em muito o investimento preventivo.

Como testar planos de continuidade sem interromper operações?
Existem testes não disruptivos como simulações de mesa, testes em ambientes clonados durante madrugadas ou fins de semana, e failover automático para data centers secundários sem impacto ao usuário final. Empresas experientes fazem testes mensais de componentes críticos e trimestrais de sistemas completos. A automação e as ferramentas de orquestração modernas permitem validar planos com risco mínimo.

Qual deve ser a governança para garantir continuidade em ambientes multicloud?
A governança requer definir políticas claras sobre quais serviços podem usar quais provedores, estabelecer SLAs diferenciados por criticidade, auditar configurações regularmente e manter inventário atualizado de dependências entre sistemas. É fundamental designar responsáveis por continuidade, documentar planos com fluxos de decisão, definir comunicação de crise e treinar equipes com frequência. Revisões trimestrais garantem que a estratégia acompanhe mudanças tecnológicas e de negócio.

A GovSimplix incorpora a Continuidade de Negócios como domínio integrante do seu modelo de governança, conectando o planejamento de continuidade à estrutura de riscos, controles e processos críticos da organização, com visibilidade executiva e rastreabilidade para auditorias internas e externas.

Sobre o autor

Julio César
Fundador e Arquiteto das Soluções, GovSimplix

Julio César é bacharel em Ciências da Computação pela USTJ e graduado em Análise e Desenvolvimento de Sistemas. É especialista pós-graduado em Cibersegurança e Governança de Dados pela PUC Minas e pós-graduado em Gestão Estratégica de Negócios pela Universidade Presbiteriana Mackenzie.

Possui certificação internacional de Lead Auditor para as normas ISO 27001 (Segurança da Informação), ISO 27701 (Privacidade da Informação) e ISO 42001 (Gestão de Inteligência Artificial), além da certificação Lean Six Sigma Black Belt, voltada para melhoria de processos e redução de variabilidade operacional.

Na GovSimplix, é o responsável pela concepção e evolução da arquitetura metodológica que estrutura os 11 domínios de governança empresarial da plataforma. Combina formação técnica, experiência em auditoria de sistemas de gestão e visão executiva para traduzir a complexidade da governança em estrutura operável para organizações de qualquer porte e setor.