A nuvem tem dono

A palavra nuvem sugere leveza, dispersão e liberdade. Na prática, boa parte da vida digital do planeta repousa sobre uma concentração extraordinária de infraestrutura, capital, cabos, data centers, sistemas de identidade e contratos jurídicos. Quando uma empresa coloca seu aplicativo na AWS, no Azure ou no Google Cloud, ela não está apenas alugando computadores pela internet. Está escolhendo uma cadeia de dependências técnicas e uma jurisdição capaz de influenciar o que pode continuar funcionando. Essa distinção costuma desaparecer enquanto tudo está no ar. O login responde, o banco de dados grava, o atendimento recebe mensagens e o sistema financeiro fecha o dia. A nuvem parece invisível, quase natural. Ela só se torna uma decisão estratégica quando falha, quando o fornecedor muda uma regra ou quando uma ordem jurídica atravessa a fronteira e alcança os dados e serviços de uma empresa brasileira.

A infraestrutura está mais concentrada do que parece

Dados recentes da Synergy Research, repercutidos pela imprensa especializada, colocam AWS, Microsoft Azure e Google Cloud juntos com algo entre 63% e 68% dos gastos globais em infraestrutura de nuvem, dependendo do recorte e do período analisado ^[1][2]. No segundo trimestre de 2026, a estimativa citada pela CRN apontou 28% para a AWS, 20% para o Azure e 15% para o Google Cloud, somando 67% do mercado de infraestrutura corporativa ^[2]. O número não significa que três empresas controlem cada servidor existente. Significa algo mais importante para quem administra uma operação: uma parcela enorme dos serviços digitais depende das mesmas poucas plataformas, direta ou indiretamente. Mesmo quando seu sistema roda em um provedor menor, ele pode usar uma camada de autenticação, um serviço de DNS, uma rede de distribuição de conteúdo, um banco gerenciado ou uma API hospedada por um dos gigantes. A concentração real vive também nas dependências que não aparecem no contrato principal.

Dependência também é uma questão jurídica

A conversa costuma parar no risco de indisponibilidade. Mas uma nuvem também está submetida a leis, sanções, controles de exportação e decisões regulatórias. Em março de 2024, sanções da União Europeia levaram AWS, Microsoft e Google a cortar o acesso de empresas russas a dados e serviços hospedados no Ocidente, segundo a análise publicada pela Exame ^[1]. O ponto não é discutir se a decisão era justificável. O ponto é perceber que o acesso a uma infraestrutura pode ser alterado por uma decisão externa à operação do cliente. A União Europeia, por sua vez, informou em junho de 2026 que avaliava designar AWS e Azure como gatekeepers no âmbito do Digital Markets Act, mesmo que os serviços não atingissem os limiares quantitativos tradicionais. A justificativa preliminar foi que os dois provedores funcionam como portas importantes entre empresas e seus clientes no mercado europeu ^[3]. O regulador está dizendo, em linguagem institucional, que a nuvem deixou de ser apenas uma camada técnica. Ela é uma infraestrutura de passagem para a economia digital.

As três dependências que você precisa enxergar:

• Dependência de execução: onde rodam o aplicativo, os bancos de dados, as filas, os jobs e os serviços que mantêm o produto funcionando.
• Dependência de acesso: quem fornece login, identidade, DNS, certificados, distribuição de conteúdo e as APIs que permitem ao usuário chegar até o sistema.
• Dependência de jurisdição: quais leis, sanções, contratos e decisões regulatórias podem restringir o acesso aos dados ou aos serviços, mesmo que a empresa esteja no Brasil.
• Dependência de recuperação: onde estão os backups, quanto tempo leva para restaurá-los e se eles podem ser usados fora do provedor que sofreu a falha.

Resiliência não é ter uma segunda nuvem no slide da apresentação. É conseguir explicar, com nomes e tempos, como a operação continua quando uma dependência crítica deixa de responder.

- Gabriel Krüger, Arquiteto de Operações com IA

