Microsoft announced on August 12, 2026 that three major Azure Monitor Auxiliary Logs capabilities are generally available.

The Auxiliary table plan now supports a subset of standard Azure tables, existing tables can switch between Analytics and Auxiliary in place, and Auxiliary Logs is available in the Azure Government and Microsoft Azure operated by 21Vianet sovereign clouds.

Together, the changes make the low-cost plan practical for more high-volume, low-touch telemetry without forcing teams to rebuild tables or reshape standard Azure data into custom schemas.

What Changed?

The Azure Monitor Logs Auxiliary plan is designed for verbose data that organizations need to retain but query infrequently.

Typical examples include audit trails, detailed network traffic, and diagnostic records kept for compliance or occasional investigation.

Three previous constraints limited adoption:

• Auxiliary supported Data Collection Rule-based custom tables ending in _CL, but not standard Azure tables.

• The table plan was effectively a creation-time choice because moving to or from Auxiliary required table recreation and data migration.

• Auxiliary was not available in Azure sovereign clouds.

The August release addresses all three areas, with an important sovereign-cloud scope distinction.

A Subset of Standard Azure Tables Can Use Auxiliary

Eligible standard Azure tables can now be configured on the Auxiliary plan.

Eligibility is defined per table according to its ingestion pattern. Microsoft maintains the current supported-table list, and teams should check that list instead of assuming every Azure table is eligible.

The table keeps its standard name and schema after moving to Auxiliary. That avoids a custom ingestion pipeline whose only purpose is to rename or reshape data into a _CL table.

Preserving the table identity matters for Microsoft Sentinel and Azure Monitor environments where queries, workbooks, content, and operational knowledge already reference the standard schema.

Existing KQL and integrations can continue to use that table within the Auxiliary query model. The final phrase is important: the Auxiliary plan has a different query and feature profile from Analytics, so keeping the name does not guarantee that every current query or dependent experience behaves identically.

In-Place Plan Switching Changes the Adoption Risk

Teams can now switch an existing table between the Analytics and Auxiliary plans without recreating it.

Microsoft says the change preserves history, schema, and integrations. The plan choice is reversible, with no data loss or disruption when switching back.

That makes the plan a lifecycle decision instead of a permanent schema decision.

A table can begin on Analytics while the data supports active monitoring and investigation. When the data becomes primarily a retention or audit source, the team can evaluate Auxiliary. If detections or operational usage later make the table high-touch again, it can return to Analytics.

Reversibility does not remove the need for testing. The data remains, but query features, performance, and charges differ by plan. Validate the consumers before and after the switch.

Sovereign Clouds Gain Auxiliary Logs

Auxiliary Logs is generally available in Azure Government (Fairfax) and Microsoft Azure operated by 21Vianet (Mooncake).

In this first sovereign-cloud stage, customers can create Data Collection Rule-based custom tables on the Auxiliary plan and use the existing Auxiliary retention and query model.

The new standard Azure table support and in-place plan switching are not included in that first sovereign release. Microsoft says those capabilities will reach the sovereign clouds after a stabilization period in public Azure.

This distinction matters for architecture and procurement. A capability described as generally available for the overall plan can still have different scope by cloud.

Document the exact cloud, region, workspace, table type, and required feature before building a migration schedule.

Choose a Plan from the Data's Usage Pattern

The cheapest ingestion option is not automatically the lowest-cost operational design.

Analytics is the natural fit for frequently queried data that supports alerting, interactive investigation, rich KQL, workbooks, and broad integrations.

Auxiliary is intended for high-volume data that is retained for infrequent access. Query behavior and charges are optimized around that pattern.

Before changing a table, measure:

• Daily ingestion volume

• Retention requirement

• Query frequency

• Bytes scanned per query

• Alert and detection dependencies

• Workbook and dashboard dependencies

• Cross-table correlation requirements

• Investigation latency expectations

• Export, search, and downstream integration needs

A table queried once a quarter for a narrow audit may be a strong candidate. A table used every five minutes by detections and incident responders is not low-touch, even if it is expensive.

Inventory Consumers, Not Only Tables

The migration unit looks like a table, but the operational impact sits in its consumers.

Search repositories, scheduled queries, alert rules, Sentinel analytics, workbooks, notebooks, dashboards, functions, Logic Apps, exports, and ad-hoc investigation guides for references to the candidate table.

Classify each dependency:

• Must continue without change

• Can use an Auxiliary-compatible query

• Can tolerate slower or on-demand access

• Should move to a summarized or derived Analytics table

• Is obsolete and can be removed

For some workloads, the best design keeps detailed events on Auxiliary while sending a smaller set of security signals, aggregates, or operational metrics to Analytics.

That separates cheap evidence retention from fast detection and triage.

Plan Switching Needs a Controlled Change Window

Microsoft describes in-place switching as non-disruptive and data-preserving.

