Como este tema funciona na sua empresa
Cloud pública é padrão (AWS, GCP, Azure). Custo fixo, sem capital inicial. Privada seria desperdício. Híbrida é overkill. Foco: cloud pública consolidada, poucos ambientes.
Abordagem mista: cloud pública para aplicações novas/escaláveis, on-premise para dados sensíveis/banco central. Híbrida começa aqui. Foco: segregação por sensibilidade, custo otimizado.
Multi-cloud (AWS + Azure + GCP) para redundância. Cloud privada para workloads proprietários. Híbrida como default para coexistência. Foco: evitar lock-in, redundância, conformidade.
Cloud pública é infraestrutura compartilhada, multi-tenant, gerenciada por provedor. Cloud privada é infraestrutura dedicada à empresa. Cloud híbrida combina ambas. Cada uma tem trade-offs de custo, controle, segurança e performance[1].
Comparação direta: custo, controle, segurança
| Dimensão | Cloud Pública | Cloud Privada | Cloud Híbrida |
|---|---|---|---|
| Custo capex | Zero (paga-se uso) | Alto (infraestrutura dedicada) | Médio (ambos) |
| Custo opex | Variável (pay-as-you-go) | Fixo (contratado) | Variável+Fixo |
| Controle infraestrutura | Baixo (provedor gerencia) | Alto (empresa gerencia) | Médio (segregado) |
| Segurança perception | "Compartilhado = inseguro?" (mito) | "Meu = seguro?" (mito) | Balanceado (escolhe por workload) |
| Performance latência | Pode depender de localização DC | Controle total, latência previsível | Local = baixa, cloud = variável |
| Escalabilidade | Automática (minutos) | Manual (semanas) | Híbrida (local limite, cloud escalável) |
| Conformidade LGPD | Viável com DPA, residência Brasil | Mais simples (dados locais) | Segrega dados por sensibilidade |
Mitos comuns: "cloud pública não é segura" (falso — controles da AWS/Azure superam maioria das empresas); "privada é sempre mais barata" (falso — capex + opex da privada é alto); "híbrida é pior dos dois mundos" (falso — é opção legítima se bem arquitetada).
Por tipo de workload: onde rodar o quê
Decisão não é "escolho cloud X e tudo vai lá". É por workload:
- Nova aplicação, startup, projeto piloto: Cloud pública (sem capex, escalável). Exemplo: SaaS novo, API backend, prototipagem.
- Aplicação crítica legada em on-premise: Híbrida (legado fica local, replicação pra backup em cloud). Exemplo: ERP, sistema de pagamento.
- Dados sensíveis pessoais (LGPD, HIPAA): Cloud privada ou on-premise com conformidade (mesmo pública com DPA é possível). Exemplo: base de saúde, financeiro.
- Banco de dados central: Híbrida (on-premise como primary, cloud como DR). Exemplo: BI, data warehouse.
- Análise, batch processing: Cloud pública (escalável, econômica). Exemplo: ML, big data, analytics.
Tudo cloud pública. Não há complexity que justifique outras opções. Foco: gerenciar custos, não infra.
70% cloud pública (aplicações novas), 30% on-premise (dados sensíveis, legado). Híbrida é ponte entre os dois. VPN/ExpressRoute conecta.
Multi-cloud (AWS + Azure + GCP) para redundância, cloud privada para proprietary, on-premise para legacy/sensível. Tudo integrado via VPN/WAN.
Conformidade LGPD em cada modelo
Mito: "dados pessoais não podem estar em cloud pública". Verdade: podem, com contratos (DPA) e medidas de segurança.
Cloud pública LGPD: provedor assina DPA, confirma dados residem em Brasil, oferece direito a acesso/exclusão/portabilidade. Exemplo: AWS S3 Brasil, Azure Brasil, Google Cloud Brasil.
Cloud privada ou on-premise: jurisdição garantida, risco de exposição menor. Mas segurança ainda depende de controles — infraestrutura legada pode ser mais vulnerável que cloud pública.
Prática: auditar conformidade, não assumir que "privada = automático LGPD-compliant".
Migração: estratégias práticas (lift-and-shift vs. refactor)
Lift-and-shift: copiar sistema tal qual para cloud (rápido, ~3 meses, mantém problemas). Refactor: redesenhar para cloud-native (lento, ~9+ meses, otimizado). Escolha depende de timeline e budget.
Prático: começar com lift-and-shift para reduzir risk, depois refactor módulo por módulo se ROI justificar.
Sinais de que modelo de cloud atual precisa reavaliação
- Custo de cloud é surpresa mensalmente (sem previsibilidade, sem controle)
- Performance de aplicação é lenta — latência ou throughput degradado
- Conformidade LGPD não foi auditada — risco regulatório não mapeado
- Lock-in é tão alto que trocar provedor é impossível (custos de saída, APIs proprietárias)
- Redundância não existe — falha de provedor = downtime completo
- Dados sensíveis são guardados em cloud sem contrato de conformidade
- Infraestrutura on-premise não é aproveitada — custa opex mas não está sendo depreciada
Caminhos para avaliar e escolher modelo de cloud
Viável para decisão inicial ou revisão simples.
- Perfil necessário: Arquiteto de TI com experiência em cloud
- Tempo estimado: 4-6 semanas para análise, 3-6 meses para piloto
- Faz sentido quando: Problema é claro, solução é óbvia, expertise existe
- Risco principal: Análise superficial, viés interno, custo subestimado
Recomendado para decisão complexa ou migração grande.
- Tipo de fornecedor: Cloud architect consultancy, partner certificado AWS/Azure/GCP
- Vantagem: Análise robusta, benchmark vs. concorrência, TCO acurado, estratégia de migração
- Faz sentido quando: Migração é grande, conformidade é crítica, timeline é apertado
- Resultado típico: Em 2-3 meses, strategy documentada, TCO modelado, roadmap de migração claro
Precisa definir ou reavalia estratégia de cloud?
O oHub conecta você gratuitamente a cloud architects e especialistas em migração. Em menos de 3 minutos, descreva sua situação e receba propostas, sem compromisso.
Solicitar orçamento de Serviços Cloud Solicitar orçamento de Serviços na Nuvem Solicitar orçamento de Instalação de Redes Solicitar orçamento de Locação de Geradores de Energia Solicitar orçamento de Locação de Equipamentos de informática
Confira no oHub as empresas da nossa rede nas categorias: Serviços Cloud, Serviços na Nuvem, Instalação de Redes, Locação de Geradores de Energia e Locação de Equipamentos de informática
Sem custo, sem compromisso. Você recebe propostas e decide se e com quem avançar.
Perguntas frequentes
Qual é a diferença entre cloud pública e privada?
Pública: multi-tenant, infraestrutura compartilhada, gerenciada por provedor, pay-as-you-go, sem capex. Privada: dedicated, gerenciada por empresa ou terceiro, custo fixo, capex alto. Trade-offs: pública é barata e escalável; privada é controlável e previsível.
Quando usar cloud pública vs. privada?
Pública: aplicações novas, startup, projeto piloto, carga variável. Privada: aplicação crítica legada, dados muito sensíveis, carga previsível, conformidade exigente. Maioria empresa usa híbrida: pública para novos, privada/on-premise para sensível.
O que é cloud híbrida?
Combinação de pública + privada + on-premise. Dados sensíveis ficam locais/privados, aplicações novas em pública. Conectadas via VPN/ExpressRoute. Permite coexistência de legacy e moderno. Não é "pior dos dois mundos" — é estratégia legítima.
Qual é mais segura: cloud pública ou privada?
Mito: privada é automaticamente mais segura. Realidade: segurança depende de controles, não de "meu" vs. "compartilhado". AWS/Azure têm security standards mais altos que maioria das empresas. Privada pode ser legada e frágil. Escolher por arquitetura, não por percepção.
Quanto custa cada tipo de cloud?
Pública: variável, ~0.1-1 USD/GB/mês storage + compute. Privada: fixo ~5-15k USD/mês (contrato anual). On-premise: capex alto (equipamento) + opex médio. TCO a 5 anos: pública vence se carga é variável; privada/on-prem se carga é estável e grande.
Como migrar de on-premise para cloud híbrida?
Faseado: fase 1 = piloto (aplicação não-crítica em cloud pública); fase 2 = mover aplicações novas; fase 3 = aplicações críticas (mais cuidado, validação completa). Nunca migrar legado inteiro de uma vez — risco muito alto. Híbrida permite coexistência durante transição.