Atualizado em
Cloud Privada vs. Cloud Pública: comparativo completo por critério
Custo, segurança, conformidade, performance, elasticidade, lock-in — um critério de cada vez, sem generalização, para que você saiba onde cada workload pertence.
Resumo Executivo
Sumário
- Definições rápidas
- Tabela comparativa por critério
- Score visual por dimensão
- Custo e TCO: o critério mais mal-entendido
- Segurança e controle
- Conformidade, LGPD e soberania
- Performance e SLA
- Elasticidade e velocidade de provisioning
- Vendor lock-in e portabilidade
- Quando usar cada modelo
- Fluxo de decisão por workload
- A resposta híbrida
- FAQ
- Glossário
Definições rápidas
Infraestrutura compartilhada sob demanda
Recursos de compute, storage e rede fornecidos por provedores como AWS, Azure e GCP sobre infraestrutura compartilhada, acessados via internet, cobrados por uso. Você não tem hardware próprio — usa capacidade do provedor, junto com milhares de outros clientes.
Infraestrutura dedicada e exclusiva
Recursos de compute, storage e rede em infraestrutura dedicada exclusivamente à sua organização — seja em data center próprio, colocation ou operada por um parceiro como cloud privada gerenciada. Você tem controle total sobre o hardware, o software e os dados.
Cloud privada moderna não é “voltar para o servidor de 2010”. É infraestrutura atual — virtualização, Kubernetes, automação, observabilidade, backup enterprise — operada de forma dedicada. A diferença em relação ao on-premises legado é a mesma diferença entre um data center moderno e um rack não gerenciado debaixo da escada.
Tabela comparativa por critério
| Critério | Cloud Pública | Cloud Privada |
|---|---|---|
| Custo para workloads previsíveis (36 meses) | Alto — modelo de uso recorrente sem desconto pelo tempo de uso | Mais baixo — CapEx amortizado em 5 anos + operação previsível |
| Custo para workloads variáveis / picos | Vantagem — paga apenas quando usa; escala no momento do pico | Menos eficiente — capacidade dimensionada para o pico fica ociosa |
| CapEx inicial | Zero — modelo OpEx puro | Investimento necessário em hardware, instalação, licenças |
| Egress fees (saída de dados) | Presentes — US$ 0,08–0,15/GB no Brasil dependendo do provedor | Eliminadas ou próximas de zero — transferência interna sem cobrança |
| Previsibilidade de custo | Baixa — fatura varia com o uso; difícil orçar com precisão | Alta — custo fixo mensal ou por capacidade contratada |
| Controle sobre hardware e software | Limitado — você não escolhe o hardware; versões gerenciadas pelo provedor | Total — escolha de hardware, hypervisor, versões de software e política de atualização |
| Segurança — modelo de responsabilidade | Compartilhada — provedor cuida da infraestrutura; cliente cuida dos dados | Unificada — uma única equipe ou parceiro é responsável por toda a pilha |
| Conformidade e auditabilidade (LGPD, ISO) | Possível, mas dependente do provedor e de configuração específica por serviço | Mais fácil de demonstrar — evidências completas de toda a cadeia de custódia |
| Soberania de dados | Depende da região contratada e dos termos do provedor | Garantida — localização física dos dados conhecida e controlada |
| Performance / latência | Variável — noisy neighbor effect pode afetar workloads sensíveis | Consistente — recursos dedicados sem interferência de outros clientes |
| SLA contratual | Padronizado — tipicamente 99,9–99,99% por serviço, com créditos por downtime | Personalizado — SLA negociado por workload e componente |
| Elasticidade horizontal (scale-out) | Ilimitada — adiciona instâncias em minutos, paga pelo uso | Limitada pela capacidade física instalada; escalar leva dias |
| Velocidade de provisionamento | Minutos — API-driven; novo servidor pronto em menos de 5 minutos | Dias a semanas — hardware físico tem lead time de aquisição e instalação |
| Presença geográfica global | Extensa — dezenas de regiões em todos os continentes | Limitada aos data centers contratados |
| Vendor lock-in | Alto — especialmente quando se usam serviços nativos do provedor | Baixo — tecnologias abertas (KVM, Kubernetes, PostgreSQL, S3-compatible) |
| Acesso a serviços gerenciados avançados | Amplo — ML, serverless, bancos de dados exóticos, CDN, IoT… | Restrito ao que o parceiro ou equipe interna implementa |
| Gestão e operação | Infraestrutura gerenciada pelo provedor; cliente gerencia configuração | Toda a pilha requer gestão — própria, terceirizada ou gerenciada pelo parceiro |
Score visual por dimensão (1–5)
Comparativo visual de 0 a 5 para cada dimensão estratégica. Maior barra = melhor desempenho na dimensão.
Custo e TCO: o critério mais mal-entendido
A afirmação “cloud pública é mais barata” é verdadeira para alguns cenários e completamente falsa para outros. O erro está em aplicar a conclusão de um cenário a todos os contextos.
Quando cloud pública é mais barata
- Ambientes com picos imprevisíveis: pagar apenas durante os picos é mais eficiente do que manter capacidade instalada para o pior cenário.
- Projetos de curto prazo: sem CapEx inicial, o custo de um projeto de 3–6 meses em cloud pública raramente justifica o investimento em hardware.
- Startups e early-stage: sem capital para CapEx, o modelo OpEx da cloud pública é o único viável.
Quando cloud privada é mais barata
- Workloads 24×7 com uso estável: o custo por hora de instâncias reservadas em cloud pública, somado ao longo de 3 anos, supera o CapEx de hardware equivalente mais a operação.
- Alto volume de dados: egress fees + storage em cloud pública para dezenas de TB mensais supera significativamente o custo de storage em SAN/NAS privado.
- Ambientes maduros com previsibilidade: quando o crescimento é previsível e o dimensionamento pode ser feito com confiança, o modelo de capacidade reservada de cloud privada é mais eficiente.
Comparar o custo de cloud pública (que inclui operação e gestão da infraestrutura) com o custo de hardware privado bruto (excluindo operação, licenças e conectividade) é uma das distorções mais comuns nas análises de TCO. O comparativo correto é cloud pública total vs. cloud privada total — incluindo todos os custos de ambos os lados, com o mesmo horizonte de análise.
Para cálculo detalhado de TCO com seus números reais, acesse a Calculadora TCO da Adentro.
Segurança e controle
Cloud pública e cloud privada têm modelos de segurança fundamentalmente diferentes, não necessariamente um mais seguro que o outro — mas com distribuição de responsabilidades completamente distinta.
Modelo de responsabilidade compartilhada (cloud pública)
Na cloud pública, o provedor é responsável pela segurança da infraestrutura (hardware, rede física, hypervisor, data center). O cliente é responsável pela segurança na infraestrutura — configuração de redes, controle de acesso, criptografia de dados, gestão de identidade, patching de SO e aplicações.
Essa divisão funciona bem quando o time do cliente tem competência para configurar e manter adequadamente sua parte da responsabilidade. Quando não tem — ou quando auditores externos precisam de evidências de toda a cadeia — o modelo compartilhado cria lacunas de evidência difíceis de preencher.
Controle unificado (cloud privada)
Em cloud privada, uma única equipe ou parceiro é responsável por toda a pilha: hardware, rede, hypervisor, SO, aplicação e dados. Isso simplifica a cadeia de responsabilidade, facilita auditorias e permite implementar políticas de segurança personalizadas em qualquer camada da pilha.
Ao avaliar a segurança de um provedor de cloud privada, solicite o certificado ISO 27001 vigente e, se o escopo incluir dados pessoais, a certificação ISO 27701. Essas certificações representam auditoria independente de controles de segurança — não apenas declaração de boas práticas. A vigência do certificado (normalmente 3 anos com auditorias anuais de vigilância) deve ser verificada.
Conformidade, LGPD e soberania de dados
Para organizações sob regulação setorial — saúde, financeiro, educação, governo — ou que processam dados pessoais em escala, a conformidade é frequentemente o critério decisivo.
LGPD e localização de dados
A LGPD (Lei nº 13.709/2018) não proíbe o uso de cloud pública ou o armazenamento de dados no exterior, mas exige que a organização saiba exatamente onde seus dados estão, quem tem acesso e que controles estão em vigor. Em cloud privada, essas respostas são imediatas e documentáveis. Em cloud pública, demandam investigação por serviço, região e configuração.
Soberania de dados e risco geopolítico
Dados armazenados em infraestrutura de provedores americanos estão sujeitos, em tese, ao CLOUD Act (Clarifying Lawful Overseas Use of Data Act), que permite ao governo dos EUA solicitar dados armazenados por empresas americanas mesmo em servidores fora dos EUA. Para organizações com dados estratégicos ou sensíveis, isso representa um risco de soberania que infraestrutura privada nacional não tem.
Setor de saúde e financeiro no Brasil enfrentam exigências crescentes de auditoria e rastreabilidade de acesso a dados. Reguladores como ANS, BACEN e ANPD pedem evidências — não declarações. Cloud privada com log de auditoria completo, acesso físico controlado e certificação ISO 27001/27701 produz esse nível de evidência de forma mais direta do que a maioria das configurações de cloud pública.
Performance e SLA
Cloud pública oferece hardware moderno e rede de alta capacidade, mas não garante desempenho consistente ao longo do tempo para um workload específico. O fenômeno do noisy neighbor — outros clientes compartilhando o mesmo hardware físico consumindo recursos intensamente — pode causar variação de latência e throughput que afeta workloads sensíveis.
Cloud privada, com hardware dedicado, elimina esse problema. A performance é função do dimensionamento da própria infraestrutura — controlada e previsível.
SLA: padrão vs. personalizado
Os SLAs de cloud pública são padronizados por serviço (EC2: 99,99%, RDS Multi-AZ: 99,95%) e compensam com créditos de serviço — não com restauração do ambiente. Cloud privada gerenciada permite negociar SLAs por workload e componente, com cláusulas específicas de RTO e RPO para cada sistema.
Elasticidade e velocidade de provisioning
Esta é a dimensão em que cloud pública tem vantagem clara e indiscutível. Escalar horizontalmente — adicionar dezenas de instâncias em resposta a um pico de tráfego — em minutos é uma capacidade que infraestrutura privada simplesmente não oferece com a mesma agilidade.
Para workloads com esse perfil — e-commerce em datas comemorativas, sistemas de processamento de folha que têm pico mensal, aplicações com campanhas de marketing — a elasticidade tem valor econômico real que deve entrar no TCO.
Antes de concluir que um workload “precisa de elasticidade”, analise os dados históricos de uso. Em muitos casos, o que parece variável na prática tem um padrão previsível: picos diários entre 8h e 18h, picos mensais em datas de fechamento, sazonalidade anual conhecida. Para esses casos, capacidade superdimensionada em cloud privada pode ser mais eficiente do que escalar dinamicamente em cloud pública — especialmente quando o custo de instâncias adicionais é alto e o período de pico é curto.
Vendor lock-in e portabilidade
Cada serviço nativo de cloud pública que você adota aumenta o custo de saída. Um banco de dados Aurora (AWS) não tem equivalente direto em Azure ou em ambiente privado. Uma função Lambda é reescrita completa para migrar para GCP Cloud Functions. Um pipeline de dados usando Glue + Athena requer redesenho para rodar em Spark on-premises.
Cloud privada baseada em tecnologias abertas — KVM, Kubernetes, PostgreSQL, Redis, S3-compatible storage (MinIO, Ceph) — tem portabilidade total. Você pode migrar para outro parceiro ou para qualquer ambiente que suporte as mesmas tecnologias abertas sem reescrita.
Lock-in não é necessariamente ruim quando a troca de valor é genuína — serviços gerenciados como RDS eliminam a operação de banco de dados, e esse tempo tem custo real. O problema é lock-in sem consciência: consumir serviços nativos sem avaliar a dependência que se está criando. A recomendação é usar serviços nativos com inteligência — priorizando camadas que oferecem valor real e que podem ser abstraídas por interfaces portáveis (ex.: S3-compatible API em vez de S3 específico).
Quando usar cada modelo
Use Cloud Pública quando:
- O workload tem demanda altamente variável ou imprevisível
- Precisar de presença em múltiplas regiões do mundo
- O projeto é de curto prazo ou experimental
- A velocidade de go-to-market é crítica e o time não tem experiência em infra
- O workload consome serviços gerenciados avançados sem equivalente open-source
- O ambiente é de desenvolvimento/testes com ciclos efêmeros
- A organização não tem ou não quer ter competência operacional de infraestrutura
Use Cloud Privada quando:
- O workload roda 24×7 com uso estável e previsível
- O volume de dados é alto e o egress representaria custo expressivo
- A conformidade exige controle completo sobre localização e acesso aos dados
- O SLA precisa ser mais rigoroso do que o padrão de mercado
- A auditabilidade de toda a cadeia de custódia é mandatória (LGPD, BACEN, ANS)
- A organização quer eliminar a dependência de um único fornecedor
- O TCO em cloud pública supera o de cloud privada no horizonte de 3–5 anos
Fluxo de decisão por workload
Para a metodologia completa de avaliação — incluindo o ACRI (Adentro Cloud Repatriation Index) e checklist de 25 itens — leia o artigo pilar do cluster:
A resposta híbrida
A maioria das organizações maduras não escolhe entre cloud pública e cloud privada — elas usam ambos, de forma deliberada, com cada workload no ambiente que oferece a melhor relação custo-benefício para aquele perfil específico.
A distribuição típica em uma arquitetura híbrida bem planejada:
| Categoria de workload | Ambiente recomendado |
|---|---|
| ERP, banco de dados de produção, sistemas core | Cloud privada |
| Backup, arquivamento, dados históricos | Cloud privada |
| Dados pessoais e sensíveis (LGPD) | Cloud privada |
| Ambientes de desenvolvimento e QA | Cloud pública |
| Aplicações com picos sazonais | Cloud pública |
| CDN e entrega de conteúdo global | Cloud pública |
| Ferramentas SaaS e colaboração | Cloud pública / SaaS |
| Disaster Recovery (destino secundário) | Cloud pública (para elasticidade em failover) |
| ML e AI — inferência em produção estável | Avaliar individualmente |
FAQ — Perguntas frequentes
Não necessariamente — mas o controle é diferente. Em cloud privada, toda a responsabilidade de segurança está com a sua organização ou com o parceiro gerenciado. Isso é um benefício quando a equipe tem competência, e um risco quando não tem. Em cloud pública, o provedor garante a segurança da infraestrutura, mas você precisa configurar corretamente sua parte. A maioria dos incidentes de segurança em cloud pública ocorre por configuração incorreta do cliente, não por falha do provedor.
Não. Em colocation, você aluga espaço físico, energia e conectividade em um data center, mas gerencia você mesmo o hardware e o software instalados. Em cloud privada gerenciada, o parceiro é responsável pela operação completa — hardware, hypervisor, rede, backup, monitoramento — entregando ao cliente apenas o ambiente operacional com SLA garantido. É mais próximo do modelo de cloud pública (sem gestão de infra pelo cliente), mas com recursos dedicados.
Sim. Modelos de cloud privada gerenciada e IaaS privado em hardware de parceiro permitem consumir infraestrutura dedicada sem investimento próprio em hardware. O modelo de subscription fixa mensal ou de capacidade contratada elimina o CapEx e mantém a previsibilidade de custo. Essa é a principal diferença entre “cloud privada” e “data center próprio”.
O comparativo deve ser feito por workload, não pelo ambiente total. Para cada workload candidato: (1) extraia o custo atual na cloud pública (compute + storage + egress + serviços); (2) obtenha uma cotação de cloud privada equivalente incluindo operação; (3) adicione o custo de migração ao TCO do primeiro ano de cloud privada; (4) projete os dois cenários por 36 meses. Use a Calculadora TCO da Adentro para facilitar esse processo.
Não. A região sa-east-1 da AWS (São Paulo) pratica preços de compute e especialmente de egress significativamente mais altos do que as regiões norte-americanas. Isso intensifica ainda mais a comparação de TCO em favor da cloud privada para workloads localizados no Brasil.
Sim, e essa é uma das configurações híbridas mais populares. O ambiente primário — onde os workloads rodam 24×7 — fica em cloud privada para melhor TCO e controle. A cloud pública serve como destino de DR, ativada apenas em caso de falha do ambiente primário. O custo do ambiente de DR em cloud pública é mínimo quando não está ativo (apenas storage de replicação), e a elasticidade da cloud pública garante capacidade de failover imediata.
A LGPD não proíbe a transferência internacional de dados, mas impõe condições: o país de destino deve oferecer nível de proteção equivalente, ou o controlador deve implementar garantias adequadas (cláusulas contratuais, certificações). Na prática, para organizações sob fiscalização mais rigorosa da ANPD ou sob regulação setorial, manter dados em infraestrutura nacional com ISO 27701 é a postura mais segura e auditável.
Depende da complexidade e do número de workloads. Um único workload bem documentado pode ser migrado em 4 a 8 semanas com operação paralela. Ambientes complexos com múltiplos sistemas interdependentes costumam demandar 6 a 18 meses com migração em fases. O prazo é determinado principalmente pela fase de planejamento e de operação paralela — não pela migração em si.
Glossário
Avalie qual modelo é certo para o seu ambiente
O Cloud Repatriation Assessment da Adentro analisa seus workloads atuais, calcula o TCO comparativo e identifica quais devem permanecer em cloud pública e quais têm perfil para cloud privada.
