Modelos de implantação de nuvem: pública, privada, híbrida e comunitária

Autor: Pedro Tebaldi PM do KeepGreen| Revisão técnica: Ednilson Correa SRE

Publicado fev/2018Atualizado ago/2026

Duas perguntas diferentes costumam ser tratadas como uma só. A primeira é o que você continua administrando depois de contratar. A segunda é onde a infraestrutura roda e de quem é o equipamento por baixo dela.

A confusão tem custo prático. Um gestor decide “vamos para a nuvem”, contrata infraestrutura pública. Só na auditoria descobre que aquele dado precisava ficar em ambiente dedicado. Ou monta uma nuvem privada cara para uma carga que variava demais e teria custado menos no modelo pago por uso.

Este artigo trata da segunda pergunta. Os modelos de computação em nuvem por implantação definem quem é dono do ambiente, quem tem acesso a ele e onde os dados repousam. São quatro, mais uma estratégia que muita gente confunde com um quinto.

O que são modelos de computação em nuvem?

Modelos de computação em nuvem são as formas de organizar a infraestrutura que sustenta um serviço em nuvem, classificadas por quem usa o ambiente e quem o controla. A referência de mercado define quatro: pública, privada, comunitária e híbrida. Eles respondem onde a nuvem roda, não o que você administra dentro dela.

Vale separar bem os dois eixos, porque o mercado embaralha os termos. Um eixo trata do modelo de serviço, ou seja, o que o provedor entrega pronto: esse é o assunto do material sobre IaaS, PaaS e SaaS. O outro eixo, tratado aqui, trata do modelo de implantação.

Os dois se combinam livremente. Você pode ter SaaS rodando em nuvem pública, IaaS em nuvem privada ou PaaS em ambiente híbrido. Dizer apenas “estamos na nuvem” não informa nem um eixo nem o outro.

A definição de referência publicada pelo NIST organiza a nuvem exatamente assim: cinco características essenciais, três modelos de serviço e quatro modelos de implantação. É o documento que a maior parte dos contratos e das normas de conformidade cita.

Repare que a coluna decisiva não é a de custo. É a de quem usa o ambiente, porque dela decorrem isolamento, conformidade e o tipo de contrato possível.

Nuvem pública

Na nuvem pública, o provedor mantém a infraestrutura e a oferece a qualquer cliente. Os recursos ficam logicamente isolados entre inquilinos, embora o hardware seja compartilhado. Você entra, provisiona em minutos e paga pelo que consumiu.

O ganho central é elasticidade sem compromisso prévio. Uma campanha de fim de ano sobe capacidade por três semanas e devolve tudo depois, sem sobrar servidor ocioso no ano seguinte.

Existe o outro lado. Custo variável precisa de acompanhamento, senão surpreende no fechamento do mês. Recurso esquecido ligado, ambiente de teste que ninguém desligou e tráfego de saída não previsto são os três vilões mais comuns.

Vale registrar uma confusão frequente sobre isolamento. Rede privada dentro de nuvem pública, como uma rede virtual isolada, continua sendo nuvem pública: o hardware segue compartilhado, apenas o endereçamento e as regras de tráfego ficam separados.

Considere também a escolha de região. Provedores públicos operam em várias localidades. A distância entre a região contratada e o usuário final aparece direto na latência. Para operação concentrada no Brasil, região local reduz o tempo de resposta e simplifica a conversa sobre onde o dado repousa.

Nuvem privada

A nuvem privada serve a uma organização só. O ambiente pode ficar no data center da própria empresa ou hospedado em terceiro, desde que os recursos sejam dedicados. O que define o modelo não é o endereço físico: é a exclusividade de uso.

Duas razões sustentam a escolha. A primeira é exigência regulatória ou contratual sobre onde o dado repousa e quem pode tocá-lo. A segunda é carga estável e previsível, cenário em que o pagamento por uso deixa de ser vantagem e vira custo recorrente sem retorno.

