Costs and performance

Search for AWS adds no ingest volume and no license usage, and the app itself charges nothing per request. What a search can cost is the AWS API behind it. This page says which commands touch a billed API, how the app and its dashboards keep those calls deliberate, and what the app uses on the search head.

What AWS bills

Check AWS’s current pricing pages for the exact rates in your region.

How the app keeps calls deliberate

• Cost Explorer waits for you. The Cost & Usage dashboard is submit-gated: nothing runs until you press Submit, so opening the page costs nothing. Every other dashboard links to it rather than embedding cost panels. | awscost runs once per account regardless of region=, so a fan-out cannot multiply it, and its results are cached for an hour.
• Metrics live on detail dashboards, with two exceptions. The fleet dashboards (every RDS instance, every queue) show inventory and posture from Cloud Control, and the per-resource CloudWatch panels live on the detail dashboard you open by clicking a row, so metric calls happen for the resource you asked about. The exceptions are Lambda, whose Fleet Health tab runs six fleet-wide metric queries when the dashboard opens and whose Saturation & Cost tab runs two more, and EKS, which runs one. Almost all of them are Metrics Insights queries - one request each, however many functions or clusters there are.
• Log tails use FilterLogEvents. The Log Tail dashboard and the Logs tab on detail dashboards read raw events newest first, capped per fetch, through the API that is not billed per GB scanned. Logs Insights is billed per GB scanned, and it runs in three places: the Logs Insights dashboard you open on purpose, the Lambda detail dashboard, and the Lambda fleet’s Saturation & Cost tab, which scans every /aws/lambda/* group over the selected window when you open that tab. Keep that window short on an account with busy functions.
• Nothing runs on a hidden tab. A dashboard tab’s searches dispatch the first time you open the tab, not when the page loads.
• Duplicates come from the cache. Panels on one dashboard that need the same data share one call, and the on-disk cache absorbs the rest - a dashboard refresh within the freshness window is answered from it and costs nothing. The exception is an account on the instance role, which is not cached: every refresh of its panels calls AWS. See Concepts - caching.

Search head footprint

Each search runs the bundled binary, calls AWS, streams results, and exits. The work is transient and tied to the search’s dispatch directory, which Splunk cleans up afterward. There is no always-on process and no background polling, apart from a cache sweep every five minutes.

The on-disk cache lives under $SPLUNK_HOME/var/run/os_aws_search/cache on the search head. It holds recent responses with short TTLs, is swept every five minutes, and stays small. Credentials are never cached.

Querying at scale

A few habits keep large queries fast and cheap:

• Scope tightly. Name the account= and region= you mean; a fan-out over every account and region runs the command once per pair, and each run makes as many API calls as its results take: one per page, plus one per resource with detail=true.
• Cap broad listings with limit=. It bounds the rows | awsget emits, and it bounds detail=true, which is one extra GetResource call per resource.
• Use detail=true only when you need it. Many Cloud Control types list only an identifier; detail=true fetches each resource’s full state. Ask for it when a panel needs those fields, not by default.
• Tune fan-out with concurrency=. It caps how many account and region pairs are queried at once (default 8, ceiling 64). The Setup page’s Settings tab changes the default for every search.
• Mind the window. start= and end= bound what CloudTrail, CloudWatch, and Logs Insights scan; a narrower window is both faster and, for Logs Insights, cheaper. | awsathena takes no window: what Athena scans is decided by the SQL, so bound it there with predicates on the table’s partition columns.
• Let the cache work. Add cache=0 only when you need the answer as of this second, for example in a scheduled alert that must not miss a change.