Delinea Secret Server Performance and Sizing Guide

Last updated: 2026-92-25

Introduction

This guide provides updated recommendations for designing and scaling your Secret Server deployment. Using your recent performance benchmarks, this document offers insights and guidance, helping you design an environment that meets your needs.

This guide uses a lot of technical jargon. If you experience "acronym failure" or wonder what the codes mean, see Supplemental Information, which includes an introduction to Amazon EC2 Instance-Type Identifiers and a Glossary of terms in this document.

Performance Testing Overview

Most, but not all, recommendations in this guide are supported by dedicated performance testing conducted in controlled environments.

Test Environment Setup

We set our performance benchmarks using clean, isolated infrastructure provisioned in Amazon Web Services (AWS) with no competing workloads. Each test environment was provisioned via Terraform, ensuring consistency, eliminating resource contention, and facilitating rapid deployment. This included adjusting computing resources, instance types, and endpoint volumes. We used AWS user-data scripts to automate endpoint configuration, enabling comprehensive testing from a single command.

Test Design Benefits

  • Consistency and accuracy: Reliable, repeatable results improved the accuracy and trustworthiness of performance benchmarks.
  • Cost efficiency: Lowered costs compared to physical data-center setups, enabling frequent and extensive testing to replicate enterprise-scale scenarios.
  • Scalability: Flexibly scaled endpoints and computing resources for varied test scenarios.
  • Versatility: Reduced setup time with an adaptable environment that is ready for future performance evaluations.

Core Sizing Principles

Component Roles

  • Application servers (web nodes): Handled UI and API requests, orchestrated workflows, and published tasks to RabbitMQ.
  • Distributed Engines (DEs): Consumed tasks from RabbitMQ and executed operations like discovery, heartbeats, remote password changing (RPC), and proxying.
  • Database server: Stored all Secret Server data where performance is critical.
  • RabbitMQ: Message queue facilitated asynchronous task processing between web nodes and DEs.

General Recommendations

Redundancy

We implemented N + 1 redundancy for all critical components (web nodes, DEs per site, database, and RabbitMQ) that ensured high availability and minimized downtime.

Engine Task Allocation

  • Deployed at least two DEs per site for high availability.
  • Limited discovery tasks to 50–60% of DE capacity to ensure resources for heartbeats, RPC, and other operations (see Engine Sizing per Site).
  • If a specific workload is restricted to only one DE, you may need to add more DEs for redundancy of that workload, assuming that the task is critical enough to warrant redundant design. See Distributed Engine Job Function Optimization for more information on DE workloads and performance benefits.
  • Example: Scanned 50,000 machines for local accounts (≈7,500 endpoints per hour with dual c5a.2xlarge DEs, ≈6.6 hours) every 24 hours yields ≈28% Discovery occupancy (6.6 ÷ 24). Scanning every 8 hours increases occupancy to ≈83% (6.6 ÷ 8), requiring 1–2 additional DEs per site.
For workload-specific DE sizing, see Heartbeats and Remote Password Changing.

Instance Selection

For dedicated hardware and software specifications, refer to System Requirements for Secret Server. Prioritize compute-optimized instances (for instance, AWS c5a series) for distributed DEs handling CPU-intensive tasks like discovery and RPC. Web nodes can use our minimum recommended system requirements unless handling proxying or session recording, which benefit from a more capable CPU (for instance, c5a.2xlarge).

For environments deploying both Secret Server and Privilege Manager on the same web nodes, use higher-spec instances. Combine disk-space requirements for both applications.

Database Performance

The database is often a key performance influence. Ensure adequate CPU, RAM, and high IOPS. Address database performance before extensively scaling web or DE tiers. Ensure dedicated database resources to avoid contention.

Session Recording

For basic session recording requirements, refer to the Basic Session Recording Requirements. For advanced session recording requirements, refer to the Advanced Session Recording Requirements.

Environmental and Compliance Considerations

Environments with stringent auditing, extensive SIEM integration, or data-at-rest encryption may introduce performance overhead. Apply a compliance overhead buffer (for instance, +10–15% of resource calculations) in such scenarios.