Do lado brasileiro, a lei geral de proteção de dados pessoais não proíbe nuvem pública nem obriga ambiente dedicado. Ela cobra controle demonstrável sobre tratamento, acesso e transferência, o que às vezes é mais simples de provar em ambiente exclusivo.

Nuvem privada cobra o preço em trabalho. Capacidade mal dimensionada não se resolve com um clique, atualização vira projeto e a equipe precisa dominar virtualização, rede e armazenamento. Quem entra nesse modelo assume operação, não só contrato.

Nuvem comunitária

A nuvem comunitária atende um grupo de organizações que compartilham o mesmo requisito: mesma norma setorial, mesma missão ou mesma exigência de jurisdição. A infraestrutura é dedicada ao grupo e o custo é rateado entre os participantes.

É o modelo menos comum dos quatro, porém tem casos claros no Brasil. Consórcios de saúde, redes de instituições de ensino e ambientes de governo com regra específica de residência de dado costumam se organizar assim.

O atrativo é diluir o custo de conformidade. Auditoria, controles e certificações saem caro para uma organização média sozinha. Divididos entre várias que precisam do mesmo controle, ficam viáveis.

A dificuldade também é coletiva. Governança compartilhada exige acordo sobre janela de manutenção, prioridade em incidente e critério de expansão, decisões que travam quando não há um responsável único definido em contrato.

Na prática, o modelo funciona melhor quando existe uma entidade coordenadora com mandato claro, como um consórcio formal ou uma associação setorial. Sem essa figura, a nuvem comunitária tende a se degradar em uma nuvem privada de quem pagou mais.

Nuvem híbrida

A nuvem híbrida combina dois ou mais modelos anteriores mantendo integração entre eles: identidade, rede e dados atravessam a fronteira de forma controlada. Sem essa integração não existe híbrido, existe apenas dois ambientes separados na mesma empresa.

Esse detalhe importa mais do que parece. Muita empresa se declara híbrida quando na verdade tem um ERP no data center e um CRM em SaaS, sem nada conectando os dois. Modelo híbrido pressupõe que uma carga possa transitar ou depender da outra.

O caso de uso clássico é o legado que não vale migrar convivendo com serviços novos que precisam escalar. Outro é manter o dado sensível em ambiente dedicado enquanto o processamento pesado acontece em capacidade pública contratada por hora.

Este é o modelo com maior custo de operação, porque exige coerência entre dois mundos com ferramentas diferentes. O detalhamento de integração, identidade e gestão está no material específico sobre cloud híbrida.

Multicloud não é um modelo de implantação

Multicloud descreve o uso de mais de um provedor, geralmente dois ou três públicos ao mesmo tempo. Não é um quinto modelo: é uma estratégia de fornecedor que pode existir dentro de qualquer um dos quatro.

A distinção evita erro de projeto. Híbrido responde “onde a carga roda”, enquanto multicloud responde “de quem eu compro”. Uma empresa pode ser híbrida sem ser multicloud, multicloud sem ser híbrida, ou as duas coisas.

As motivações mais comuns são reduzir dependência de um fornecedor, atender exigência de continuidade e aproveitar serviço específico que só um provedor entrega bem. O contraponto é operacional: dobra a superfície de aprendizado da equipe.

Quem está avaliando esse caminho encontra os critérios de decisão e as armadilhas de operação no material sobre estratégia multicloud.

Como escolher o modelo de implantação

A escolha sai de quatro perguntas objetivas, respondidas por carga de trabalho e não pela empresa inteira. Onde o dado pode repousar? Quanto a demanda varia? Que competência a equipe tem hoje? Quanto custa sair depois?

A primeira pergunta costuma decidir sozinha. Havendo regra explícita de residência ou de acesso, o espaço de escolha encolhe para privada ou comunitária. O resto da análise vira detalhe.

Não havendo essa restrição, a variação da demanda manda. Carga que oscila muito favorece nuvem pública, porque o pagamento por uso acompanha o pico. Carga plana e previsível tende a ficar mais barata em ambiente dedicado, sobretudo em horizonte de três anos ou mais.

