Introduction

Secrets management is always about balance – balancing security, usability, and cost. Vault offers Secrets Sync as a way to replicate secrets into cloud-native stores like AWS Secrets Manager, Azure Key Vault, or Google Cloud Secret Manager.

It’s a powerful feature – but like all powerful features, it should be used carefully. Let’s break down why centralized secrets management should remain the default strategy, when it makes sense to use Secrets Sync, and the tradeoffs that organizations will want to consider before rolling it out broadly.

The North Star: One Source of Truth

One of Vault’s biggest benefits is acting as a single source of truth for secrets. By keeping all secrets centralized, you simplify:

• Governance – one system of policies and ACLs for access to privileged credentials
• Rotation – consistent automation of secret lifecycles through dynamic secrets engines
• Visibility – full audit logging of every secret request, rotation, and modification

Vault should remain the system of record for secrets. Secrets Sync does not change that. Sync lets Vault publish a copy of a secret to a destination store so a legacy SDK or cloud service can consume it, while you continue to manage the lifecycle in Vault. That “manage in one place, project out to a few places” model is exactly how HashiCorp designed Secrets Sync. The synced secret still originates and is managed in Vault, but now it is also synced (one-way) into your cloud provider’s secret manager service. That means the lifecycle – rotation, renewal, revocation – still flows from Vault.

But here’s the first catch: audit visibility is no longer centralized.

The Audit Tradeoff

If your applications pull directly from Vault, every secret retrieval is captured in Vault’s audit logs. That gives you a clean, centralized view of who accessed what and when.

When you sync secrets to a cloud provider, applications consuming those secrets never touch Vault. The secrets are retrieved from the native secrets manager service. With that in mind, you need to consider that:

• Access to secrets is now logged in CloudTrail (AWS), Azure Monitor, or Cloud Audit Logs (GCP).
• Vault only logs the sync operation itself, not the secret usage.

IMPORTANT: This means you no longer have centralized auditing for secret access and now have to combine Vault audit logs with your cloud provider’s API logs to get the full picture. It’s not impossible, but it complicates compliance and monitoring.

Cost Considerations

Another factor is licensing. Each synced secret that you configure in Vault counts as a Vault client, just like a traditional Vault client making API requests. See here for official docs.

If you sync dozens, or hundreds, of secrets to be consumed by your cloud-based workloads, your Vault client count (and therefore your license usage) can spike quickly. For organizations with strict cost controls, this is a strong reason to limit Secrets Sync to only what’s necessary to avoid surprises on your yearly true-up with HashiCorp/IBM.

With that said, there might be some tradeoffs here that you can put a positive spin on. Syncing one secret from Vault (and thus consuming one client license) that is consumed by many apps from a cloud-based secrets manager could actually REDUCE the number of apps that talk to Vault directly. Those apps will no longer be counted as Vault clients because they do not call Vault directly. As a result, you could use a single license to actually increase the number of Vault clients without penalty (but you still have the audit log issue above to consider).

Operating at Org Scale: Hundreds of Accounts

Large organizations rarely run in a single cloud account. If you plan to sync secrets across dozens or hundreds of accounts or projects, you need to design for two things up front: permissions at scale and cost visibility.

Permissions at scale. In AWS, prefer having Vault assume a role in each target account instead of distributing long-lived keys. The AWS model for cross-account access is to use IAM roles with a trust policy and call STS AssumeRole, which Vault’s AWS Secrets Manager destination supports via the role_arn parameter. This lets a central Vault cluster write secrets into many accounts while keeping least privilege tight in each one. Similar patterns apply in Azure with per-vault RBAC and in GCP with per-project service accounts.

Cost visibility. As mentioned, Vault counts secret sync clients by secret, not by destination. The same secret synced to multiple accounts still counts as a single secret sync client, which helps when one secret must land in many places. Track your totals and periods using the client-count docs and the /sys/internal/counters API so you can model license impact before you fan out. The new graphs and reports in the Vault UI for 1.20+ are helpful as well.

The Default: Go Direct to Vault (and collect $200?)

Ok, this is all great but what should I do here? Well, whenever possible, I have a strong opinion that applications should talk directly to Vault rather than relying on a synced copy of secrets. Vault is designed to be the single-source of truth for secrets across your organization, giving you one system where lifecycle, access control, and audit are all defined and enforced. By using Vault as the primary secret consumption platform, you avoid spreading policy logic across multiple platforms and keep authorization rules consistent no matter which team or environment is accessing the data.

Just as importantly, every request to Vault is captured in its audit logs. This means you get a complete, centralized record of who accessed what secret, when, and with which authentication method. You do not have to reconcile multiple log sources or stitch together partial records from different providers. That makes compliance reviews, incident response, and day-to-day monitoring far easier.

In short, if your apps are capable of integrating with Vault, always take that path first. It keeps the architecture simpler, strengthens your security posture, and ensures that Vault remains your single source of truth for secrets.

Ok, When Does Secrets Sync Makes Sense

Secrets Sync is best reserved for scenarios where applications absolutely require a cloud-native secret store. Common examples include:

• Third-party SaaS apps that can’t integrate with Vault but natively support AWS Secrets Manager or Azure Key Vault.
• Cloud-native services (like AWS Lambda or Azure Functions) that fetch secrets directly from the provider’s store.
• Cross-account use cases where syncing is easier than deploying Vault agents everywhere.

In these cases, Secrets Sync gives you flexibility without abandoning Vault as the system of record while simplifying critical access to privileged credentials.

Recommendations

So what’s the practical takeaway?

• Default to Vault: Point applications directly to Vault whenever possible.
• Use Sync only when required: SaaS apps or cloud services that can’t consume Vault directly.
• Plan for audit complexity: You’ll need to aggregate Vault logs with CloudTrail / Azure / GCP logs for a complete view.
• Watch your license usage: Every synced secret counts as a client. Limit sync volume to control costs.
• Secure permissions: Ensure Vault has the least-privilege IAM role or equivalent for each provider.

Final Thoughts

Vault Secrets Sync is a valuable feature, but it should be used surgically, not broadly, and especially not without oversight. Vault’s strength has always been in centralization: one place to control, rotate, and audit secrets.

If you treat Secrets Sync as the exception rather than the rule, you’ll preserve Vault’s role as your single source of truth while still meeting the edge cases where cloud-native stores are unavoidable.