SaaS, IaaS, PaaS e XaaS: o que significa cada modelo de serviço em nuvem

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

Publicado abr/2015Atualizado ago/2026

Toda empresa que usa nuvem já opera nos três modelos ao mesmo tempo, ainda que ninguém tenha desenhado isso de propósito. O e-mail corporativo é SaaS. O banco de dados gerenciado que o time de desenvolvimento subiu é PaaS. As máquinas virtuais que sustentam o sistema legado são IaaS.

A confusão entre as siglas custa dinheiro. Ela leva a contratar infraestrutura quando bastava uma plataforma, a assumir responsabilidade de segurança que era do fornecedor ou a supor que o provedor cuida de um backup que ninguém configurou.

Este artigo separa IaaS, PaaS e SaaS pelo critério que realmente importa: o que você continua administrando em cada um. Também trata do guarda-chuva XaaS, dos exemplos concretos de cada modelo e de como escolher entre eles.

O que significam IaaS, PaaS e SaaS?

IaaS, PaaS e SaaS são os três modelos de serviço da computação em nuvem. No IaaS você aluga infraestrutura bruta e administra o sistema operacional para cima. No PaaS o provedor entrega uma plataforma pronta e você cuida apenas do código e dos dados. No SaaS você consome um software pronto, sem administrar nada da base.

Essa divisão em três camadas não é invenção de fornecedor. Ela vem da definição de referência publicada pelo NIST, o instituto de padrões dos Estados Unidos, que também descreve as características essenciais e os modelos de implantação da nuvem.

A lógica é de escada. A cada degrau que você sobe, entrega mais controle ao provedor e recebe menos trabalho operacional em troca. Nenhum degrau é melhor que o outro: eles resolvem problemas diferentes.

Uma observação de grafia, já que os erros circulam bastante. As siglas vêm de Infrastructure as a Service, Platform as a Service e Software as a Service, sempre no singular em “infrastructure” e com “platform” sem o A do português.

Repare na primeira linha da tabela. Dados e controle de acesso ficam com o cliente nos três modelos, sem exceção. Esse é o ponto que mais gera incidente quando alguém supõe o contrário.

IaaS: infraestrutura como serviço

IaaS é o aluguel de recursos computacionais brutos: máquinas virtuais, armazenamento em bloco, rede virtual e balanceadores. O provedor cuida do hardware, do datacenter e da camada de virtualização. Do sistema operacional para cima, a responsabilidade volta a ser sua.

Exemplos típicos incluem instâncias de computação, volumes de disco e redes privadas virtuais dos grandes provedores públicos. Quem quiser comparar as ofertas encontra o detalhamento no material sobre AWS, Azure e Google Cloud, que confronta serviços equivalentes entre eles.

O modelo compensa em três situações. Migração de sistema legado que exige um sistema operacional específico, cargas com necessidade de ajuste fino de kernel ou driver, além de ambientes sujeitos a exigência regulatória sobre configuração de rede.

Em contrapartida, o IaaS transfere pouco trabalho. Patch de sistema operacional, dimensionamento, backup e hardening continuam na sua conta. Muita equipe migra para IaaS esperando alívio operacional e descobre que apenas trocou o servidor físico por um virtual, com fatura mensal.

PaaS: plataforma como serviço

PaaS entrega um ambiente pronto para executar aplicação, sem que você administre servidor ou sistema operacional. O provedor cuida da plataforma inteira: máquina, atualização, escalonamento e disponibilidade. Você entra com o código, a configuração e os dados.

Bancos de dados gerenciados, filas de mensagem, ambientes de execução de aplicação e serviços de função sob demanda entram nessa categoria. O time de desenvolvimento publica a aplicação e para de discutir versão de biblioteca de sistema.

O ganho aparece em velocidade. Sem patch, sem cluster para montar, sem janela de manutenção para negociar. Para produto novo, esse é quase sempre o caminho mais rápido entre a ideia e o ambiente de produção.

