Azure Monitor Logs cost calculations and options

  • Article

The most significant charges for most Azure Monitor implementations are typically ingestion and retention of data in your Log Analytics workspaces. Several features in Azure Monitor don't have a direct cost but add to the workspace data that's collected. This article describes how data charges are calculated for your Log Analytics workspaces and the various configuration options that affect your costs.

Tip

For strategies to reduce your Azure Monitor costs, see Cost optimization and Azure Monitor.

Pricing model

The default pricing for Log Analytics is a pay-as-you-go model that's based on ingested data volume and data retention. Each Log Analytics workspace is charged as a separate service and contributes to the bill for your Azure subscription. Pricing for Log Analytics is set regionally. The amount of data ingestion can be considerable, depending on:

  • The set of management solutions enabled and their configuration.
  • The number and type of monitored resources.
  • The types of data collected from each monitored resource.

A list of Azure Monitor billing meter names is available here.

Data size calculation

Data volume is measured as the size of the data sent to be stored and is measured in units of GB (10^9 bytes). The data size of a single record is calculated from a string representation of the columns that are stored in the Log Analytics workspace for that record. It doesn't matter whether the data is sent from an agent or added during the ingestion process. This calculation includes any custom columns added by the logs ingestion API, transformations or custom fields that are added as data is collected and then stored in the workspace.

Note

The billable data volume calculation is generally substantially smaller than the size of the entire incoming JSON-packaged event. On average, across all event types, the billed size is around 25 percent less than the incoming data size. It can be up to 50 percent for small events. The percentage includes the effect of the standard columns excluded from billing. It's essential to understand this calculation of billed data size when you estimate costs and compare other pricing models.

Excluded columns

The following standard columns are common to all tables and are excluded in the calculation of the record size. All other columns stored in Log Analytics are included in the calculation of the record size. The standard columns are:

  • _ResourceId
  • _SubscriptionId
  • _ItemId
  • _IsBillable
  • _BilledSize
  • Type

Excluded tables

Some tables are free from data ingestion charges altogether, including, for example, AzureActivity, Heartbeat, Usage, and Operation. This information is always indicated by the _IsBillable column, which shows whether a record was excluded from billing for data ingestion and retention.

Charges for other solutions and services

Some solutions have more specific policies about free data ingestion. For example, Azure Migrate makes dependency visualization data free for the first 180 days of a Server Assessment. Services such as Microsoft Defender for Cloud, and configuration management have their own pricing models.

See the documentation for different services and solutions for any unique billing calculations.

Commitment tiers

In addition to the pay-as-you-go model, Log Analytics has commitment tiers, which can save you as much as 30 percent compared to the pay-as-you-go price. With commitment tier pricing, you can commit to buy data ingestion for a workspace, starting at 100 GB per day, at a lower price than pay-as-you-go pricing. Any usage above the commitment level (overage) is billed at that same price per GB as provided by the current commitment tier. (Overage is billed using the same commitment tier billing meter. For example if a workspace is in the 200 GB/day commitment tier and ingests 300 GB in a day, that usage is billed as 1.5 units of the 200 GB/day commitment tier.) The commitment tiers have a 31-day commitment period from the time a commitment tier is selected or changed.

  • During the commitment period, you can change to a higher commitment tier, which restarts the 31-day commitment period. You can't move back to pay-as-you-go or to a lower commitment tier until after you finish the commitment period.
  • At the end of the commitment period, the workspace retains the selected commitment tier, and the workspace can be moved to pay-as-you-go or to a lower commitment tier at any time.
  • If a workspace is inadvertently moved into a commitment tier, contact Azure Support to reset the commitment period so you can move back to the Pay-As-You-Go pricing tier.

Billing for the commitment tiers is done per workspace on a daily basis. If the workspace is part of a dedicated cluster, the billing is done for the cluster. See the following "Dedicated clusters" section. For a list of the commitment tiers and their prices, see Azure Monitor pricing.

Azure Commitment Discounts, such as discounts received from Microsoft Enterprise Agreements, are applied to Azure Monitor Logs commitment-tier pricing just as they are to pay-as-you-go pricing. Discounts are applied whether the usage is being billed per workspace or per dedicated cluster.

Tip

The Usage and estimated costs menu item for each Log Analytics workspace shows an estimate of what your data ingestion charges would be at each commitment level to help you choose the optimal commitment tier for your data ingestion patterns. Review this information periodically to determine if you can reduce your charges by moving to another tier. For information on this view, see Usage and estimated costs. To review your actual charges, use Azure Cost Management = Billing.

Dedicated clusters

An Azure Monitor Logs dedicated cluster is a collection of workspaces in a single managed Azure Data Explorer cluster. Dedicated clusters support advanced features, such as customer-managed keys, and use the same commitment-tier pricing model as workspaces, although they must have a commitment level of at least 100 GB per day. Any usage above the commitment level (overage) is billed at that same price per GB as provided by the current commitment tier. There's no pay-as-you-go option for clusters.

The cluster commitment tier has a 31-day commitment period after the commitment level is increased. During the commitment period, the commitment tier level can't be reduced, but it can be increased at any time. When workspaces are associated to a cluster, the data ingestion billing for those workspaces is done at the cluster level by using the configured commitment tier level.

