Designing your log architecture: which sources to send to Sentinel, for how long and at what cost

Start from detections, not sources

The most common approach is to enable every available connector and then work out what to do with the data. It produces large bills and tables that are never queried. The opposite approach works better: list the scenarios you need to detect and investigate (account takeover, privilege escalation, malicious consent, exfiltration, lateral movement in AD), then identify the logs strictly required for each one.

Two needs must also be distinguished: detection, which requires recent data that can be queried quickly, and investigation or compliance, which requires data kept for a long time but rarely consulted.

The must-have sources

For a Microsoft environment, the sources that appear in almost every architecture we review are:

• Entra ID: sign-in logs (interactive, non-interactive, service principals, managed identities), audit logs, risk events; and, depending on needs, Microsoft Graph activity logs, which are valuable for spotting API abuse but voluminous;
• Microsoft 365: Exchange, SharePoint, OneDrive and Teams activity from the unified audit log;
• Defender XDR: incidents and alerts, and possibly some advanced hunting tables when they serve specific rules;
• Active Directory: security events from domain controllers, collected selectively, and Defender for Identity signals where it is deployed;
• Azure: subscription activity logs, if the organisation hosts resources there.

Storage tiers and retention

Microsoft's logging platforms offer several storage tiers with different costs and capabilities: an analytics tier for data used by detection rules, cheaper tiers with limited query capabilities for large, rarely queried volumes, and long-term retention for compliance and late investigations. The names, capabilities and pricing of these tiers change regularly, as does the integration of Sentinel into the Defender portal; check the current offering at design time.

The principle remains stable: each table is placed in the tier that matches its use. Logs needed by near real-time rules go to analytics; large logs mainly useful for investigation go to a cheaper tier; total retention is set according to regulatory requirements and the realistic time it takes to discover an intrusion, often several months.

Keeping costs under control

1. Check free or included sources: some Microsoft sources are ingested at no cost or benefit from licence-related allowances; the terms change, so check them.
2. Filter at ingestion: collection rules and transformations let you drop unnecessary events or columns before storage, for instance for Windows logs.
3. Collect Windows events selectively rather than the full security log of every server.
4. Track ingestion per table every month and alert on abnormal increases.
5. Size capacity commitments on the volume actually observed.

From collection to operations

A log architecture only has value if someone handles the alerts. From the design stage, plan the owner of each rule, the associated response procedure, a periodic review of false positives and checks that connectors are still working. A connector that has been down for weeks without anyone noticing is a frequent finding.

What an audit checks

• The presence of essential identity logs, including non-interactive and service principal sign-ins.
• The mapping between collected sources and documented detection scenarios.
• Retention periods per table and whether they meet requirements.
• Monitoring of ingestion volumes and costs.
• Connector health and alerting when one stops.
• Access rights to the workspace and protection against log deletion.