Escalado automático AVD y grupos de hosts: modelo de costos

Todas las facturas de Azure Virtual Desktop que reviso tienen la misma forma: el proceso es la línea más grande con mucha diferencia, y una parte sorprendente de él estaba funcionando a las 2 de la madrugada para nadie. El escalado automático es la función que corrige esto, y la llegada de los grupos de hosts automatizados y el escalado automático dinámico que traté en el resumen de novedades de Azure Virtual Desktop de junio de 2026 lo mejoró. Pero la pregunta que me hacen los equipos de TI de Estados Unidos no es “¿el escalado automático ahorra dinero?”, sino “¿cuánto, en nuestro caso, y qué tenemos que cambiar?”. Esta guía lo responde con un modelo de costos que puede copiar en una hoja de cálculo: los componentes de costo, en qué se diferencian los dos métodos de escalado automático, un ejemplo resuelto con fórmulas, las palancas ordenadas por impacto, los límites que evitan que el ahorro se convierta en tickets del servicio de asistencia y cómo medir el resultado en Azure Cost Management. Cada afirmación sobre funciones está contrastada con las páginas de Microsoft Learn enlazadas en el texto y listadas en Fuentes. Los precios unitarios se dejan como marcadores de posición a propósito: varían según la región y el contrato, y los números correctos para usted son los que obtenga de la Calculadora de precios de Azure después de iniciar sesión.

Adónde va el dinero de Azure Virtual Desktop

La página de precios de Azure Virtual Desktop de Microsoft describe la factura en dos partes: los derechos de acceso de los usuarios y la infraestructura de Azure, formada por máquinas virtuales, almacenamiento para imágenes del sistema operativo, discos de datos y perfiles de usuario, y red, facturada con pago por uso o mediante reservas. En la práctica la divido en siete líneas, porque se comportan de forma distinta al activar el escalado automático.

Dos puntos de licencias importan para el modelo. Primero, para hosts de sesión con Windows 11 Enterprise multisesión las licencias aptas son Microsoft 365 E3, E5, A3, A5, F3, Business Premium y Student Use Benefit, Windows Enterprise E3 y E5, Windows Education A3 y A5, y Windows VDA por usuario; la página de licencias es explícita en que debe proporcionar una para cada usuario que acceda al servicio, y las preguntas frecuentes de multisesión señalan que estas licencias de Windows por usuario sustituyen a las licencias de acceso de cliente de RDS. Segundo, los hosts de sesión con Windows Server necesitan una CAL de RDS con Software Assurance o una licencia de suscripción de usuario de RDS, y ahí es donde entra más adelante la Ventaja híbrida de Azure para Windows Server. Ninguna de las dos líneas de licencias se mueve al escalar automáticamente, por eso el porcentaje titular sobre el proceso siempre es mayor que el porcentaje sobre la factura total.

Escalado automático de administración de energía frente a escalado automático dinámico

Qué hace cada uno

El glosario del escalado automático define los dos métodos. El escalado automático de administración de energía “enciende y apaga hosts de sesión para ajustarse a la capacidad disponible en un grupo de hosts” y es el método para grupos de hosts con administración estándar. El escalado automático dinámico “enciende y apaga hosts de sesión y crea y elimina hosts de sesión para ajustarse a la capacidad disponible en un grupo de hosts” y solo se puede usar en grupos de hosts agrupados con configuración de host de sesión. Ambos ejecutan la misma programación: fases de subida, pico, bajada y fuera de horas pico, cada una con un algoritmo de equilibrio de carga, un porcentaje mínimo de hosts y un umbral de capacidad. Ambos usan una lógica de consolidación idéntica durante la bajada; el recorrido de escenarios de Microsoft dice que “la única diferencia es que la administración de energía desasigna hosts de sesión mientras que el escalado automático dinámico puede eliminarlos”.

Dos notas de disponibilidad de la misma página. El escalado automático de administración de energía está disponible en Azure y Azure Government en todas las regiones donde se pueden crear grupos de hosts. El escalado automático dinámico solo está disponible en Azure, no se admite en Azure Government y, en el momento de escribir esto, sigue marcado como versión preliminar en las páginas de Learn.

Requisitos previos

