Thiago R. de Souza (*)
Por muito tempo, a discussão sobre multi-cloud foi dominada por um argumento técnico: não colocar todos os ovos na mesma cesta. Distribuir aplicações e serviços entre diferentes provedores permitiria reduzir a dependência de um único fornecedor, explorar os melhores recursos de cada plataforma e aumentar a resiliência da infraestrutura. No Brasil, porém, essa conversa ganhou outras camadas.
Escolher onde uma aplicação roda e por onde seus dados trafegam deixou de ser apenas uma decisão de arquitetura. Hoje, envolve também jurisdição, proteção de dados, exposição financeira e até a distância física entre infraestrutura e usuário. É justamente aí que o debate sobre multi-cloud se encontra com o de soberania de dados. Segundo estimativa da Gartner, até 2026, mais de 75% das empresas usarão múltiplos provedores de nuvem.
Existe uma interpretação simplista de que soberania significa manter todo dado fisicamente dentro das fronteiras brasileiras. Porém, a discussão é mais complexa. Localização importa, especialmente em determinados setores e cargas sensíveis, mas soberania também envolve saber quem controla a informação, quais leis podem alcançá-la, quem pode acessá-la e sob quais regras ela pode circular entre jurisdições. A própria regulamentação brasileira mostra essa evolução. A Resolução CD/ANPD nº 19/2024 estabeleceu mecanismos para a transferência internacional de dados pessoais e detalhou instrumentos como cláusulas-padrão contratuais, normas corporativas globais e decisões de adequação. A regra não determina simplesmente que os dados permaneçam no Brasil, estabelece condições e salvaguardas para que possam atravessar fronteiras preservando o nível de proteção exigido pela legislação brasileira. Isso muda a forma como uma arquitetura de nuvem deve ser desenhada.
Uma empresa pode, por exemplo, manter determinadas cargas e informações mais sensíveis em uma região brasileira enquanto utiliza serviços especializados disponíveis em outra região ou até em outro provedor. Nesse cenário, multi-cloud pode se tornar parte da estratégia de governança: não porque utilizar várias nuvens torne uma empresa automaticamente mais aderente à LGPD, mas porque oferece opções arquiteturais para definir onde cada carga deve estar e como os dados podem circular.
Há ainda uma segunda variável particularmente brasileira: dinheiro. Boa parte da tecnologia utilizada pelas empresas brasileiras está inserida em uma cadeia global de custos. Mesmo quando existe faturamento local ou pagamento em reais, determinados contratos, serviços e estruturas de preço podem carregar exposição direta ou indireta à variação cambial. Quando o dólar sobe, portanto, a infraestrutura pode ficar mais cara sem que a empresa tenha necessariamente aumentado proporcionalmente seu consumo computacional. Para ilustrar o cenário: mais de 70% das empresas brasileiras tiveram aumento nos custos de nuvem em 2024, num período em que o dólar subiu 13%.
É nesse ponto que FinOps e multi-cloud precisam conversar. Distribuir cargas pode ampliar o poder de negociação e permitir comparar alternativas, mas ter dois ou três provedores não significa automaticamente gastar menos. Sem governança, o efeito pode ser exatamente o contrário: mais contratos, mais ferramentas, mais tráfego entre ambientes e uma operação muito mais complexa.
Existe ainda uma terceira variável que nenhum contrato consegue eliminar: a geografia. O Brasil tem dimensões continentais. Para sistemas nos quais milissegundos fazem diferença – aplicações financeiras, plataformas digitais, jogos, streaming, sistemas industriais ou serviços que precisam responder em tempo real -, a localização da infraestrutura influencia diretamente a experiência. Não basta dizer que algo está “na nuvem”, porque a nuvem continua dependendo de data centers, redes, rotas, cabos e distância física.
Uma arquitetura distribuída pode combinar cloud, edge, regiões distintas e diferentes provedores para aproximar processamento e usuários. Mas, novamente, multi-cloud não resolve latência sozinho. Se o desenho for ruim, pode, inclusive, acrescentar novas chamadas entre ambientes e aumentar o tempo de resposta. Esse talvez seja o maior erro na discussão atual: transformar multi-cloud em objetivo quando ela deveria ser consequência de uma necessidade de negócio.
Operar múltiplas nuvens significa lidar com diferentes modelos de identidade e acesso, observabilidade, redes, segurança, cobrança, automação e competências técnicas. Uma empresa que adota três provedores apenas para dizer que não depende de nenhum pode acabar criando três ambientes complexos para administrar. Por isso, antes de decidir quantas nuvens utilizar, a organização deveria responder a perguntas mais importantes: quais cargas realmente precisam permanecer em determinada jurisdição? Quais podem cruzar fronteiras? Quanto custa mover dados entre ambientes? Qual latência é aceitável? Existe equipe capaz de operar essa arquitetura? E, principalmente, qual problema de negócio estamos tentando resolver?
No exterior, multi-cloud muitas vezes nasceu como uma discussão sobre arquitetura e dependência tecnológica. No Brasil, ela inevitavelmente encontra LGPD, câmbio, infraestrutura e uma geografia continental. É justamente por isso que a estratégia de nuvem não deveria terminar no departamento de TI. Quando a localização de uma aplicação pode afetar simultaneamente compliance, custo, disponibilidade e experiência do cliente, decidir onde o dado roda passa a ser também uma decisão do negócio como um todo.
E a sua empresa: sabe responder onde estão os seus dados – e por que estão lá?
(*) Senior Cloud/DevOps Engineer com mais de 9 anos de experiência em infraestrutura corporativa, AWS Community Builder e detentor de múltiplas certificações AWS nos níveis Professional e Specialty.
