Should I ingest AADNonInteractiveUserSignInLogs from Entra ID to a LAW

You should ingest this table if : 

1. You are actively using Microsoft Sentinel or another SIEM for threat hunting.
2. You want visibility into non-interactive sign-ins , especially for service principals and managed identities ( common in lateral movement attacks or credential misuse). 
3. You need a complete audit trail of all authentication activity, including background and token-based auth. 
4. You're analyzing service-to-service communications, automation activity, or script-based operations in your tenant

Ways to Reduce Data Volume and Cut Costs

If you're concerned about the high volume (and cost) of ingesting AADNonInteractiveUserSignInLogs into your Log Analytics Workspace, here are some practical ways to reduce the impact:

Use Diagnostic Settings Filters

Fine-tune what gets sent to your workspace. In your Entra ID diagnostic settings, you can:

• Filter out non-essential data based on resource type—like ignoring certain apps or service principals.
• Apply KQL filters to exclude known, low-risk sign-ins (like trusted internal apps).

This helps you focus only on the events that really matter.

2. Switch to Basic Logs (If Available)

Check if the AADNonInteractiveUserSignInLogs table supports Basic Logs. These are cheaper to store, though they come with limitations like shorter retention and less advanced query capabilities. Still, for low-priority logs, they can be a great cost-saver.

3. Send Logs to Azure Storage

If you mainly need the logs for auditing or compliance—not real-time analysis—you can route them to Azure Storage instead of Log Analytics. Storage is far more affordable, and you can always pull the data into Azure Data Explorer or Log Analytics temporarily if you ever need to analyze it.

4. Leverage Sentinel with Custom Analytics Rules

If you're using Microsoft Sentinel, consider setting up custom rules that ingest only the data you care about—like unusual patterns or high-risk sign-ins. You can still detect threats without bringing in the full volume of raw log data.

Final Recommendation

If you’re not regularly monitoring service principals or non-interactive sign-ins—and cost is a concern—there’s no harm in skipping this data or being selective about what you ingest.

But if you operate in a high-security environment or need to meet strict audit/compliance standards, it's smart to ingest the logs (even if partially) so you don’t miss critical service activity.

Let me know if you’d like help setting up filters or deciding on a storage strategy.