Cloud é sempre mais caro que servidor próprio no longo prazo?

Não sempre, mas fica mais caro quando o workload é previsível e roda 24/7 — é aí que o custo variável da nuvem pública perde pro custo fixo de hardware próprio. Cargas com pico sazonal ou imprevisível continuam favorecendo cloud, porque pagar só pelo pico é mais barato que manter capacidade ociosa o ano inteiro.

A LGPD exige que o dado da minha empresa fique armazenado no Brasil?

Não. A LGPD se aplica a qualquer empresa que processa dado de pessoa no território nacional, esteja o servidor aqui ou fora — a lei fala de jurisdição sobre o tratamento, não de localização física obrigatória. Existe um projeto de lei (PL 4723/20) discutindo exigir armazenamento em território nacional, mas ele não é a lei vigente. Quem decide manter dado sensível local está resolvendo controle e auditoria, não uma obrigação legal que já existe.

O que é cloud repatriation?

É o movimento de trazer de volta pra infraestrutura própria (ou nuvem privada) uma carga que já estava rodando em nuvem pública. Não é abandonar cloud — na prática, a maioria das empresas que faz isso mantém parte do ambiente na nuvem pública e move só o pedaço que ficou caro, sensível ou difícil de controlar.

Minha empresa é pequena, vale a pena ter servidor próprio?

Só se o volume de uso já justificar o investimento fixo — hardware, energia, refrigeração, alguém responsável por manter no ar. Abaixo de um certo volume, o custo fixo de operar infraestrutura própria supera qualquer economia de sair da nuvem. A conta muda quando a operação já tem volume estável e previsível o suficiente pra virar custo fixo que compensa.

Arquitetura híbrida não é só complicar o ambiente sem necessidade?

É complicar, sim — só que às vezes o problema real já é complicado, e a solução simples demais (tudo numa nuvem só, ou tudo local) é que ignora isso. Híbrido faz sentido quando existe uma linha clara separando o que precisa de controle direto do que precisa de elasticidade, e alguém mantém essa linha com critério — não quando vira mistura sem dono.

Quem decide isso dentro da empresa, o time de TI ou a diretoria?

Os dois, mas em papéis diferentes. TI (interna ou terceirizada) sabe o comportamento técnico de cada workload. A decisão de onde colocar o quê — o que é sensível o bastante pra justificar controle direto, o que pode aceitar risco de terceiro pela elasticidade — é decisão de negócio, que precisa de alguém com mandato executivo pra bater o martelo e prestar contas por ela depois.

Cloud pra escalar, local pra dado sensível: como decidir sem dogma

Sua empresa decidiu ir de cloud, ou só seguiu a maioria? Essa pergunta importa mais agora do que importava cinco anos atrás, porque a maioria mudou de ideia.

Segundo a pesquisa trimestral de CIOs do Barclays (4º trimestre de 2024), 86% dos CIOs entrevistados já planejavam mover algum workload da nuvem pública de volta pra ambiente privado ou local — o maior número da série histórica da pesquisa, contra 43% no fim de 2020. A IDC, no mesmo período, encontrou algo parecido: cerca de 80% das organizações esperavam repatriar parte de computação ou armazenamento nos 12 meses seguintes. Quase ninguém está saindo de cloud por completo — só 8% planejavam saída total —, mas a maioria está reconsiderando pedaço por pedaço.

O caso que virou referência: como a 37signals economizou saindo da nuvem

A 37signals (empresa por trás do Basecamp e do Hey) publicou em detalhe, no próprio blog, sua saída da AWS e do Google Cloud. O primeiro “ano limpo” fora da nuvem gerou cerca de US$ 2 milhões de economia, depois de um investimento único de aproximadamente US$ 700 mil em servidores Dell — valor recuperado no próprio primeiro ano. A projeção pública da empresa é economizar entre US$ 7 milhões e US$ 10 milhões ao longo de cinco anos.

Isso não vira regra universal — a 37signals tinha um workload específico (aplicações web com tráfego previsível, rodando há anos, com equipe técnica capaz de operar hardware próprio) que favorece essa conta. O ponto não é “saia da cloud”. É que o caso mais citado do setor prova que a suposição “cloud é sempre mais barato no longo prazo” não é universal — depende de que carga está rodando e há quanto tempo.

Por que “cloud ou local” virou pergunta errada

A pergunta certa nunca foi binária. É “qual workload, com qual perfil de uso, com qual exigência de controle”. Tratando a decisão como escolha única pra empresa inteira, dois erros se repetem:

O primeiro é colocar tudo em nuvem pública achando que resolve escala — inclusive dado que não tem pico de uso nenhum, que roda estável o ano inteiro, e que teria custo previsível e menor rodando em infraestrutura própria. O segundo é o oposto: manter tudo local por reflexo de segurança, inclusive workload com pico sazonal forte, onde pagar só pela demanda de pico sairia mais barato que manter capacidade ociosa o resto do ano.

Nenhum dos dois é decisão de arquitetura. É decisão de dogma — “a gente sempre fez assim” ou “todo mundo está migrando pra cloud” — aplicada sem checar se o workload específico se encaixa.

Cloud pública vs infraestrutura local, por característica do workload