Todo esto procede de la guía para crear y asignar un plan de escalado, que también advierte que asignar los roles por debajo del ámbito de la suscripción “impide que el escalado automático funcione correctamente”. El enfoque de administración en sí se decide una sola vez: la página de enfoques de administración de grupos de hosts advierte que “se establece al crear un grupo de hosts y no se puede cambiar después. Si crea un grupo de hosts sin configuración de host de sesión, no podrá agregarla más tarde”.

Cuándo aplica cada uno

Si gestiona un grupo de hosts estándar y crea hosts con su propio Terraform, Bicep o canalizaciones más un token de registro, la administración de energía es su única opción, y está disponible con carácter general. Si gestiona un grupo de hosts con configuración de host de sesión, el escalado automático dinámico es la opción natural, y las preguntas frecuentes del escalado automático explican cómo darle forma: ponga Minimum host pool size igual a Maximum host pool size y se comporta como la administración de energía; ponga Minimum percentage of active hosts (%) en 100 y solo crea y elimina. Los hosts que crea el escalado automático dinámico usan “la versión de imagen válida/estable más reciente definida en la configuración de host de sesión predeterminada”, así que su canalización de imágenes alimenta directamente al escalado automático. Los grupos de hosts personales tienen otra programación: desasignar, hibernar o no hacer nada cuando una sesión lleva entre 0 y 360 minutos desconectada o cerrada, con Iniciar VM al conectar para la mañana. FSLogix y App Attach no admiten la hibernación, así que los grupos personales que usen cualquiera de los dos deben desasignar.

El modelo de costos

Variables

El modelo siguiente es el que entrego a los clientes. Es deliberadamente sencillo: las horas son el término que cambia el escalado automático, así que el modelo aísla las horas.

Fórmulas

P          = U × C                                           peak concurrent sessions
H          = ceil( P / (S × T) )                             hosts running at peak
Hours_on   = N × 730                                         always-on host-hours per month
Hours_as   = D × (R × h_up + H × h_peak + R × h_down + F × h_off) + W × F × 24
Compute    = Hours × p_vm
Disks      = DiskMonths × p_disk                             persistent OS disks
Profiles   = GiB_prov × p_gib + IOPS_prov × p_iops + MiBps_prov × p_tp   (Azure Files provisioned v2)
Egress_GB  = P × h_active × D × kbps × 0.45 / 1000           0.45 MB per kbps-hour
Egress     = max(Egress_GB - 100, 0) × p_egress
Licences   = U × your per-user licence (outside the Azure bill for internal users)

La fórmula de H es de Microsoft. Las preguntas frecuentes del escalado automático indican “Hosts necesarios = Sesiones totales / (Límite máximo de sesiones x Umbral de capacidad %)”, redondeado hacia arriba. Está escrita para la consolidación durante la bajada, pero la misma aritmética determina cuántos hosts mantiene encendidos el escalado automático en estado estable, porque enciende hosts cada vez que la capacidad usada supera el umbral.

Ejemplo resuelto

Sustituyendo los valores de ejemplo:

Los 30 GiB por usuario proceden de la columna de almacenamiento mínimo de perfil de las directrices de dimensionamiento; los 150 kbps son el punto medio de las estimaciones de ancho de banda de RDP de Microsoft para trabajo activo en Word y Excel en el modo predeterminado, que van de 100 a 200 kbps a 1080p. El vídeo, PowerPoint y la navegación con muchas imágenes se miden en megabits por segundo en esa página, así que si sus usuarios hacen esas cosas, modélelas por separado.

Cómo cambia el escalado automático el término de horas

El escalado automático llevó la línea de proceso de 23 360 a 8011 horas de host, el 34 % del original, una reducción de aproximadamente dos tercios, y lo hizo sin descuentos, sin cambiar tamaños y sin cambiar nada de lo que los usuarios ven durante el día. Todo lo demás del modelo siguió igual. Ese es el titular honesto: el escalado automático es una palanca de proceso, y si el proceso es el 60 % de su factura, un ahorro de dos tercios en proceso es un ahorro total del 40 %.

