Estimate Azure Monitor costs

Azure Monitor Logs is a service that collects, indexes, and stores data generated by your environment. Because of this, the Azure Monitor pricing model is based on the amount of data that's brought into and processed (or "ingested") by your Log Analytics workspace in gigabytes per day. The cost of a Log Analytics workspace isn't only based on the volume of data collected, but also which Azure payment plan you've selected and how long you choose to store the data your environment generates.

This article will explain the following things to help you understand how pricing in Azure Monitor works:

  • How to estimate data ingestion and storage costs upfront before you enable this feature
  • How to measure and control your ingestion and storage to reduce costs when using this feature

Note

All sizes and pricing listed in this article are just examples to demonstrate how estimation works. For a more accurate assessment based on your Azure Monitor Log Analytics pricing model and Azure region, see Azure Monitor pricing.

Estimate data ingestion and storage costs

We recommend you use a predefined set of data written as logs in your Log Analytics workspace. In the following example estimates, we'll look at billable data in the default configuration

The predefined datasets for Azure Monitor for Windows Virtual Desktop include:

  • Performance counters from the session hosts
  • Windows Event Logs from the session hosts
  • Windows Virtual Desktop diagnostics from the service infrastructure

Your data ingestion and storage costs depend on your environment size, health, and usage. The example estimates we'll use in this article to calculate the cost ranges you can expect are based on healthy virtual machines running light to power usage, based on our virtual machine sizing guidelines, to calculate a range of data ingestion and storage costs you could expect.

The light usage VM we'll be using in our example includes the following components:

  • 4 vCPUs, 1 disk
  • 16 sessions per day
  • An average session duration of 2 hours (120 minutes)
  • 100 processes per session

The power usage VM we'll be using in our example includes the following components:

  • 6 vCPUs, 1 disk
  • 6 sessions per day
  • Average session duration of 4 hours (240 minutes)
  • 200 processes per session

Estimating performance counter ingestion

Performance counters show how the system resources are performing. Performance counter data ingestion depends on your environment size and usage. In most cases, performance counters should make up 80 to 99% of your data ingestion for Azure Monitor for Windows Virtual Desktop.

Before you start estimating, it’s important that you understand that each performance counter sends data at a specific frequency. We set a default sample rate-per-minute (you can also edit this rate in your settings), but that rate will be applied at different multiplying factors depending on the counter. The following factors affect the rate:

  • For the per virtual machine (VM) factor, each counter sends data per VM in your environment at the default sample rate per minute while the VM is running. You can estimate the number of records these counters send per day by multiplying the default sample rate per minute by the number of VMs in your environment, then multiplying that number by the average VM running time per day.

    To summarize:

    Default sample rate per minute × number of CPU cores in the VM SKU × number of VMs × average VM running time per day = number of records sent per day

  • For the per CPU factor, each counter sends at the default sample rate per minute per vCPU in each VM in your environment while the VM is running. You can estimate the number of records the counters will send per day by multiplying the default sample rate per minute by the number of CPU cores in the VM SKU, then multiplying that number by the number of minutes the VM runs and the number of VMs in your environment.

    To summarize:

    Default sample rate per minute × number of CPU cores in the VM SKU × number of minutes the VM runs × number of VMs = number of records sent per day

  • For the per disk factor, each counter sends data at the default sample rate for each disk in each VM in your environment. The number of records these counters will send per day equals the default sample rate per minute multiplied by number of disks in the VM SKU, multiplied by 60 minutes per hour, and finally multiplied by the average active hours for a VM.

    To summarize:

    Default sample rate per minute × number of disks in VM SKU × 60 minutes per hour × number of VMs × average VM running time per day = number of records sent per day

  • For the per session factor, each counter sends data at the default sample rate for each session in your environment while the session is connected. You can estimate the number of records these counters will send per day can by multiplying the default sample rate per minute by the average number of sessions per day and the average session duration.

    To summarize:

    Default sample rate per minute × sessions per day × average session duration = number of records sent per day

  • For the per-process factor, each counter sends data at the default rate for each process in each session in your environment. You can estimate the number of records these counters will send per day by multiplying the default sample rate per minute by the average number of sessions per day, then multiplying that by the average session duration and the average number of processes per session.

    To summarize:

    Default sample rate per minute × sessions per day × average session duration × average number of processes per session = number of records sent per day

