Back to production requirements

Serverless audit logging to Splunk and Azure Monitor

Audience: Security and platform engineering
Status: Complete for GA via Logstash workaround; native external delivery remains on the product roadmap


Requirement

Security requires all audit logging forwarded into your domain:

DestinationTiming
SplunkCurrent requirement
Azure Monitor / Azure Log AnalyticsFuture or alternate path

Native Serverless-only audit destinations do not meet this policy for production. External delivery to customer SIEMs is a future enhancement and is not available for GA.

Decision: This requirement is complete for GA using the Logstash bridge below. Native push to Splunk / Azure Monitor stays a longer-term product ask and does not block cutover.


Recommended approach

Phase 1 — GA: Logstash bridge in your environment

Near-term path: run Logstash (or equivalent) in your network or Azure subscription.

Elastic Serverless (audit events)
        │
        │  Elasticsearch API over Private Link
        ▼
Logstash (your VPC / Azure)
        │
        ├─► Splunk HEC          (primary today)
        └─► Azure Monitor / Event Hub  (later)

Why Logstash:

  • Runs in your domain, so audit data stays under your control
  • Proven path from Elasticsearch to HTTP / HEC destinations
  • Can send to Splunk now and Azure Monitor later without re-platforming Serverless

Implementation outline:

  1. Enable Serverless audit logging to the destinations available inside the project (source of truth).
  2. Deploy Logstash in Azure Central US, reachable to Serverless over Private Link.
  3. Input: read audit indices or data streams with a read-only API key.
  4. Filter: normalize to your SIEM schema; stamp project, environment, and dataset fields.
  5. Output A (Splunk): HTTP Event Collector — token, index, and sourcetype agreed with security.
  6. Output B (Azure, later): Azure Monitor Logs or Event Hubs into Log Analytics — same pipeline, second output.
  7. Operations: retries, lag alerting, and delivery notes for security sign-off.

Security acceptance criteria:

  • All required audit event types present (authentication, authorization, config, data access as applicable)
  • Freshness SLA agreed (for example under 5–15 minutes)
  • Retention in Splunk or Azure matches policy
  • Pipeline and credentials owned by you (or jointly operated under your IAM)
  • Private networking only — no public audit egress

Phase 2 — Native external delivery

Longer term, Elastic can deliver audit events directly to customer-owned destinations (Splunk, Azure Monitor, or equivalent HTTPS endpoints). That work has non-functional requirements around authentication, reliability, and multi-tenant egress. It should not block GA if Phase 1 is accepted.


Options compared

OptionIn your domainReady for GAEffortNotes
A. Logstash to Splunk HECYesYesMediumPreferred near-term
B. Logstash to Azure MonitorYesYes, when Azure path is readyMediumSame bridge, second output
C. Manual query and export scriptsPartialFragileLow start, high opsNot recommended for continuous audit
D. Wait for native external deliveryYes, when shippedNoLow customer effort, long waitRoadmap risk if this is the only path
E. Serverless destinations onlyNoDoes not meet security policy

Recommendation: commit to option A for GA; design the pipeline so B is a configuration change; track D as the long-term simplification.


Discussion points with security

  1. Audit must land in Splunk (and later Azure monitoring), not only inside Elastic Serverless.
  2. Native push to an external SIEM is a future enhancement — not available for GA.
  3. For GA, Logstash in your Azure environment pulls Serverless audit data over Private Link and forwards to Splunk HEC.
  4. When native external delivery ships, the bridge can be retired or reduced.
  5. Confirm event catalog, lag SLA, and Splunk index / sourcetype so a pilot can run before cutover.

Open questions

  1. Exact audit event catalog on Serverless Search versus hosted deployments.
  2. Roadmap timing for native external log delivery.
  3. Preferred Splunk path (HEC versus indexer) and Azure path (Log Analytics direct versus Event Hub).
  4. Who operates Logstash and who owns API key rotation.

Next steps

  1. Share Phase 1 architecture with security for sign-off.
  2. Record the external-delivery product ask with Elastic for the longer-term roadmap.
  3. Stand up a pilot Logstash to Splunk HEC against the Serverless project (Central US and Private Link).
  4. Document the runbook and lag alerts; add Azure Monitor as a second output when security is ready.