Workload-Specific Sizing Guidance

Discovery Operations

For environments with significant or time-sensitive discovery requirements we recommend dedicated DEs, potentially within a distinct "discovery site." Endpoint count is the primary driver of scan duration, each endpoint requiring individual connection and processing. Performance metrics assume low-latency (<20ms) connections to endpoints. Higher latency (for instance, >50ms) may reduce throughput, requiring additional DEs or regional sites. Web servers with the DE worker server role enabled can process discovery responses, enhancing efficiency. However, these nodes also handle other tasks (such as UI and API), so you cannot dedicate them solely to discovery. For high discovery loads, prioritize dedicated DEs (see Engine Sizing Per Site and Distributed Engine Job Function Optimization).

  • Guidance: For quick discovery sizing, estimate DE needs as follows:

    • Local accounts: one DE ≈3,600 endpoints per hour; each additional DE ≈1,800 per hour.
    • Local accounts + dependencies: one DE ≈1,800 per hour; each additional DE ≈900 per hour.
  • Example: 25,000 endpoints in 8 hours (local accounts) requires ≈3,125 per hour. One DE (3,600 per hour) is sufficient. For 4.5 hours, use two DEs (≈5,400 per hour). Use detailed metrics (see Discovery Sizing Considerations) for precise sizing with specific instance types (for instance, c5a.2xlarge).

Discovery Sizing Considerations

Accurate discovery sizing requires understanding customer requirements and environmental constraints. Ask the following questions to validate inputs.

Considerations:

  • Scan frequency: How often must discovery run (hourly, daily, or weekly)?
  • Completion time: How quickly must scans complete (for instance, <8 hours)?
  • Endpoint count: Is the total number of systems accurate? Will discovery scale gradually (for instance, in a phased rollout)?
  • Contention: Are other features (for instance, heartbeats, RPC, or proxying) heavily used, potentially impacting DE capacity?

Guidance: Verify endpoint counts with customers, because initial estimates may include future growth. For phased rollouts, start with fewer DEs and scale as endpoints increase. Ensure discovery occupancy remains <50–60% to avoid contention with other tasks (see Engine Sizing per Site).

Discovery Sizing Reference Table

The table below provides approximate discovery times for Windows local account discovery across enterprise scales, assuming dual c5a.2xlarge DEs ( ≈7,500 endpoints per hour) and additional DEs for faster completion.

Enterprise Size Endpoints Time (one DE, ≈3,750 endpoints per hour) Desired Time DEs Needed (Total)
Small 2,000 ≈0.5 hours <1 hour 1
Medium 25,000 ≈6.7 hours <4 hours 2 ( ≈3.3 hours)
Large 50,000 ≈13.3 hours <8 hours 2 ( ≈6.7 hours)
Massive 100,000 ≈26.7 hours <12 hours 3 ( ≈8.9 hours)

Guidance: Use this table for initial sizing estimates. Adjust based on specific requirements (for instance, scan frequency or dependency discovery) and environmental factors, such as latency).

See these sections for site-level sizing:

Active Directory Computer Object Discovery

Discovery efficiently queries Active Directory (AD) via LDAP for computer objects. Having no endpoint operations, it produces minimal load.

Guidance: A single DE (for instance, c5a.2xlarge) can handle thousands of AD computer objects in minutes. This is not a sizing constraint.

Windows Local Account Discovery

This discovery connects to Windows endpoints (RPC or WMI) to enumerate local accounts. Endpoint count drives scan duration due to connection or query overhead. Benefits from parallel processing with multiple DEs:

  • Performance (endpoints per hour):

    • Dual c5a.2xlarge (16 total vCPUs, 2 DEs): ≈7,500 endpoints per hour (for 507 endpoints, 1,506 accounts).
    • Single c5a.2xlarge or c5a.4xlarge (8 or 16 vCPUs, 1 DE): ≈3,700 endpoints per hour.

  • Guidance: Use 2+ DEs for >500 endpoints to reduce scan time. Engines with 8 vCPUs (for instance, c5a.2xlarge) are optimal—scaling out is more effective than scaling up beyond 8 vCPUs.

Windows Local Accounts + Dependency Discovery

Extends local account discovery to identify application and service dependencies, adding processing per endpoint. Endpoint count remains the primary driver.

  • Performance (endpoints per hour):

    • Dual c5a.2xlarge (16 total vCPUs, 2 DEs): ≈6,900 endpoints per hour (for 507 endpoints, 1,506 accounts).
    • Single c5a.4xlarge (16 vCPUs, 1 DE): ≈3,400 endpoints per hour.
  • Guidance: Use multi-DE configurations for large endpoint counts. Expect ≈10–15% throughput reduction compared to local accounts-only discovery due to dependency processing.

Unix Computer Scan (Account Enumeration)

This discovery establishes SSH sessions to Unix endpoints to retrieve local accounts. Endpoint count drives duration due to SSH connection overhead.

  • Performance (endpoints per hour):

    • t2.xlarge (3 DEs, 4 vCPUs each): Up to 90,000 (for 100 endpoints).
    • c5a.4xlarge or c5a.2xlarge (1 DE, 16 ÷ 8 vCPUs): ≈30,000–40,000 (for 500 endpoints).

  • Guidance: Throughput scales with DE count. For small to moderate counts (<1,000), t2.xlarge is cost-effective. For larger volumes (>1,000), we suggest c5a.2xlarge or c5a.4xlarge for sustained throughput.

Unix Network Discovery (Endpoint Identification)

Sweeps subnets (for instance, /22, /24) via SSH to identify responsive hosts and gather metadata without login. IP range size and host density drive duration.

  • Performance (endpoints per hour):

    • c5a.2xlarge (1/22 subnet, 1 DE, 8 vCPUs): ≈36,700 endpoints per hour.
    • c5a.2xlarge (2/24 subnets, 2 sources, 2 sites, 2 DEs, 8 vCPUs): ≈45,000 endpoints per hour.
    • c5a.2xlarge (2 /24 subnets, 1 source, 1 site, 2 DEs, 8 vCPUs): ≈26,000 endpoints per hour.
    • Larger ranges (for instance, 10 x /22, single site): ≈4,100 endpoints per hour.
  • Guidance: Use a single c5a.2xlarge for a large segment. For multiple segments, create separate sources and sites with dedicated DEs to scan in parallel, as additional DEs on a single segment yield diminishing returns.

Heartbeats

Heartbeats verify stored credentials against target systems. Target system responsiveness and network latency primarily influence performance with DE CPU as a secondary factor.

Performance metrics (per t2.xlarge, 4 vCPUs):

  • Windows local accounts: ≈9–10 secrets per sec (≈32,400–36,000 secrets per hour).
  • Unix: ≈8 secrets per sec (≈28,800 secrets per hour).
  • Dual DEs: ≈14–20 secrets per sec (≈50,400–72,000 secrets per hour, mixed targets).
  • Capacity insight: DEs are capable of >100 secrets per sec with RabbitMQ backlog and fast target responses, indicating DEs often wait in steady-state operation.

Guidance:

  • Calculate hourly heartbeat load: Divide total secrets by heartbeat interval (for instance, 8 hours). For 25,000 Secrets, ≈3,125 heartbeats per hour.
  • Engine requirements: DEs required = (heartbeats per hour, ≈36,000 secrets per hour per t2.xlarge). Round up and add one for redundancy. A single t2.xlarge handles ≈3,125 heartbeats per hour with spare capacity.
  • Redundancy: Deploy 2+ DEs per site for N+1 redundancy.
  • Performance optimization: If queues grow or completion times lag, investigate target system performance (for instance, latency, timeouts) before adding DEs.
  • Workload balance: Heartbeats are rarely the primary driver for DE count, as discovery is more resource-intensive (see Engine Sizing per Site).

Example scenario: Customer needs to validate 75,000 credentials across three regions in <2 hours.

  • Calculation: 75,000 heartbeats per 2 hours = 37,500 heartbeats per hour. Per t2.xlarge: ≈36,000 heartbeats per hour. DEs required: 37,500 ÷ 36,000 ≈1.04, round up to 2. For three regions: Site 1 (3 DEs, high-density), Site 2 (2 DEs), Site 3 (1 DE) = 6 DEs total.
  • Recommendation: Deploy 6 DEs across three sites, with 2+ DEs per site where possible. Monitor RabbitMQ queue depths and target latency.

Remote Password Changing

Remote Password Changing (RPC) automates password rotation on target systems. RPC is more CPU-intensive than heartbeats due to authentication, password generation, and updates. Performance varies based on target system policies (for instance, password complexity, change propagation).

  • Performance (per t2.xlarge, 4 vCPUs):

    • Unix: ≈1.8 secrets per sec (≈6,480 secrets per hour).
    • Dual DEs: ≈3.3 secrets per sec (≈11,880 secrets per hour).
    • Three DEs: ≈5.0 secrets per sec (≈18,000 secrets per hour).
    • Mixed workload (Windows and Unix): ≈2–4 secrets per sec (≈7,200–14,400 secrets per hour).

  • Guidance:

    • Calculate Hourly RPC Load: For monthly schedules, divide secrets by 720 (24 hours × 30 days). For 25,000 Secrets, ≈35 password changes per hour.
    • Engine requirements: Engines required = (password changes per hour per ≈7,200 secrets per hour per t2.xlarge). A single t2.xlarge handles ≈35 per hour easily.
    • Redundancy: Deploy 2+ DEs per site for N+1 redundancy.
    • Emergency rotations: For rapid rotations (for instance, post-breach), assume ≈2 secrets per sec per DE and add +1–2 DEs buffer for latency or target issues.
    • Workload balance: RPC is rarely the primary driver for DE count. Monitor RabbitMQ queues and target response times during rotations.

Example scenario: Customer needs to rotate 50,000 secrets (Windows and Unix) in <1 hour post-breach.

  • Calculation: 50,000 secrets per 1 hour = 50,000 secrets per hour. Per t2.xlarge: ≈7,200 secrets per hour. DEs required: 50,000 ÷ 7,200 ≈6.94, round up to 7. Add 1–2 DEs buffer = 8–9 DEs.
  • Recommendation: Deploy 9 DEs across sites, with 2+ DEs per site. Monitor DE CPU and RabbitMQ queue depths.

SSH and RDP Proxying

Securely tunnels SSH and RDP sessions, enabling controlled access. Proxy sessions can be handled by web Servers or DEs, with no inherent capacity difference. Sessions are assigned round-robin. Performance varies by activity and environmental factors.

  • Performance (per node, web Server or DE, Intel 3.7 GHz Quad Core, 16 GB RAM equivalent):

    • SSH: ≈300 concurrent sessions (standard activity, for instance, file navigation, editing on Linux).
    • RDP: ≈100 concurrent sessions (standard activity, for instance, opening MMC snap-ins, editing files on Windows).
    • Heavy data transfer: ≈150 combined sessions (SSH + RDP) for large file transfers or high-bandwidth activities (for instance, video streaming).
    • Light activity: May exceed 400 combined sessions for minimal operations (for instance, basic commands).
