Designing Microsoft Sentinel for a 5,000-Subscription Azure Fleet

When organizations start managing Azure at fleet scale, security operations quickly becomes a control-plane problem.

It is no longer enough to deploy Microsoft Sentinel into a single workspace, enable a few connectors, and call it a SIEM strategy. At enterprise or managed-service scale, the real problem is harder:

How do you manage security visibility across thousands of Azure subscriptions, hundreds of customer tenants, mixed data residency requirements, different workspace ownership models, and still create a consistent detection, response, and remediation experience?

This post walks through an architecture pattern for integrating Microsoft Sentinel with a large Azure fleet platform managed through Azure Lighthouse. The design assumes a delegated model across customer tenants, a mix of centralized and customer-owned logging requirements, and a platform architecture built on Azure WAF, internal API Management, ASE v3, Azure Functions, PostgreSQL, Cosmos DB, Service Bus, Event Hubs, and Durable Functions.

The goal is not just to “turn on Sentinel.” The goal is to make Sentinel part of a governed security operations fabric.

The environment

The reference environment looks like this:

• Approximately 5,000 Azure subscriptions
• Approximately 500 customer tenants
• Azure Lighthouse delegation across customer estates
• Platform-provisioned Microsoft Sentinel workspaces
• Mixed requirements for customer-local and provider-centralized telemetry
• Azure Policy used to enforce diagnostic settings
• Microsoft Defender/Sentinel used as the security case system
• AIOps and approved remediation handled by a central fleet platform
• Durable Functions and Service Bus used for reliable orchestration
• Event Hubs used for downstream fan-out

The platform itself follows a private, layered architecture:

Internet
  → Azure Application Gateway WAF
  → internal Azure API Management
  → internal ASE v3
  → Azure Functions
  → PostgreSQL / Cosmos DB

Application Gateway WAF is the initial public ingress control. Azure Front Door WAF can be added later for global edge protection. API Management remains internal and fronted by WAF. ASE v3 hosts the private application layer, while Azure Functions handle onboarding, policy operations, enrichment, remediation, and evidence collection.

PostgreSQL stores durable fleet state: customer, tenant, subscription, workspace, asset, policy, and remediation metadata. Cosmos DB stores operational logs, correlation state, job telemetry, and workflow traces.

Why a single Sentinel workspace is the wrong default

At small scale, it is tempting to centralize everything into one Microsoft Sentinel workspace. At managed fleet scale, that usually breaks down.

A single workspace model struggles with:

• Customer data ownership requirements
• Regional data residency rules
• Per-customer access control
• Cost attribution
• Workspace-level retention differences
• Customer-specific analytics content
• Regulatory or contractual boundaries
• Cross-tenant operating models

In this architecture, the better pattern is hybrid.

Use customer-owned Sentinel workspaces where logs must remain in the customer tenant. Use provider-owned regional Sentinel workspaces for platform telemetry, AIOps output, SOC meta-events, and centralized customer logging where explicitly allowed.

The result is a multi-workspace, multi-tenant Sentinel architecture managed through Azure Lighthouse.

Workspace topology

The workspace model should be policy-driven, not ad hoc.

A typical deployment supports these patterns:

Provider tenant
├── provider-sentinel-eastus-prod
├── provider-sentinel-centralus-prod
├── provider-sentinel-westus-prod
├── provider-sentinel-westeurope-prod
└── provider-sentinel-uksouth-prod

Customer tenant A
└── sentinel-customerA-prod

Customer tenant B
├── sentinel-customerB-subscription1-prod
├── sentinel-customerB-subscription2-prod
└── sentinel-customerB-subscription3-prod

Customer tenant C
├── sentinel-customerC-eastus-prod
└── sentinel-customerC-westeurope-prod

The default should be one Sentinel workspace per customer tenant. Some customers may require one workspace per subscription. Others may require regional workspaces for data residency. The platform needs to support all three models.

The important design rule is this:

Raw customer telemetry follows customer data residency.
Provider telemetry follows provider regional residency.
AIOps meta-events are centralized only when policy allows.

Reference architecture

