0.4 Splunk Enterprise, Splunk Cloud Platform and SPL2

Introduction

Splunk comes in two forms, and analysts meet both in their work. Splunk Enterprise is software an organization installs and runs itself; Splunk Cloud Platform is the same software run by Splunk as a service. For an analyst at the search bar, the two are almost the same: the same Search & Reporting app, the same SPL, the same answers from the same data.

The differences are in administration, who can change configuration and install apps, and they matter when a search needs something only an administrator can provide. Alongside both runs a second language, SPL2, chosen with a picker above the search bar where the deployment supports it. This section compares the platforms and the languages from an analyst's side.

Every product statement in it was checked against Splunk's documentation on 3 October 2026. You will run a search that would run unchanged on either platform, list what differs between them, see where SPL2 is available and how it is chosen, compare an SPL search with its SPL2 form, and fix an SPL2 habit written into SPL.

By the end you should be able to say what any Splunk deployment you meet will let you do, which parts depend on its administrators, and which language to write in.

The diagram is the whole comparison, from the top down. The top row differs in who runs Splunk; the middle row is what an analyst uses, and it is the same; the bottom row is the choice of language, made at the search bar.

The second line is the one that matters most here: the Search & Reporting app, its search bar and its results, which is where every search in this course would be typed.

The card's fourth and fifth lines matter to analysts who build tools around Splunk. An app or a script that works on one platform may need changes for the other, which is a conversation with the administrators before it is a problem.

The trial line is worth knowing for anyone who wants to practice on a real Splunk: Splunk Cloud Platform's free trial runs for 15 days according to the Admin Manual, or 14 according to Splunk's trial page, at up to 5 GB a day, with at most ten searches at once, and its data cannot be exported or kept when the trial ends, according to the Admin Manual's deployment types page.

The card lists the differences an analyst might meet. Most concern administration. For searching, the documentation describes the New Search view as almost identical on the two platforms.

Splunk describes Splunk Cloud Platform as delivering the functionality of Splunk Enterprise as a service, and for searching that description holds.

A search written for one platform runs on the other, given the same data and the same field names.

index=azuread category=SignInLogs action=failure
| stats count by user
| sort - count
| head 3

The lab is a third place the same search runs, and its answer matches what either platform would give for this data. That three-way sameness is what lets a course taught in a lab apply at work.

Nothing in the search names a platform. An index, field terms, a stats, a sort and a head are common to every Splunk, and most searches an analyst writes are built from the same few parts.

The answer depends on the data, not the platform: the same index names, sourcetypes and fields. A search moved between deployments fails far more often because the data is named differently than because the platform is.

The same three accounts on either platform. This course's searches are written in SPL that both run, so nothing learned here needs relearning on the other.

The search names index, sourcetype and a field value, and nothing that belongs to one installation. Searches written this way can be shared between teams on either platform with no changes but the index name, if it differs.

The gateway's user field holds short names, svc_vpn and m.webb, where Entra ID's holds full addresses such as m.webb@ne.com. The same person under two names is a theme Module 5 takes up when it combines sources.

The gateway's 43 failures are spread across 29 accounts, svc_vpn with the most at 7 and administrator among them, the shape of a spray and some guessing at likely names rather than one account under attack. The result looks the same whichever platform runs it.

The write exercise is another such search, on the VPN gateway. Searches that use only commands and data, without depending on a particular installation's custom settings, are the most portable kind.

Portability has a limit worth knowing: searches that call custom commands, scripts or lookups installed on one deployment fail on another that lacks them. That is a difference between deployments, not platforms, and Module 7 shows how to recognize what a search depends on.

Searches saved as reports, alerts and dashboard panels move between the platforms the same way, as text. What they depend on, an index name, a lookup, a macro, has to exist on the other side too.

Splunk Cloud Platform gives its customers no command line and no access to configuration files, according to its Admin Manual. Changes that an Enterprise administrator would make by editing a file are made through Splunk Web, or by Splunk's support team.

| makeresults
| eval platform=split("Splunk Enterprise,Splunk Cloud Platform", ",")
| mvexpand platform
| eval same_spl="yes"
| table platform same_spl

split made a multivalue field from a comma-separated string, and mvexpand gave each value its own row: a small preview of Module 6, where the same two commands take apart lists inside real events.

The table is a toy, and it makes a real point: the course never needs to say which platform a search is for, because every search it teaches is valid on both.

makeresults built one result, eval split a string into two values, and mvexpand turned them into two rows. Every one of those commands is available on both platforms, as is every other command this course teaches.

