I Asked GitHub Copilot Whether Auxiliary Fits Log Analytics
While browsing Hot Topics on this site, I came across the Microsoft Community Hub article “Azure Monitor Auxiliary Logs expands with Azure tables support, plan switching, and sovereign clouds.”
The article covers recent changes to Azure Monitor Auxiliary Logs, including support for more Azure tables and the ability to switch table plans. That made me wonder whether using Auxiliary for this site’s Log Analytics workspaces could reduce monitoring costs.
I asked GitHub Copilot to review the official Microsoft Learn documentation, the Bicep files in this repository, the actual Azure resources, and ingestion volume over the past 30 days. I did not change any settings; this investigation only examines what would happen if we adopted Auxiliary.
Table of Contents
- Key takeaway
- Overview of Auxiliary
- Log Analytics workspaces currently used by this site
- Benefits of using Auxiliary
- Drawbacks of using Auxiliary
- Decision for this site
- Summary
Key takeaway
For Memolog’s current setup, I concluded that we should keep Analytics and not use Auxiliary.
The main reason is that the two Log Analytics workspaces ingested only about 32 MB of logs in total over the past 30 days, leaving little room for savings from Auxiliary. At the same time, tables switched to Auxiliary lose alerting and face restrictions on query performance and available features.
In addition, AzureDiagnostics, which contains most of the security logs, does not support Auxiliary according to official information available as of August 16, 2026. We cannot switch the entire security workspace to Auxiliary while keeping the current collection method.
Given the low ingestion volume and the current emphasis on real-time monitoring, retaining Analytics capabilities is more valuable than the modest potential savings.
Overview of Auxiliary
In a Log Analytics workspace, you can select a plan for each table based on how you use the stored logs.
The key point is that Auxiliary is not a pricing plan applied to an entire workspace. A single workspace can use Analytics, Basic, and Auxiliary for different tables. However, not every table supports every plan.
| Table plan | Primary use | Characteristics |
|---|---|---|
| Analytics | Continuous monitoring, real-time detection, performance analysis | Fast queries, alerts, and analysis across multiple tables |
| Basic | Troubleshooting, incident investigation | Lower ingestion costs, queries focused on a single table, and Simple Log Alerts |
| Auxiliary | High-volume, infrequently accessed detailed logs, auditing, compliance | Lowest ingestion price, but limited query performance and features |
Auxiliary is well suited to large volumes of logs that are rarely accessed but must be retained for audits or future investigations. It is not a good fit for logs that require frequent interactive analysis or alert evaluation every few minutes.
Auxiliary provides 30 days of interactive retention. Total retention can be configured for up to 12 years, but investigating data older than 30 days requires tools such as Search Jobs.
For a detailed comparison, see Azure Monitor Logs table plans and Configure a table plan in a Log Analytics workspace on Microsoft Learn.
Log Analytics workspaces currently used by this site
As of August 16, 2026, Memolog has two Log Analytics workspaces in East US 2. Using Azure MCP Server through GitHub Copilot, I reviewed the actual resources and the past 30 days of Usage data in read-only mode.
| Workspace | Primary use | Retention | Daily cap | Ingestion over the past 30 days |
|---|---|---|---|---|
memolog-prod-law | Monitoring Application Insights, Azure Functions, and Table Storage | 30 days | 0.1 GB | About 28.4 MB |
memolog-prod-security-law | Security monitoring for Azure Front Door, WAF, and Microsoft Sentinel | 90 days | No cap | About 3.4 MB |
Workspace for routine monitoring
memolog-prod-law primarily received data from the following tables.
| Table | Ingestion over the past 30 days | Primary use on this site |
|---|---|---|
StorageTableLogs | About 9.0 MB | Monitoring Table Storage access and failures |
AppMetrics | About 4.6 MB | Application Insights metrics |
AppTraces | About 4.5 MB | Hot Topics collection results and incident investigation |
AzureMetrics | About 4.1 MB | Azure resource metrics |
AppPerformanceCounters | About 3.2 MB | Function performance data |
FunctionAppLogs | About 1.4 MB | Azure Functions logs |
AppRequests | About 1.4 MB | Monitoring API failures, latency, and missing data |
This workspace uses AppRequests, AppTraces, StorageTableLogs, AppAvailabilityResults, AppEvents, and other tables to monitor API 5xx responses, long-running cancellations, Table Storage failures, scheduled collection failures, and browser rendering times.
Workspace for security monitoring
Over the past 30 days, the billable data in memolog-prod-security-law consisted of about 3.4 MB in AzureDiagnostics. The workspace receives Azure Front Door access and WAF logs, which Microsoft Sentinel uses for the following detections:
- Requests blocked by WAF
- Attack patterns targeting management APIs
- Configuration changes to Front Door, WAF, workspaces, and related resources
- RBAC changes
- Sentinel anomalies and connector changes
- Sudden increases in security log ingestion
These detections run primarily at 5-minute intervals. In other words, the logs support real-time detection rather than simple archival storage.
Benefits of using Auxiliary
Lower log ingestion costs
Auxiliary’s main benefit is a lower ingestion price than Analytics or Basic.
In environments that retain large volumes of debug, network flow, or audit logs for long periods, the savings grow with ingestion volume. Auxiliary works well when teams usually review only aggregate results and inspect detailed logs only when an issue occurs.
Suitable for long-term retention
Auxiliary supports total retention of up to 12 years. When the goal is to retain data for auditing, evidence, or compliance rather than real-time analysis, it can serve as a lower-cost storage option.
Works alongside other plans in the same workspace
You can keep critical monitoring data in Analytics while moving only infrequently accessed detailed logs to Auxiliary. This lets you balance cost and functionality table by table without creating a separate workspace for every use case.
Drawbacks of using Auxiliary
Alerts become unavailable
Azure Monitor alerts stop working for a table after it is switched from Analytics to Auxiliary.
Memolog monitors APIs, storage, collection processes, and WAF activity through log alerts and Sentinel analytics rules. Moving the relevant tables to Auxiliary could eliminate anomaly detection in exchange for lower costs.
Basic supports Simple Log Alerts, but Auxiliary does not support alerts. If real-time detection is required, we must either retain Analytics or use a Summary Rule to aggregate Auxiliary data and monitor the destination Analytics table.
Queries are slower and billed by data scanned
Analytics is optimized for interactive analysis, and standard query costs are included in the ingestion price. Auxiliary is not optimized for query performance and charges by the amount of data scanned.
Even if ingestion costs decrease, frequently querying dashboards or running investigations can increase both wait times and query charges.
KQL and integration features are limited
Auxiliary queries are primarily limited to a single table. Features such as join, find, search, and cross-resource queries are restricted.
Auxiliary also does not support some Analytics features, including Insights, data export, Restore, and Workspace Replication. See Azure Monitor Logs table feature comparison for current support details.
Not every table supports Auxiliary
Support for Basic and Auxiliary varies across Azure built-in tables.
For example, Azure Monitor Logs table feature support lists AzureDiagnostics, which the security workspace currently uses, as not supporting Auxiliary. We therefore cannot keep the current Azure Front Door diagnostic settings and switch only AzureDiagnostics to Auxiliary.
Switching back does not immediately restore full data access
Switching from Analytics to Auxiliary does not delete data ingested before the change. However, queries spanning the date of the change may return partial results.
Even after switching back to Analytics, data ingested while the table used Auxiliary is unavailable through standard interactive queries. Accessing data from that period requires a Search Job or the Search API. Table plan changes are also limited to once per table per week.
Decision for this site
This assessment considered not only Auxiliary’s generally lower price, but also Memolog’s actual log volume and how the logs are used.
| Decision factor | Current state of Memolog | Assessment |
|---|---|---|
| Ingestion volume | About 32 MB across two workspaces over 30 days | The absolute potential savings are small |
| Log usage | Continuous monitoring of APIs, storage, collection processes, and WAF activity | Does not fit Auxiliary’s infrequent-access archival use case |
| Alerts | Many detection rules, including rules that run at 5-minute intervals | Switching to Auxiliary would remove important capabilities |
| Security logs | Primarily stored in AzureDiagnostics | The current table does not support Auxiliary |
| Investigation method | Interactive use of Application Insights and KQL | Query performance and feature restrictions would have an impact |
For these reasons, we will retain Analytics in both workspaces for now.
Before switching to Auxiliary, further cost reductions could come from disabling unnecessary log categories, adjusting Application Insights sampling, or using Data Collection Rule transformations to exclude unnecessary records or columns. These options may reduce ingestion volume itself while preserving monitoring requirements.
If Memolog later begins generating large volumes of logs that are rarely accessed, we could separate those logs into a dedicated Auxiliary-compatible table and send only the required aggregates to an Analytics table.
Summary
Auxiliary does not switch an entire Log Analytics workspace to a less expensive plan. It is a per-table plan available only for supported tables. It can significantly reduce costs when retaining large volumes of infrequently accessed logs for auditing or long-term storage.
However, Auxiliary does not support alerts and places restrictions on query performance, KQL, and integration features. Not every Azure table supports it, either.
Memolog ingested only about 32 MB over the past 30 days, and its logs support real-time monitoring and incident investigation. Because the lost capabilities would outweigh the potential savings, we decided not to use Auxiliary at this time.
Instead of asking GitHub Copilot only for general guidance, I had it review Microsoft Learn, Bicep, the actual Azure resources, and recent log volume. That evidence led to a decision suited to this environment. When choosing a table plan, it is important to consider not only the unit price, but also why the logs are retained and which features depend on them.