Topology selection guidance
Initial publication: June 23, 2025
Last reviewed: Jan 22, 2025Overview
This document was created to aid the selection of Splunk SOAR software deployment topologies and associated Splunk SOAR Validated Architectures (SSVAs). It is not, itself, an SVA. The document provides background information on the tier categories, the methodology used to construct a topology category code, and includes a questionnaire that may be used to align requirements for your architecture to a topology category code.
Topology categories
The following is a key to SVA topology categories. These categories are used in the questionnaire below. You will also find references to these categories in the next steps of the SVA selection process.
Platform topology categories
| Category code | Explanation |
|---|---|
| S0 | Category "S0" indicates a Splunk SOAR Cloud Software as a Service deployment. |
| S1 | Category "S1" indicates a single-server Splunk SOAR (On-premises) deployment. |
| X | Category "X" indicates a single-server Splunk SOAR (On-premises) deployment with an externalized shared service such as a database. |
| D | Category "D" indicates a distributed Splunk SOAR (On-premises) deployment that can be spread across two sites configured in warm standby mode. Warm standby is not supported with externalized shared services. |
| C | Category "C" indicates the need for a clustered Spunk SOAR (On-premises) deployment for horizontal performance scaling with multiple SOAR nodes and externalized shared services. The clustered Splunk SOAR (On-premises) deployment does not support multi-site configurations. |
Determine your topology category code
In the following Defining Your Requirements for SOAR, section you answer questions to help identify the topology that best aligns with your requirements. You answer a series of questions and, based on your answers, you identify a topology category that is best for your needs.
Instructions
- Write down the questions to which you answer "yes."
- If you answer "yes" to multiple questions, follow the topology recommendation for the highest numbered question. If you see multiple topology options (for example, "X/D/C"), look at the previous questions to determine which option is best suited for you.
Example #1
Assume you answer "yes" to questions #2, #3 and #4. You end up with a topology category of "D", indicating the need for a warm standby instance.
Example #2
Assume you answer "yes" to questions #3, #5, and #6. You end up with a topology category of "C", indicating a clustered SOAR deployment as your ideal topology.
Questionnaire for defining your requirements
Review and answer the questions in the table below to determine your topology category code. If you answer "yes" to multiple questions, use the topology category code for the highest numbered question.
| # | Question | Considerations | Impact on topology | Core Platform topology |
|---|---|---|---|---|
| 1 | Are you wanting a solution that reduces your infrastructure and maintenance costs while maximizing performance? | Splunk SOAR Cloud is regularly updated with the latest features and performance improvements.
Please review the current service limitations to verify that it meets your requirements for immediate and short-term growth. |
Candidate for SaaS solution that provides reduced maintenance costs, latest functionality and performance enhancements with managed infrastructure. | S0 |
| 2 | Is your expected event ingestion rate in the standard range, no more than 30,000 events/hour running 2 active standard playbooks? | Consider short-term growth in the daily ingest (~6-12 months).
For this requirement, a standard playbook has 10 or less blocks that consists of 5 or less action calls (procedure steps). If the complexity and number of active playbooks differs greatly, then the supported ingestion rate would be modified accordingly. SOAR can achieve higher automation workloads with vertical scaling and system tuning. More details on system tuning are available at Splunk Lantern, see Tuning SOAR to optimize performance. |
Candidate for a single server, single server with externalized services or warm standby deployment, depending on answers to availability-related questions. | S1, X, D |
| 3 | Do you have administrative resources to manage the Splunk SOAR (On-premises) external services, i.e. database, file share and web proxy? | Externalizing shared services within Splunk SOAR (On-premises) offers significant benefits, including potential performance improvements, enhanced scalability, and increased reliability and resilience. However, it is important to note that this approach may also incur higher administrative costs.
While general guidance on connecting Splunk SOAR (On-premises) with external services is provided, it is strongly recommended to seek additional expertise for the comprehensive management and integration of these services. Engaging with specialists can ensure optimal performance, security, and reliability. For enhanced availability and resilience, consider utilizing cloud services when externalizing services within the platform. Cloud-native technologies offer built-in features that can significantly boost the reliability and performance of your services. |
Candidate for a single instance with externalized shared service or a high capacity cluster with externalized services. | X, C |
| 4 | Do you require multi-site high availability? | Warm Standby provides Active/Passive failover and can be used in multi-site environments. The failover method is manual but can be scripted with additional engineering.
Warm Standby cannot use externalized services for the database or file system. It is possible to achieve High Availability requirements with other Splunk SOAR (On-premises) architectures using third party services that may already be in use in the customer's environment. |
Requires two Splunk SOAR (On-premises) instances deployed in a warm standby configuration to support continuous ingest and automation. | D |
| 5 | Is your expected event ingestion rate greater than 30,000 events/hour running 2 active standard playbooks? | Consider short-term growth in the daily ingest (~6-12 months).
For this requirement, a standard playbook has 10 or less blocks that consists of 5 or less action calls (procedure steps). If the complexity and number of active playbooks differs greatly, then the supported ingestion rate would be modified accordingly. |
Requires a High Capacity Clustered with externalized shared services. | C |
| 6 | Are you planning to use Splunk SOAR (On-premises) for Case Management and with more than 50 concurrent users? | Consider the number of concurrent users who will actively use Splunk SOAR (On-premises) for Case Management.
This does not take into consideration the automation workload. If the automation workload is high capacity (>30,000 events/hour), then a lower number of concurrent users would be supported. |
Requires a High Capacity Cluster with externalized shared services for horizontal scaling. | C |
Next steps
After identifying the topology code that is appropriate for your requirements, the next step is to review the Splunk SOAR Validated Architecture (SSVA) that aligns with your topology code. Links to the SVAs are available in the left navigation under the Splunk Platform Indexing and Search header as well as individually below.
- SOAR Cloud SAAS (S0)
- Single Server Deployment (S1)
- Single Server with Externalized Shared Services (X)
- Warm Standby (D)
- High Capacity Cluster (C)
Splunk Lantern has additional content that may be valuable while planning your infrastructure.