Licenciamento Windows Server é um daqueles assuntos que todo gestor de TI sabe que precisa resolver, mas que vai empurrando até o dia em que a Microsoft (ou um auditor terceirizado) bate na porta. Aí começa a correria, a planilha de emergência e aquele desconforto de descobrir que o ambiente está subdimensionado há dois anos.

O curioso é que o problema contrário também é comum. Já vi empresas pagando por licenças Datacenter em servidores que rodam duas VMs. Duas. É como alugar um galpão de 5.000 m² para guardar três caixas.

Este guia cobre o que você realmente precisa saber sobre o licenciamento do Windows Server e do SQL Server: modelo por core, CALs, virtualização, as pegadinhas de cada edição e como o Software Assurance entra nessa conta. Sem enrolação, com os números que importam.

Licenciamento Windows Server por core: como funciona na prática

Desde o Windows Server 2016, a Microsoft abandonou o modelo por processador e adotou o licenciamento por core. A ideia parece simples, mas tem regras que pegam muita gente de surpresa.

O ponto de partida: cada servidor físico exige no mínimo 16 cores licenciados. E cada processador físico exige no mínimo 8 cores licenciados. As licenças são vendidas em pacotes de 2 cores.

Na prática, se o seu servidor tem dois processadores de 12 cores cada (24 cores físicos no total), você precisa licenciar 24 cores. Mas se tiver um único processador de 4 cores, ainda assim precisa licenciar 16, porque o mínimo por servidor é 16. O mínimo por processador (8) também se aplica, então um servidor com dois processadores de 4 cores cada totaliza 16 cores obrigatórios (8 por processador).

Parece burocrático? É. Mas entender essa conta evita dois problemas: pagar por cores que não existem fisicamente (quando o servidor já tem mais que o mínimo) e comprar menos do que deveria (quando o servidor tem processadores com muitos cores e você só comprou o pacote básico de 16).

Mínimos que você precisa decorar

• Mínimo por servidor físico: 16 cores
• Mínimo por processador físico: 8 cores
• Licenças vendidas em pacotes de 2 cores
• Se a soma dos cores reais ultrapassar 16, você licencia o total real

Standard vs Datacenter: a diferença que pesa no bolso

As duas edições usam exatamente o mesmo modelo de licenciamento por core. A diferença mora nos direitos de virtualização.

O Windows Server Standard dá direito a rodar até 2 máquinas virtuais (VMs) no servidor físico licenciado, mais o próprio host (se ele rodar o papel de Hyper-V). Quer rodar mais VMs? Você pode comprar licenças Standard adicionais para o mesmo servidor. A cada conjunto de licenças Standard que cobre todos os cores físicos, você ganha direito a mais 2 VMs.

Então, se o servidor tem 24 cores e você quer 6 VMs do Windows Server, precisa de três conjuntos de 24 cores Standard. A conta começa a ficar salgada.

O Windows Server Datacenter resolve isso de forma direta: licenciou todos os cores físicos uma vez, roda quantas VMs quiser. Sem limite. Por isso custa mais por core, mas para ambientes com alta densidade de virtualização, geralmente compensa.

Quando cada edição faz sentido

Se o servidor roda 1 ou 2 VMs (ou nenhuma), Standard. Se roda 4 ou mais, faça a conta: geralmente a partir de 4 a 6 VMs no mesmo host, o Datacenter já empata ou fica mais barato que empilhar Standard. A partir de 8 VMs, não tem discussão.

Na minha experiência, o erro mais frequente é licenciar Standard em hosts de virtualização que já passaram de 6 VMs faz tempo. O time de infra foi subindo VMs, ninguém avisou compras, e quando o auditor chega, o gap é enorme.

CALs do Windows Server: usuário, dispositivo e o caso do RDS

Licenciar os cores do servidor é só metade da história. Para que usuários ou dispositivos acessem os serviços do Windows Server, você precisa de CALs (Client Access Licenses).

Existem dois tipos:

CAL de dispositivo: cada máquina que acessa o servidor precisa de uma CAL, independentemente de quantos usuários usem aquela máquina. Funciona bem quando vários funcionários dividem o mesmo computador (turnos em fábrica, por exemplo).

CAL de usuário: cada pessoa que acessa o servidor precisa de uma CAL, não importa de quantos dispositivos ela acesse. Melhor para quem usa notebook, celular e tablet alternadamente.

Você pode misturar os dois tipos no mesmo ambiente, mas cada CAL é de um tipo só. Não existe CAL híbrida. E aqui vai um detalhe que muita gente ignora: a CAL não é atribuída a um servidor específico. Ela dá direito de acesso a qualquer servidor Windows Server do mesmo tipo (Standard ou Datacenter) na organização. Isso facilita, mas também significa que o número total de CALs tem que cobrir todos os usuários ou dispositivos que acessam qualquer servidor.

RDS CALs: uma licença à parte