The following table lists the 20 performance counters Azure Monitor for Windows Virtual Desktop collects and their default rates:

Counter name Default sample rate Frequency factor
Logical Disk(C:)\% free space 60 seconds Per disk
Logical Disk(C:)\Avg. Disk Queue Length 30 seconds Per disk
Logical Disk(C:)\Avg. Disk sec/Transfer 60 seconds Per disk
Logical Disk(C:)\Current Disk Queue Length 30 seconds Per disk
Memory(*)\Available Mbytes 30 seconds Per VM
Memory(*)\Page Faults/sec 30 seconds Per VM
Memory(*)\Pages/sec 30 seconds Per VM
Memory(*)\% Committed Bytes in Use 30 seconds Per VM
PhysicalDisk(*)\Avg. Disk Queue Length 30 seconds Per disk
PhysicalDisk(*)\Avg. Disk sec/Read 30 seconds Per disk
PhysicalDisk(*)\Avg. Disk sec/Transfer 30 seconds Per disk
PhysicalDisk(*)\Avg. Disk sec/Write 30 seconds Per disk
Processor Information(_Total)\% Processor Time 30 seconds Per core/CPU
Terminal Services(*)\Active Sessions 60 seconds Per VM
Terminal Services(*)\Inactive Sessions 60 seconds Per VM
Terminal Services(*)\Total Sessions 60 seconds Per VM
User Input Delay per Process(*)\Max Input Delay 30 seconds Per process
User Input Delay per Session(*)\Max Input Delay 30 seconds Per session
RemoteFX Network(*)\Current TCP RTT 30 seconds Per VM
RemoteFX Network(*)\Current UDP Bandwidth 30 seconds Per VM

If we estimate each record size to be 200 bytes, an example VM running a light workload on the default sample rate would send roughly 90 megabytes of performance counter data per day per VM. Meanwhile, an example VM running a power workload would send roughly 130 megabytes of performance counter data per day per VM. However, record size and environment usage can vary, so the megabytes per day your deployment uses may be different.

To learn more about input delay performance counters, see User Input Delay performance counters.

Estimating Windows Event Log ingestion

Windows Event Logs are data sources collected by Log Analytics agents on Windows virtual machines. You can collect events from standard logs like System and Application as well as custom logs created by applications you need to monitor.

These are the default Windows Events for Azure Monitor for Windows Virtual Desktop:

  • Application
  • Microsoft-Windows-TerminalServices-RemoteConnectionManager/Admin
  • Microsoft-Windows-TerminalServices-LocalSessionManager/Operational
  • System
  • Microsoft-FSLogix-Apps/Operational
  • Microsoft-FSLogix-Apps/Admin

Windows Events send whenever the terms of the event are met in the environment. Machines in healthy states will send fewer events than machines in unhealthy states. Since event count is unpredictable, we use a range of 1,000 to 10,000 events per VM per day based on examples from healthy environments for this estimate. For example, if we estimate each event record size in this example to be 1,500 bytes, this comes out to roughly 2 to 15 megabytes of event data per day for the specified environment.

To learn more about Windows events, see Windows event records properties.

Estimating diagnostics ingestion

The diagnostics service creates activity logs for both user and administrative actions.

These are the names of the activity logs the diagnostic counter tracks:

  • WVDCheckpoints
  • WVDConnections
  • WVDErrors
  • WVDFeeds
  • WVDManagement
  • WVDAgentHealthStatus

The service sends diagnostic information whenever the environment meets the terms required to make a record. Since diagnostic record count is unpredictable, we use a range of 500 to 1000 events per VM per day based on examples from healthy environments for this estimate.