Proxying via DEs is less efficient if session recording is enabled (see Session Recording), due to traffic capture and RabbitMQ queuing overhead.

  • Guidance:

    • Node selection: Prefer web servers if DEs are busy with session recording, discovery, or other tasks. Ensure DEs have sufficient CPU and memory for combined workloads.
    • Dedicated nodes for high loads: For 1,000 concurrent SSH sessions, deploy dedicated web servers or DEs: 1,000 per ≈200–250 sessions per node with ≈4–5 nodes.

  • Key performance factors:

    • Latency: Minimize end-user-to-node latency. Lower latency to web servers vs. DEs may improve efficiency.
    • CPU resources: Proxying is CPU-intensive, especially for RDP. Scale to higher-core instances (for instance, c5a.2xlarge) if needed.
    • Network bandwidth: Ensure 100 MB/s for standard activity, 1 GB/s for heavy transfers.
    • Troubleshooting: If performance degrades: reduce latency, increase CPU (for instance, c5a.4xlarge), test web server proxying if DEs show contention, and monitor CPU, network, and session latency.
    • Redundancy: Deploy 2+ proxy-enabled nodes per site for N+1 redundancy.
    • SSH public address: Multiple web servers' SSH public addresses impact routing or firewall configurations.

  • Example scenario: 1,000 concurrent SSH sessions with standard activity, minimal recording.

    • Calculation: capacity: ≈200–250 sessions per node. Nodes required: 1,000 ÷ 250 ≈4. Add 1 for redundancy = 5 nodes.
    • Recommendation: Deploy 5 dedicated web servers (for instance, c5a.2xlarge, 100 MB/s bandwidth). Ensure low latency. offload recording to separate nodes. Monitor CPU or network metrics.

Heavy API Use

Consider API (nonhuman) interaction with Secret Server.

  • Performance: A single web node (for instance, m5.large, 2 vCPUs, 8 GB RAM) handles ≈500–1,000 API requests per sec for lightweight calls (for instance, secret retrieval). Resource-intensive calls (for instance, bulk updates) reduce throughput by 50–70%.

  • Guidance:

    • Allocate 2+ dedicated web nodes for API traffic, with a separate load balancer endpoint (for instance, AWS ELB, F5).
    • Encourage API clients to cache authentication tokens.

    • Be mindful of resource-intensive calls (for instance, bulk updates or broad searches). High-impact API calls include:

      • Authentication requests (cache tokens to reduce frequency).
      • File Uploads (for instance, secret attachments).
      • Downloading session recording videos (offload to dedicated storage).
      • Update operations (for instance, bulk updates, folder moves, more taxing than Get calls).
    • Optimize these calls through caching, batching, or isolating to dedicated nodes.
    • Monitor Application Server CPU and RAM and database performance under API load.

Session Recording

Session recording records proxied sessions for audit or review.

  • Guidance:

    • Client session launching: ≈100 sessions per web node.
    • Video encoding (transcoding): Default 2 concurrent transcodes per session recorder worker role-enabled web node. Scale horizontally.

  • Processing Capacity:

    • Standard node: ≈400–450 hours of video per day.
    • Intel quick sync node: ≈1,500–2,000 hours per day.
It's likely cheaper for you to buy additional web node licenses than it would be to buy hardware dedicated for this function.
  • Storage: ≈15 hours per GB (≈27 GB per day for 400 hours). Use high-performance, SSD-backed file shares (for instance, AWS EFS, or NetApp). To manage storage costs, archive session recordings to slower and cheaper storage (for instance, AWS S3, cold storage). For encrypted recordings, restore to the original high-performance file share for playback in Secret Server. Plan archival strategies to balance cost and compliance requirements.

  • Sizing Equations:

    • Web nodes for launching = (maximum concurrent per 100).
    • Session recording worker nodes = (total daily video hours per 400 or 1,500).
    • Dedicate web nodes with a session recorder role. The CPU is primary for transcoding. Deploy 2+ nodes per site for N+1 redundancy.

For additional recommendations and session recording capacities, refer to the Session Recording Caveats and Recommendations and System Capacity Specifications.

Web UI Traffic

Interactive user sessions.

  • Performance: A single web node (for instance, m5.large) handles ≈1,000–2,000 UI requests per sec for light use (for instance, credential vault). Heavy feature use (for instance, reports, searches, dashboards) reduces throughput by 30–50%.

  • Guidance:

    • A single web node supports 5,000+ concurrent UI sessions for light use.
    • For active environments with heavy feature use, start with 2 web nodes for HA and load distribution.
    • Isolate UI traffic to dedicated web nodes if impacted by API or background processing. Monitor CPU and RAM use.

Engine Sizing per Site

DEs handle discovery, heartbeats, RPC, and other tasks. Sites are logical groupings of DEs, often aligned with geographical or network boundaries. Proper sizing ensures balanced workloads and high availability.