Still treat the switch as a production observability change because the table's query and cost behavior changes.

Create a before-and-after validation pack containing:

• Representative KQL queries

• Saved investigations

• Workbook panels

• Alert and detection tests

• Expected row counts and time ranges

• Query duration and scanned volume

• Access-control checks

• Export or automation tests

Run the pack before the switch, immediately after it, and again after normal ingestion has continued.

Keep the decision owner, rollback threshold, and review date with the change record. Reversible changes are most useful when the team knows exactly when to reverse them.

Cost Governance Becomes More Granular

In-place switching makes table-level cost tuning easier.

Build a monthly view that separates ingestion, interactive retention, long-term retention, query scanning, exports, and any downstream processing. Compare the current Analytics cost with realistic Auxiliary query behavior, not with an assumption that retained data is never read.

Watch for cost displacement.

Moving raw logs to Auxiliary can lower ingestion cost while increasing query-scan charges, engineer wait time, or the amount of summarized data kept on Analytics. The correct metric is the cost of retaining and using the evidence at the required service level.

Set a review trigger when query frequency, detection coverage, ingestion volume, or compliance requirements change.

Security and Compliance Considerations

A lower-cost table plan does not reduce the sensitivity of its data.

Verbose logs can contain user identifiers, network addresses, resource names, request details, and business events. Preserve access controls, retention policy, audit evidence, and data residency requirements through the plan change.

Review:

• Workspace and table-level permissions

• Data Collection Rule transformations

• Sensitive-field minimization

• Retention and deletion requirements

• Query and access auditing

• Sovereign-cloud boundaries

• Incident-response access during an outage

• Legal-hold and investigation procedures

Confirm that responders can retrieve the required evidence under realistic time pressure. Cheap retention is not useful if the incident process cannot access it correctly.

What Comes Next?

Microsoft identifies multi-table queries and broader standard-table coverage as upcoming Auxiliary investments.

Multi-table queries will make it easier to join and correlate Auxiliary data without first moving it elsewhere. Broader table support will expand the set of standard sources eligible for the plan.

Treat those items as roadmap direction, not available production functionality. Architecture decisions should use the capabilities documented for the target cloud today.

Who Should Care?

Observability teams should care because Auxiliary can now fit existing standard-table estates without forcing a custom-schema migration.

Microsoft Sentinel teams should care because verbose security data can be evaluated for lower-cost retention while high-value detections stay on the appropriate query path.

Platform teams should care because table-plan policy, dependency inventory, validation, and rollback can be automated across workspaces.

FinOps teams should care because the plan can reduce ingestion cost for the right usage pattern, but query and operational costs still need measurement.

Government and regulated-cloud teams should care because Auxiliary is now GA in Fairfax and Mooncake, with a narrower initial feature set than public Azure.

Practical Cloud Engineer Takeaway

Do not start with the largest table in the workspace.

Choose one eligible, non-critical table whose data is retained primarily for audit or occasional investigation.

Collect 30 days of evidence about ingestion volume, query frequency, alerts, workbooks, automation, retention, and scanned bytes. Build a consumer inventory and a small validation pack.

Then switch the table in a non-production workspace or controlled production window.

Validate:

• New records continue to arrive.

• Historical and current records remain accessible.

• Required queries work within the Auxiliary query model.

• Alerts, workbooks, and integrations behave as planned.

• Access controls and audit trails remain correct.

• Observed query and ingestion cost match the estimate.

• The documented rollback returns the table to Analytics cleanly.

Review the pilot after a representative investigation, not only after a successful configuration change.

Bottom Line

Azure Monitor Auxiliary Logs can now support a subset of standard Azure tables and switch existing tables between Analytics and Auxiliary in place.

Auxiliary Logs is also generally available in Azure Government and Microsoft Azure operated by 21Vianet, initially with the existing custom-table functionality. Standard Azure tables and in-place switching will arrive in those clouds later.

The release removes major adoption friction: teams can preserve table names and schemas, avoid unnecessary custom pipelines, and reverse a plan decision without recreating the table or losing data.

The right next step is a dependency-aware pilot on one genuinely low-touch table, with query validation, cost measurement, security review, and a tested return to Analytics.

Sources

Microsoft Azure Observability Blog, published August 12, 2026: https://techcommunity.microsoft.com/t5/azure-observability-blog/azure-monitor-auxiliary-logs-expands-with-azure-tables-support/ba-p/4525206

Azure Monitor table plans overview: https://aka.ms/logsTablePlans

Tables that support the Auxiliary plan: https://aka.ms/auxiliaryLogsTablesList

Select or change a Log Analytics table plan: https://aka.ms/logsTablePlanChange

Query Basic and Auxiliary tables: https://aka.ms/auxiliaryLogsQuery

---

Stay radical, stay curious, and keep pushing the boundaries of what is possible in the cloud.

Chriz Beyond Cloud with Chriz