O custo de saída merece conta própria, porque costuma ficar de fora da comparação inicial. Ele soma três parcelas: tráfego de saída dos dados acumulados, reescrita do que dependia de recurso exclusivo do provedor e tempo de equipe na transição. Quanto mais tempo o ambiente roda, maior fica essa conta.

Um erro recorrente é decidir por diretriz geral, do tipo “tudo vai para a nuvem pública”. A decisão correta é por carga: o mesmo negócio pode ter ERP em ambiente dedicado, site em nuvem pública e uma análise de dados que sobe só quando roda.

Antes de fechar, vale confrontar a decisão com o balanço de vantagens e riscos da adoção da nuvem, que trata dos pontos que costumam aparecer depois da assinatura.

O que muda no monitoramento de cada modelo

O modelo de implantação muda o que você consegue enxergar e de onde. Em ambiente dedicado, existe acesso ao hipervisor, ao armazenamento e aos equipamentos de rede, então a coleta desce até o hardware.

Na nuvem pública, essa camada some. O provedor expõe métricas do serviço e nada abaixo dele, portanto o trabalho passa a ser correlacionar o que a API entrega com a experiência medida de fora, do ponto de vista de quem usa.

O ambiente híbrido é o mais exigente. Ele precisa de uma visão única sobre duas coletas diferentes, senão cada time olha o próprio painel e a discussão sobre causa raiz vira disputa de versão entre infraestrutura e nuvem.

Vale padronizar o vocabulário antes de escolher ferramenta. Quando indisponível significa coisas diferentes para o time de infraestrutura e para o time de nuvem, nenhum painel unificado resolve o desentendimento. Definir qual evento conta como indisponibilidade vem antes de decidir onde coletar.

Independentemente do modelo, três medições não podem faltar: disponibilidade do serviço vista pelo usuário, latência entre os ambientes que trocam dados e consumo contra a capacidade contratada. As categorias de serviço envolvidas nessa conta estão detalhadas no material sobre serviços de computação em nuvem.

Erros comuns na escolha do modelo

Alguns tropeços se repetem em empresas de portes bem diferentes. Reconhecê-los antes do contrato evita migração de volta.

• Chamar de híbrido o que está apenas separado: sem integração de identidade, rede e dados, são dois ambientes isolados, não um modelo híbrido.
• Escolher privada por medo, sem requisito escrito: se nenhuma norma exige, o custo de operar o ambiente raramente se paga.

• Migrar tudo de uma vez: decisão por diretriz geral ignora que cargas diferentes têm perfis de custo e risco diferentes.
• Ignorar o tráfego de saída: mover dado para fora do provedor é cobrado e costuma ser a linha que estoura o orçamento do híbrido.

Existe ainda um erro silencioso: não revisar a escolha. O modelo certo em um ano deixa de ser o certo quando o volume triplica ou quando uma norma nova entra em vigor, então vale reavaliar por carga a cada ciclo de orçamento.

Conclusão

Os modelos de computação em nuvem por implantação respondem uma pergunta específica: quem usa o ambiente e quem controla o que está por baixo. Pública para demanda que varia, privada para exigência de controle com carga estável, comunitária para grupos que dividem a mesma norma, híbrida para quem precisa das duas coisas ao mesmo tempo.

Guardar essa separação evita a discussão improdutiva mais comum do tema. Modelo de implantação não se confunde com modelo de serviço. Já multicloud não é modelo nenhum: é decisão de fornecedor.

Comece pela carga de trabalho mais crítica que você opera hoje. Escreva onde o dado pode repousar, quanto a demanda varia ao longo do mês e quanto custaria mudar de ambiente daqui a dois anos. Com essas três respostas, o modelo adequado costuma ficar evidente sem precisar de comparação de fornecedor.

Quer enxergar disponibilidade, performance e custo dos seus ambientes, seja qual for o modelo adotado? Fale com um especialista da OpServices e veja como unificar essa visão.