Azure Monitor – Reduce Storage Costs with Retention Policies

An Azure Monitor retention policy sets how long a Log Analytics workspace keeps log data in interactive (analytics) retention, using the retention_in_days attribute on the azurerm_log_analytics_workspace Terraform resource. Every day of retention beyond the 31 days included in the ingestion price is billed per GB per month, so long retention windows turn log volume into a cost that grows month after month. Apply this policy to every Log Analytics workspace and table whose logs lose day-to-day value after a known period.

Policy at a Glance

Why This Policy Matters

How It Helps Reduce Cloud Costs

Azure Monitor bills Log Analytics in two parts: ingestion when data arrives, and retention for as long as data stays queryable. The ingestion price includes the first 31 days of analytics retention.

Any analytics retention beyond 31 days is billed daily, per GB, for every day the data is kept. A workspace set to retention_in_days = 730 pays to keep nearly two years of logs in the most expensive retention tier.

This is a common source of slow, invisible spend. Retention charges rise every month until the window fills, then stay at that higher level for as long as the workspace exists.

An Azure Monitor retention policy keeps analytics retention at the included 30 days unless a team has a documented reason to keep more. Data that must be kept for audits moves to long-term retention, which Microsoft prices far below analytics retention.

Retention only addresses storage. It does not change Log Analytics ingestion charges, which are usually the larger line on an Azure Monitor bill.

Potential Savings

Consider an application that sends 5 GB of logs per day to a Log Analytics workspace in East US. Analytics retention beyond 31 days is listed at about $0.10 per GB per month in that region.

Over one year, the workspace ingests about 1,825 GB, or roughly 1.8 TB. With retention set to 365 days, first-year retention charges add up to roughly $900 to $1,000.

From year two onward, the same workspace holds about 1,670 GB of billable retained data at all times. That costs roughly $167 per month, or about $2,000 per year, on top of ingestion.

With retention_in_days = 30, the retention charge for the same workspace is zero, because every day of retained data falls inside the included period.

These figures are illustrative and based on list prices at the time of writing. Check the Azure pricing calculator for current rates in your region.

Implementation Guide

Infrastructure-as-Code Example (Terraform)

The following examples show a Log Analytics workspace with a long retention window, and the corrected configuration.

Non-compliant configuration: two years of analytics retention on every table

resource "azurerm_log_analytics_workspace" "platform" {
  name                = "law-platform-prod"
  location            = azurerm_resource_group.monitoring.location
  resource_group_name = azurerm_resource_group.monitoring.name
  sku                 = "PerGB2018"
  retention_in_days   = 730
}

resource "azurerm_log_analytics_workspace" "platform" {
  name                = "law-platform-prod"
  location            = azurerm_resource_group.monitoring.location
  resource_group_name = azurerm_resource_group.monitoring.name
  sku                 = "PerGB2018"
  retention_in_days   = 730
}

resource "azurerm_log_analytics_workspace" "platform" {
  name                = "law-platform-prod"
  location            = azurerm_resource_group.monitoring.location
  resource_group_name = azurerm_resource_group.monitoring.name
  sku                 = "PerGB2018"
  retention_in_days   = 730
}

This keeps every table in the workspace queryable for 730 days. Every GB older than 31 days is billed at the analytics retention rate, whether or not anyone queries it. This configuration increases costs without improving day-to-day troubleshooting.

Compliant configuration: 30-day workspace retention, long-term retention only where required

resource "azurerm_log_analytics_workspace" "platform" {
  name                = "law-platform-prod"
  location            = azurerm_resource_group.monitoring.location
  resource_group_name = azurerm_resource_group.monitoring.name
  sku                 = "PerGB2018"
  retention_in_days   = 30
}

# Audit data that must be kept for one year moves to
# long-term retention instead of analytics retention.
resource "azurerm_log_analytics_workspace_table" "audit" {
  workspace_id            = azurerm_log_analytics_workspace.platform.id
  name                    = "AzureDiagnostics"
  retention_in_days       = 30
  total_retention_in_days = 365
}

resource "azurerm_log_analytics_workspace" "platform" {
  name                = "law-platform-prod"
  location            = azurerm_resource_group.monitoring.location
  resource_group_name = azurerm_resource_group.monitoring.name
  sku                 = "PerGB2018"
  retention_in_days   = 30
}