A imagem popular de um apagão é a tela completamente preta. O cenário mais provável é mais confuso e, por isso, mais perigoso: partes da operação continuam vivas enquanto outras deixam de responder. Um aplicativo pode estar rodando em um data center e, mesmo assim, perder o serviço de autenticação. O painel pode abrir, mas não conseguir consultar o banco. O pedido pode ser recebido, mas não chegar à fila de processamento. O atendimento pode existir, mas não acessar o histórico do cliente. A análise da Exame sobre a concentração da nuvem destaca justamente essa camada cotidiana: aplicativos, autenticação, comércio eletrônico, serviços corporativos, plataformas de atendimento e partes das operações financeiras seriam afetados primeiro por uma interrupção ampla ^[1]. O núcleo de liquidação do Pix, operado pelo Banco Central em infraestrutura própria, não depende simplesmente de uma nuvem comercial. Porém, as extremidades da transação, como aplicativos bancários, fintechs, adquirentes e sistemas antifraude, podem depender de serviços externos. Um sistema pode continuar existindo e ainda assim ficar inutilizável para quem precisa acessá-lo.

Essa diferença muda a forma de testar continuidade. Não basta perguntar se o servidor volta. É preciso descobrir se o cliente consegue entrar, se o funcionário consegue identificar o pedido, se o pagamento pode ser confirmado, se o suporte consegue consultar o histórico e se a equipe consegue registrar o que aconteceu durante a interrupção. Disponibilidade técnica é apenas uma parte da disponibilidade do negócio. O mesmo princípio vale para a contingência. Se o serviço principal estiver indisponível, a equipe precisa saber como registrar pedidos, confirmar pagamentos, responder clientes e recuperar o histórico sem esperar a nuvem voltar. A pergunta não é apenas se existe um backup, mas se alguém consegue operar com informação parcial, quais decisões podem ser tomadas manualmente e quais precisam ser suspensas. Continuidade não é manter todas as funções intactas. É preservar as funções que mantêm a empresa viva enquanto o restante é restaurado.

A resposta automática para concentração costuma ser multi-cloud: distribuir cargas entre dois ou mais provedores. É uma estratégia válida, mas não é um amuleto. Duas nuvens podem compartilhar o mesmo serviço de identidade, o mesmo DNS, a mesma empresa de telecomunicações, o mesmo repositório de código ou a mesma equipe sem prática de recuperação. Podem também estar submetidas à mesma jurisdição, como ocorre com os três grandes provedores americanos citados na análise da Exame ^[1]. Além disso, multi-cloud acrescenta complexidade. Ferramentas, permissões, observabilidade, custos, modelos de dados e procedimentos de implantação precisam funcionar em ambientes diferentes. Se a empresa não consegue operar a segunda nuvem sem o primeiro fornecedor, ela não criou independência. Criou uma segunda camada de configuração que pode falhar junto com a primeira. A pergunta correta não é apenas onde hospedar. É qual dependência precisa ser retirada do caminho crítico e qual pode permanecer, desde que seja conhecida, monitorada e testada.

Teste de continuidade para fazer esta semana:

• Liste os cinco serviços que, se pararem, impedem sua empresa de vender, receber, atender ou entregar.
• Desenhe as dependências de cada serviço, incluindo login, DNS, banco de dados, pagamentos, mensageria, arquivos e fornecedores de API.
• Escolha um intervalo de duas horas e defina como você atenderia clientes, registraria pedidos e autorizaria decisões sem cada serviço crítico.
• Restaure um backup em ambiente separado. Backup que nunca foi restaurado é uma promessa, não um plano de recuperação.
• Defina o modo degradado: quais funções podem operar manualmente, quais precisam ser suspensas e quem comunica a situação ao cliente.
• Repita o exercício a cada trimestre e registre o tempo real de recuperação, não o tempo desejado no documento.

A nuvem continuará sendo a escolha mais eficiente para a maioria das empresas. Escala, velocidade e acesso a serviços especializados são vantagens reais. O erro está em transformar conveniência em cegueira. Uma operação madura sabe exatamente quais partes dependem de um provedor, quais podem ser desligadas com segurança, quais precisam de redundância e quais exigem uma alternativa manual. O exercício desta edição não pede que você migre tudo para servidores próprios, contrate três fornecedores ou construa uma arquitetura de guerra. Pede algo mais simples e mais incômodo: escolha cinco serviços críticos e descubra como atenderia por duas horas sem cada um. Ao terminar, você talvez encontre menos fragilidade do que imaginava. Ou encontre o ponto em que seu negócio para antes mesmo de o aplicativo cair. Nos dois casos, agora você tem uma decisão concreta para tomar.