Característica do workload	Favorece nuvem pública	Favorece infraestrutura local
Padrão de uso	Pico sazonal ou imprevisível	Estável, previsível, rodando o tempo todo
Sensibilidade do dado	Baixa a média, sem exigência de auditoria própria	Alta — dado de cliente, financeiro, propriedade intelectual central
Maturidade do sistema	Novo, padrão de uso ainda desconhecido	Antigo, comportamento já bem entendido
Capacidade técnica interna	Time pequeno, sem alguém dedicado a operar hardware	Time capaz de manter servidor, aplicar patch, monitorar disponibilidade
Horizonte de custo	Curto prazo, ou incerteza sobre continuidade do projeto	Longo prazo, com volume já validado

Essa tabela não decide sozinha — ela organiza a conversa. A decisão real nasce de cruzar as cinco linhas pro workload específico que está sendo avaliado, não de escolher uma coluna pra empresa inteira.

O critério que separa o que vai pra nuvem do que fica local

Três perguntas concretas, aplicadas por workload (não pela empresa inteira de uma vez):

Previsibilidade de uso. Carga estável, rodando o tempo todo, sem pico sazonal forte, tende a ficar mais barata em infraestrutura própria a partir de um certo volume — porque o custo variável da nuvem pública, multiplicado por uso constante, ultrapassa o custo fixo do hardware num prazo relativamente curto. Carga com pico previsível (fechamento de mês, campanha, sazonalidade de setor) ou pico imprevisível (crescimento repentino, evento fora do controle) favorece nuvem pública, porque pagar só pelo pico é mais barato que manter capacidade parada o ano inteiro.

Sensibilidade e exigência de controle do dado. Dado que exige rastreabilidade completa de acesso, auditoria interna forte ou simplesmente representa risco alto se vazado — informação de cliente, dado financeiro, propriedade intelectual central do negócio — ganha em ter controle direto de onde está e quem acessa. Isso não é sobre a nuvem pública ser insegura (ela não é, tem certificação que a maioria das empresas de porte médio não teria condição de replicar sozinha); é sobre quem responde pelo dado quando algo sai errado, e ter esse “quem” mais próximo de casa.

Capacidade de operar o que for local. Servidor próprio sem alguém formalmente responsável por mantê-lo, aplicar atualização de segurança e monitorar disponibilidade é pior que estar na nuvem pública mal configurada. Trazer workload pra local sem esse dono técnico só troca o risco de “terceiro cuida mal” pelo risco de “ninguém cuida”.

O mito da LGPD que ainda aparece em toda reunião

Uma crença recorrente merece correção direta: a LGPD não exige que o dado fique armazenado dentro do território brasileiro. A lei se aplica a qualquer empresa — brasileira ou não, com servidor aqui ou fora — que processa dado de pessoa localizada no Brasil. O que existe é um projeto de lei (PL 4723/20), ainda em tramitação, propondo essa obrigação — não é a lei vigente hoje.

Isso muda a conversa. Manter dado sensível em infraestrutura local não é uma obrigação legal disfarçada de decisão técnica — é uma escolha de controle e de facilidade de auditoria, que pode fazer sentido mesmo sem exigência legal nenhuma. Vender a decisão como “a lei exige” quando não exige é o tipo de argumento que desmorona na primeira pergunta de alguém que checou.

Arquitetura híbrida: nem fuga da decisão, nem meio-termo preguiçoso

O modelo mais comum entre quem já passou por essa reavaliação não é “tudo local” nem “tudo cloud” — é híbrido, com critério explícito por workload. Dado sensível e sistema de uso estável e previsível ficam sob controle direto. Carga elástica, sazonal, ou nova o suficiente pra ninguém saber ainda qual será o padrão de uso, fica na nuvem pública até esse padrão ficar claro.

Isso só funciona com alguém mapeando ativamente qual workload está em qual lado, e revisando essa divisão à medida que o padrão de uso muda — um sistema que nasceu imprevisível pode virar estável em dois anos, e a arquitetura precisa acompanhar, não ficar congelada na decisão original.

Quando essa decisão não é técnica — é executiva

Escolher onde cada workload roda tem componente técnico (comportamento de uso, custo de infraestrutura, requisito de rede) e componente de negócio (quanto risco a empresa aceita, quanto controle exige, quanto orçamento está disposta a fixar versus deixar variável). Fornecedor de TI terceirizado, quando existe, normalmente executa a arquitetura que foi decidida — raramente tem mandato pra questionar se a divisão cloud/local ainda faz sentido dois anos depois.

É esse o papel de quem responde pela tecnologia com autoridade executiva: revisar essa divisão com cadência, não deixar a decisão original virar dogma só porque ninguém teve mandato pra reabrir a pergunta.

Conclusão

“Cloud vs local” nunca foi uma escolha de time único. É uma decisão por workload, revisada com o tempo, baseada em previsibilidade de uso, sensibilidade do dado e capacidade real de operar o que ficar local. A maioria das empresas ainda decide isso uma vez, no início, e nunca mais revisita — e é exatamente esse hábito que 86% dos CIOs entrevistados pelo Barclays estão corrigindo agora.