# Audit data that must be kept for one year moves to
# long-term retention instead of analytics retention.
resource "azurerm_log_analytics_workspace_table" "audit" {
  workspace_id            = azurerm_log_analytics_workspace.platform.id
  name                    = "AzureDiagnostics"
  retention_in_days       = 30
  total_retention_in_days = 365
}

resource "azurerm_log_analytics_workspace" "platform" {
  name                = "law-platform-prod"
  location            = azurerm_resource_group.monitoring.location
  resource_group_name = azurerm_resource_group.monitoring.name
  sku                 = "PerGB2018"
  retention_in_days   = 30
}

# Audit data that must be kept for one year moves to
# long-term retention instead of analytics retention.
resource "azurerm_log_analytics_workspace_table" "audit" {
  workspace_id            = azurerm_log_analytics_workspace.platform.id
  name                    = "AzureDiagnostics"
  retention_in_days       = 30
  total_retention_in_days = 365
}

Setting retention_in_days = 30 on the azurerm_log_analytics_workspace resource keeps analytics retention inside the included period. The change is an in-place update, so Terraform does not recreate the workspace.

The azurerm_log_analytics_workspace_table resource sets retention for a single table. Its total_retention_in_daysattribute keeps data in long-term retention after the analytics window ends, at a lower price.

On the workspace resource, retention_in_days accepts values from 30 to 730. On the table resource, retention_in_days accepts 4 to 730, and total_retention_in_days accepts up to 4383 days, or 12 years.

Step-by-Step Fix Instructions

1. Search Terraform configuration for every azurerm_log_analytics_workspace resource and note any retention_in_days value above 30.

2. Search for azurerm_log_analytics_workspace_table resources that set table-level retention above the workspace default.

3. List workspaces created outside Terraform with az monitor log-analytics workspace list, and check the retentionInDays value for each Log Analytics workspace.

4. Agree on a retention period per data type with the teams that own the logs and with security or compliance, since some logs have mandated minimums.

5. Set retention_in_days = 30 on each workspace that has no documented requirement for longer analytics retention.

6. For tables that must be kept for audits, add an azurerm_log_analytics_workspace_table resource with a short retention_in_days and a longer total_retention_in_days.

7. Run terraform plan to confirm each change is an in-place update, then apply.

8. Add Infracost to CI/CD so any new or changed azurerm_log_analytics_workspace retention setting is reviewed in the pull request before merge.

Best Practices

• Set retention_in_days as an explicit input in shared Terraform modules that create Log Analytics workspaces, with 30 as the default.

• Use table-level retention for the few tables that need longer history, instead of raising retention for the whole workspace.

• Use long-term retention through total_retention_in_days for compliance data that is rarely queried.

• Keep development and test workspaces at 30 days. Lowering analytics retention below 31 days does not reduce cost, because those days are already included.

• Long retention is not wrong for every workspace. Security and audit data often carries regulatory minimums that override cost goals.

Tools and Scripts

How does Infracost detect Azure Monitor retention issues automatically?

The Azure Monitor retention policy is available in Infracost, including in the free trial. When Infracost runs in CI/CD, it checks azurerm_log_analytics_workspace resources added or changed in a pull request and surfaces retention findings directly in the PR comment. Teams choose whether each finding only warns the engineer or blocks the pull request.

This catches a long retention window before the workspace starts accumulating billable data, when the fix is a one-line change in the same pull request. Infracost also scans all connected repositories for Log Analytics workspaces already in violation, so FinOps and platform teams can burn down the backlog over time and track progress on a burndown chart as the count of non-compliant workspaces falls.

To list Log Analytics workspaces and their workspace-level retention with the Azure CLI:

az monitor log-analytics workspace list \
  --query "[].{name:name, resourceGroup:resourceGroup, retentionInDays:retentionInDays}" \
  --output

az monitor log-analytics workspace list \
  --query "[].{name:name, resourceGroup:resourceGroup, retentionInDays:retentionInDays}" \
  --output

az monitor log-analytics workspace list \
  --query "[].{name:name, resourceGroup:resourceGroup, retentionInDays:retentionInDays}" \
  --output

To list table-level retention for one workspace:

az monitor log-analytics workspace table list \
  --resource-group <resource-group> \
  --workspace-name <workspace-name> \
  --query "[].{table:name, retentionInDays:retentionInDays, totalRetentionInDays:totalRetentionInDays}" \
  --output