Conviene conocer dos sensibilidades antes de ajustar. Cada hora pico adicional en 30 hosts suma 30 × 21 = 630 horas de host al mes, así que una programación que empieza la subida a las 6:00 para un equipo que inicia sesión a las 8:30 está pagando 1260 horas de host de aire. Cada host adicional en el mínimo nocturno suma 10 × 21 + 24 × 9,4, unas 436 horas de host al mes; subir el mínimo de dos a cuatro hosts cuesta 871 horas de host, el 11 % de toda la factura con escalado. El mínimo es donde mueren las buenas intenciones, así que dimensiónelo con datos de Insights sobre sesiones reales fuera de horario, no por miedo.

El escalado automático dinámico no cambia más el término de horas; un host en ejecución cuesta lo mismo tanto si se encendió como si se creó. Lo que cambia es el término de disco y la huella de VM detenidas. Con administración de energía, 32 discos persistentes del sistema operativo se facturan todo el mes; con escalado dinámico solo existe todo el mes el tamaño mínimo del grupo, y con discos del sistema operativo efímeros el cargo de almacenamiento de los hosts creados desaparece por completo.

Palancas ordenadas por impacto

Esta es mi clasificación para un grupo típico de trabajadores del conocimiento en EE. UU. Su orden puede variar si ya tiene alguna aplicada.

1. Horas de programación y el mínimo. Como se ha visto. Empiece la subida cuando aparezcan los primeros inicios de sesión reales, empiece la bajada cuando se produzcan los últimos cierres reales y ponga el porcentaje mínimo fuera de pico en 0 % si sus sesiones fuera de horario son realmente cero. Nada se le acerca.
2. Supuestos de densidad: C y S. La mayoría de entornos que heredo suponen un 100 % de simultaneidad y un límite de sesiones prudente. Mida C con los recuentos de sesiones de Insights durante un mes. Para S, las directrices de dimensionamiento indican un máximo de usuarios por vCPU de 6 para cargas ligeras, 4 medias, 2 pesadas y 1 de potencia, recomiendan 8 vCPU y 16 GB como host multisesión mínimo y aconsejan mantener los hosts multisesión entre 4 y 24 vCPU porque “la experiencia de usuario es mejor con dos VM de 16 núcleos que con una de 32”. También señalan que muchos hosts pequeños dejan más hosts sin usuarios que apagar, que es justo lo que necesita el escalado automático.
3. Dimensionar bien la familia de VM. La misma página dice que el escalado de CPU no es lineal (un factor de 1,5 a 1,9 por cada duplicación) y que pasar de 8 GB a 16 GB de memoria “puede más que duplicar el número de usuarios que puede admitir” cuando la memoria es el límite. Use la pestaña de rendimiento de hosts de Insights para ver qué recurso se satura primero antes de cambiar el tamaño. Elija tamaños de la serie D v5 o v6 con almacenamiento local para que los discos efímeros sigan siendo una opción.
4. Descuentos por compromiso solo en la base. Las Reservas de Azure ofrecen hasta un 72 % de descuento sobre el pago por uso en plazos de uno o tres años, se aplican por horas y solo cubren el medidor de proceso de la VM: “No cubre cargos adicionales de software, Windows, red ni almacenamiento”. Como las horas de reserva no usadas se pierden, un host que funciona h horas al mes solo llega al punto de equilibrio cuando h ÷ 730 > 1 − descuento. En el ejemplo, los dos hosts del mínimo funcionan 730 horas y son candidatos evidentes a reserva; los 30 hosts pico funcionan unas 14 horas en 21 días laborables, 294 horas o el 40 % del mes, lo que solo compensa con un descuento superior al 60 %. Compruebe el porcentaje real en la Calculadora de precios para su tamaño y plazo en lugar de suponerlo. La flexibilidad de tamaño de instancia permite que una reserva se aplique a otros tamaños del mismo grupo, lo que le protege si cambia de tamaño más adelante. Para la capa variable, un plan de ahorro de Azure para proceso es un compromiso horario en dólares que se aplica a distintos tamaños, regiones y servicios de proceso; tampoco cubre software, red ni almacenamiento, y las compras no se pueden cancelar ni reembolsar. La secuencia propia de Microsoft es dimensionar primero, intercambiar o canjear las reservas infrautilizadas, después comprar reservas nuevas para el uso estable y, por último, añadir un plan de ahorro. Para hosts de sesión Windows Server, la Ventaja híbrida de Azure elimina el cargo de software de Windows Server si tiene licencias por núcleo con Software Assurance, con un mínimo de 8 licencias de núcleo por VM. Los hosts Windows 11 multisesión obtienen sus derechos de Windows a través de la licencia del usuario.
5. Discos del sistema operativo efímeros. La página de discos del sistema operativo efímeros deja claro que el estado detenido (desasignado) y la detención e inicio son “No compatibles”, así que no se combinan con un plan que desasigna hosts. Sí se combinan con la creación y eliminación del escalado dinámico, y encajan en AVD porque el host no tiene estado una vez que los perfiles están en FSLogix. Limitaciones: la imagen debe caber en el disco de caché, temporal o NVMe de la VM (hasta 2040 GiB), y no se admiten la captura de imagen de VM, las instantáneas de disco, Azure Disk Encryption, Azure Backup, Azure Site Recovery ni el intercambio de discos del sistema operativo. Si elige un disco base Standard SSD o Premium SSD para obtener un SLA mayor, paga ese cargo de disco base.
6. Directiva de desasignación. Una VM Detenida (asignada) sigue facturando proceso; solo Detenida (desasignada) detiene el medidor. El escalado automático desasigna, que es lo que usted quiere. En grupos personales, configure las acciones de desconexión y cierre de sesión para desasignar (no hibernar, si interviene FSLogix) y habilite Iniciar VM al conectar para que los usuarios puedan recuperar su propio escritorio.
7. Nivel de almacenamiento de FSLogix. La comparación de almacenamiento para FSLogix recomienda Azure Files para la mayoría de los clientes, recursos compartidos estándar para cargas ligeras de menos de 200 usuarios y premium para todo lo demás, y dice que el rendimiento de Azure NetApp Files “es una función del nivel por la capacidad”, así que aprovisionar más capacidad en un nivel inferior puede ser la forma más barata de alcanzar un objetivo de IOPS. La guía de facturación de Azure Files indica usar el modelo aprovisionado v2 en todas las implementaciones nuevas y que las reservas de Azure Files pueden descontar el almacenamiento hasta un 36 %.
8. Elección de región. Los precios de VM, disco y salida varían por región, y las tarifas de salida varían por continente. La configuración del plan de escalado debe estar en la misma región que la configuración del grupo de hosts, pero los hosts de sesión pueden estar en cualquier región, así que puede dejar los metadatos donde están y colocar los hosts donde mejor equilibren precio y latencia. No persiga una región más barata a costa del tiempo de ida y vuelta; las directrices de dimensionamiento citan la latencia, la pérdida de paquetes y la fluctuación como factores directos de la experiencia de usuario.