For example, if we estimate each diagnostic record size in this example to be 200 bytes, then the total ingested data would be less than 1 MB per VM per day.

To learn more about the activity log categories, see Windows Virtual Desktop diagnostics.

Estimating total costs

Finally, let's estimate the total cost. In this example, let's say we come up with the following results based on the example values in the previous sections:

Data source Size estimate per day (in megabytes)
Performance counters 90-130
Events 2-15
Windows Virtual Desktop diagnostics < 1

In this example, the total ingested data for Azure Monitor for Windows Virtual Desktop is between 92 to 145 megabytes per VM per day. In other words, every 31 days, each VM ingests roughly 3 to 5 gigabytes of data.

Using the default Pay-as-you-go model for Log Analytics pricing, you can estimate the Azure Monitor data collection and storage cost per month. Depending on your data ingestion, you may also consider the Capacity Reservation model for Log Analytics pricing.

Manage your data ingestion to reduce costs

This section will explain how to measure and manage data ingestion to reduce costs.

To learn about managing rights and permissions to the workbook, see Access control.

Note

Removing data points will impact their corresponding visuals in Azure Monitor for Windows Virtual Desktop.

Log Analytics settings

Here are some suggestions to optimize your Log Analytics settings to manage data ingestion:

  • Use a designated Log Analytics workspace for your Windows Virtual Desktop resources to ensure that Log Analytics only collects performance counters and events for the virtual machines in your Windows Virtual Desktop deployment.
  • Adjust your Log Analytics storage settings to manage costs. You can reduce the retention period, evaluate whether a fixed storage pricing tier would be more cost-effective, or set boundaries on how much data you can ingest to limit impact of an unhealthy deployment. To learn more, see Manage usage and costs for Azure Monitor Logs.

Remove excess data

Our default configuration is the only set of data we recommend for Azure Monitor for Windows Virtual Desktop. You always have the option to add additional data points and view them in the Host Diagnostics: Host browser or build custom charts for them, however added data will increase your Log Analytics cost. These can be removed for cost savings.

Measure and manage your performance counter data

Your true monitoring costs will depend on your environment size, usage, and health. To understand how to measure data ingestion in your Log Analytics workspace, see Understanding ingested log data volume.

The performance counters the session hosts use will probably be your largest source of ingested data for Azure Monitor for Windows Virtual Desktop. The following custom query template for a Log Analytics workspace can track frequency and megabytes ingested per performance counter over the last day:

let WVDHosts = dynamic(['Host1.MyCompany.com', 'Host2.MyCompany.com']);
Perf
| where TimeGenerated > ago(1d)
| where Computer in (WVDHosts)
| extend PerfCounter = strcat(ObjectName, ":", CounterName)
| summarize Records = count(TimeGenerated), InstanceNames = dcount(InstanceName), Bytes=sum(_BilledSize) by PerfCounter
| extend Billed_MBytes = Bytes / (1024 * 1024), BytesPerRecord = Bytes / Records
| sort by Records desc

Note

Make sure to replace the template's placeholder values with the values your environment uses, otherwise the query won't work.

This query will show all performance counters you have enabled on the environment, not just the default ones for Azure Monitor for Windows Virtual Desktop. This information can help you understand which areas to target to reduce costs, like reducing a counter’s frequency or removing it altogether.

You can also reduce costs by removing performance counters. To learn how to remove performance counters or edit existing counters to reduce their frequency, see Configuring performance counters.

Manage Windows Event Logs

Windows Events are unlikely to cause a spike in data ingestion when all hosts are healthy. An unhealthy host can increase the number of events sent to the log, but the information can be critical to fixing the host's issues. We recommend keeping them. To learn more about how to manage Windows Event Logs, see Configuring Windows Event logs.

Manage diagnostics

Windows Virtual Desktop diagnostics should make up less than 1% of your data storage costs, so we don't recommend removing them. To manage Windows Virtual Desktop diagnostics, Use Log Analytics for the diagnostics feature.

Next steps

Learn more about Azure Monitor for Windows Virtual Desktop at these articles: