Splunk® Validated Architectures

Splunk Validated Architectures

Splunk Cloud Platform Experiences

Your Splunk Cloud Platform deployment has one of two Experience designations: Classic or Victoria. In the medium term, all customers will move to the Victoria Experience. Refer to the Splunk Cloud Platform Service Description to check region availability for each experience.

Victoria Experience and Classic Experience provide nearly identical capabilities and service limits, with some exceptions.

For information on the differing capabilities and service limits of each Splunk Cloud Platform Experience, see Determine your Splunk Cloud Platform Experience in the Splunk Cloud Platform Admin Manual.

Architecture diagram

The following diagrams represent the high-level architecture of a Splunk Cloud Platform deployment and show the integration points with your environment.

Splunk Cloud Platform with Victoria Experience
Splunk Cloud Platform with Victoria Experience.

Splunk Cloud Platform with Classic experience
Splunk Cloud Platform with Classic Experience.

Architecture description and benefits

When you choose Splunk Cloud Platform, all deployments are based on a standardized architecture for all customers in the same region. The Splunk Cloud Platform team builds and operates your dedicated (single-tenant) AWS or Google Cloud Platform (AWS only for Victoria Experience ) environment to ensure that the service is compliant and resilient.

As shown in the architecture diagrams in this document, the standard Splunk Cloud Platform deployment presents the following main components or characteristics:

  • Indexers spread across three different availability zones (in a single region) to help ensure high availability.
  • Single Search Head (SH) or a Search Head Cluster (SHC), depending on your service agreement. SHC instances are also spread across different availability zones and are fronted by a load balancer so users can use a single endpoint for UI access.
  • Additional SH for Premium Apps (Enterprise Security (ES) and IT Service Intelligence (ITSI)). SHC is available for ES in Victoria Experience only.
  • Data ingestion using Splunk to Splunk (S2S) on the standard TCP port (9997) and using HTTP Event collector (HEC) on port 443.
  • Data collection for modular and scripted inputs.
    • Configured directly in the Search Head tier for Victoria Experience.
    • Configured on Inputs Data Manager (IDM) for Classic Experience.
  • Data distribution is accomplished through client and/or server side load balancing where appropriate.
  • Access rules are defined in the network layer to allow or deny inbound and outbound connections for both Search Head and Indexer tiers.
  • All data in transit is encrypted by default.

When you have access to your Splunk Cloud Platform instance and are ready to start onboarding data, there are still some decisions you need to make to help ensure your environment is secure and performant.

The following sections describe customer-specific configurations that allow you to tailor your environment for your needs. Refer to the section "Splunk Cloud Platform: Shared Responsibility Model" in the Splunk Cloud Platform Service Description for more details.


Consider the need for encryption at rest.

  • Splunk Cloud Platform offers data encryption as a premium service enhancement that customers can purchase. The keys are managed by Splunk. Regulated subscriptions (DoD IL5, FedRAMP moderate, HIPAA, IRAP and PCI) have encryption at rest enabled by default.
  • Enterprise Managed Encryption Keys (EMEK) is also available for customers that require to manage their own keys. See Secure data with Enterprise Managed Encryption Keys in Securing Splunk Cloud Platform.
  • Define your authentication strategy. Other than the native splunk authentication, Splunk Cloud Platform also supports integration with LDAP and SAML for single sign on. See Set up user authentication with LDAP and Configure single sign-on with SAML in Securing Splunk Cloud Platform.
  • Configure role based access control (RBAC) to control user access to platform resources. See About configuring role-based user access in Securing Splunk Cloud Platform.


  • Define retention settings for indexes. See Manage data retention settings in Splunk Cloud Platform Admin Manual.
  • Define data lifecycle strategy. When you create indexes, you must specify Index Type (metrics or logs), and Searchable Days of retention. Optionally, you can configure your indexes to archive data as it ages out. There are two archival options:
  • Restore archived data if or when needed (only applicable for DDAA). Restored DDAA data is typically ready to search within 24 hours after a restoration request and remains searchable for up to 30 days. Large amounts of DDAA data restore can take beyond 24 hours to complete. See Restore archived data to Splunk Cloud Platform in Splunk Cloud Platform Admin Manual.

Knowledge Objects Management

  • Manage apps: Splunk Cloud Platform requires apps to be vetted to ensure the stability and security of your environment. For Victoria Experience all the apps installed are replicated across all Search Heads and/or Search Head Clusters, including ES and ITSI SHs.

Environment performance management/tuning

  • Manage/tune the allocation of compute resources used by the different workloads (search, ingest, and others) using Workload Management. See Workload Management overview in Splunk Cloud Platform Admin Manual.
  • Specify default app, searchable indexes, and search-related limits for a role using RBAC. See Create and manage roles with Splunk Web in Securing Splunk Cloud Platform.
  • Monitor your Splunk Cloud Platform deployment using Cloud Monitoring Console. See Workload Management overview in Splunk Cloud Platform Admin Manual.

Many admin tasks can be automated using Admin Config Service (ACS). ACS is a cloud-native API that provides programmatic self-service administration capabilities for Splunk Cloud Platform. See Admin Config Service Manual for supported administration capabilities.


  • For general service limits and constraints, see Service limits and constraints in Splunk Cloud Platform Service Description. For specific limits for Victoria Experience and Classic Experience, see Experience designations in the same document.
  • To learn about differences between Splunk Cloud Platform and Splunk Enterprise, see Differences between Splunk Cloud Platform and Splunk Enterprise in Splunk Cloud Platform Service Description.
  • As a customer, you define your Splunk Cloud Platform instance name, which can't be changed after the service is in operation. The instance name determines the environment's URL, for example https://<instance name>.splunkcloud.com/.
  • Ports for API/Management (8089) and for getting data in (9997 S2S, and 443 HEC) cannot be changed.
  • Splunk Cloud Platform does not allow the standard Splunk Enterprise CLI access. Any supported task that requires standard CLI access is performed by the self-service capabilities of Splunk (either using the Splunk Web interface or ACS) or by filing a service ticket.
  • Splunk Cloud Platform does not manage or monitor your customer-managed Splunk software components such as Deployment Servers or Universal Forwarders.
Last modified on 12 March, 2024
Federated Search for Amazon S3   Splunk Cloud Platform IL5

This documentation applies to the following versions of Splunk® Validated Architectures: current

Was this topic useful?

You must be logged into splunk.com in order to post comments. Log in now.

Please try to keep this discussion focused on the content covered in this documentation topic. If you have a more general question about Splunk functionality or are experiencing a difficulty with Splunk, consider posting a question to Splunkbase Answers.

0 out of 1000 Characters