Todos os artigos
176 artigos · atualizado semanalmente Veja nossas Ferramentas
Todos os artigos
Comparativos

Nuvem pública, privada ou híbrida: diferenças e qual escolher

Nuvem pública, privada e híbrida comparadas por custo real (egress, TCO), controle e regras do Bacen e da LGPD, com um critério simples para escolher.

Nuvem pública, privada ou híbrida: diferenças e qual escolher
COVER · Comparativos

A reunião de arquitetura durou três horas. No final, o CTO perguntou uma coisa simples: "nuvem pública ou privada?". Ninguém sabia responder sem antes responder outras cinco perguntas. Isso é normal: a escolha entre os três modelos de nuvem (cloud) não é técnica, é de negócio. Depende do perfil da carga, do volume de dados que sai da sua rede, do que o regulador do seu setor exige e de quem vai operar a coisa às três da manhã.

A resposta curta: nuvem pública é a escolha padrão para a maioria dos produtos digitais; nuvem privada se paga quando a carga é estável, o volume de dados é alto e o controle físico importa; nuvem híbrida é para quem tem os dois problemas ao mesmo tempo e um time capaz de operar a soma. O resto deste post é como chegar nessa resposta com números, e não com intuição.

Nuvem pública, privada e híbrida: a diferença em uma frase

  • Nuvem pública: você aluga capacidade compartilhada de um provedor (AWS, Google Cloud, Azure, Oracle) e paga pelo uso, sem comprar nem operar hardware.
  • Nuvem privada: a infraestrutura é dedicada a uma única organização, seja no seu datacenter (on-premises), seja hospedada por um provedor com recursos exclusivos seus.
  • Nuvem híbrida: pública e privada operando como um ambiente só, com rede, identidade e deploy integrados entre os dois lados.
Critério Pública Privada Híbrida
Quem é dono do hardware O provedor Você (ou um provedor, dedicado a você) Os dois
Modelo de custo Opex variável, sem investimento inicial Capex alto + opex previsível Capex da parte privada + fatura variável
Escala Praticamente imediata Limitada pelo que você comprou Base fixa, picos na pública
Controle Até a camada que o serviço expõe Total, do firmware à rede Total de um lado, parcial do outro
Compliance Atende a maioria, depende do contrato e da região Mais fácil provar localização e acesso Dado sensível no privado, resto no público
Equipe necessária Pequena, focada em cloud Time de infraestrutura completo Time de plataforma maduro

Antes de seguir: se a dúvida for VPS, VPC ou servidor dedicado, ou seja, como escolher dentro de um modelo, o post VPS, VPC e servidor dedicado: qual escolher? cobre esse nível. Este aqui fica um degrau acima.

Custo: a conta que ninguém faz direito

Nuvem pública parece mais barata porque não tem capex. O custo total de propriedade (TCO) conta outra história, e quem decide quase sempre olha só para a linha de computação.

Computação é a parte fácil de estimar. Uma instância m5.2xlarge (8 vCPU, 32 GiB) custava US$ 0,384/hora sob demanda em us-east-1 em novembro de 2026, cerca de US$ 280/mês ligada direto; reservada por um ano, a hora cai para perto de US$ 0,24 (preços EC2, conferidos em 09/11/2026). Para carga estável rodando 24/7, a reserva derruba boa parte da vantagem que um servidor próprio teria.

A linha que surpreende é a transferência de dados para a internet (egress). E aqui a região faz diferença. Pela tabela de preços da AWS publicada em 03/11/2026, a primeira faixa de egress (até 10 TB/mês) custa US$ 0,09/GB em us-east-1 e US$ 0,15/GB em sa-east-1 (São Paulo), depois dos 100 GB/mês gratuitos agregados (preços EC2, seção Data Transfer). Fiz a conta para três volumes:

Egress mensal para a internet (aprox., novembro/2026)
volume     us-east-1     sa-east-1 (São Paulo)
 5 TB      ~US$   450    ~US$   750
20 TB      ~US$ 1.780    ~US$ 2.930
50 TB      ~US$ 4.400    ~US$ 7.180

Hospedar em São Paulo resolve latência e simplifica a conversa de compliance, mas cada terabyte servido sai cerca de dois terços mais caro na primeira faixa. Se a sua aplicação distribui vídeo, datasets ou backups para fora, a fatura de transferência pode passar a de computação. Uma CDN na frente costuma ser o primeiro ajuste, antes de qualquer conversa sobre trocar de modelo.

Nuvem privada inverte essa estrutura: você paga o hardware de uma vez, o tráfego interno não tem tarifa por GB, e energia, link e operação viram custo fixo previsível. O ponto de equilíbrio depende do seu caso (preço do link, salário do time, ciclo de troca de hardware), então desconfie de quem cita um número de meses sem ver a sua planilha. O que dá para afirmar: quanto mais estável a carga e maior o volume de dados saindo, mais cedo a privada se paga.