O preço vem em flexibilidade. A plataforma impõe versões, limites e formas de fazer as coisas, então uma aplicação com dependência exótica pode simplesmente não caber. Vale também olhar o custo por transação: o que parece barato no piloto às vezes fica caro em escala.

Existe ainda um formato intermediário que confunde muita gente. Containers gerenciados ficam entre IaaS e PaaS: você empacota a aplicação com as próprias dependências, porém o provedor opera o cluster por baixo. O controle é maior que no PaaS clássico, sem o peso de administrar servidor.

SaaS: software como serviço

SaaS é o software pronto, acessado pelo navegador ou por aplicativo, sem instalação nem administração de infraestrutura. O fornecedor cuida de tudo, do datacenter à correção de bug na aplicação. Você administra apenas seus dados, seus usuários e suas permissões.

E-mail corporativo, CRM, ferramenta de assinatura eletrônica, videoconferência e sistema de chamados são os exemplos mais comuns. A cobrança costuma seguir assinatura por usuário ou por consumo, o que troca investimento inicial por despesa recorrente.

A vantagem é evidente: adoção rápida, sem projeto de implantação de infraestrutura. Existe, porém, um efeito colateral conhecido. Como qualquer área contrata SaaS com um cartão corporativo, a empresa acumula ferramentas sem inventário, o que alimenta o problema de shadow IT e cria risco de dado corporativo fora de controle.

Vale registrar um mal-entendido caro. O fornecedor garante a disponibilidade do serviço, não a preservação eterna dos seus dados. Política de retenção, exportação periódica e plano de saída precisam estar no contrato antes da assinatura.

XaaS e EaaS: quando tudo vira serviço

XaaS é o guarda-chuva que descreve a tendência de transformar qualquer produto de tecnologia em serviço consumido sob demanda. A sigla significa anything as a service ou everything as a service. Ela não é um quarto modelo ao lado dos outros três: é o nome do movimento que os engloba.

Sob esse guarda-chuva cabem dezenas de recortes comerciais: desktop como serviço, backup como serviço, segurança como serviço, rede sem fio como serviço, monitoramento como serviço. Cada um adapta a mesma lógica de assinatura a um pedaço diferente da TI.

Um alerta de vocabulário: EaaS aparece na literatura ora como everything as a service, ora como enterprise as a service. Como o termo é ambíguo e pouco usado em contrato, prefira XaaS quando quiser falar do conceito guarda-chuva.

Do ponto de vista prático, o que importa não é a sigla do fornecedor. Importa onde a fronteira de responsabilidade foi desenhada, quanto custa sair depois e qual métrica prova que o serviço entregou o que prometeu.

Quem é responsável por quê em cada modelo?

A responsabilidade é compartilhada e a divisão muda conforme o modelo. O provedor sempre responde pela segurança da nuvem, ou seja, datacenter, hardware e camada de virtualização. O cliente sempre responde pela segurança na nuvem: seus dados, seus acessos e suas configurações. O que se desloca entre IaaS, PaaS e SaaS é a faixa do meio.

O modelo de responsabilidade compartilhada documentado pela Amazon descreve essa fronteira em detalhe. Os demais provedores públicos adotam desenho equivalente, com nomes ligeiramente diferentes.

Três configurações concentram a maior parte dos incidentes, independentemente do modelo contratado. Armazenamento exposto publicamente por engano, credencial com permissão ampla demais e ausência de autenticação em múltiplos fatores nas contas administrativas.

Nenhuma dessas falhas é responsabilidade do provedor. Elas moram exatamente na faixa que continua sua em qualquer degrau da escada, tema tratado em profundidade no material sobre segurança em cloud computing.

Como escolher entre IaaS, PaaS e SaaS?

A escolha começa por uma pergunta simples: essa capacidade diferencia o seu negócio? Se não diferencia, compre pronto em SaaS. Se diferencia mas roda sobre tecnologia comum, use PaaS e concentre o esforço no código. Se exige controle profundo do ambiente ou tem restrição regulatória específica, fique em IaaS.