Guidance:

  • Workload balance: Limit discovery to 50–60% of DE capacity for heartbeats, RPC, and more.
  • Redundancy: Deploy 2+ DEs per site for N+1 redundancy.
  • Discovery-driven sizing: Calculate DEs based on discovery needs. Estimate occupancy: discovery scan duration or scan interval). If >50–60%, add DEs.
  • Multi-site considerations: Create sites with dedicated DEs to minimize latency for regional endpoints.

Example scenario: Scanning 25,000 machines for Windows local accounts every 24 hours, <50% occupancy.

  • Calculation: Dual c5a.2xlarge (≈7,500 endpoints per hour): 25,000 ÷ 7,500 ≈3.33 hours. Occupancy: 3.33 ÷ 24 ≈14%. Every 8 hours: 3.33 ÷ 8 ≈42%.
  • Recommendation: 2 DEs per site (redundancy, low occupancy). For 8-hour scans, consider 3 DEs. Monitor CPU and RabbitMQ.

Large-scale example: 75,000 endpoints every 8 hours, 3 sites.

  • Calculation: Dual c5a.2xlarge: 75,000 ÷ 7,500 ≈ 10 hours. For <8 hours, use 3–4 DEs per site (75,000 per ≈ 11,250 ≈ 6.67 hours). Occupancy: 6.67 ÷ 8 ≈ 83%. Add 1–2 DEs per site = 4 per site, 12 total.
  • Recommendation: Deploy 4 DEs per site (12 total), ensuring <50% occupancy. Adjust for heartbeats and RPC.

Combined Use Cases and Example Scenarios

Prioritize sizing for the most resource-intensive or time-critical workload (for instance, session recording, discovery, or RPC with tight deadlines), then layer other requirements.

  • Example 1 (discovery, proxy, recording): 50,000 systems (Windows local accounts, 8-hour target) discovery, 500 concurrent SSH sessions, 200 concurrent recordings.

    • Session recording launching: 200 ÷ 100 = 2 web nodes with session recording worker role enabled.
    • Session recording processing: 8 hours per day × 200 sessions = 1,600 hours per day. 1,600 ÷ 400 = 4 standard worker nodes (or ≈ 1 quick sync node).
    • SSH proxy: 500 ÷ 200 = 2–3 dedicated web nodes.
    • Discovery: 50,000 endpoints: ≈ 7 DEs (50,000 per ≈ 7,500, dual c5a.2xlarge).
    • Additional: 1–2 web nodes for UI or API if not covered.

  • Example 2 (large discovery, recording, heartbeat or RPC, growth): 75,000 accounts discovery, 100 concurrent recordings, heartbeat and RPC for all, user growth from 500 to 2,000.

    • Initial:

      • UI web nodes: 2 (m5.large). For 2,000 users, assume 1–2 UI sessions per user (≈2,000–4,000 sessions). Assess if 2 nodes suffice or add 1–2.
      • Session recording launching: 100 ÷ 100 = 1 web node.
      • Session recording processing: 800 hours per day (8 hours × 100): 800 ÷ 400 = 2 worker nodes.
      • Discovery, heartbeat, or RPC DEs: 75,000 accounts in 10 hours (≈4 DEs, c5a.2xlarge). Add capacity for heartbeat or RPC (14 hours free; start with 4–6 DEs and monitor).

    • 3-Year growth (15,000 accounts, 150 recordings):

      • Session recording: ≈2 more worker nodes.
      • Discovery, heartbeat, or RPC: ≈1–2 more DEs.

Addressing Large-Scale Sizing Questions

While Secret Server is built for enterprises, we have not had many customers with environments exceeding the conditions above. Sales engineers, partners, and consultants should work directly with Delinea solutions architects to properly size Secret Server environments fitting at least one of the following parameters:

  • 100,000+ secrets
  • 500+ concurrent session recordings
  • 5,000+ simultaneous active UI web sessions
  • 50,000+ systems for frequent, full discovery
  • 1,000+ simultaneous SSH or RDP proxy sessions