A híbrida tende a ter o pior custo de entrada, porque você paga a infraestrutura privada e mantém conta no provedor público, mais o link dedicado entre os dois. Bem dimensionada, é a mais eficiente para carga mista: base estável no privado, picos no público. Para picos curtos e imprevisíveis, compare também com serverless, que cobra por execução e some quando não há tráfego.

Regra de bolso
- Carga imprevisível, pouco dado saindo           → pública
- Carga estável 24/7, muito egress, horizonte 3+ anos → privada
- Base estável + picos sazonais                   → híbrida

Compliance: LGPD e Banco Central

A LGPD (Lei 13.709/2018) não proíbe nuvem pública, nem nuvem no exterior. O art. 33 lista as hipóteses em que a transferência internacional de dados pessoais é permitida, entre elas cláusulas contratuais aprovadas pela ANPD. Essas cláusulas-padrão vieram com a Resolução CD/ANPD nº 19/2024, que deu 12 meses (até agosto de 2025) para incorporá-las aos contratos. Na prática: se o dado sai do Brasil, o contrato com o provedor precisa ter o mecanismo certo. Se fica numa região brasileira (sa-east-1 na AWS, brazilsouth na Azure, southamerica-east1 no Google Cloud), essa parte da conversa encolhe.

Dados de saúde são dados pessoais sensíveis (art. 5º, II e art. 11 da LGPD) e têm hipóteses de tratamento mais restritas. Isso não proíbe a nuvem pública, mas pede contrato, controles de acesso e registro de operações que você consiga mostrar a um auditor.

O setor financeiro tem regra própria, e é aqui que muito post repete norma revogada. A Resolução CMN 4.658/2018 foi revogada pela Resolução CMN 4.893/2021 (alterada pela 5.274/2025), e a Circular 3.909/2018 foi substituída, para instituições de pagamento e corretoras, pela Resolução BCB 85/2021. Nenhuma delas exige que os dados fiquem em território nacional. O que exigem, em resumo:

  • Comunicar ao Banco Central a contratação de serviço relevante de processamento, armazenamento ou nuvem em até dez dias, informando os países e regiões onde os dados podem ser armazenados e processados (art. 15).
  • Nuvem no exterior é permitida desde que exista convênio de troca de informações entre o BCB e o supervisor do país; sem convênio, a instituição precisa pedir autorização com pelo menos sessenta dias de antecedência (art. 16).
  • Garantir acesso da instituição e do BCB aos dados, e ter plano de continuidade caso o contrato acabe.

Em outras palavras: uma fintech pode rodar em nuvem pública, inclusive fora do Brasil, desde que cumpra o rito. Se o seu jurídico disser "o Bacen exige dado no Brasil", peça o artigo.

Para a maioria das empresas B2B que tratam dados pessoais comuns (nome, e-mail, endereço), a nuvem pública com região no Brasil atende sem drama. O risco raramente é o modelo; é o contrato que ninguém leu.

Controle operacional e SLA: o que você abre mão

Na nuvem pública você não vê o hardware, não escolhe o host físico e não controla a janela de manutenção do hipervisor. Em troca, recebe SLA contratual e serviços gerenciados que seriam caros de operar sozinho: Kubernetes, bancos, filas, CDN.

Leia o SLA, não o marketing. O S3 Standard é projetado para 99,99% de disponibilidade, mas o SLA, o que gera crédito se falhar, é 99,9% (AWS S3 SLA, atualizado em 28/11/2023). No Cloud SQL, o compromisso é 99,95% na edição Enterprise com alta disponibilidade e 99,99% só na Enterprise Plus com HA; instância sem HA nem entra no SLA (Cloud SQL SLA, conferido em 09/11/2026). E crédito de SLA é desconto na próxima fatura, não indenização pelo seu prejuízo.

Na nuvem privada você controla tudo e opera tudo: patch de firmware, disco com falha, upgrade de rede. Esse controle tem valor real quando hardware específico importa (GPUs para HPC, latência muito baixa entre serviços, integração com equipamento legado).

A híbrida só é viável com um time de plataforma maduro. Alguém precisa operar a conexão entre os ambientes (VPN site-to-site, AWS Direct Connect, Azure ExpressRoute) e manter rede, identidade e observabilidade consistentes nos dois lados. Um detalhe que derruba projeto: os blocos de IP privado do datacenter e das VPCs não podem se sobrepor, senão o roteamento entre os lados simplesmente não funciona. Containers ajudam na portabilidade das aplicações; se isso ainda é nebuloso, imagem Docker vs container é o ponto de partida.