Two platforms, one language, built as a small table. The differences on the card do not touch any command in this course; they touch what an administrator can configure around the searches, such as which apps are installed and which data models are accelerated.

The first assumption is common enough that it is worth testing once: any search from this course, run on a Splunk Cloud Platform deployment with the same data, gives the same answer.

None of the three is about SPL itself. They are about what surrounds a search, and the four questions in this section's ladder answer all of them.

The second assumption costs time when a search needs a new field extraction or lookup. On Splunk Enterprise, an administrator edits a file; on Splunk Cloud Platform, the same change goes through Splunk Web or a support request, and knowing which avoids a wasted afternoon.

The third assumption matters for anyone following Section 10.9 at work. Whether SPL2 is offered depends on the version and, for Splunk Enterprise, on the operating system, so the picker's presence is the quickest test.

The first assumption is the commonest: that the cloud version is a cut-down search language. It is not; the restrictions are on administration and on a few kinds of output, not on the commands an analyst uses.

The REST API is the other difference an analyst may meet, through tools or scripts rather than the search bar. Splunk Cloud Platform supports a subset of Splunk Enterprise's endpoints, limited to the search tier, so a script written against one may need changes for the other.

Searches depend on more than SPL: the add-ons that give a sourcetype its fields, the data models that tstats reads, the lookups and macros a team shares. On Splunk Enterprise, administrators install these freely. On Splunk Cloud Platform, public apps from Splunkbase can be installed through self-service, and others through Splunk.

For an analyst, the result is the same on both: if a field, a lookup or a data model is missing, the fix is a request to whoever administers Splunk. Module 7 covers the knowledge objects an analyst can create without an administrator, which work the same on both platforms.

The third question is quick: open the Search app and look above the search bar. A picker means SPL2 is available; no picker means SPL only, which is everything this course needs.

The first question is often answered by the address in the browser. Splunk Cloud Platform deployments are reached at a Splunk-hosted address, Enterprise ones at an organization's own.

The fourth question is the one that decides most of this course's later modules in practice. Data models and their acceleration, lookups and macros are set up by administrators, and knowing which exist turns Modules 7 and 9 from theory into tools.

The four questions take a few minutes on a new job and save hours of confusion. The second, the version, decides which features exist; Splunk Cloud Platform versions are named with the year and month of release, such as 10.2.2510.

Splunk manages and updates Splunk Cloud Platform uniformly, according to its Admin Manual, so its customers receive current features as they are released. Splunk Enterprise is updated by its owners, and an older installation may lack features the documentation describes, which is why the version question comes before any other.

SPL2 is a newer version of the language, designed to work across more of Splunk's products. In the Search & Reporting app, a language picker above the search bar switches between SPL and SPL2.

The Unix and Linux note concerns the operating system Splunk Enterprise is installed on. Many deployments already run on Linux, so the picker is common there; checking is quicker than guessing.

The module editor is new to SPL2: a file holding several named searches that can build on each other. SPL has no equivalent; in SPL, each saved search stands alone, and reuse comes from macros, Module 7's subject.

Search history is kept separately for each language, according to the Search Manual's page on the Search app: switching the picker to SPL2 shows only earlier SPL2 searches. A small detail that confuses anyone who switches and finds their history gone.

The card is Splunk's own description of where SPL2 runs. On Splunk Enterprise it is available only on Unix and Linux systems, so a deployment hosted on Windows will show no picker. Where the picker exists, SPL is the default.

The Search app also offers a Convert to SPL2 button when the picker is set to SPL and a search is in the bar, according to the same page. A converted search is a draft, to be checked against the SPL answer like any other, as Section 10.8 recommends for anything written by a tool.

SPL2 is also used outside the search bar, in products that process data before it is stored, according to the same documentation. Those are an administrator's tools, and this course stays with searching.

Most SPL converts to SPL2 with small changes. Here is a search in SPL, run in the lab:

index=azuread category=SignInLogs
| stats count(eval(action="failure")) as failures count by user
| where failures >= 10
| sort - failures

The where keeps accounts with ten or more failures after stats, a condition on a computed count. In SPL2 the same where works unchanged, which is part of why most conversions are small.

The SPL search uses count(eval(...)) to count only failures within stats, a pattern Module 4 teaches. It is also the pattern that changes most visibly in SPL2.

r.scott, d.foster, d.thompson and r.okafor, the four accounts with ten or more failures, the same four Section 10.1 found with a different search.

