O Azure Virtual Desktop é uma solução extremamente poderosa para entregar desktops e aplicações remotas com flexibilidade, segurança e escalabilidade.
Mas existe um ponto que muitas organizações ainda tratam de forma superficial:
o dimensionamento correto dos session hosts.
Em muitos ambientes, o custo do AVD não aumenta apenas pela quantidade de usuários. Ele aumenta porque o ambiente foi desenhado com mais máquinas virtuais do que realmente precisa.
E isso normalmente acontece por um motivo simples:
a organização trata o AVD como se fosse apenas um conjunto de máquinas virtuais comuns no Azure.
Mas no Azure Virtual Desktop multi-session, a lógica é diferente.
Por que o dimensionamento do AVD é diferente de uma VM comum?
Em uma máquina virtual tradicional, normalmente pensamos em uma VM para uma finalidade específica: um servidor, uma aplicação ou até um usuário.
No Azure Virtual Desktop multi-session, a lógica muda.
Uma única VM pode atender vários usuários ao mesmo tempo.
Por isso, o dimensionamento não deve começar apenas pela pergunta:
“Qual tamanho de VM eu vou criar?”
Ele deve começar por outra pergunta:
“Quantos usuários simultâneos cada vCPU dessa VM consegue suportar com boa performance?”
Esse é um ponto que muitas organizações não consideram.
A documentação da Microsoft diferencia cenários de sessão única, onde um usuário se conecta a um host por vez, e cenários de várias sessões, onde mais de um usuário se conecta simultaneamente à mesma VM de host de sessão. Nesse modelo multi-session, a Microsoft reforça que o host tem um limite máximo de carga antes que seus recursos sejam esgotados. (Microsoft Learn)
Por exemplo, em um cenário de workload médio, a Microsoft utiliza como referência até 4 usuários por vCPU.
Isso significa que:
4 vCPUs podem atender até 16 usuários médios.
8 vCPUs podem atender até 32 usuários médios.
Esses números não são uma regra fixa, porque dependem do perfil do usuário, das aplicações utilizadas, da memória, do disco, da rede, do tempo de logon e do consumo real do ambiente.
Mas eles ajudam a evitar um erro comum:
criar mais session hosts do que o necessário porque poucos usuários foram distribuídos em cada VM.
Na prática, é comum encontrar ambientes onde uma máquina poderia atender 12 ou 16 usuários, mas está sendo utilizada por apenas 4 ou 5.
O ambiente funciona? Provavelmente sim.
Mas financeiramente, talvez ele esteja mal dimensionado.
Em AVD, custo não é apenas sobre quantas VMs existem. É sobre quantos usuários cada vCPU consegue atender com boa experiência.
O problema não é o AVD. O problema pode estar no dimensionamento.
Quando uma empresa começa um projeto de Azure Virtual Desktop, é comum a discussão começar por perguntas como:
Qual VM vamos utilizar?
Quantos session hosts vamos criar?
Qual família de máquina é melhor?
Quantos usuários vamos colocar por VM?
Como garantir performance?
Como reduzir custo?
Essas perguntas são importantes, mas existe uma pergunta anterior:
quem são os usuários e qual carga de trabalho eles realmente executam?
A Microsoft reforça que o dimensionamento de hosts de sessão para Azure Virtual Desktop exige análise cuidadosa dos tipos de carga de trabalho e das configurações de hardware, porque workloads diferentes exigem recursos diferentes para garantir uma boa experiência de uso. (Microsoft Learn)
Um usuário que acessa apenas um sistema interno ou uma aplicação web simples não consome os mesmos recursos que um desenvolvedor, um analista com várias aplicações abertas ou um usuário que trabalha com CAD, edição de imagem, vídeo ou aplicações gráficas.
Quando todos esses perfis são tratados da mesma forma, o ambiente pode acabar com dois problemas:
Superdimensionamento: mais VMs do que o necessário, gerando custo maior.
Subdimensionamento: poucas VMs ou poucos recursos, gerando lentidão e reclamações.
O objetivo do sizing correto é encontrar o equilíbrio entre:
experiência do usuário, performance, estabilidade e custo operacional.
O erro mais comum: poucos usuários por session host
Um dos erros mais comuns em ambientes de AVD é distribuir poucos usuários por máquina virtual.
Imagine um ambiente com 80 usuários.
Se a empresa coloca apenas 5 usuários por VM, ela precisará de aproximadamente 16 máquinas virtuais.
Agora imagine que, após uma análise correta de perfil, concorrência e consumo, seja possível trabalhar com 10 a 12 usuários por VM, mantendo boa experiência.
Nesse cenário, a quantidade de session hosts poderia ser reduzida de forma significativa.
O ponto aqui não é colocar o máximo de usuários possível em cada máquina.
O ponto é usar a capacidade correta.
A Microsoft destaca que o planejamento de capacidade deve considerar carga de trabalho, contagem de usuários simultâneos, CPU, memória, armazenamento, rede, expectativas de desempenho, escalabilidade, resiliência, monitoramento e otimização contínua. (Microsoft Learn)
AVD não começa na máquina virtual. Começa no perfil do usuário.
Para dimensionar corretamente um ambiente de Azure Virtual Desktop, a primeira etapa deveria ser a classificação dos usuários.
Nem todo usuário tem o mesmo comportamento.
Nem toda área consome os mesmos recursos.
Nem toda aplicação tem o mesmo impacto no ambiente.
A documentação da Microsoft organiza os workloads em quatro tipos principais: leve, médio, pesado e power. Cada perfil possui exemplos diferentes de usuários e aplicações, o que ajuda a definir a densidade esperada por host de sessão. (Microsoft Learn)
| Perfil | Exemplo de usuário | Tipo de uso |
| Leve | Operadores, usuários de entrada de dados | Sistemas simples, aplicações básicas, linha de comando, baixa utilização de recursos |
| Médio | Consultores, pesquisadores, áreas administrativas | Microsoft Word, sistemas corporativos, páginas web estáticas |
| Pesado | Desenvolvedores, criadores de conteúdo, usuários avançados | Outlook, PowerPoint, páginas web dinâmicas, desenvolvimento de software |
| Power | Designers, CAD, 3D, edição, machine learning | Edição de fotos e vídeos, CAD, CAM, aplicações gráficas e intensivas |
Essa separação é essencial porque a quantidade de usuários suportada por uma VM muda completamente conforme o perfil.
Uma mesma máquina pode atender muitos usuários leves, mas poucos usuários power.
Como funciona o cálculo de usuários por vCPU
Em ambientes multi-session, vários usuários compartilham a mesma máquina virtual.
Por isso, uma métrica essencial no dimensionamento é a relação entre:
usuários simultâneos x vCPU.
A Microsoft apresenta uma referência inicial para workloads multi-session, indicando o número máximo sugerido de usuários por vCPU conforme o tipo de carga de trabalho. (Microsoft Learn)
| Tipo de workload | Máximo sugerido de usuários por vCPU |
| Leve | até 6 usuários por vCPU |
| Médio | até 4 usuários por vCPU |
| Pesado | até 2 usuários por vCPU |
| Power | até 1 usuário por vCPU |
Esse é o ponto que muitas empresas não sabem.
O cálculo de capacidade no AVD não deve ser feito apenas pensando em:
“quantos usuários eu tenho no total?”
Ele precisa considerar:
“quantos usuários simultâneos cada vCPU consegue suportar dentro daquele perfil de uso?”
Esses números não devem ser tratados como regra absoluta.
Eles são uma referência inicial.
Cada ambiente precisa ser validado com piloto, simulação, monitoramento e ajustes contínuos, considerando métricas como CPU, memória, disco, rede, tempo de logon e experiência do usuário. A própria Microsoft orienta usar as diretrizes como estimativas iniciais e ajustar conforme as necessidades reais dos usuários. (Microsoft Learn)
Quais famílias de máquinas virtuais fazem sentido para AVD?
Depois de entender o perfil do usuário e a relação de usuários por vCPU, o próximo passo é escolher a família de máquina virtual adequada.
Esse ponto é importante porque o AVD não deve ser dimensionado apenas olhando quantidade de vCPU.
Também é necessário considerar:
- memória;
- tipo de processador;
- tipo de disco;
- capacidade de rede;
- necessidade de GPU;
- comportamento da aplicação;
- tempo de logon;
- consumo real dos usuários.
A documentação da Microsoft traz exemplos de instâncias Azure para workloads multi-session. Para workloads leves, médios e pesados, aparecem como exemplos as famílias e tamanhos:
- D8s_v5
- D8s_v4
- F8s_v2
- D8as_v4
- D16s_v5
- D16s_v4
- F16s_v2
- D16as_v4
Para workloads Power, a documentação cita exemplos como:
- D16ds_v5
- D16s_v4
- D16as_v4
- NV6
- NV16as_v4
Esses exemplos não significam que toda empresa deve usar exatamente essas máquinas, mas servem como uma referência inicial para desenho e validação do ambiente. A mesma tabela da Microsoft também apresenta, para multi-session, recursos mínimos de VM e armazenamento de perfil para cada tipo de workload. (Microsoft Learn)
Como interpretar essas famílias no contexto do AVD?
De forma prática:
| Família / Série | Quando avaliar no AVD | Exemplo de uso |
| D-series / Das-series / Dds-series | Uso geral, bom equilíbrio entre CPU e memória | Usuários leves, médios e parte dos pesados |
| F-series | Cenários com maior demanda de CPU | Aplicações mais dependentes de processamento |
| NV-series | Workloads gráficos com necessidade de GPU | CAD, 3D, edição, visualização e aplicações gráficas |
| B-series | Usar com muito cuidado em AVD produtivo | Cenários muito específicos, dev/test ou workloads não sustentados |
A família D costuma ser uma escolha comum para AVD porque entrega um bom equilíbrio entre CPU e memória para vários cenários corporativos.
A família F pode fazer sentido quando a aplicação exige mais processamento.
Já a família NV deve ser avaliada quando o usuário possui workloads gráficos, como CAD, 3D, edição ou aplicações que exigem GPU.
Um cuidado importante é com a família B-series. Máquinas B-series trabalham com modelo de créditos de CPU: elas acumulam créditos quando operam abaixo da performance base e consomem créditos quando precisam performar acima dessa base. Quando os créditos acabam, a VM retorna ao desempenho base até acumular créditos novamente. Por isso, para workloads sustentados ou ambientes AVD produtivos com consumo constante, é necessário avaliar com cautela. (Microsoft Learn)
Exemplo prático usando D8s_v5
Vamos considerar um ambiente com usuários de perfil médio.
A Microsoft utiliza como referência para workload médio até 4 usuários por vCPU em multi-session. (Microsoft Learn)
Nesse caso, uma VM com 8 vCPUs, como uma D8s_v5, poderia ser considerada inicialmente para até 32 usuários médios, desde que o consumo real de aplicações, memória, disco, rede e experiência do usuário sejam validados.
Exemplo:
| VM | vCPU | Perfil | Referência de usuários por vCPU | Capacidade inicial estimada |
| D8s_v5 | 8 | Médio | até 4 usuários por vCPU | até 32 usuários |
| D16s_v5 | 16 | Médio | até 4 usuários por vCPU | até 64 usuários |
| D8s_v5 | 8 | Pesado | até 2 usuários por vCPU | até 16 usuários |
| NV16as_v4 | 16 | Power / gráfico | até 1 usuário por vCPU | até 16 usuários |
Mas existe um ponto importante:
não significa que você deve sempre colocar o máximo de usuários possível em uma VM.
A tabela é uma referência inicial.
O ambiente precisa ser validado com piloto, monitoramento e análise de consumo real.
Uma D8s_v5 pode fazer sentido para um cenário médio bem distribuído, mas pode ser insuficiente para um workload gráfico ou superdimensionada para poucos usuários leves.
O contexto define o sizing.
Exemplo prático: VM com 8 vCPUs
Vamos considerar uma VM com 8 vCPUs em um cenário multi-session.
Dependendo do perfil dos usuários, a capacidade estimada pode mudar bastante:
| Perfil | Cálculo | Capacidade estimada |
| Leve | 8 vCPUs x 6 usuários | até 48 usuários |
| Médio | 8 vCPUs x 4 usuários | até 32 usuários |
| Pesado | 8 vCPUs x 2 usuários | até 16 usuários |
| Power | 8 vCPUs x 1 usuário | até 8 usuários |
Agora imagine que uma organização utiliza uma VM de 8 vCPUs para apenas 4 ou 5 usuários médios.
Do ponto de vista técnico, provavelmente o ambiente terá performance.
Mas do ponto de vista financeiro, talvez exista capacidade sendo mal aproveitada.
Se os usuários são médios e a VM possui capacidade para atender mais usuários com segurança, a empresa pode estar utilizando mais session hosts do que realmente precisa.
É nesse momento que o Azure Virtual Desktop começa a ser percebido como uma solução cara.
Mas talvez o problema não esteja no AVD.
Talvez esteja no desenho inicial.
O impacto financeiro de um sizing incorreto
O custo em Azure Virtual Desktop não está apenas no tamanho da VM.
Também está na quantidade de máquinas virtuais provisionadas.
Quando o ambiente é desenhado com baixa densidade de usuários por session host, a empresa tende a criar mais VMs para atender a mesma quantidade de usuários.
Exemplo:
Uma empresa com 80 usuários decide distribuir apenas 5 usuários por VM.
Resultado: aproximadamente 16 VMs.
Agora imagine que, após análise do perfil de uso, seja identificado que os usuários são de perfil médio e podem ser distribuídos com maior densidade por host, mantendo uma margem de segurança e boa experiência.
Nesse cenário, talvez o ambiente não precise de 16 máquinas.
Talvez precise de menos session hosts, melhor distribuídos, com autoscaling e monitoramento.
Isso não significa reduzir máquinas de forma irresponsável.
Significa dimensionar com base em dados.
A Microsoft recomenda considerar usuários simultâneos, carga de trabalho, requisitos de recursos, expectativas de desempenho e margem para picos inesperados durante o planejamento de capacidade. (Microsoft Learn)
Cuidado: VM maior nem sempre significa melhor ambiente
Outro erro comum é imaginar que, para melhorar o ambiente, basta criar VMs maiores.
Na prática, isso nem sempre é verdade.
A Microsoft destaca que dobrar o número de núcleos de CPU não necessariamente dobra a capacidade de usuários. Conforme o número de núcleos aumenta, existe diminuição de retorno e maior sobrecarga de sincronização. (Microsoft Learn)
Em cenários multi-session, a documentação também recomenda limitar o tamanho das VMs entre 4 e 24 vCPUs na maioria dos casos. A Microsoft explica que quatro núcleos é o menor número recomendado para uma VM multi-session estável e que, para muitos cenários, várias VMs menores podem entregar uma experiência melhor do que poucas VMs muito grandes. (Microsoft Learn)
Esse ponto é importante porque reforça que o sizing correto não é apenas escolher a maior máquina disponível.
O desenho precisa considerar:
- densidade de usuários;
- distribuição de carga;
- tempo de logon;
- performance das aplicações;
- consumo de CPU e memória;
- capacidade de desligar hosts sem usuários;
- manutenção;
- autoscaling;
- custo.
Em muitos cenários, várias VMs menores e bem distribuídas podem ser mais eficientes do que poucas VMs grandes sempre ligadas.
Autoscaling ajuda, mas não substitui um bom dimensionamento
O autoscaling é uma funcionalidade essencial em ambientes de Azure Virtual Desktop.
Ele permite ligar e desligar session hosts conforme a demanda, ajudando a reduzir custos em horários de menor utilização.
Mas existe um ponto importante:
autoscaling não corrige sozinho um ambiente mal dimensionado.
Se a organização criou mais máquinas virtuais do que precisava desde o início, o autoscaling pode ajudar a reduzir parte do custo, mas o problema estrutural continua existindo.
Antes do autoscaling, é necessário entender:
- quantos usuários acessam simultaneamente;
- qual é o perfil de consumo;
- quantos usuários cada VM pode suportar;
- qual família de VM faz sentido;
- qual margem de segurança será adotada;
- como será feita a distribuição entre session hosts;
- quais métricas serão monitoradas.
A documentação da Microsoft destaca que VMs menores podem ser mais fáceis de desligar quando não estão em uso, inclusive manualmente ou automaticamente com autoscaling no Azure Virtual Desktop, ajudando a conservar recursos e reduzir custos. (Microsoft Learn)
Dimensionamento precisa ser validado com piloto e monitoramento
Nenhuma tabela substitui a análise real do ambiente.
As recomendações de usuários por vCPU são uma excelente base para iniciar o desenho, mas cada organização possui suas particularidades.
Aplicações diferentes consomem recursos diferentes.
Usuários diferentes possuem hábitos diferentes.
Horários de pico podem alterar completamente o comportamento do ambiente.
A Microsoft recomenda duas abordagens para ajudar na definição de capacidade: piloto e simulação. No piloto, um servidor de teste é implantado e a carga aumenta gradualmente enquanto indicadores como CPU, paginação, disco, rede e feedback dos usuários são monitorados. Na simulação, ferramentas de automação geram cargas de trabalho semelhantes ao comportamento real dos usuários. (Microsoft Learn)
Também é importante considerar horários críticos, como início do expediente ou troca de turno, onde muitos usuários podem fazer logon ao mesmo tempo.
Uma VM pode suportar determinada quantidade de usuários em estado normal, mas apresentar lentidão quando todos fazem logon simultaneamente.
Por isso, um projeto bem conduzido deve seguir uma abordagem em etapas.
Etapa 1: classificar os usuários
O primeiro passo é separar os usuários por perfil:
- leve;
- médio;
- pesado;
- power.
Não faz sentido tratar todos como se tivessem o mesmo consumo.
Uma área de atendimento, uma equipe administrativa, um time de desenvolvimento e uma equipe de engenharia podem ter necessidades completamente diferentes.
Essa classificação ajuda a definir o desenho inicial do ambiente.
Etapa 2: entender a concorrência real
Nem todo usuário licenciado estará conectado ao mesmo tempo.
Por isso, é necessário entender:
- quantos usuários acessam por turno;
- quantos acessam no pico;
- quantos fazem logon ao mesmo tempo;
- quais áreas possuem maior consumo;
- quais aplicações são críticas.
Esse ponto evita criar VMs com base apenas no número total de usuários.
O mais importante é entender a quantidade de usuários simultâneos.
Etapa 3: definir o sizing inicial
Com base no perfil dos usuários e na concorrência, é possível estimar:
- quantidade de session hosts;
- tamanho das VMs;
- família de máquinas;
- memória necessária;
- tipo de disco;
- estratégia de FSLogix;
- distribuição entre host pools;
- margem para crescimento.
Essa definição não precisa ser perfeita no primeiro desenho, mas precisa ser baseada em critérios técnicos.
Etapa 4: executar piloto controlado
Antes de expandir para todo o ambiente, o ideal é validar com usuários reais.
O piloto deve considerar:
- tempo de logon;
- consumo de CPU;
- consumo de memória;
- performance de aplicações críticas;
- comportamento do FSLogix;
- experiência do usuário;
- estabilidade das sessões;
- impacto em horários de pico.
Essa etapa ajuda a confirmar se o sizing teórico faz sentido na prática.
Etapa 5: monitorar e ajustar continuamente
AVD não deve ser tratado como um ambiente estático.
O comportamento dos usuários muda.
As aplicações mudam.
A quantidade de acessos muda.
A operação muda.
Por isso, o sizing precisa ser revisado periodicamente.
O ideal é acompanhar métricas como:
- CPU;
- memória;
- disco;
- rede;
- tempo de logon;
- quantidade de sessões por host;
- hosts ociosos;
- custo por máquina;
- custo por usuário;
- experiência percebida.
Com esses dados, a empresa consegue ajustar o ambiente de forma contínua.
O objetivo não é reduzir máquinas a qualquer custo
É importante reforçar:
o objetivo de um bom sizing não é colocar o maior número possível de usuários em cada VM.
Isso poderia prejudicar a experiência.
O objetivo é encontrar o equilíbrio entre:
densidade de usuários, performance, estabilidade, escalabilidade e custo.
Poucos usuários por VM podem gerar custo desnecessário.
Muitos usuários por VM podem gerar lentidão.
VMs muito grandes podem concentrar risco.
VMs pequenas demais podem aumentar administração e reduzir eficiência.
O desenho correto está no equilíbrio.
E esse equilíbrio só aparece quando o ambiente é analisado com base em dados reais.
Conclusão
Azure Virtual Desktop não deve começar pela criação das máquinas virtuais.
Deve começar pela análise do usuário.
Quem utiliza?
Como utiliza?
Quando utiliza?
Quais aplicações consome?
Quantos acessam simultaneamente?
Qual experiência é esperada?
Qual custo operacional faz sentido?
Quando essa análise não é feita, a organização pode acabar criando mais session hosts do que realmente precisa.
E, com isso, passa a pagar mais por compute, administrar mais máquinas e enxergar o AVD como uma solução cara.
Mas, muitas vezes, o problema não está no Azure Virtual Desktop.
Está na falta de dimensionamento.
AVD bem desenhado não é sobre criar mais máquinas para evitar problemas.
É sobre entender o perfil dos usuários, calcular corretamente a relação entre vCPU e usuários simultâneos, escolher a família adequada de VM, validar com piloto, aplicar autoscaling e monitorar continuamente o ambiente.
No Azure, custo não está apenas no tamanho da máquina.
Está também na quantidade de máquinas criadas sem necessidade.
Azure Virtual Desktop bem dimensionado começa no usuário, não na máquina virtual.
Referência
Este artigo foi baseado nas recomendações oficiais da Microsoft para dimensionamento de hosts de sessão em ambientes de Azure Virtual Desktop e Remote Desktop Services, especialmente nos pontos relacionados a planejamento de capacidade, tipos de workload, usuários por vCPU, famílias de máquinas virtuais, validação por piloto/simulação, escolha do tamanho das VMs e otimização contínua. (Microsoft Learn)
Também foi considerada a documentação da Microsoft sobre o modelo de créditos de CPU das VMs B-series, para reforçar o cuidado no uso dessa família em workloads com consumo sustentado. (Microsoft Learn)
0 comentário