Choose the right mode for your environment

Deciding whether to use standard mode or transparent mode across your federated search deployment depends on how you want your users to interact with remote data and the level of control you require over search execution and resource allocation.

When to choose standard mode

Your organization should choose standard mode if you:

• Require explicit control over when and how remote searches are triggered. By default, standard mode isolates the remote provider and requires explicit permission to access remote provider data sets, such as indexes, saved searches, and data models.
• Want to build new federated search deployments and data access strategies from the ground up without maintaining legacy hybrid search configurations.
• Follow the principle of least privilege and want to ensure that users only interact with remote data sets if they explicitly include the federated: prefix in their searches, which invokes a federated index on the federated search head that maps to a dataset on the remote search head.

In standard mode, you create federated indexes on your local search head that map to specific remote datasets, so searches can run on the remote search head. This approach is ideal for administrators who want to prevent accidental or heavy resource consumption on remote instances, since searches are run only when a user intentionally targets a federated index using the federated: prefix.

Standard mode is also the preferred choice for maintaining a strict separation between local and remote datasets, such as indexes, saved searches, last scheduled search jobs, and data models. It ensures that remote resources are only engaged for specific, targeted searches rather than being part of the general search overhead. This is particularly useful in environments with data sovereignty requirements or where remote providers have limited compute resources that must be protected from high-frequency searches.

Searches that invoke knowledge objects in standard mode can require more knowledge object administration than searches in transparent mode. A standard mode federated search can use knowledge objects from the remote search head, the federated search head, or both, depending on where the knowledge object is used in the search and how the search is optimized. Administrators should review expected standard mode federated searches and ensure that required knowledge objects are available where they are needed. See Manage knowledge objects for standard mode federated providers.

The following are some sample use cases for standard mode federated search:

• Targeted security investigations: A security analyst needs to perform a deep-dive search into a specific remote environment to investigate a rare event without impacting daily dashboard performance.
• Compliance auditing: An auditor needs to run a one-time report against a long-term storage instance or a Splunk environment for a different business unit.
• Cross-deployment correlation: A user needs to correlate data between multiple independent Splunk Cloud Platform stacks or Splunk Enterprise environments for historical or functional reasons.

When to choose transparent mode

Your organization should choose transparent mode if you:

• Want to provide a consistent experience where existing knowledge objects and federated searches remain unchanged. Transparent mode is the best choice for organizations aiming for a unified, seamless user experience across multiple Splunk platform deployments.
• Have specific requirements for knowledge object distribution. In transparent mode, knowledge objects are automatically replicated. The federated search head does not use remote knowledge objects, but instead transmits your local knowledge objects, such as apps and lookups, to the remote deployment. This might be a security concern when connecting deployments across different domains where you might need to restrict access to local assets. For example, the federated search head administrator might not want to expose their local knowledge objects to the remote deployment.
• Prefer users to be able to run existing hybrid searches without needing to make syntax changes to their searches or re-map data sources.
• Plan to migrate to Federated Search for Splunk from a hybrid search. Transparent mode is designed to simplify this transition by mimicking the behavior of your existing hybrid search behavior. Because hybrid search already synchronizes knowledge objects across both on-premises and cloud indexers, transparent mode allows you to migrate to federated search without disrupting your users’ current workflows, searches, or reporting dashboards. In addition, transparent mode creates one search domain with the same knowledge objects, which significantly reduces administrative overhead during the transition.

In this mode, you map remote providers to the local search head so that all searches that are triggered on the local federated search head are also sent to the remote provider. Transparent mode allows you to maintain a "single pane of glass" where the physical location of the data is irrelevant to the end user and remote data feels like it is native to the local environment. Transparent mode also lets users run searches against remote data using standard SPL, such as index=remote_data, without needing to invoke an index using specialized syntax like the federated: prefix that is needed for standard mode federated searches. As long as the remote federated provider service account grants the remote search head access to the indexes specified in the search on the federated search head, and the local user has permissions to its indexes, the remote search head will process those search requests. See Security models for Federated Search for Splunk.

The following are some sample use cases for transparent mode federated search:

• Migration scenarios: Your organization is in the process of moving from a hybrid search setup from an on-premises Splunk Enterprise deployment to Splunk Cloud Platform, and users need to be able to search across both environments during the transition.
• Dashboard portability: You have a large library of pre-built dashboards, saved searches, and alerts that must incorporate data from remote providers without any modification to existing searches.
• Unified app support: Your organization uses premium applications like Splunk Enterprise Security, which often require the transparent mapping of indexes to function correctly across distributed deployments.

Implementation considerations

Keep the following considerations in mind as you plan your rollout of standard or transparent mode in your Federated Search for Splunk deployment.

• Mode selection
  • It is not possible to change the mode of the federated provider once it has been created without deleting and recreating it. Therefore, plan your selection carefully during the initial setup phase.
• Security
  • If your organization chooses transparent mode federated search, you should do a pre-deployment analysis of the indexes you want to make accessible on remote search heads and make sure that access permissions across your deployment align with your current security policies. See Security models for Federated Search for Splunk.
• Performance
  • By default, the local federated search head sends every transparent mode search to all remote search heads, even if every search doesn’t need to be sent to every remote search head, which can cause significant performance and search concurrency consequences on remote search heads. However, you can use granular search targeting controls to alter this behavior and tailor searches to your organization’s specific needs. See Configure role-based access and search targeting for transparent mode federated providers.