Límites de seguridad

Momento de la subida y la bajada

El escalado automático no apaga hosts durante la subida, así que una subida que empieza demasiado pronto simplemente quema horas. Iníciela entre 30 y 60 minutos antes de la primera oleada de inicios de sesión con un porcentaje mínimo de hosts más alto, que la guía del escalado dinámico recomienda mantener en el pico. En la bajada, el cierre forzado de sesión solo ocurre en esa fase y solo después del tiempo de espera configurado; las preguntas frecuentes describen el fallo con exactitud: “si la fase de bajada dura 15 minutos y el tiempo de espera antes de cerrar las sesiones y apagar las VM es de 20 minutos, la programación pasa a la fase fuera de pico y las sesiones de usuario no se cerrarán a la fuerza”. Haga la fase de bajada más larga que el tiempo de espera. Si su programación solo cubre de lunes a viernes, la configuración fuera de pico del viernes se mantiene durante el fin de semana hasta la subida del lunes, que es lo que quiere para el mínimo.

Modo de drenaje y etiquetas de exclusión

El escalado automático sobrescribe el modo de drenaje: “el escalado automático sigue activando o desactivando el modo de drenaje de las VM, sin importar quién lo haya activado”. Para el mantenimiento, etiquete el host con la etiqueta de exclusión del plan de escalado (el ejemplo de Microsoft es excludeFromScaling) y el escalado automático no lo iniciará, detendrá ni cambiará su modo de drenaje. Dos advertencias de la página de Learn: los hosts etiquetados siguen contando para el porcentaje mínimo de hosts, y si etiqueta todos los hosts y los apaga, los usuarios verán “No hay recursos disponibles” porque al escalado automático no le queda nada que iniciar.