Se alguém acessa o servidor via Remote Desktop Services (área de trabalho remota, terminal server), a CAL padrão do Windows Server não basta. É preciso uma RDS CAL adicional, que também vem nas versões usuário e dispositivo.

Isso pega muitas empresas porque o acesso remoto se popularizou e ninguém contabilizou as RDS CALs separadamente. Cada sessão de Remote Desktop sem a RDS CAL correspondente é uma não conformidade em auditoria.

Ponto de atenção: RDS CALs precisam ser da mesma versão ou superior ao servidor que está provendo o serviço. Se o servidor é Windows Server 2022, as RDS CALs precisam ser da versão 2022.

Licenciamento SQL Server: por core ou Server + CAL

O SQL Server tem dois caminhos de licenciamento, e a escolha entre eles muda completamente o custo.

Modelo por core

Funciona de forma parecida com o Windows Server. Você licencia os cores físicos do servidor (ou da VM, dependendo do cenário). O mínimo é 4 cores por servidor, vendidos em pacotes de 2. Esse modelo não exige CALs. Qualquer usuário ou aplicação pode acessar o banco sem licença adicional do lado do cliente.

É o modelo obrigatório quando o SQL Server é acessado pela internet ou por um número indeterminado de usuários (aplicações web, sistemas SaaS internos, APIs abertas). Se você não consegue contar quantos usuários vão acessar, core é o caminho.

Modelo Server + CAL

Aqui você compra uma licença de servidor (por servidor, não por core) e uma CAL de SQL Server para cada usuário ou dispositivo que acessa o banco. É mais barato quando o número de usuários é pequeno e bem definido. Mas atenção: se esse sistema é acessado por um formulário web público ou por uma aplicação que atende clientes externos, o modelo Server + CAL não é permitido.

SQL Server Standard vs Enterprise

O SQL Server Standard tem limites técnicos que muita gente só descobre na hora errada: máximo de 128 GB de RAM por instância, 24 cores por instância e sem suporte a Always On Availability Groups com múltiplas réplicas síncronas (a versão Standard permite Basic Availability Groups, que é limitado a um banco por grupo).

O Enterprise remove esses limites e adiciona funcionalidades de alta disponibilidade, particionamento de tabelas, compressão avançada e In-Memory OLTP sem restrições. O custo por core, porém, é significativamente maior.

Para muitas empresas de médio porte, o Standard atende. Mas se o banco de dados cresceu, se a aplicação exige alta disponibilidade real e o RPO/RTO é apertado, o Enterprise passa a ser necessidade, não luxo.

Como licenciar SQL Server em máquinas virtuais

Aqui é onde a coisa fica interessante (e onde os erros se multiplicam).

No modelo por core, você pode licenciar apenas os cores virtuais atribuídos à VM, com um mínimo de 4 cores por VM. Isso vale tanto para o Standard quanto para o Enterprise. Mas existe uma condição: a VM precisa estar com os cores fixos (não pode usar alocação dinâmica de processador no Hyper-V, por exemplo, sem tomar cuidado com as regras).

Se o host roda muitas VMs com SQL Server, o Enterprise oferece uma alternativa: você pode licenciar todos os cores físicos do host e, com isso, rodar quantas VMs com SQL Server Enterprise quiser naquele servidor. É o equivalente ao Datacenter do Windows Server, mas para o SQL.

Já o SQL Server Standard licenciado por core na VM não tem essa opção de licenciar o host inteiro. Cada VM precisa dos seus cores licenciados individualmente.

Na hora de consolidar ambientes virtualizados com SQL Server, essa conta precisa ser feita com cuidado. Já presenciei situações em que a empresa licenciou o SQL Standard por VM, mas o host tinha 12 VMs com SQL. Licenciar o Enterprise no host inteiro teria saído mais barato. Ninguém fez a conta até a auditoria aparecer.

Software Assurance: o que você ganha (e o que não ganha)

O Software Assurance (SA) é um programa de manutenção da Microsoft, geralmente adquirido junto com a licença ou em acordos de volume. Ele não é obrigatório, mas abre portas que podem valer muito, dependendo do cenário.

Os benefícios mais relevantes para servidores:

• Direito a novas versões: enquanto o SA estiver ativo, você recebe upgrades para versões mais recentes do Windows Server e SQL Server sem custo adicional de licença
• Mobilidade de licenças: permite mover licenças de um servidor para outro (incluindo entre data centers próprios) sem precisar comprar novas, respeitando regras de frequência (a cada 90 dias, em geral)
• Azure Hybrid Benefit: este é o benefício que mais muda a conta para quem usa nuvem. Com SA ativo no Windows Server ou SQL Server, você pode usar essas licenças em VMs no Azure sem pagar o custo do software na VM. A economia pode chegar a 40% ou mais no custo da VM do Azure, dependendo do tamanho e da configuração
• Suporte estendido, treinamento e planejamento de deployment