flowchart TB

    Internet["Internet / Users / Attackers"]

    subgraph ProviderRegion["Provider Tenant - Regional Control Plane"]
        Defender["Microsoft Defender Portal<br/>Sentinel SOC / Case Management"]
        SOC["Central SOC + Platform Engineering"]

        WAF["Application Gateway WAF<br/>Initial public ingress"]
        FDWAF["Front Door WAF<br/>Future global edge"]
        APIM["Internal API Management<br/>WAF-fronted API boundary"]
        ASE["Internal ASE v3<br/>Private app hosting"]
        Funcs["Azure Functions<br/>Provisioning, policy, enrichment,<br/>remediation, evidence collection"]
        Durable["Durable Functions<br/>AIOps orchestration"]
        PG[("PostgreSQL<br/>Fleet state and governance")]
        Cosmos[("Cosmos DB<br/>App telemetry and correlation state")]

        ProviderSentinel[("Regional Provider Sentinel Workspace<br/>Platform telemetry, AIOps events,<br/>centralized logs where allowed")]
        ServiceBus["Service Bus<br/>Reliable incident and remediation commands"]
        EventHub["Event Hubs<br/>Fan-out stream"]
        Downstream["Downstream Consumers<br/>ServiceNow, Datadog, Teams,<br/>email, internal systems"]
        Evidence["Evidence Store<br/>queries, exports, payloads,<br/>before/after state"]
        DCR["DCR + Logs Ingestion API<br/>Custom fleet tables"]
    end

    subgraph Lighthouse["Azure Lighthouse"]
        DelegatedRBAC["Delegated RBAC / PIM<br/>Sentinel, Security, Monitoring,<br/>Policy roles"]
    end

    subgraph CustomerEstate["Customer Tenants and Subscriptions"]
        CustomerTenantWS[("Customer Tenant Sentinel Workspace")]
        CustomerSubWS[("Subscription-level Sentinel Workspace")]
        CustomerRegionalWS[("Regional Sentinel Workspace")]
        Subs["Azure Subscriptions"]
        Policy["Azure Policy Initiatives<br/>Diagnostic settings, DCR/AMA,<br/>connector compliance"]
        Sources["Telemetry Sources<br/>Azure Activity, Entra ID, Defender,<br/>WAF, APIM, Functions, PostgreSQL,<br/>Cosmos DB, Key Vault, NSG,<br/>Firewall, VM/AMA, Kubernetes"]
    end

    Internet --> FDWAF
    Internet --> WAF
    FDWAF --> WAF
    WAF --> APIM
    APIM --> ASE
    ASE --> Funcs
    Funcs --> Durable
    Funcs --> PG
    Funcs --> Cosmos

    SOC --> Defender
    Defender --> ProviderSentinel
    Defender --> CustomerTenantWS
    Defender --> CustomerSubWS
    Defender --> CustomerRegionalWS

    Funcs --> DelegatedRBAC
    Durable --> DelegatedRBAC
    DelegatedRBAC --> Subs

    Subs --> Policy
    Policy --> Sources
    Sources --> CustomerTenantWS
    Sources --> CustomerSubWS
    Sources --> CustomerRegionalWS
    Sources --> ProviderSentinel

    PG --> DCR
    Cosmos --> DCR
    Funcs --> DCR
    Durable --> DCR
    DCR --> ProviderSentinel

    CustomerTenantWS --> ServiceBus
    CustomerSubWS --> ServiceBus
    CustomerRegionalWS --> ServiceBus
    ProviderSentinel --> ServiceBus

    ServiceBus --> Durable
    Durable --> Evidence
    Durable --> EventHub
    EventHub --> Downstream
    Durable --> ProviderSentinel

The Fleet Platform as the control plane

In this model, Sentinel is the security operations case system, but the fleet platform is the operational control plane.

The platform owns the lifecycle of the Sentinel environment:

1. Provisioning
2. Workspace registration
3. Azure Lighthouse validation
4. Policy assignment
5. Diagnostic coverage
6. Connector health
7. Detection content deployment
8. Incident enrichment
9. AIOps correlation
10. Approved remediation
11. Evidence collection

The platform should maintain a registry of every customer, tenant, subscription, workspace, policy assignment, connector, and remediation policy.

A simplified data model might include:

customer
tenant
subscription
sentinel_workspace
workspace_policy
diagnostic_policy_assignment
data_connector_state
aiops_routing_policy
remediation_action_catalog
incident_evidence_package

This registry becomes the source of truth for routing decisions.

When an incident is created, the platform should know:

• Which customer owns the subscription?
• Which tenant does it belong to?
• Which workspace generated the incident?
• Is the customer managed, co-managed, or monitor-only?
• Are raw logs allowed to leave the customer tenant?
• Is provider-side AIOps metadata allowed?
• Which remediation actions are pre-approved?
• Which downstream systems should receive the event?

Without this control-plane context, Sentinel incidents remain security events. With it, they become actionable operational workflows.

Telemetry onboarding

At this scale, telemetry onboarding must be policy-driven.

The baseline diagnostic policy initiative should include:

Azure Activity Logs
Microsoft Entra ID sign-in and audit logs
Microsoft Defender for Cloud alerts
Application Gateway WAF logs
Azure Front Door WAF logs
API Management gateway logs
Function App and App Insights telemetry
PostgreSQL diagnostics
Cosmos DB diagnostics
Key Vault audit logs
NSG flow logs
Azure Firewall logs
VM security events through AMA/DCR
Kubernetes control plane and audit logs

The platform should continuously validate coverage.

A subscription should not simply be marked “onboarded” because a workspace exists. It should be marked onboarded only when required diagnostic settings, DCR associations, connectors, and analytics rules are healthy.

Recommended coverage states:

NotStarted
WorkspaceProvisioned
SentinelEnabled
PolicyAssigned
DiagnosticsCompliant
ConnectorsHealthy
RulesDeployed
AutomationEnabled
FullyOnboarded
DriftDetected

This gives the SOC and platform teams a shared operating language.

Incident flow

A reliable incident flow should avoid direct point-to-point integrations.

The recommended flow is:

Sentinel incident created
  → Automation rule
  → Logic App playbook
  → normalized JSON payload
  → Service Bus topic
  → Durable Functions orchestration
  → enrichment from PostgreSQL and Cosmos DB
  → AIOps scoring and deduplication
  → approved remediation or human approval
  → evidence package
  → update Sentinel incident
  → publish fan-out event to Event Hubs
  → downstream consumers

Sentinel remains the case system. The fleet platform handles the operational workflow behind the case.

Service Bus and Event Hubs should not do the same job

Both services are useful, but they serve different purposes.

Use Service Bus for reliable command processing:

sentinel.incidents
sentinel.incident-updates
aiops.decisions
remediation.commands
remediation.results
evidence.requests
evidence.results
policy.drift
workspace.health

Use Event Hubs for fan-out and streaming integration:

security-events-fanout
sentinel-incidents-fanout
aiops-decisions-fanout
remediation-results-fanout
platform-audit-fanout

Service Bus is where orchestration commands should go. Event Hubs is where downstream consumers should subscribe.

That separation matters. Remediation workflows need ordering, retries, dead-letter handling, and command semantics. Downstream consumers need scalable event streaming.

AIOps is not auto-remediation

AIOps should start as decision support, not an unrestricted automation engine.

The first phase should focus on:

• Deduplication
• Correlation
• Suppression recommendations
• Customer-aware severity scoring
• Entity enrichment
• Evidence collection
• Recommended action
• Routing logic

Auto-remediation should start slowly and only for approved, low-risk actions.

Good first candidates include:

Reapply missing diagnostic setting
Reassociate missing DCR
Re-enable required policy assignment
Add missing ownership/routing tag
Re-enable known approved analytics rule

Higher-risk actions should require approval:

Disable public network access
Remove role assignment
Rotate secrets or keys
Block IP globally
Modify WAF policy
Change firewall rules

The remediation action catalog should include:

actionId
actionName
riskLevel
allowedCustomerIds
allowedTenantIds
allowedSubscriptionIds
requiresApproval
approvalGroup
rollbackSupported
maxExecutionsPerHour
maintenanceWindowRequired
evidenceRequired
enabled

This allows automation to be powerful without being reckless.

Custom tables

The provider Sentinel workspace should receive platform-level and AIOps-level events through DCR-based ingestion.

Recommended provider custom tables:

FleetCustomer_CL
FleetTenant_CL
FleetSubscription_CL
FleetWorkspace_CL
FleetResourceInventory_CL
FleetDiagnosticCoverage_CL
FleetPolicyCompliance_CL
FleetAIOpsIncident_CL
FleetAIOpsDecision_CL
FleetRemediationCommand_CL
FleetRemediationResult_CL
FleetEvidencePackage_CL
FleetControlPlaneAudit_CL
FleetPipelineHealth_CL

Customer workspaces should receive only what they need:

FleetCustomerContext_CL
FleetAIOpsDecision_CL
FleetRemediationResult_CL
FleetEvidencePackage_CL

Avoid dumping every verbose application trace into Sentinel. Sentinel should hold security-relevant operational data, investigation context, and detection-grade telemetry. High-volume application telemetry can remain in App Insights, Cosmos DB, or another operational store, with summarized security events pushed into Sentinel.

Content deployment

At this scale, Sentinel content should be managed as code.

That includes:

Analytics rules
Automation rules
Playbooks
KQL functions
ASIM parsers
Watchlists
Workbooks
Hunting queries
Diagnostic policies
DCRs
Custom table definitions

The workflow should look like this:

Git repository
  → CI validation
  → KQL and IaC validation
  → package content
  → deploy to provider regional workspace
  → deploy to customer workspaces
  → detect drift
  → report or remediate

This gives you repeatability, versioning, peer review, and rollback.

Manual Sentinel configuration does not survive fleet scale.

Operating model

The final operating model should be simple:

Microsoft Defender / Sentinel is the SOC case system.
The Fleet Platform is the operational control plane.
Azure Policy is the compliance enforcement layer.
Durable Functions is the AIOps orchestration engine.
Service Bus is the reliable command pipeline.
Event Hubs is the downstream fan-out stream.
PostgreSQL is the fleet state store.
Cosmos DB is the operational correlation store.

This pattern respects customer data boundaries while still enabling a centralized SOC experience.

It also allows the organization to grow into more advanced capabilities over time:

• Cross-workspace hunting
• Customer-aware incident scoring
• Policy drift remediation
• AIOps suppression
• Campaign correlation across tenants
• Evidence automation
• Controlled self-healing
• Security posture dashboards
• Regional compliance views

Final thought

The future of Sentinel at fleet scale is not a single workspace. It is a governed, multi-workspace security operations fabric.

For organizations managing thousands of Azure subscriptions through Azure Lighthouse, the architecture needs to balance four concerns:

1. Customer data ownership
2. Regional data residency
3. Centralized SOC operations
4. Automated but controlled remediation

The best design is hybrid: customer-local where required, provider-centralized where allowed, and platform-driven everywhere.

That is how Sentinel becomes more than a SIEM. It becomes part of the Azure fleet control plane.