Search for AWS is built to be fully manageable from Splunk Web, because on Splunk Cloud nobody can open a terminal on the search head or edit a configuration file by hand. This page collects what is different there. Everything else in the documentation applies to Splunk Cloud unchanged.
Installing the beta
The app is not on Splunkbase yet, so on Splunk Cloud it installs as a private app: upload the package we send from Apps - Manage Apps - Install app from file. Splunk Cloud runs AppInspect on a private app when you upload it, and the package is built and tested against that check set. Ask sales@outcoldsolutions.com for the package and the beta license key; Installation has the rest.
Everything is on the Setup page
Every setting you can change on Splunk Cloud is on the app’s Setup page, which writes the app’s configuration files for you:
| Tab | What it manages |
|---|---|
| Accounts | The shared account registry: account id, default region, region lock, partition, endpoint override, and the credential |
| Credentials | Your own per-user credential overrides (paid) |
| Cache | Disable the response cache, set its default TTL, clear it |
| Settings | The default region, fan-out concurrency, the per-request AWS timeout, and the log level |
| License | Enter, replace, or remove the license key, and read the entitlements |
Nothing requires a configuration-file edit. Two values have no control there, because they are file locations on the search head: the cache directory ([cache] dir) and the per-search log file’s name ([logging] file). Their defaults are the right ones on Splunk Cloud. The log file’s name can be changed through the app’s settings REST endpoint if you ever need to; the cache directory is set in the file only, so on Splunk Cloud it stays at its default. The Configuration page documents the same values in their aws_search.conf form for self-managed search heads.
Who can configure it
Splunk Cloud has no admin role; its administrators hold sc_admin, which the app’s access lists include. An sc_admin can do everything without being assigned an app role. To delegate, assign aws_search_admin (register accounts, change settings and the license) or aws_search_user (query only) under Settings - Roles. See Access control.
Credentials on Splunk Cloud
A Splunk Cloud search head has no EC2 instance role you control, so the instance role credential source does not apply. Use one of:
- Static keys - an IAM user’s access key pair, stored encrypted. Available on the free tier.
- Assume role with base credentials - an IAM role in the target account, assumed with a static key pair that has
sts:AssumeRoleon it, plus an external id in the role’s trust policy. Cross-account assume-role is a paid feature. Leave the base credentials blank only on a self-managed search head with an instance role.
Both apply to a per-user credential as well. A per-user override replaces the account’s credential outright and inherits nothing from it, so a per-user assumed role needs its own base credentials: fill in the base access key on the Credentials tab. Without them the override would sign requests as the search head itself, so the form refuses to save one without them - on Splunk Cloud and everywhere else.
The credential setup for each is in Accounts.
Outbound access to AWS
The search head calls the AWS service endpoints over HTTPS (port 443): cloudcontrolapi.<region>.amazonaws.com, logs.<region>.amazonaws.com, monitoring.<region>.amazonaws.com, cloudtrail.<region>.amazonaws.com, athena.<region>.amazonaws.com, glue.<region>.amazonaws.com, tagging.<region>.amazonaws.com, sts.<region>.amazonaws.com for assumed roles, and ce.us-east-1.amazonaws.com for Cost Explorer.
Outbound connections from a Splunk Cloud stack are governed by its outbound port rules, which you manage through the Admin Config Service (ACS). If the Test button on an account reports a connection timeout while the credentials are known to be good, that is the first thing to check: confirm the stack allows outbound traffic on port 443 to the AWS endpoints you use. Prefer scoping a rule to the AWS service endpoints over opening 0.0.0.0/0.
If your stack routes AWS traffic through a single egress proxy, set the account’s endpoint override to it instead of allow-listing AWS’s own address ranges, which change often. See Accounts - endpoint override.
Caching and logs
The response cache lives under the search head’s var/run directory. If the search head cannot write there, searches run uncached and nothing breaks; you can also switch the cache off on the Cache tab.
Warnings and errors a command raises appear in the search’s own messages and in the job’s search.log, both readable from the Job Inspector. The app’s setup handlers and cache sweeper log to index=_internal, which you can search. The per-search aws_search.log in the dispatch directory is readable only on a self-managed search head. Raise the log level on the Settings tab while you reproduce a problem. See Troubleshooting.
Search head clusters
Search for AWS supports search head clustering with a paid license. The account registry, per-user credentials, settings, and the license replicate to every member; the response cache is per member. Nothing about that is different on Splunk Cloud.