Log-Management in Azure: LAW, Elastic (Marketplace) und Splunk sauber einordnen

Einleitung

In realen Azure-Landschaften scheitert Logging selten an Technik, sondern an fehlender Architekturentscheidung. Teams aktivieren Diagnostic Settings „irgendwie“, schicken Daten parallel an mehrere Ziele und merken erst Monate später, dass Kosten, Datenqualität und die Analyseprozesse nicht mehr beherrschbar sind.

Die zentrale Frage ist deshalb nicht ob Logs gesammelt werden, sondern:

1. Wo werden die Informationen zentral gespeichert?
2. Welche Datenpfade sind erlaubt (Security/Compliance)?
3. Wo wird korreliert und alarmiert (Ops vs. SecOps)?
4. Wie verhindert man doppelte Ingestion-Kosten?

Dieser Artikel bewertet LAW, Elastic (insbesondere über den Azure Marketplace) und Splunk aus Produktionssicht mit klaren Trade-offs.

Option A: LAW als Azure-Standard: stark, aber kein Selbstläufer

Für Azure-native Umgebungen ist der Log Analytics Workspace (LAW) der natürliche Kern, weil Logs aus Azure-Diensten dort ohne Umwege landen wie beispielsweise Activity Logs, Diagnostic Logs, AMA/DCR-Streams, Defender for Cloud oder Sentinel.

Warum LAW in Azure so oft gewinnt

• Natives Routing: Diagnostic Settings und DCR sind erstklassig integriert.
• KQL als gemeinsame Sprache: Betrieb, SRE und Security arbeiten auf derselben Query-Basis.
• Plattformfeatures hängen daran: Sentinel, Workbooks, Alerting, teils Defender-Workflows.
• Governance-fähig: Azure Policy kann Logging-Standards erzwingen.

Wo LAW in der Praxis schmerzt

• Hohes Log-Volumen lässt Kosten für den Log Analytics Workspace explodieren.
• Multi-Cloud-Analysen sind möglich, aber nicht so elegant wie bei den spezialisierten Plattformen.

Praxisregel: LAW ist die beste Default-Option für Azure-first, aber nur mit sinnvollen Retention-Time Policy und Data-Collection-Rule Konfiguration.

Datenpfade in Azure sauber designen (statt später „nachzurüsten“)

Ein belastbares Zielbild unterscheidet zwischen Control Plane, Workload Logs und Security-Telemetrie:

• Control Plane: Azure Activity Logs (Subscription/MG-Ebene)
• Workload-Ebene: PaaS/IaaS-Diagnostic Logs, VM- und AKS-Telemetrie
• Security-Ebene: Defender/Sentinel-relevante Tabellen, Audit-Trails

Minimaler Referenzpfad:

Azure Resources
  ├─ Diagnostic Settings ──────────────────▶ LAW
  ├─ AMA + DCR (+ DCE/Private Link) ───────▶ LAW
  ├─ Optional Export (Event Hub/Storage)───▶ Downstream (Splunk)
  └─ Optional Export (Nativer Export)──────▶ Elastic Cloud (Marketplace)

Praxisregel: Wenn LAW und ein zweites Tool parallel „primär“ befüllt werden, zahlt man oft doppelt für Ingestion, Retention, Egress und Betriebsaufwand.

Option B: Elastic via Azure Marketplace

Elastic über den Azure Marketplace ist nicht nur „Kibana per Klick“, sondern ein eigenes Betriebsmodell mit Konsequenzen.

Integrationsbesonderheiten

Typische Integrationspfade in Azure:

1. Azure Natives Marketplace-Deployment für Elastic Cloud
2. Nativer Support für Azure Service Logs
3. Agent-basierte Log-Erfassung für VMs, Container, Kubernetes Workloads
4. Direktquellen aus M365/Azure-APIs je nach Use Case

Beim Einsatz von Elastic Cloud ist die Erfassung von Logs nur eine Teilaufgabe. Ideallerweise müssen ebenfalls Themen wie Single-Sign-On, separate Kibana Spaces für Stages und individuelle Kibana-Rollen in den Entra-Tenante synchrosiert werden. Damit ist die Elastic Cloud Instanz vollumfänglich abgesichert und die Benutzerverwaltung erfolgt zentral im Azure Tenant.

Typische Aufgaben bei der Verwendung von Elastic

Bei produktiver Nutzung entstehen zwingend Aufgaben wie:

• Index-/Data-Stream-Strategie: Namenskonventionen, Rollover und ILM-Phasen
• Shard-Planung: falsch dimensionierte Shards kosten Performance und Geld
• Pipeline-Hygiene: Parsing, Enrichment, Dead-Letter-Verhalten
• Upgrade-/Version-Management: besonders bei Integrationen und Agenten
• On-Call-Fähigkeit: Cluster-Health, Backpressure, Ingest-Latenz

Die Marketplace Lösung reduziert den initialen Beschaffungs- und Initialaufwand, aber leider nicht die Notwendigkeit einer erfahrenen Betriebsverantwortung.

Zusätzlich müssen bei stark regulierten Umgebungen die folgenden Punkte geklärt sein:

• Datenresidenz und Region-Bindung
• Private Connectivity und kontrollierte Egress-Pfade
• Verschlüsselung (at rest/in transit)
• RBAC/SSO-Integration (Azure AD/Entra ID)
• Tenant- und Space-Trennung für Teams/Mandanten
• Auditierbarkeit von Admin- und Query-Aktionen

Wenn diese Themen erst nach Incidents oder einem Audit adressiert werden, ist die Migration meist teurer als eine saubere Vorab-Architektur.

Elastic als Ersatz für LAW ?

Die häufige Management-Frage lautet: „Können wir LAW abschalten und alles nach Elastic legen?“

Kurz: teilweise ja, aber nicht ohne funktionale Verluste im Azure-Ökosystem.

Was funktioniert gut mit Elastic als Primärplattform

• Sehr starke Volltextsuche und flexible Schema-Entwicklung
• Gute Plattform für Multi-Cloud-/Hybrid-Korrelation
• Einheitliche Oberfläche, wenn Elastic bereits Unternehmensstandard ist

Was dabei verloren geht oder komplexer wird

• Native Anbindung bestimmter Azure-Features, die LAW voraussetzen
• Reibungslose Nutzung von Sentinel als auf LAW-aufsetzendes SIEM
• Einheitliche KQL-Workflows für Azure-Ops-Teams
• Teilweise höherer Integrationsaufwand für Plattformdienste

Wie ich die Entscheidung treffen würde?

• Azure-first + Sentinel/Defender-fokussiert: LAW als SoR behalten.
• Elastic bereits konzernweit als Standard: LAW auf Mindestmaß für Azure-native Pflichtpfade reduzieren, Elastic als Primär-Analytics nutzen.
• Greenfield ohne starke Azure-SecOps-Bindung: Elastic kann Primärplattform sein, wenn Betriebskompetenz und Security-Design vorhanden sind.

Option C: Splunk richtig einordnen

Splunk bleibt in vielen Enterprises besonders dort relevant, wo SIEM/SOC-Prozesse historisch darauf aufbauen.

Wann Splunk in Azure sinnvoll ist

• Vorhandene globale Splunk-Use-Cases und Content-Libraries
• Reife SOC-Prozesse auf SPL-Basis
• Einheitliche Detection-/Response-Logik über On-Prem, AWS, Azure, GCP

Typisches Azure-Muster mit Splunk

• Azure Logs nach Event Hub
• Weiterleitung nach Splunk (mit Hilfe von HEC/Connector/Functions je nach Zielbild)
• LAW oft weiterhin für Azure-native Betriebsfunktionen aktiv

Der harte Trade-off

• Splunk ist technisch stark, aber häufig die teuerste Option pro ingested GB.
• Ohne klare Use-Case-Priorisierung wird „alles nach Splunk“ schnell unwirtschaftlich.

Praxisfazit: Splunk ist keine Fehlentscheidung, wenn es organisatorisch gesetzt ist, aber in Azure-only-Setups oft nicht die wirtschaftlichste Erstwahl.

Konkrete Architekturmuster für deine Produktivumgebung

Muster A: Azure-native Standardarchitektur

• LAW als System of Record
• DCR-basiertes Routing (kritische Logs in Log Analytics)
• Sentinel bei SIEM-Anforderungen
• Export nur für definierte Use-Cases

Muster B: Dual-Platform mit klarer Rollentrennung

• LAW für Azure-Plattformbetrieb und native Security-Integrationen
• Elastic oder Splunk für unternehmensweite Korrelation/Threat-Hunting
• Striktes Filter-/Sampling-Design, um Doppel-Ingestion zu begrenzen

Muster C: Elastic-zentriert mit Azure-Minimal-Footprint

• Elastic als Primär-Store und Analyseebene
• LAW nur dort, wo Azure-Funktionalität zwingend LAW voraussetzt
• Governance-Regeln dokumentieren, damit „Schattenpfade“ nicht entstehen

Fazit

Die beste Entscheidung ist selten „Tool X gegen Tool Y“, sondern ein klarer Verantwortungszuschnitt pro Plattform:

• LAW dort verwenden, wo Azure-Native-Mehrwert und Betriebsstabilität zählen.
• Elastic dort nutzen, wo flexible Suchen, Multi-Cloud-Korrelation und bestehende Kibana-Feature notwendig sind.
• Splunk dort einsetzen, wo Enterprise-Prozesse bereits darauf standardisiert sind.

Wer diese Rollen früh festlegt, verhindert die typischen Spätfolgen wie zum Beispiel doppelte Kosten, inkonsistente Datenpfade und lange Incident-Zeiten.

Klarheit in eure Log- und Monitoring-Architektur bringen

Unklare Datenpfade, doppelte Ingestion und inkonsistente Logging-Standards führen in vielen Azure-Umgebungen zu unnötigen Kosten und erschweren Incident Response und Security-Analysen erheblich.

Mit unserem Cloud Audit analysieren wir eure Azure- und Observability-Architektur ganzheitlich – von Log Analytics Workspace über Elastic oder Splunk bis hin zu Datenpfaden, Retention-Strategien und Sicherheitsmodellen.

Ihr erhaltet konkrete Empfehlungen, wie ihr Kosten reduziert, Logging sauber strukturiert und eine belastbare Grundlage für Betrieb, Security und Compliance schafft.

→ https://henden-consulting.de/de/cloud-audit