Azure Monitor Workspace Auto-Scale Preview: Automatic Metrics Ingestion Limits and Billing Caveats

What problem it targets​

The default AMW ingestion limit is 1 million active time series and 1 million events per minute. Microsoft's documentation calls this a soft limit that can be raised by opening a support ticket. Microsoft's scaling guidance recommends requesting an increase if ingestion is exceeding or close to 80% of the limit.

The usual failure pattern is familiar. A new service rolls out, a cluster scales out, or label cardinality creeps up. Usage then nears the ceiling while a manual request is still pending. When ingestion limits are reached, throttling can occur. Microsoft's announcement says that when usage outgrows the limit, metrics can be dropped. That means losing visibility just as the environment is changing.

How Auto-scale behaves​

During the public preview, Auto-scale is an opt-in setting for each workspace. The announcement describes two directions:

• Scale up: when ingestion approaches the upper utilization threshold, the limit is raised to help prevent throttling.
• Scale down: when utilization stays low for a sustained period, unused capacity is reclaimed. Microsoft says ingestion isn't affected.

If you leave the setting off, Microsoft says nothing changes. The workspace keeps behaving as it does today.

How to enable it​

The documented route today is an ARM update through the Azure CLI. It targets the metricsContainers/default child resource of the workspace:

$resourceId = "/subscriptions/<subscriptionId>/resourceGroups/<resourceGroupName>/providers/Microsoft.Monitor/accounts/<azureMonitorWorkspaceName>/metricsContainers/default"

az resource update --ids $resourceId --api-version 2026-09-03-preview --set properties.limits.enableAutoScale=true --force-string

Replace the placeholders with your subscription ID, resource group and workspace name. To switch it off, set enableAutoScale=false. Limits then stay fixed and you manage them manually, as before.

Portal support is coming. The portal path will be Azure Monitor Workspace -> Limits and Usage. Microsoft says the portal rollout is phased and should reach all regions in the coming weeks. Don't assume the toggle is visible in your tenant yet.

Watching what it does​

Automatic changes still need oversight:

• When Auto-scale is enabled, any change in the ingestion limits is recorded in the workspace's Activity Log. That gives you a history of when limits moved and in which direction.
• Microsoft recommends alerts on three things: ingestion usage against current limits (events per minute and active time series), dropped events or time series, and any scale event triggered by Auto-scale.
• An activity log alert rule is the mechanism for scale-event notifications. Usage and dropped-data alerts show capacity pressure separately.

Billing: the important caveat​

Microsoft says Auto-scale doesn't change what you pay. It adjusts only the ingestion limit, which is the quota ceiling. Billing still follows what you actually ingest.

This is not a spending guardrail. Microsoft's own guidance says to keep Auto-scale off if you need a hard, fixed ingestion cap to control volume. It also says to keep it off if you prefer to manage limits through existing processes. A runaway metric, such as a cardinality explosion from a bad label, could in principle push usage up. With a fixed limit that would hit a wall. With Auto-scale on, the ceiling may move instead. That is my inference from how the feature is described, not something Microsoft states. It is a good reason to set up usage alerts before enabling the feature.

It is also not a Log Analytics-style daily cap. Microsoft's documentation notes that a daily ingestion cap isn't available in an Azure Monitor workspace.

What Microsoft hasn't said​

The announcement leaves several operational details open:

• The actual utilization thresholds
• How long "sustained" low usage must last
• Scale increments
• Any maximum limit Auto-scale can reach
• The required Azure role
• Preview support terms

For context, Microsoft documents a separate preview ARM API for requesting limit increases. That API is documented as a preview feature, and creating an AMW always applies the default limits. The announcement does not explain how Auto-scale relates to that manual process. Don't assume it can reach any particular ceiling.

Who should try it​

Preview means "non-production use and testing" in Azure's own status definitions. Sensible candidates are:

• Dev, test or staging workspaces
• Workloads where metrics volume tracks deployments or cluster growth
• Teams tired of padding quota requests "just in case"

Be more cautious in these situations:

• Production workspaces with strict volume governance
• Chargeback models that depend on fixed ceilings
• Environments where change control forbids unattended quota changes

Suggested rollout​

1. Confirm your change-control and preview-terms position.
2. Set usage alerts on events per minute and active time series first, then dropped-data alerts.
3. Create an activity log alert rule for limit changes.
4. Enable enableAutoScale=true on a non-production workspace.
5. Watch the Activity Log across a few deployment cycles.
6. Compare scale events with your billing data before deciding about production.

Microsoft is asking for feedback via a form and says user input will shape general availability. For anyone who has waited on a quota ticket while Prometheus metrics were being throttled, that is a welcome change. Just remember that a ceiling that moves automatically is not a cap.