Please do not directly contact developers to help with sizing requests. Solution architects will directly work with R&D if necessary to help size environments exceeding any of these numbers.

Monitoring and Iterative Sizing

Sizing is iterative. Continuously monitor:

  • RabbitMQ: Queue depths, message rates.
  • Distributed DEs: CPU use, task processing times, error logs.
  • Application servers: CPU and RAM, request latencies, API metrics.
  • Database server: CPU and RAM, Disk I/O (IOPS, latency, queue depth), and query performance.
  • Secret server application logs: Performance insights, errors. Adjust resources based on observed performance, changing requirements, and user feedback to maintain optimal performance.

Supplemental Information

Amazon EC2 Instance-Type Identifiers

Overview

Amazon EC2 instance type identifiers are simple labels for virtual hardware. They tell you exactly what computer specs you are renting. By learning to read them, you can pick the best machine for your workload and budget.

The name follows a standard formula:
Family + Generation + Attribute + . + Size.

The first letter is the family. This tells you what the server is good at. For instance, c stands for compute-optimized, which is great for high-performance processing. An r stands for RAM, meaning it is memory-optimized for databases.

Next is the generation number. This indicates the age of the technology. A higher number means newer hardware. For example, an m6 instance uses newer chips than an m5.

You might see extra letters before the dot. These are attributes for special features. A g indicates AWS Graviton processors, while d means the server has fast local storage disks.

Everything after the dot represents the size. This defines how much memory and how many virtual CPUs you get. Sizes usually double as they go up; an xlarge has twice the power of a large.

Here is an example using m6gd.xlarge:

  • m: General purpose family.

  • 6: Sixth generation (newer tech).

  • g: Graviton processor.

  • d: Includes local disk storage.

  • xlarge: The specific capacity.

Not Just AWS

Amazon EC2 instance type identifiers have "leaked" into other areas:

  • Other cloud providers have adopted similar naming conventions. Azure and Google Cloud use their own schemes, but documentation and architecture discussions often reference AWS instance types as a shorthand for describing compute requirements—"this workload needs roughly a c5.2xlarge equivalent"—even when the actual deployment is elsewhere.

  • Infrastructure and DevOps tooling frequently uses EC2 instance type identifiers in configuration files, Terraform scripts, Kubernetes node selectors, and cost-optimization tools regardless of whether the author is explicitly discussing EC2. They've become a de facto unit of compute specification.

  • Benchmarking and performance documentation often cites instance types as a reproducible way to describe the test environment—"tested on a c5a.2xlarge"—so readers know the exact CPU, memory, and network baseline without a lengthy hardware description.

  • Job postings and architecture docs sometimes use them loosely to communicate scale, as in "this service runs on a handful of m5.xlarge nodes," where the instance type doubles as a concise spec sheet.

So while the identifiers are formally AWS terminology, they have spread into general cloud infrastructure discourse as a convenient shorthand for describing compute resources precisely.

Glossary

Acronyms and Initialisms

AD: Active Directory. A Microsoft directory service used to manage users, computers, and other objects on a network. Secret Server queries AD via LDAP to discover computer objects.

API: Application Programming Interface. A set of protocols that allows software to interact with Secret Server programmatically. API calls include secret retrieval, bulk updates, and authentication requests.

AWS: Amazon Web Services. A cloud computing platform used in Delinea's performance testing to provision controlled test environments.

CPU: Central Processing Unit. The primary processor in a server. CPU capacity is a key sizing factor for DEs, web nodes, and database servers.

DE: Distributed Engine. A Secret Server component that consumes tasks from RabbitMQ and executes operations such as discovery, heartbeats, remote password changing, and proxying. DEs are deployed across sites for workload distribution and redundancy.

EFS: Elastic File System. An AWS managed file storage service. Referenced as an option for high-performance, SSD-backed file shares used in session recording storage.

ELB: Elastic Load Balancer. An AWS service that distributes incoming traffic across multiple targets, such as dedicated web nodes handling API traffic.

HA: High Availability. A system design approach that minimizes downtime by deploying redundant components. The guide recommends N+1 redundancy for all critical Secret Server components.

