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 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.

Networking/Security

• Define and configure a list of IP addresses that are allowed to access the platform (for data ingestion, UI, or API access). See Configure IP allow lists for Splunk Cloud Platform in the Admin Config Service Manual.
• Configure outbound ports. Some Splunk Cloud Platform use cases require opening an outbound port so that your deployment can establish an outbound network connection with an external resource. See Configure outbound ports for Splunk Cloud Platform in the Admin Config Service Manual.
  • For example, to configure Splunk Federated Search, you must open Splunk Management port 8089. For more details on Federated Search, see Federated Search for Splunk platform.
• Manage authentication tokens for API access. See Manage authentication tokens in Splunk Cloud Platform in the Admin Config Service Manual.
• Manage HEC tokens for data ingestion authentication. See sections for Victoria Experience and Classic Experience in Manage HTTP Event Collector (HEC) tokens in Splunk Cloud Platform in the Admin Config Service Manual.
• Enable private connectivity to secure your ingest data from traversing over the public internet. Private Connectivity is available only for regulated cloud environments (FedRAMP moderate, HIPAA, IRAP and PCI) on AWS regions. See About private connectivity in Securing Splunk Cloud Platform.

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.

Storage

• 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:
  • Dynamic Data Active Archive (DDAA): Move your indexes' expired data to a Splunk-managed archive. See Store expired Splunk Cloud Platform data in a Splunk-managed archive in Splunk Cloud Platform Admin Manual.
  • Dynamic Data Self-Storage (DDSS): Move your indexes' expired data to a self-managed archive location on AWS S3. You are then responsible for restoring this data should the need arise to search against it. See Store expired Splunk Cloud Platform data in your private archive in Splunk Cloud Platform Admin Manual.
• 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.
  • Manage Splunkbase apps via Splunk Web. See Install a public app from Splunkbase in Splunk Cloud Platform Admin Manual. Manage Splunkbase apps programmatically in Victoria Experience only. See Manage Splunkbase apps in Splunk Cloud Platform in Admin Config Service Manual. More than 98% of Splunkbase apps are already certified and vetted and available for self-service installation.
  • Manage private apps. Private apps must be validated using Splunk AppInspect before being installed. See Manage private apps in Splunk Cloud Platform in Admin Config Service Manual and Use the Splunk AppInspect API on the Splunk Developer Portal.

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.

Limitations

• 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.