There are two modes of billing for a cluster that you specify when you create the cluster:

  • Cluster (default): Billing for ingested data is done at the cluster level. The ingested data quantities from each workspace associated to a cluster are aggregated to calculate the daily bill for the cluster. Per-node allocations from Microsoft Defender for Cloud are applied at the workspace level prior to this aggregation of data across all workspaces in the cluster.

  • Workspaces: Commitment tier costs for your cluster are attributed proportionately to the workspaces in the cluster, by each workspace's data ingestion volume (after accounting for per-node allocations from Microsoft Defender for Cloud for each workspace).

    If the total data volume ingested into a cluster for a day is less than the commitment tier, each workspace is billed for its ingested data at the effective per-GB commitment tier rate by billing them a fraction of the commitment tier. The unused part of the commitment tier is then billed to the cluster resource.

    If the total data volume ingested into a cluster for a day is more than the commitment tier, each workspace is billed for a fraction of the commitment tier, based on its fraction of the ingested data that day and each workspace for a fraction of the ingested data above the commitment tier. If the total data volume ingested into a workspace for a day is above the commitment tier, nothing is billed to the cluster resource.

Examples of how cluster billing works in each of these modes can be found here.

Data retention is billed for each workspace, the same as for workspaces not joined to a cluster.

Cluster billing starts when the cluster is created, regardless of whether workspaces are associated with the cluster.

When you link workspaces to a cluster, the pricing tier is changed to cluster, and ingestion is billed based on the cluster's commitment tier. Workspaces associated to a cluster no longer have their own pricing tier. Workspaces can be unlinked from a cluster at any time, and the pricing tier can be changed to per GB.

If a cluster is deleted, billing for the cluster stops even if the cluster is within its 31-day commitment period.

For more information on how to create a dedicated cluster and specify its billing type, see Create a dedicated cluster.

Basic and Auxiliary table plans

You can configure certain tables in a Log Analytics workspace to use Basic and Auxiliary table plans. Data in these tables has a significantly reduced ingestion charge. There's a charge to query data in these tables.

The charge for querying data in Basic and Auxiliary tables is based on the GB of data scanned in performing the search.

For more information about the Basic and Auxiliary table plans, see Azure Monitor Logs overview: Table plans.

Log data retention

In addition to data ingestion, there's a charge for the retention of data in each Log Analytics workspace. You can set the retention period for the entire workspace or for each table. After this period, the data is either removed or kept in long-term retention. During the long-term retention period, you pay a reduced retention charge, and there's a charge to retrieve the data using a search job. Use long-term retention to reduce your costs for data that you must store for compliance or occasional investigation.

Deleting a custom table doesn't remove data associated with that table, so interactive and long-term retention charges continue to apply.

For more information on data retention, including how to configure these settings and access data in long-term retention, see Manage data retention in a Log Analytics workspace.

Note

Deleting data from your Log Analytics workspace using the Log Analytics Purge feature doesn't affect your retention costs. To lower retention costs, decrease the retention period for the workspace or for specific tables.

Search jobs

Retrieve data from long-term retention by running search jobs. Search jobs are asynchronous queries that fetch records into a new search table within your workspace for further analytics. Search jobs are billed by the number of GB of data scanned on each day that's accessed to perform the search.

Log data restore

When you need to intensively queried large volumes of data, or data in long-term retention with the full analytic query capabilities, the data restore feature is a powerful tool. The restore operation makes a specific time range of data in a table available in the hot cache for high-performance queries. You can later dismiss the data when you're finished. Log data restore is billed by the amount of data restored, and by the time the restore is kept active. The minimal values billed for any data restore are 2 TB and 12 hours. Data restored of more than 2 TB and/or more than 12 hours in duration is billed on a pro-rated basis.

Log data export

Data export in a Log Analytics workspace lets you continuously export data per selected tables in your workspace to an Azure Storage account or Azure Event Hubs as it arrives to an Azure Monitor pipeline. Charges for the use of data export are based on the amount of data exported. The size of data exported is the number of bytes in the exported JSON-formatted data.

Application Insights billing

Because workspace-based Application Insights resources store their data in a Log Analytics workspace, the billing for data ingestion and retention is done by the workspace where the Application Insights data is located. For this reason, you can use all options of the Log Analytics pricing model, including commitment tiers, along with pay-as-you-go.

Tip

Looking to adjust retention settings on your Application Insights tables? The table names have changed for workspace based components, see Application Insights Table Structure

Data ingestion and data retention for a classic Application Insights resource follow the same pay-as-you-go pricing as workspace-based resources, but they can't use commitment tiers.

Telemetry from ping tests and multi-step tests is charged the same as data usage for other telemetry from your app. Use of web tests and enabling alerting on custom metric dimensions is still reported through Application Insights. There's no data volume charge for using Live Metrics Stream.

For more information about legacy tiers that are available to early adopters of Application Insights, see Application Insights legacy enterprise (per node) pricing tier.

Workspaces with Microsoft Sentinel

When Microsoft Sentinel is enabled in a Log Analytics workspace, all data collected in that workspace is subject to Microsoft Sentinel charges along with Log Analytics charges. For this reason, you'll often separate your security and operational data in different workspaces so that you don't incur Microsoft Sentinel charges for operational data.

In some scenarios, combining this data can result in cost savings. Typically, this situation occurs when you aren't collecting enough security and operational data for each to reach a commitment tier on their own, but the combined data is enough to reach a commitment tier. For more information, see:

Workspaces with Microsoft Defender for Cloud

Microsoft Defender for Servers (part of Defender for Cloud) bills by the number of monitored services. It provides 500 MB per server per day of data allocation that's applied to the following subset of security data types:

The count of monitored servers is calculated on an hourly granularity. The daily data allocation contributions from each monitored server are aggregated at the workspace level. If the workspace is in the legacy Per Node pricing tier, the Microsoft Defender for Cloud and Log Analytics allocations are combined and applied jointly to all billable ingested data.

Next steps