Nuvem híbrida vs multicloud

São coisas diferentes e muita gente usa como sinônimo. Híbrida é pública + privada. Multicloud é usar mais de um provedor público (AWS + Google Cloud, por exemplo), com ou sem parte privada.

As motivações também mudam. Híbrida costuma nascer de controle, compliance ou de um datacenter que ainda não foi amortizado. Multicloud nasce de evitar dependência de um só fornecedor ou de querer um serviço específico de cada um (o banco analítico de um, o modelo de IA de outro). O custo também é diferente: multicloud multiplica IAM, rede, faturamento e observabilidade, e cobra egress entre provedores. Para empresa grande com time dedicado, pode compensar. Para time pequeno, quase sempre é complexidade sem retorno.

Quando cada modelo faz sentido

Nuvem pública quando:

  • Você está validando produto e não quer capex antes de ter receita.
  • A carga tem picos imprevisíveis (Black Friday, lançamento, conteúdo que viraliza).
  • Serviços gerenciados economizam semanas de engenharia (RDS, Pub/Sub, BigQuery).
  • O time de infraestrutura é pequeno ou inexistente.

Nuvem privada quando:

  • A carga é estável, roda 24/7 e move muito dado para fora.
  • Você precisa provar controle físico do dado (defesa, parte do setor público).
  • Há capex disponível e horizonte de três anos ou mais.
  • Hardware específico ou latência ultrabaixa é requisito, não preferência.

Nuvem híbrida quando:

  • Existe uma base estável que justifica a privada e picos que justificam a pública.
  • Dados sensíveis ficam no privado e a camada de front precisa de escala.
  • Você está migrando de on-premises para a pública aos poucos e precisa conviver com os dois.

Perguntas frequentes

Qual a diferença entre nuvem pública e privada?

Na pública, a infraestrutura é do provedor e compartilhada entre clientes, e você paga pelo uso. Na privada, a infraestrutura é dedicada a uma organização, no seu datacenter ou hospedada por terceiros. A pública troca controle por elasticidade e zero investimento inicial; a privada troca elasticidade por controle e custo previsível.

Nuvem pública é segura para dados sensíveis?

Sim, com configuração correta. Os grandes provedores têm certificações como ISO 27001 e SOC 2 e operam no modelo de responsabilidade compartilhada: eles cuidam da infraestrutura, você cuida da configuração. A maior parte dos vazamentos em nuvem pública vem do lado do cliente (bucket público, chave vazada no GitHub, IAM permissivo). Um servidor mal configurado on-premises não é mais seguro.

O Banco Central exige que os dados fiquem no Brasil?

Não. A Resolução CMN 4.893/2021 e a Resolução BCB 85/2021 permitem nuvem no exterior, desde que haja convênio entre o BCB e o supervisor do país (ou autorização prévia, se não houver), comunicação ao BCB em até dez dias e garantia de acesso aos dados. A exigência é de transparência e acesso, não de localização.

Nuvem privada é sempre mais cara que a pública?

Não. Para carga estável com muito egress, a privada pode ter TCO menor no médio prazo. O que ela sempre tem mais caro é a entrada (hardware) e a operação (time). Se você não tem esse time, a pública sai mais barata na prática, seja qual for o resultado da planilha.

Comece pelas três perguntas, não pelo modelo

A maioria das startups não precisa de nuvem híbrida, e a maioria das empresas com datacenter próprio não precisa migrar tudo de uma vez. A decisão sai de três perguntas: a carga é estável ou imprevisível, quanto dado sai da sua rede por mês, e o que o regulador do seu setor realmente exige (o texto da norma, não o resumo de alguém). Faça a conta de egress na região que você vai usar, leia o SLA de cada serviço crítico e só então escolha.

Se o caminho for híbrido, planeje os blocos de IP antes de abrir o primeiro túnel. Uso a calculadora de sub-redes CIDR do Qual é meu IP para conferir se o range da VPC conflita com o do escritório, e a mesma página mostra por qual IP público e provedor (ASN) a máquina em que você a abre está saindo, o que ajuda a confirmar se o tráfego está mesmo passando pela VPN ou pelo NAT que você configurou. Para entender a diferença entre esses endereços, veja IP público, privado, fixo e dinâmico.

RD
Autor
Rafael Duarte
Desenvolvedor backend com passagem por fintech e SaaS B2B — trabalhou em times que escalaram APIs de zero a milhões de requisições. Carrega cicatrizes de produção suficientes para ter opiniões fortes sobre ferramentas, padrões e decisões de arquitetura. Não é acadêmico: leu a RFC do UUID quando precisou escolher entre v4 e v7 para uma tabela de alta escrita.
Ver perfil