Quatro critérios costumam decidir o empate. Volume de personalização necessário, exigência de conformidade sobre onde o dado reside, competência disponível no time interno e o custo de sair do fornecedor mais tarde.

Esse último merece cálculo próprio antes da assinatura. Ele reúne três parcelas. A primeira é exportar os dados no formato que outro fornecedor aceita. A segunda é reescrever integrações que dependiam de recursos exclusivos. A terceira é treinar o time na nova ferramenta.

Na prática, quase nenhuma empresa escolhe um modelo só. O desenho comum combina os três. A decisão acontece por carga de trabalho, não por diretriz geral. Quem está estruturando esse caminho encontra o passo a passo no guia de migração para nuvem.

O que muda no custo e no monitoramento de cada modelo

A conta muda de forma junto com o modelo. IaaS cobra por recurso provisionado, então máquina ligada sem uso vira desperdício direto. PaaS costuma cobrar por consumo, o que faz o valor oscilar com o tráfego. SaaS cobra por assinatura. O desperdício aparece em licença atribuída a quem saiu da empresa.

Esses três padrões de desperdício exigem controle contínuo, não revisão anual. A disciplina de FinOps existe justamente para atribuir custo a quem consome e transformar economia em rotina, com dono definido para cada linha da fatura.

Do lado do monitoramento, a regra segue a mesma escada. Quanto mais alto o degrau, menos você enxerga por dentro e mais precisa medir por fora, do ponto de vista de quem usa o serviço.

Em IaaS você coleta métrica de sistema operacional, disco e rede. Em PaaS observa métrica exposta pela plataforma, latência e taxa de erro da aplicação. Em SaaS resta medir disponibilidade e tempo de resposta a partir do usuário, além de acompanhar o histórico de indisponibilidade do fornecedor.

Vale registrar que o SLA do contrato não é evidência. Ele descreve a promessa. A medição própria é o que sustenta uma conversa de renovação com dado em mãos, tema que atravessa todo o guia de cloud computing do blog.

Erros comuns ao adotar modelos como serviço

Alguns tropeços se repetem em empresas de portes bem diferentes. Reconhecê-los antes da assinatura evita retrabalho caro.

• Supor que backup é do provedor: em SaaS, retenção costuma ser curta e o dado apagado por engano some depois da janela.
• Ignorar o custo de saída: exportar histórico anos depois pode custar mais que a migração original.

• Levantar IaaS para tudo: a migração fica fácil, porém o time herda a mesma carga operacional de antes.
• Contratar SaaS sem inventário: sem dono e sem catálogo, ninguém sabe quantas ferramentas a empresa paga.

Há ainda um erro silencioso: não medir nada. Sem métrica própria de disponibilidade, a discussão sobre qualidade do serviço vira troca de impressões entre cliente e fornecedor. O histórico registrado é o que dá lastro a um pedido de crédito contratual.

Conclusão

IaaS, PaaS e SaaS descrevem degraus de uma mesma escada. A cada degrau, o provedor assume mais camadas e você fica com menos trabalho operacional, porém também com menos controle sobre como as coisas funcionam por baixo.

Guardar essa lógica evita a maior parte dos erros. Dados e acessos continuam seus nos três modelos. O que muda é quem cuida do sistema operacional, do runtime e da aplicação, ou seja, exatamente a faixa que define quanto esforço a sua equipe vai gastar depois da contratação.

Comece pelo inventário. Liste o que a empresa já consome em cada modelo, marque quem responde por cada item e verifique se existe medição própria de disponibilidade. Boa parte das surpresas de custo e de indisponibilidade nasce de serviço contratado que ninguém acompanha.

Quer enxergar disponibilidade, performance e custo dos seus ambientes em nuvem em um lugar só? Fale com um especialista da OpServices e veja como medir o que hoje depende da palavra do fornecedor.