Hey everyone! I'm in the final planning stages for a major SaaS migration, and part of it involves moving a ton of secrets out of AWS Secrets Manager. We're seriously considering Delinea (Secret Server) as the new vault.
I know the core features look great on paper, but I'm a bit paranoid about performance impact on our applications. In AWS, secret retrieval is generally super fast, but we'll be introducing a network hop to an on-prem Delinea instance.
**Has anyone done actual benchmarking or have real-world metrics on this?** I'm looking for concrete numbers, even if they're rough.
My specific worries:
* Average latency for a simple secret retrieval via the API (compared to AWS Secrets Manager's typical ~100-200ms for our region).
* Any noticeable difference during high concurrency (think dozens of instances spinning up simultaneously needing credentials).
* The impact of the Delinea architecture—does the proxy or HA setup add significant overhead?
I'm building my cutover checklist and this is a big unknown. I'd rather not find out about a 2-second lag during the live migration! 😅
Any data points, war stories, or even "we tested it and saw no issue" reports would be a huge help. Thanks in advance
I'm an app team lead at a mid-size e-commerce company, and we migrated about half our workload's secrets from AWS to Delinea Secret Server last year.
My notes from our testing:
Latency: In our hybrid setup, retrieving a simple secret via the Delinea API averaged 300-350ms from our AWS workloads. That's about 1.5x to 2x our AWS Secrets Manager latency for the same region (which was ~180ms for us). It was consistent but noticeably slower.
Concurrency: We simulated 50 EC2 instances booting at once. The Delinea instance (a 4-core, 16GB RAM VM on-prem) handled it, but p95 latency spiked to about 900ms. AWS was more stable under that load. For steady-state, day-to-day ops, concurrency hasn't been an issue.
Architecture overhead: We use the Privilege Cloud gateway (their proxy). It added maybe 20-30ms of overhead in our tests. The bigger factor was our network link - latency swung more based on that than the Delinea components themselves.
Migration effort: The actual secret migration via API was straightforward. The real effort was updating all our app configs and IAM roles to use the new HTTP calls, which took us two sprints. They don't have a direct drop-in replacement for the AWS SDK.
I'd pick Delinea if you need the on-prem control and their specific PAM features, but stick with AWS Secrets Manager if your apps are all in AWS and you're purely optimizing for speed and simplicity. To be sure, tell us the peak requests-per-second you need and if all your apps can tolerate ~300ms+ for a secret fetch.
I ran some load tests for a similar migration scenario a while back, focusing on that high-concurrency boot storm you're worried about. Your 2-second fear is valid - we saw it happen.
While steady-state retrieval was fine (similar to the 300-350ms others report), the spike during simultaneous auto-scaling events was the real killer. We had a deployment where 80 containers came online within a minute, all hitting the Delinea API for database creds. The p99 latency ballooned to nearly 1.8 seconds, which caused timeouts in some of our apps.
The fix, which we should have designed in from the start, was implementing a local caching layer in our orchestration platform. It added complexity, but it turned those spikes into single-digit millisecond retrievals after the first fetch. You'll want to plan for that upfront if your cutover involves any bulk scaling operations. The overhead of the proxy itself wasn't bad, maybe 20-30ms, but the queueing at the secret server under load was the main bottleneck.
api first
The caching layer is a critical mitigation, but its effectiveness depends entirely on your cache invalidation strategy. If you're caching database credentials, you now have a distributed state problem; a secret rotation event must propagate that invalidation to all your cached nodes instantly, or you risk application outages. This often requires integrating with a pub/sub system or using a sidecar with a TTL shorter than your rotation schedule.
Also, that 1.8-second p99 under load points directly to the secret server's internal architecture, likely its connection pool or rate limiting. You can sometimes tune this on the Delinea side by adjusting thread pools and connection limits, but that shifts the bottleneck instead of removing it. Did you measure the breakdown of time spent in the gateway versus the server core during those spikes? A trace would show if the time was spent in network queueing, authentication, or the actual data retrieval.
metrics over vibes