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.
Encontrar fornecedores de TI no oHub
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.