O Azure Hybrid Benefit, em particular, é subutilizado. Muitas empresas pagam o preço cheio das VMs no Microsoft Azure sem perceber que já têm licenças on-premises com SA que poderiam abater o custo. Se sua empresa está migrando cargas para o Azure, ou opera em modelo de cloud híbrida, verificar o SA das licenças existentes deveria ser o primeiro passo.

Mas o SA tem custo. Ele é renovado anualmente e, se você deixar expirar, perde os benefícios e pode precisar comprar licenças novas para voltar ao programa. A decisão de manter ou não o SA depende de quanto você aproveita esses direitos.

Quais são os riscos reais de subdimensionar o licenciamento?

A Microsoft conduz auditorias de licenciamento (geralmente via consultorias terceirizadas como a própria SAM Partner da Microsoft) e os resultados podem ser desconfortáveis.

Se a auditoria encontra não conformidade, a empresa tem um prazo para regularizar. Isso significa comprar as licenças faltantes pelo preço de tabela vigente, sem desconto de volume, sem negociação amigável. Em alguns casos, o custo retroativo inclui o SA que deveria ter sido pago durante o período de uso irregular.

O impacto financeiro não é o único problema. A auditoria consome tempo do time de TI (que precisa levantar inventário, justificar configurações, mapear VMs) e gera atrito entre TI, compras e diretoria.

Tem algo errado quando uma empresa paga R$ 200 mil a mais em licenciamento retroativo só porque ninguém revisou o mapeamento de cores e CALs nos últimos três anos. Mas acontece. E acontece com frequência suficiente para ser um risco que merece atenção no planejamento anual de TI.

Quem já passou por uma auditoria de TI sabe: a hora de arrumar a casa é antes da carta chegar, não depois.

O que verificar no seu ambiente hoje

Antes de contratar qualquer coisa, um inventário honesto do ambiente responde 80% das dúvidas de licenciamento. Aqui vai o que olhar:

1. Quantos servidores físicos existem, quantos processadores e quantos cores cada um tem
2. Quantas VMs Windows Server rodam em cada host e qual edição está instalada
3. Quantos usuários e dispositivos acessam esses servidores (para dimensionar CALs)
4. Se existe uso de Remote Desktop Services e quantas RDS CALs foram adquiridas
5. Quantas instâncias de SQL Server existem, em que edição, e se rodam em servidor físico ou VM
6. Se as licenças atuais têm Software Assurance ativo e qual é a data de expiração
7. Se há VMs no Azure que poderiam se beneficiar do Azure Hybrid Benefit

Esse levantamento parece trabalhoso, e é. Mas é infinitamente mais barato do que fazer tudo isso sob pressão de uma auditoria com prazo de 30 dias para responder.

Perguntas frequentes sobre licenciamento de servidores Microsoft

Posso usar a mesma CAL do Windows Server para acessar servidores Standard e Datacenter?

Sim. A CAL do Windows Server dá direito de acesso independentemente da edição do servidor (Standard ou Datacenter). A versão da CAL precisa ser igual ou superior à versão do servidor. Uma CAL do Windows Server 2022 acessa servidores 2019 e 2022, mas uma CAL 2019 não acessa um servidor 2022.

Se eu licenciar SQL Server por core, ainda preciso de CALs de SQL?

Não. O modelo por core do SQL Server dispensa CALs. Qualquer número de usuários pode acessar a instância. Esse é justamente o motivo pelo qual o modelo por core é exigido quando o acesso é feito pela internet ou por usuários que não podem ser contabilizados individualmente.

O Azure Hybrid Benefit funciona com qualquer licença de Windows Server?

Não. O Azure Hybrid Benefit exige que a licença tenha Software Assurance ativo. Licenças avulsas sem SA não dão direito ao benefício. Além disso, o benefício se aplica a edições específicas (Windows Server Standard e Datacenter) e segue regras de conversão de cores que vale conferir nos Product Terms da Microsoft antes de aplicar.

A conta que ninguém faz (mas deveria)

O licenciamento de Windows Server e SQL Server não é um custo que se resolve uma vez e se esquece. Ambientes mudam. VMs são criadas. Novos serviços aparecem. O time de infra sobe mais um host de virtualização e ninguém avisa compras.

O que separa as empresas que passam por auditorias sem susto das que levam multa é um processo simples: revisar o mapeamento de licenciamento de software pelo menos uma vez por semestre, cruzando o inventário real com as licenças adquiridas. Parece óbvio. Mas na correria do dia a dia, é a primeira coisa que fica para depois.

Se você não tem certeza de que o licenciamento dos seus servidores está correto (e se não revisou nos últimos 12 meses, provavelmente não está), vale buscar ajuda especializada. A Omega Brasil faz esse tipo de análise com frequência, revisando o ambiente, identificando gaps e oportunidades de economia como o Azure Hybrid Benefit, e ajustando o licenciamento antes que o problema apareça.

Porque no fim, o mais caro não é a licença. É a licença que você descobre que deveria ter comprado dois anos atrás.