Okta Privileged Access gateway capacity planning
The resources that you allocate to a gateway depend on the role that the gateway performs. An Okta Privileged Access gateway can perform either of the following roles:
- Server access proxy: The gateway brokers SSH and RDP sessions to your servers. Size the gateway for the number of concurrent sessions that it handles and for the session recordings that it stores.
- Infrastructure orchestrator (Database): The gateway runs account discovery and password rotation tasks against your integrated databases. Size the gateway for the total number of users across the databases that it services.
The guidance in each of the following sections assumes a gateway that performs one role. Okta hasn't tested a gateway that performs both roles and can't make any recommendation about the resources that such a gateway requires.
Server access proxy capacity planning
When a gateway brokers SSH and RDP sessions, the number of concurrent sessions determines the processing and memory that it needs. If you enable session capture, the volume of session recordings that you retain determines the storage that it needs.
Processing and memory
The type of server or instance that you use to host an Okta Privileged Access gateway depends on which provider you use.
A gateway with two vCPUs and 4 GB of RAM handles 120 concurrent SSH sessions. CPU use rises and falls with the number of sessions, and memory use stays low.
In Amazon Web Services (AWS), a current generation burstable instance of this size meets this requirement. Examples include t3.medium and t4g.medium instances with an EBS volume. The original tests ran on a t2.medium instance, which is a previous generation of the same size.
Storage
Carefully consider both the type and amount of storage that you need when deploying SSH session capture with Okta Privileged Access gateways.
The ideal storage solution is solid-state drives (SSDs), which can be a dedicated SSD that's attached to the gateway or SSD-based storage like Amazon Elastic Block Stores.
How much storage you require depends on the workloads of your users. For example, a 30-minute interactive session that consists of performing a directory listing every five seconds is captured and stored in a binary file about 150 kilobytes in size.
If users copy files with the scp command during their session, the copied files are also included with the session capture recording. See Session capture.
If session recording is enabled and a gateway has insufficient storage available to store session logs, the gateway prevents connections for security reasons. To avoid this situation, Okta recommends that you monitor the storage utilization of your gateways to ensure that they have sufficient available storage for logs.
One method to ensure sufficient storage capacity for session logs is to use an available cloud storage destination. Be sure that the temporary directory where in-progress sessions are stored (/tmp on most systems) has enough space to store logs for your expected sessions.
Infrastructure orchestrator capacity planning
An orchestrator gateway runs account discovery and password rotation against your integrated databases. The total number of users across those databases determines the processing and memory that it needs.
Add up the users across every database that the gateway services. The number of integrations isn't the primary factor, so ten integrations with 100 users each need about the same capacity as one integration with 1,000 users.
Count every user that discovery returns, including users that you don't manage and users that don't authenticate with a password. Counting all of them keeps your estimate conservative.
Find the row that matches your total user count. Use these sizes as a starting point. Your requirements can vary with your database type, the number of integrations, and your workload.
| Total users across all integrated databases | Minimum vCPU and RAM | AWS burstable example | AWS general-purpose example |
|---|---|---|---|
| Up to 1,500 | 2 vCPU, 4-GB RAM | t4g.medium | m6a.large |
| 1,501 to 10,000 | 4 vCPU, 16-GB RAM | t4g.xlarge | m6a.xlarge |
| 10,001 to 50,000 | 8 vCPU, 32-GB RAM | t4g.2xlarge | m6a.2xlarge |
Treat the vCPU and RAM values as the requirement and the instance names as examples that meet it. Some examples provide more RAM than the minimum.
An orchestrator gateway uses little CPU between discovery and rotation runs, and then uses it in short bursts while a task runs. Burstable instances suit that pattern, because they run at a low baseline and draw on accumulated credits during a burst.
Above 1,500 users, a general-purpose instance is the safer default, because discovery can drive a burstable instance to 100% CPU for a few seconds. A burstable instance is still suitable if the gateway host runs no other workloads that consume CPU.
If you run the gateway on your own virtual machine or on physical hardware, there's no burst credit behavior, so provision the vCPU and RAM in the table as fixed resources. The general-purpose examples show the equivalent non-burstable size.
High availability
Okta recommends two gateways in each orchestration group. They keep discovery and rotation available if one gateway becomes unavailable, and they share the task load.
Size both gateways for the full user count of the orchestration group. Don't divide the count between them, because either gateway must be able to carry the whole load on its own.
Sizing examples
These examples show how the total user count, rather than the number of integrations, drives the recommendation.
| Deployment | Total users | Recommendation |
|---|---|---|
| 20 integrated databases with approximately 50 users each | 1,000 | Two gateways, each with two vCPUs and 4 GB of RAM (t4g.medium equivalent) |
| Three integrated databases with approximately 400 users each | 1,200 | Two gateways, each with two vCPUs and 4 GB of RAM (t4g.medium equivalent) |
| Eight integrated databases with approximately 1,000 users each | 8,000 | Two gateways, each with four vCPUs and 16 GB of RAM (t4g.xlarge equivalent) |
Discovery performance
Discovery is fast. On a gateway with two vCPUs and 4 GB of RAM, discovery completes in less than a second at every user count up to 1,500.
| Users in the integrated database | Discovery time |
|---|---|
| 10 | approximately 0.5 seconds |
| 100 | approximately 0.5 seconds |
| 1,000 | approximately 0.7 seconds |
| 1,500 | approximately 0.9 seconds |
Discovery tasks run one after another, and scheduled runs are randomized across integrations, so the integrations in an orchestration group don't all start discovery at the same moment. A discovery that you start manually is a one-off. Sharing an orchestration group across several integrations is practical when your total user count is within the recommended range.
Discovery against a database that's already under heavy load can take longer. That affects discovery time, not the size of the gateway that you need.
Rotation performance
Rotation takes longer than discovery, and it uses less CPU. Rotations process one after another, so the total time for a batch grows with the number of users that you rotate.
A single user rotation completes in approximately four seconds. Larger batches process at a sustained rate of 2.5–5 users per second. At that rate, rotating 100 users takes approximately 20–40 seconds, and rotating 1,000 users takes approximately 3-7 minutes.
The password change itself completes within a few seconds. The status shown in the Admin Console or returned by the API can take longer to reflect that the rotation finished. A rotation that appears to be in progress may already be complete on the database.