az monitor log-analytics workspace table list \
  --resource-group <resource-group> \
  --workspace-name <workspace-name> \
  --query "[].{table:name, retentionInDays:retentionInDays, totalRetentionInDays:totalRetentionInDays}" \
  --output

az monitor log-analytics workspace table list \
  --resource-group <resource-group> \
  --workspace-name <workspace-name> \
  --query "[].{table:name, retentionInDays:retentionInDays, totalRetentionInDays:totalRetentionInDays}" \
  --output

Examples of Impact

Illustrative example: "just in case" retention on a shared workspace. A platform team creates one shared Log Analytics workspace for all production services and sets retention_in_days = 730 to be safe. A year later, most of the retention bill comes from container and diagnostic logs that nobody has queried after the first week. Setting the workspace to 30 days, and moving only the audit table to long-term retention, removes most of the retention charge.

This pattern is typical in Azure environments where a single workspace collects logs from many teams, so nobody owns the retention decision.

Illustrative example: debug logging in a test subscription. A test environment sends verbose diagnostic logs to a workspace copied from the production module, including its 365-day retention. Setting the test workspace to 30 days keeps the debugging value and drops the long tail of retention cost.

(These are illustrative, composite scenarios, not specific customer accounts.)

Considerations and Caveats

• Compliance minimums come first. Frameworks such as PCI DSS, or internal security policies, may require a year or more of log history for specific data.

• Going below 31 days saves nothing. The ingestion price already includes 31 days of analytics retention, so values under that do not lower the Azure Monitor bill.

• Some tables have longer free retention. Application Insights tables and the Usage and AzureActivity tables keep data for 90 days at no extra charge.

• Shortening total retention has a grace period. Azure Monitor waits 30 days before removing data after total retention is shortened, so the saving is not immediate.

• Ingestion is not affected. An Azure Monitor retention policy reduces retention cost only. High ingestion bills require collecting less data, filtering at the source, or using cheaper table plans.

Related Policies and Concepts

• Amazon CloudWatch - consider using a retention policy to reduce storage costs: the AWS equivalent of this Logging-group policy, applying the same retention discipline to CloudWatch Logs log groups.

• Azure Storage Accounts - consider using a lifecycle policy for blob storage: a related Azure policy for logs exported to Blob Storage, which need their own lifecycle rules to avoid unbounded storage growth.

• Amazon S3 - consider deleting or moving old objects to a cheaper storage class: the same principle of moving rarely used data to a cheaper tier, applied to object storage.

• Google Compute Engine - consider using a retention policy for snapshots: the same retention principle applied to disk snapshots on Google Cloud.

Frequently Asked Questions (FAQs)

Is this policy supported in Infracost?

Yes. The Azure Monitor retention policy is supported in Infracost and available in the free trial. Infracost checks azurerm_log_analytics_workspace resources in pull requests and surfaces retention findings in the PR comment, so the team can adjust retention before the change merges.

Can this policy be customized?

Yes. Teams can adjust how the Azure Monitor retention policy is enforced in Infracost, for example whether a finding only warns the engineer or blocks the pull request. The retention period itself is chosen by the team in Terraform, not by Infracost.

Does Infracost automatically fix violations?

No. Infracost identifies and reports Log Analytics workspaces that do not meet the Azure Monitor retention policy. Choosing a retention_in_days value and applying the change is a decision the team makes and reviews in its own pull request.

Is this policy cloud-agnostic?

No. This policy targets Azure Monitor Log Analytics workspaces through the azurerm_log_analytics_workspaceTerraform resource. Amazon CloudWatch Logs and Google Cloud Logging have their own retention settings, with different resource and attribute names.

How often should I review Azure Monitor retention settings?

Teams running Infracost in CI/CD get an Azure Monitor retention check on every pull request that adds or changes an azurerm_log_analytics_workspace resource. For existing workspaces, a quarterly review of retention against current compliance requirements is a reasonable cadence.

Does setting Azure Monitor retention to fewer than 30 days save money?

No. The Log Analytics ingestion price includes 31 days of analytics retention, so lowering Azure Monitor retention below that does not reduce cost. Savings come from removing analytics retention beyond 31 days.

Does an Azure Monitor retention policy reduce log ingestion costs?

No. An Azure Monitor retention policy only reduces retention cost. Log Analytics ingestion is billed per GB as data arrives, so reducing ingestion cost requires collecting less data or moving tables to a cheaper plan.