And the same search as SPL2, written from Splunk's documentation of the differences and not run, because the lab runs SPL only:

$failing = search index=azuread category=SignInLogs
| stats count(action="failure") AS failures, count() AS total by user
| where failures >= 10
| sort -failures

No answer is shown for the SPL2 block, because none was run. When a deployment with SPL2 runs it, the four rows above are what it should return.

The SPL2 version names its total with AS, so the where and sort after it can refer to plain field names. That is a habit Section 10.9 adopts for every conversion.

The search command is written out, count takes parentheses, the statistics are separated by a comma, and the condition goes straight into count without eval. Section 10.9 covers every change and how to check a conversion.

The SPL2 block has no Run button, deliberately. Every SPL2 example in this course is a worked example checked against Splunk's documentation on a stated date, and its SPL reference beside it is what can be run and checked.

Moving between the languages works both ways, and SPL2 habits written into SPL fail.

eval inside count tells SPL that the parentheses hold an expression to test for each event, not a field name. SPL2 drops the marker because it reads expressions there directly.

The fixed search's answer, r.scott with 89, is the same as the reference's top row. Two ways of writing the condition, one answer, which is the check a fix has to pass.

The broken starter is a mistake people who know both languages make, and assistants that write both make too. The error message names the problem, which is the best case.

The fix writes the condition the SPL way, with eval inside count. The lab reports an error for the SPL2 form, because SPL expects eval() around a condition inside count, which is the kinder kind of mistake; Section 10.9's conversions show the silent kind, where a search runs and means something else.

The reference's four rows are kept as they are, so that a later SPL2 run can be compared with them row by row.

The SPL sort writes a space between the minus sign and the field; the SPL2 sort reference's examples attach the sign to the field. Small differences like this are why a conversion is checked by running it, not by reading it.

The completion exercise is the SPL reference's sort. Keeping the SPL answer beside any SPL2 version is the habit that makes a conversion checkable.

Other SPL2 habits to watch for in SPL are a plus sign for joining strings, where SPL uses a period, and the SPL2 module editor's named searches, which SPL has no place for. Section 10.9 lists them all.

SPL is the default in the Search & Reporting app on both platforms, it runs on every Splunk Enterprise installation whatever its operating system, and it is the language of almost every detection, dashboard and saved search an analyst will inherit. Public detection libraries, Splunk's own among them, publish their searches in SPL.

| tstats fillnull_value="null" dc(Authentication.user) AS unique_accounts
    from datamodel=Authentication.Authentication where Authentication.action="failure"
    by Authentication.src _time span=30m
| where unique_accounts > 10

The search begins with a pipe and tstats, a generating command, like the source counts in Sections 0.1 and 0.3. It reads a data model rather than raw events, and Module 9 explains what that means for speed and coverage.

fillnull_value is a tstats option that keeps events whose by fields are empty, which Module 9 explains. The search names it explicitly because the published detection set it in a macro, a common pattern in shared content.

The published version of this detection used five-minute buckets and a threshold of 30, and Section 10.6 shows why it could not fire on this spray. The language was never the problem; the assumptions were.

The search uses tstats over a data model, Module 9's subject, and a half-hour span from Section 10.6's adaptation of a published detection.

SPL2 matters too, and the course does not ignore it: Section 10.9 converts searches from the course and reads every difference, so that an analyst whose team adopts SPL2 can move with it. The lab runs SPL only, which keeps every answer in the course reproducible.

Where it is installed, the Search app also shows an icon for Splunk AI Assistant for SPL, which writes and explains searches from plain language, according to the Search Manual's page on the Search app. Section 10.8 covers checking searches an assistant writes, which applies to it as to any other.

The practice lab sits outside both platforms: it runs SPL in the browser against a fixed month, which Section 0.6 describes. What it teaches about the language applies to either platform equally.

The course rarely mentions the platform again, because the searches do not depend on it. Where they do, a data model's acceleration, a lookup's definition, a limit an administrator can change, the lesson says which settings are an administrator's and how to ask for them.

The habits are four, and none of them is about syntax. Answer the four questions about your deployment once. Write plain SPL that runs on both platforms unchanged. Ask administrators for what only they can change, and say why. And keep SPL answers beside any SPL2 conversion.

Practice

Three questions about the reference searches, each answered in SPL.

All three answers come from SPL in the lab, and each would be the same on either platform. The first is the reference for the SPL2 example in Section 5.

Next, Section 0.5 builds a first search from a question, step by step.