IOPS: Input/Output Operations Per Second. A performance metric for storage devices. High IOPS is critical for Secret Server database performance.

LDAP: Lightweight Directory Access Protocol. A protocol used to query and manage directory services such as Active Directory. Secret Server uses LDAP for AD computer object discovery.

MMC: Microsoft Management Console. A Windows administrative tool that hosts management snap-ins. Referenced as an example of standard RDP session activity.

RAM: Random Access Memory. Volatile memory used for active data processing. Adequate RAM is recommended for database servers and web nodes.

RDP: Remote Desktop Protocol. A Microsoft protocol for remote graphical access to Windows systems. Secret Server can proxy and record RDP sessions.

RPC: Remote Password Changing. A Secret Server feature that automates password rotation on target systems. RPC is more CPU-intensive than heartbeats due to authentication, password generation, and update operations.

S3: Simple Storage Service. An AWS object storage service. Referenced as a cold-storage option for archiving session recordings to reduce costs.

SIEM: Security Information and Event Management. A system that aggregates and analyzes security event data. Extensive SIEM integration may introduce performance overhead in Secret Server environments.

SSH: Secure Shell. A protocol for encrypted remote access to Unix/Linux systems. Secret Server uses SSH for Unix discovery, proxying, and session recording.

SSD: Solid-State Drive. A high-performance storage device. SSD-backed file shares are recommended for session recording storage.

UI: User Interface. The web-based graphical interface for interacting with Secret Server. UI traffic is handled by web nodes and can support thousands of concurrent sessions.

vCPU: Virtual CPU. A virtualized processor core allocated to a virtual machine or cloud instance. vCPU count is a key factor in DE and web node sizing.

WMI: Windows Management Instrumentation. A Windows infrastructure for managing data and operations. Secret Server can use WMI (or RPC) to connect to Windows endpoints during local account discovery.

Terms

Compliance overhead buffer: An additional resource allocation (typically 10–15%) applied to sizing calculations for environments with stringent auditing, SIEM integration, or data-at-rest encryption requirements.

Computer object discovery: The process of querying Active Directory via LDAP to identify computer objects on the network. This produces minimal load and is not typically a sizing constraint.

Dependency discovery: An extension of local account discovery that also identifies application and service dependencies on each endpoint. It adds roughly 10–15% processing time per endpoint compared to accounts-only discovery.

Discovery occupancy: The percentage of a DE's available time consumed by discovery tasks, calculated as scan duration divided by scan interval. Delinea recommends keeping occupancy below 50–60% to reserve capacity for heartbeats, RPC, and other operations.

Heartbeat: A Secret Server operation that verifies stored credentials against target systems by periodically checking that passwords remain valid. Performance depends primarily on target system responsiveness and network latency.

Intel Quick Sync: A hardware-accelerated video encoding technology built into Intel processors. Nodes with Quick Sync can process approximately 1,500–2,000 hours of session recording video per day, compared to 400–450 hours on standard nodes.

N+1 redundancy: A high-availability strategy where one additional component is deployed beyond the minimum required. For example, if three DEs are needed for workload, four are deployed so that one can fail without service disruption.

RabbitMQ: An open-source message broker used by Secret Server to facilitate asynchronous task processing between web nodes and Distributed Engines. Monitoring RabbitMQ queue depths and message rates is important for performance tuning.

Session recording: A Secret Server feature that captures proxied SSH and RDP sessions for auditing and review. Recording involves client session launching, video transcoding, and storage management.

Site: A logical grouping of DEs in Secret Server, often aligned with geographical or network boundaries. Each site should have at least two DEs for redundancy.

Terraform: An infrastructure-as-code tool used by Delinea to provision consistent, repeatable test environments in AWS for performance benchmarking.

Transcoding: The process of encoding recorded session video into a storable and playable format. By default, each session recorder worker role-enabled web node handles two concurrent transcodes.

Web node: A Secret Server application server that handles UI requests, API traffic, and workflow orchestration. Web nodes can also be configured with worker roles for session recording launching and processing.