Cloud Connector Guidelines and Best Practices
The Delinea connector provides a multipurpose service that supports key features and enables secure communication between other services on your internal network and a cloud instance.
Customers' different usages determine the deployment of connectors. For a long time, customers found it difficult to figure out how many connectors they need and the specifications of machines to install connectors on.
The connector is an application that utilizes the CPU.
To better guide customers, we will show a comprehensive analysis of all features and product components utilizing the Delinea connector, and provide detailed assessments of the resource requirements for each.
Disclaimer
Many parameters impact connector performance, such as:
-
Number of active users
-
Number of concurrent users
-
Types of features being used
-
Applications being accessed
-
Daily usage patterns
An active user is someone who logs into the PAS at least once after their account is created. You can find all active users by going to Access > Users > All Active Users.
Even the way certain features are used can vary between companies, drastically impacting connector performance. For example, the types of commands used when accessing SSH or RDP services.
Given the wide range of customer use cases and usage patterns, it is impossible to provide an exact formula that fits all scenarios.
Once the system is up and running, it is important for customers to keep track of connector performance (CPU and memory) and adjust the connector settings accordingly.
Customer Categories
To classify customers for sizing purposes, we will use the following three tiers:
-
Small (SMB): Up to 10k total users
-
Medium (Mid Market): Up to 100k total users
-
Large (Enterprise): Over 100k total users
The more total users a customer has, the more connector resources we will allocate to support their usage.
Connector Machine Configuration
You can install connectors on physical or virtual machines.
The machine requirements can be classified into the following sizes:
-
Small: 2 Core 8 GB RAM, 500GB disk
-
Medium: 4 Core, 16 GB RAM, 500GB disk
-
Large: 6 Core, 32 GB RAM, 1 TB disk
All sizes should be served by 1 GB Ethernet.
Impact of Features and Capabilities
Using more features increases the load on the connector, so you may need additional connectors.
This is especially relevant for network and CPU intensive features, like:
-
Session Monitoring (RDP or SSH)
-
App Gateway
-
Password Vaulting
It is recommended to designate dedicated connectors for supporting certain functionality, rather than using a single connector to serve any number of features together.
Connector Placement
For IWA-based login, the system selects a preferred connector based on the client's IP address and available connectors. Placement of the connectors relative to the user's Active Directory sites should be considered in relation to the user's Domain Controller.
The Radius Server functionality of the connector allows users to configure and distribute it according to the location and the load from the Radius clients, such as VPN servers.
Place SSH and RDP connectors close to the systems they are serving to improve connection and performance.
Guidelines
Light Traffic Use Cases
For light traffic use cases, such as IWA or simple authentication use cases, without heavy-load features like "session monitoring" or "application gateway", we recommend the following ratios:
-
One small-sized connector per 4k concurrent authentications (only suitable for SMB customers)
-
One medium-sized connector per 8k concurrent authentications (suitable for Mid-Market and some smaller Enterprise customers)
-
One large-machine for every 10k concurrent authentications (suitable for Mid-Market and Enterprise customers)
See the below table for examples:
| Count | |
|---|---|
| Total | 7 |
Each Active Directory forest should have its own set of connectors (based on the number of users it serves).
Provisioning Functionality
The connectors dealing with authentication can also typically handle the small amount of load that provisioning functionality adds to the connectors.
In medium environments (<100k users), you should add a dedicated set (2) of mid-sized connectors for provisioning.
In larger environments (>100k users) even more connectors should be added (recommend one connector for every 50k users).
| Active Users | Number of Connectors (Medium Machines) | Number of Connectors (Large Machines) |
|---|---|---|
| 20k | Not required | Not required |
| 50k | 1 + 1 (for redundancy) | 1 + 1 (for redundancy) |
| 100k | 2 + 1 (for redundancy) | 2 + 1 (for redundancy) |
| 200k | Not recommended | 4 + 1 (for redundancy) |
App Gateway
App gateway performance highly depends on what users are doing, how much traffic/data users pass through, number of clients, and the number of connections.
We recommend designating dedicated connectors for app gateway support.
A single connector can support ~2k concurrent users for simple web applications (e.g. Jira, Jenkins).
Users may require additional connecters for more data intense applications (e.g. reporting).
| Concurrent Users | Number of Connectors (Medium Machines) | Number of Connectors (Large Machines) |
|---|---|---|
| 2k | 1 + 1 (for redundancy) | Not required |
| 4k | 2 + 1 (for redundancy) | 2 + 1 (for redundancy) |
| 8k | 4 + 1 (for redundancy) | 3 + 1 (for redundancy) |
| 16k | 8 + 1 (for redundancy) | 6 + 1 (for redundancy) |
As with other cases, redundancy should also be considered to ensure continuous availability.
SSH Session Monitoring
The SSH Session Monitoring functionality adds some load to the connectors. However, a large connector should be able to support hundreds of simultaneous connections.
We recommend designating dedicated connectors for SSH Session Monitoring.
We achieved a peak load of ~1,000 SSH sessions per connector under lab conditions, however, we would not recommend reaching this number.
A more reasonable guideline would be 1 medium-sized connector for 500 concurrent SSH sessions (750 SSH sessions for a large connector).
SSH sessions vary in the amount of data they pass. We assume that our recommendations involve moderate traffic less than 1kb per second. Higher traffic rates (e.g. through automation) may require more connector resources.
| Concurrent Sessions | Number of Connectors (Medium Machines) | Number of Connectors (Large Machines) |
|---|---|---|
| 500 | 1 + 1 (for redundancy) | Not required |
| 1k | 2 + 1 (for redundancy) | 2 + 1 (for redundancy) |
| 2k | 4 + 1 (for redundancy) | 3 + 1 (for redundancy) |
| 4k | 8 + 1 (for redundancy) | 6 + 1 (for redundancy) |
| 8k | 16 + 1 (for redundancy) | 11 + 1 (for redundancy) |
As with other cases, redundancy should be considered to ensure continuous availability.
RDP (Windows) Session Monitoring
The RDP Session Monitoring functionality adds a substantial amount of load to the connectors.
We recommend designating dedicated connectors for RDP Session Monitoring.
We achieved a peak load of ~100 RDP sessions per large connector under lab conditions, however, we would not recommend reaching this number.
A more reasonable guideline would be 1 large-sized connector for 50 concurrent RDP sessions (using light traffic).
| Concurrent Sessions | Number of Connectors (Medium Machines) | Number of Connectors (Large Machines) |
|---|---|---|
| 50 | Not recommended | 1 + 1 (for redundancy) |
| 100 | 3 + 1 (for redundancy) | 2 + 1 (for redundancy) |
| 500 | 15 + 1 (for redundancy) | 10 + 1 (for redundancy) |
| 1k | Not recommended | 20 + 1 (for redundancy) |
As with other cases, redundancy should be considered to ensure continuous availability.
Discovery
Discovery heavily uses connector resources.
We will update this section in the next few weeks once we gather additional measurements.
We recommend scheduling discovery for off-hours to ensure sufficient connector resources.
Other Features and Considerations
The connectors support many other features, which could impact performance and scalability.
For example: IWA, Radius Server, MFA, CDA (Direct Audit) Agent, and Discovery.
In general, we recommend dedicating connectors for such functionalities (not to mix with general authentication, provisioning, app gateway and session monitoring).
We have not yet established sizing guidelines for these functionalities. We will assess the guidelines in the future, as needed.
Bulk updates to Active Directory may increase the load on connectors, so they should be scheduled for off-hours.
Users should consider Direct Audit (especially for RDP session recording) as it heavily consumes connector resources. More specific guidelines will be provided in the future.
