I've seen this debate come up a lot in shops that are heavily invested in a single cloud. Teams look at the bill for CyberArk and wonder why they're paying for a third-party PAM when AWS Secrets Manager, Azure Key Vault, or GCP Secret Manager is right there, integrated, and cheaper on paper.
The core question isn't just about storing secrets. It's about **privileged session management** and **credential lifecycle control**. Native cloud services are excellent at *storing* and *rotating* secrets. But can they do this?
* **SSH/RDP session isolation and recording** for a bastion host scenario.
* **Full command auditing** for a non-human account accessing a database.
* **Just-in-time elevation** for an Azure VM admin, with approval workflows outside the native IAM system.
* **Managing secrets for on-prem legacy systems** alongside cloud resources from a single pane.
If your entire world is serverless functions and your only secret is a database connection string rotated by the cloud provider, you probably don't need CyberArk. But if you have a mixed environment, compliance requirements for session monitoring, or need to manage privilege beyond simple secret storage, the native tools fall short.
A practical example: In AWS, you'd glue together IAM, Secrets Manager, Session Manager, and CloudTrail, and you still wouldn't have a unified video record of a privileged session. You'd be building and maintaining that "pipeline" yourself.
```yaml
# This is a clean, reproducible IaC approach for a cloud secret.
# But it's just one piece of the PAM puzzle.
AWSTemplateFormatVersion: '2010-09-09'
Resources:
MySecret:
Type: 'AWS::SecretsManager::Secret'
Properties:
Description: 'RDS Credentials'
GenerateSecretString:
SecretStringTemplate: '{"username": "admin"}'
GenerateStringKey: 'password'
PasswordLength: 32
ExcludeCharacters: '"@/'
```
The extra cost is for the orchestration, control, and audit of the *use* of the secret, not just its storage. You're paying to avoid building a flaky, half-baked internal tool that tries to bridge IAM, cloud logs, and on-prem systems. For a large, regulated enterprise with mixed infra, that's often worth it. For a greenfield cloud-native app, maybe not.
Build once, deploy everywhere
I'm the cloud guy at a mid-sized e-commerce company (~200 employees). We run our core on AWS but still have some on-prem databases and vendor systems. I help manage the PAM tools, and we just went through this same evaluation.
Here are my four concrete takeaways.
1. **Target Fit.** CyberArk is built for complex, regulated environments. If you have to manage privilege for on-prem Windows servers, network devices, and legacy apps, the native cloud vaults can't even see them. But if your world is 95% cloud and your auditors are okay with CloudTrail/SQL logs for command auditing, native tools will fit 80% of your needs for 30% of the cost.
2. **Real Cost.** The cloud secret managers are incredibly cheap for pure secret storage (think ~$0.40 per secret per month). CyberArk's licensing is opaque, but at my last shop it ran us north of $60k a year in license and support, plus a server team to maintain it. That's not counting the engineering time for integrations.
3. **Integration Effort.** Native vaults are trivial to integrate. You add an IAM policy and your Lambda can fetch a secret. For CyberArk, we had to deploy a Conjur server, write our own sidecar to fetch secrets for apps, and maintain connectors. It added ~2 months to our container migration timeline.
4. **Where Native Tools Break.** This is the OP's main point. Native cloud vaults are for *secrets*, not *sessions*. They cannot do SSH session isolation, record RDP screens, or provide just-in-time elevation with external approval. If you need to prove "this admin ran this exact command on this server at 2 AM," you need CyberArk or something like it. CloudTrail logs won't cut it.
My pick depends on your audit requirements. If you need strict session-level auditing for compliance (like PCI-DSS 8.2, SOX), you can't avoid a full PAM. But if you're mostly securing API keys and connection strings, stick with the native secret managers and spend the savings on hardening your IAM roles.
Tell us your compliance framework and what percentage of your systems are outside your main cloud. That'll make the answer clear.
Exactly. The "cheaper on paper" line is the most common trap. The real comparison isn't just software licensing versus cloud service fees. It's the total operational overhead of building and maintaining those missing features yourself.
For instance, achieving full command auditing with native tools means stitching together CloudTrail, VPC Flow Logs, and database audit logs, then writing and managing the correlation logic. That's a significant engineering time sink and creates a bespoke solution that needs its own ongoing support and validation for audits. The cost of that developer time can quickly eclipse a vendor subscription.
So the question shifts from "is the software cost worth it?" to "do we have the internal bandwidth and expertise to build, secure, and maintain a compliant PAM workflow that spans our entire estate?" For many, the answer is no.
Buy once, cry once.
You're spot on about the operational overhead. That engineering time is brutal and often invisible until you're already committed.
We learned this the hard way trying to replicate just-in-time access approvals. Building the workflow, UI, and audit log alone took two devs a quarter. Then came scaling issues and compliance review gaps.
Suddenly, the CyberArk quote didn't look so crazy. It's not just about building it once, it's about the ongoing maintenance and audit prep that eats into product development cycles every single year.
Ship fast. Learn faster.