Experiencia de usuario durante la reducción

El escalado automático solo apaga hosts sin sesiones salvo que el cierre forzado esté habilitado en la bajada, y cuando selecciona un host primero lo pone en modo de drenaje, envía el mensaje de notificación configurado, espera, y después cierra las sesiones y desasigna. Como el host está en modo de drenaje, un usuario que se reconecta llega a un host que sigue activo y no al que está a punto de apagarse. Use equilibrio de carga en amplitud en la subida y el pico por rendimiento, y en profundidad en la bajada y fuera de pico para consolidar las sesiones en menos hosts, que es el patrón que recomiendan las preguntas frecuentes. Combínelo con la configuración de directiva de grupo o Intune Set time limit for disconnected sessions (de 15 a 30 minutos en el ejemplo de Microsoft) para que las sesiones desconectadas no mantengan hosts abiertos toda la noche.

Capacidad para avalanchas de inicio de sesión

Iniciar VM al conectar no es una herramienta para avalanchas de inicio de sesión; en grupos agrupados inicia como máximo una VM cada cinco minutos y los usuarios que llegan en ese intervalo reciben “No hay recursos disponibles”. Su defensa es la fase de subida con un porcentaje mínimo de hosts sensato. Si está en una región con capacidad ajustada, una reserva de capacidad a petición garantiza el tamaño y la cantidad de VM que indique, sin compromiso de plazo, pero paga la tarifa de la VM por la capacidad reservada tanto si una VM la usa como si no, y tanto la capacidad reservada usada como la no usada pueden recibir descuentos de reservas y planes de ahorro. Reserve el tramo pico, no todo el grupo, y solo donde los fallos de implementación le hayan afectado de verdad.

Medición

Vistas de Azure Cost Management

Las vistas inteligentes de Análisis de costos ofrecen KPI, información sobre anomalías y un desglose de suscripción a grupo de recursos, a recurso y a medidor; la vista Reservas muestra el uso amortizado de los últimos 30 días. Cree un presupuesto con alertas en el grupo de recursos de AVD, habilite la alerta de anomalías en la suscripción y revise cada semana; Microsoft sugiere revisar a diario durante la primera o las dos primeras semanas después de cualquier cambio, que es justo cuando entra en funcionamiento un plan de escalado nuevo.

Etiquetas

Agrupe los costos por grupo de hosts con etiquetas en el grupo de recursos de los hosts de sesión y en el grupo de hosts. En cuentas de Contrato Enterprise, Contrato de cliente de Microsoft y Contrato de partners de Microsoft, active la herencia de etiquetas para que las etiquetas del grupo de recursos y de la suscripción se apliquen a los registros de uso de los recursos secundarios en unas 24 horas; después podrá crear presupuestos filtrados por la etiqueta heredada. Los hosts que crea el escalado dinámico heredan las etiquetas de VM de la configuración de host de sesión, así que defina las etiquetas allí y no en cada VM.

Insights y el libro de escalado automático

Azure Virtual Desktop Insights necesita un área de trabajo de Log Analytics dedicada, configuraciones de diagnóstico en el grupo de hosts y el área de trabajo, y el agente de Azure Monitor con una regla de recopilación de datos en los hosts de sesión; el libro de configuración en aka.ms/avdi lo prepara todo. Añada la categoría Autoscale logs for pooled host pools a la configuración de diagnóstico del grupo de hosts y aparecerá la pestaña Autoscale en Insights, con los cambios de estado de energía a lo largo del tiempo. La tabla subyacente es WVDAutoscaleEvaluationPooled, que registra SessionOccupancyPercent, ActiveSessionHostCount, la fase de la programación y ScalingReasonMessage en cada evaluación. Esta consulta le dice si su umbral de capacidad y su mínimo son correctos:

WVDAutoscaleEvaluationPooled
| where ResultType == "Succeeded"
| summarize max(SessionOccupancyPercent), max(SessionCount), max(ActiveSessionHostsPercent), max(ActiveSessionHostCount)
    by _ResourceId, bin(TimeGenerated, 1d), ConfigScheduleName, ConfigSchedulePhase
| order by _ResourceId asc, TimeGenerated asc, ConfigScheduleName, ConfigSchedulePhase asc

Las evaluaciones fallidas se combinan con WVDErrors por CorrelationId. Los grupos personales no pueden usar la pestaña de Insights; envíe sus registros de escalado automático a una cuenta de almacenamiento o a Event Hubs.

Qué revisar cada mes

• Horas de host de proceso por grupo de hosts frente al modelo, y las horas por fase de la programación desde WVDAutoscaleEvaluationPooled.
• El SessionOccupancyPercent máximo por fase. Si nunca se acerca al umbral, suba el umbral o baje el porcentaje mínimo de hosts.
• El ActiveSessionHostCount fuera de pico. Si está por encima del mínimo, busque las sesiones desconectadas que mantienen hosts abiertos.
• El uso de reservas y planes de ahorro en Análisis de costos; todo lo que esté por debajo del 100 % en una reserva es dinero pagado por adelantado y no usado.
• Meses de disco frente al número de hosts; con escalado dinámico deberían separarse.
• La ingesta de Log Analytics en GB, que crece a medida que añade contadores.
• La versión de imagen en la configuración de host de sesión, para que el escalado automático no cree hosts a partir de una compilación antigua.

Qué hacer al respecto

1. Exporte los costos de AVD del mes pasado por medidor desde Análisis de costos y rellene las siete líneas de costo; anote el porcentaje de proceso.
2. Obtenga 30 días de recuentos de sesiones de Insights y calcule su proporción real de simultaneidad y su número real de sesiones fuera de horario.
3. Confirme el enfoque de administración del grupo de hosts. Estándar significa escalado de administración de energía; configuración de host de sesión significa que el escalado dinámico está disponible.
4. Establezca un MaxSessionLimit personalizado según las directrices de dimensionamiento para su tipo de carga y tamaño de host; el valor predeterminado bloquea el escalado automático.
5. Asigne Desktop Virtualization Power On Off Contributor (más Desktop Virtualization Virtual Machine Contributor para el dinámico) en el ámbito de la suscripción.
6. Construya la programación a partir de los datos: subida entre 30 y 60 minutos antes de los primeros inicios de sesión, bajada más larga que la espera del cierre forzado y mínimo fuera de pico del 0 % si las sesiones fuera de horario son cero.
7. Implemente Set time limit for disconnected sessions mediante Intune o directiva de grupo para que el grupo pueda llegar realmente al mínimo.
8. Defina la etiqueta de exclusión en el plan de escalado y escríbala en su procedimiento de mantenimiento.
9. Habilite Insights, añada la categoría de registros del escalado automático y ejecute la consulta de ocupación al cabo de dos semanas; ajuste el umbral y el mínimo una vez.
10. Solo entonces compre reservas para los hosts que superen el uso de equilibrio, un plan de ahorro para el resto, Ventaja híbrida de Azure para los hosts Windows Server y reservas de Azure Files para el almacenamiento de perfiles que vaya a conservar.
11. Si el grupo usa configuración de host de sesión, pruebe los discos del sistema operativo efímeros en una nueva versión de imagen y deje que el escalado dinámico cree los hosts.
12. Ponga un presupuesto y una alerta de anomalías en el grupo de recursos, y etiquete la configuración de host de sesión para que el próximo host creado ya esté asignado a un centro de costos.

Preguntas frecuentes

¿Cuánto ahorra el escalado automático de Azure Virtual Desktop? Depende de cuántas horas funcionan hoy sus hosts para nadie. El escalado automático en sí no tiene costo; las preguntas frecuentes responden “¿Se me cobrará más por usar el escalado automático?” con un “No”. En el ejemplo, un grupo de 32 hosts que funciona 24 horas al día consume 23 360 horas de host al mes y el mismo grupo con un horario de días laborables y un mínimo de dos hosts consume unas 8000, una reducción de aproximadamente dos tercios en la línea de proceso. El almacenamiento de perfiles, las licencias y la salida no cambian, así que el ahorro sobre la factura total es menor que el ahorro sobre el proceso.

¿Cuál es la diferencia entre el escalado automático de administración de energía y el dinámico en AVD? El escalado de administración de energía enciende y apaga (desasigna) hosts y es el método para grupos de hosts con administración estándar. El escalado dinámico también crea y elimina hosts y solo funciona con grupos de hosts agrupados que tienen configuración de host de sesión. Ambos usan las mismas fases, umbral de capacidad y lógica de consolidación; la diferencia es la acción final, desasignar o eliminar, que es lo que cambia el costo del disco del sistema operativo.

¿Debo comprar reservas de Azure para hosts de sesión de AVD con escalado automático? Solo para los hosts que funcionan la mayor parte del mes. Una reserva se aplica por horas y las horas no usadas se pierden, así que un host que funciona h horas al mes llega al punto de equilibrio cuando h ÷ 730 es mayor que uno menos el descuento. Reserve el mínimo nocturno y los hosts que funcionan toda la jornada laboral, considere un plan de ahorro para la capa variable y recuerde que ninguno cubre el software de Windows, el almacenamiento ni la red.

¿Puedo usar discos del sistema operativo efímeros con el escalado automático de AVD? No con un plan que desasigna. La página de Learn marca la detención y desasignación y la detención e inicio como no compatibles para los discos efímeros. Encajan con el escalado dinámico, que crea y elimina hosts a partir de la configuración de host de sesión, y eliminan el cargo de almacenamiento del disco del sistema operativo en hosts sin estado. Necesita un tamaño de VM con almacenamiento local y renuncia a Azure Backup, Site Recovery y las instantáneas de disco en esos hosts.

¿Por qué el escalado automático mantiene hosts de sesión encendidos fuera de horario cuando nadie trabaja? Porque las sesiones desconectadas cuentan. El escalado automático supone que un usuario desconectado puede reconectarse y mantiene en ejecución Hosts necesarios = Sesiones totales ÷ (Límite máximo de sesiones × Umbral de capacidad) para ellos. Para llegar a cero hosts necesita cero sesiones, incluidas las desconectadas: configure Set time limit for disconnected sessions para que se cierren antes de que termine la bajada y ponga el porcentaje mínimo de hosts fuera de pico en 0 %.

Si todavía está decidiendo si AVD es la plataforma adecuada para un grupo de usuarios antes de ajustarlo, la comparación entre Windows 365 y Azure Virtual Desktop cubre el caso de precio fijo por usuario, y la serie de novedades de Azure Virtual Desktop sigue los cambios del escalado automático y la configuración de host de sesión a medida que Microsoft los publica.

¿Necesita otro par de manos? Big Hat Group ofrece servicios de arquitectura de Azure Virtual Desktop y revisiones de costos para organizaciones de Estados Unidos y Canadá, desde una revisión de dos semanas del escalado automático hasta un rediseño completo del grupo de hosts. Reserve una llamada de descubrimiento para hablar de su entorno.

Fuentes

• Autoscale scaling plans and example scenarios in Azure Virtual Desktop
• Create and assign an autoscale scaling plan for Azure Virtual Desktop
• Azure Virtual Desktop autoscale glossary
• Azure Virtual Desktop autoscale FAQ
• Host pool management approaches
• Licensing Azure Virtual Desktop
• Windows Enterprise multi-session FAQ
• Session host virtual machine sizing guidelines
• Remote Desktop Protocol bandwidth requirements
• Storage options for FSLogix profile containers in Azure Virtual Desktop
• Understand Azure Files billing
• Ephemeral OS disks for Azure VMs
• States and billing status of Azure Virtual Machines
• What are Azure Reservations?
• Virtual machine size flexibility with Reserved VM Instances
• What are Azure savings plans?
• Decide between a savings plan and a reservation
• Explore Azure Hybrid Benefit for Windows VMs
• On-demand capacity reservation in Azure
• Drain session hosts for maintenance in Azure Virtual Desktop
• Configure Start VM on Connect for Azure Virtual Desktop
• Enable Insights to monitor Azure Virtual Desktop
• Monitor Autoscale operations with Insights in Azure Virtual Desktop
• Set up diagnostics for Autoscale in Azure Virtual Desktop
• Quickstart: Start using Cost analysis
• Group and allocate costs using tag inheritance
• Azure Virtual Desktop pricing
• Azure Pricing Calculator
• Windows Virtual Machines pricing
• Managed Disks pricing
• Azure Files pricing
• Bandwidth pricing