Secrets Management Across Clouds: Vault, AWS Secrets Manager, Azure Key Vault, and GCP Secret Manager

Why Secrets Management Still Gets Teams in Trouble

Every production outage post-mortem I have read in the last three years that involved credential exposure had the same root cause: someone stored a secret somewhere it should not have been. An API key in a .env file committed to Git. A database password in a Kubernetes ConfigMap instead of a Secret. A service account JSON key downloaded to a developer's laptop and never rotated. The tooling to prevent these mistakes has been available for years, yet teams keep making them because secrets management sits at the intersection of security, operations, and developer experience -- and most solutions optimize for only one of those.

This guide compares the four dominant approaches to secrets management in cloud-native environments: HashiCorp Vault, AWS Secrets Manager, Azure Key Vault, and GCP Secret Manager. Rather than listing feature matrices, we focus on the real tradeoffs you face when choosing between them, the rotation strategies that actually work, how each integrates with Kubernetes, and what the costs look like at scale.

HashiCorp Vault: The Swiss Army Knife

Vault is the most flexible option and the most operationally demanding. It supports dynamic secrets (generating short-lived credentials on the fly for databases, AWS IAM, SSH, and more), encryption as a service, PKI certificate management, and a policy engine that lets you model complex access hierarchies. If you need to manage secrets across multiple clouds, on-premises infrastructure, and third-party services from a single control plane, Vault is the only option that covers all of it.

The cost of that flexibility is operational complexity. Running Vault in production requires understanding its unsealing process, configuring a storage backend (Consul, Raft integrated storage, or a cloud provider's storage), managing HA clusters, handling upgrades, and monitoring for seal events. I have seen teams of two or three engineers spend 10 to 15 percent of their time just keeping Vault running. HCP Vault (the managed offering) eliminates much of this burden but comes at $0.03 per hour for the starter tier and scales up from there, which translates to roughly $22 per month minimum before you add secrets or requests.

Vault's dynamic secrets are its killer feature. Instead of storing a static database password that might be valid for months, Vault generates a new set of credentials for each application instance with a TTL you define. When the TTL expires, the credentials are automatically revoked. This means a compromised credential is only useful for minutes or hours, not indefinitely. For teams that handle sensitive data or operate in regulated industries, this capability alone justifies Vault's operational overhead.

When Vault Makes Sense

• Multi-cloud or hybrid environments where you need a single secrets control plane
• Workloads requiring dynamic, short-lived credentials (database, SSH, cloud IAM)
• Organizations with dedicated platform engineering teams who can manage the infrastructure
• Compliance requirements that mandate detailed audit trails for secret access

AWS Secrets Manager: Native and Straightforward

AWS Secrets Manager does fewer things than Vault but does them with less operational friction. It stores secrets as key-value pairs or plaintext, integrates natively with RDS, Redshift, and DocumentDB for automatic credential rotation, and uses IAM policies for access control. There is no infrastructure to manage -- it is a fully managed service.

Pricing is simple: $0.40 per secret per month, plus $0.05 per 10,000 API calls. For a team managing 200 secrets with moderate access patterns (say 500,000 API calls per month), the monthly cost is about $82.50. That is significantly cheaper than running and maintaining a Vault cluster, especially when you factor in the engineering time saved.

The automatic rotation for RDS credentials is genuinely useful. You configure a rotation Lambda function (AWS provides templates), set a rotation interval (30, 60, or 90 days are common), and Secrets Manager handles the rest. It creates a new password, updates the database, and updates the secret value. Applications that use the Secrets Manager SDK to fetch credentials at startup or periodically will pick up the new credentials without downtime.

The limitations are real, though. Secrets Manager does not generate dynamic, short-lived credentials the way Vault does. You are still storing static secrets, just rotating them on a schedule. Cross-account access requires careful IAM policy configuration with resource-based policies. And if you need to manage secrets across multiple clouds, you are building custom integration layers.

Rotation Strategy That Works

The most reliable rotation pattern for RDS secrets uses the alternating users strategy: Secrets Manager maintains two sets of credentials (user_v1 and user_v2) and alternates between them during rotation. This avoids the brief window where the old password is invalid but applications have not yet fetched the new one. Set the rotation interval to 30 days for production databases. Configure your applications to cache the secret for no more than 5 minutes, so they pick up new credentials quickly after rotation. Test the rotation in a non-production environment first -- rotation Lambda failures are the number one cause of secrets management incidents on AWS.

Azure Key Vault: Integrated Into the Microsoft Ecosystem

Azure Key Vault manages three types of objects: secrets (arbitrary key-value data), keys (cryptographic keys for encryption and signing), and certificates (TLS/SSL certificates with automatic renewal). This broader scope makes it more than just a secrets store -- it is a centralized cryptographic service for Azure workloads.

The pricing model differs from AWS. Key Vault charges per operation: $0.03 per 10,000 secret operations for the Standard tier. There is no per-secret monthly fee, which makes it significantly cheaper for teams with many secrets but low access frequency. For 200 secrets accessed 500,000 times per month, the cost is about $1.50 -- roughly 55 times cheaper than AWS Secrets Manager for the same usage pattern. However, if you use the Premium tier for HSM-backed keys, costs jump to $1 per key per month plus higher per-operation charges.

Key Vault's integration with Azure services is deep. App Service and Azure Functions can reference Key Vault secrets directly in application settings, meaning the application code never sees the secret value in its configuration. Azure Kubernetes Service supports the Secrets Store CSI Driver, which mounts Key Vault secrets as volumes in pods. Managed identities eliminate the chicken-and-egg problem of needing credentials to access your credential store.

One operational quirk worth noting: Key Vault has soft-delete enabled by default with a 90-day retention period. If you delete a secret and try to recreate it with the same name, you will get an error. You need to purge the deleted secret first. This catches teams off guard during infrastructure teardown and recreation cycles, especially in CI/CD pipelines. Plan for it in your IaC templates.

GCP Secret Manager: Simple and Developer-Friendly

GCP Secret Manager takes a minimalist approach. It stores secret data as versioned blobs, integrates with Cloud IAM for access control, and supports automatic replication across regions. There are no built-in rotation Lambda equivalents -- you handle rotation yourself, typically with Cloud Functions triggered by Cloud Scheduler.

Pricing is the most straightforward of the four: $0.06 per secret version per month, plus $0.03 per 10,000 access operations. For 200 secrets with an average of 3 active versions each, accessed 500,000 times per month, the monthly cost is about $37.50. The per-version pricing means you pay more if you rotate frequently and keep many versions, but old versions can be destroyed to reduce costs.

GCP's strength is in its IAM integration. Secret Manager uses the same IAM model as every other GCP service, so you can use Workload Identity Federation to give Kubernetes pods or external workloads access to secrets without service account keys. This is the most secure authentication model of the four options for Kubernetes workloads, because there are no long-lived credentials anywhere in the chain.

Environment Variables vs. Secret Stores: When Each Makes Sense

The twelve-factor app methodology popularized the idea of configuring applications through environment variables, and it remains a reasonable approach for non-sensitive configuration: feature flags, service URLs, log levels, and similar settings. But environment variables are a poor choice for actual secrets, for several reasons.

First, environment variables are visible to any process running in the same context. On a Kubernetes pod, any container in the pod can read them. On a VM, any process running as the same user can read them via /proc. Second, environment variables are often logged accidentally -- crash dumps, debug output, and process inspection tools all expose them. Third, there is no access audit trail. You cannot tell who or what read an environment variable, whereas secret stores log every access.

That said, there are scenarios where environment variables are the pragmatic choice. For local development, fetching secrets from a remote store adds latency and complexity. A .env file (excluded from version control via .gitignore) works fine for local dev. For simple applications with one or two secrets that change rarely, the operational overhead of a secret store may not be justified. And for CI/CD pipeline secrets, most platforms (GitHub Actions, GitLab CI, CircleCI) provide encrypted secret storage that injects values as environment variables -- this is a reasonable compromise because the secrets are encrypted at rest and the pipeline environment is ephemeral.

Kubernetes Integration Patterns

Getting secrets into Kubernetes pods securely is one of the most common challenges in cloud-native deployments. There are three main approaches, each with different security and operational characteristics.

1. Kubernetes Secrets with KMS Encryption

The simplest approach is using native Kubernetes Secrets with envelope encryption via your cloud provider's KMS. EKS, AKS, and GKE all support this. Secrets are encrypted at rest in etcd using a KMS key, and decrypted only when pods need them. This is the minimum viable approach -- it protects against etcd compromise but does not provide rotation, detailed audit trails, or cross-cluster secret management.

2. External Secrets Operator

The External Secrets Operator (ESO) synchronizes secrets from external stores (AWS Secrets Manager, Azure Key Vault, GCP Secret Manager, Vault, and others) into Kubernetes Secrets. You define an ExternalSecret resource that specifies which secret to fetch and how to map it, and ESO creates and updates the corresponding Kubernetes Secret automatically. This gives you the benefits of a managed secret store (rotation, auditing, centralized management) while keeping your application code unchanged -- it still reads from Kubernetes Secrets.

The refresh interval is the critical configuration parameter. Setting it too low increases API calls and costs; setting it too high means applications run with stale credentials after rotation. For most workloads, a 5 to 15 minute refresh interval strikes the right balance. For secrets that rotate frequently (hourly or faster), consider the Secrets Store CSI Driver instead.

3. Secrets Store CSI Driver

The Secrets Store CSI Driver mounts secrets from external stores directly as volumes in pods, bypassing Kubernetes Secrets entirely. This is the most secure approach because secrets never exist as Kubernetes objects -- they are fetched from the external store at pod startup and mounted as files. The downside is that secret updates require pod restarts, and the driver adds complexity to your cluster configuration.

Cost Comparison at Scale

Let us compare costs for a realistic scenario: 500 secrets, accessed 2 million times per month, with monthly rotation.

• HashiCorp Vault (self-managed): Infrastructure costs (3-node HA cluster on small VMs) of roughly $150 to $300 per month, plus engineering time for operations. HCP Vault Dedicated starts at around $1.58 per hour ($1,137/month).
• AWS Secrets Manager: 500 secrets at $0.40 = $200/month, plus 2M API calls at $0.05/10K = $10/month. Total: approximately $210/month.
• Azure Key Vault (Standard): 2M operations at $0.03/10K = $6/month. Total: approximately $6/month.
• GCP Secret Manager: 500 secrets with 2 active versions each at $0.06 = $60/month, plus 2M accesses at $0.03/10K = $6/month. Total: approximately $66/month.

Azure Key Vault is the clear winner on cost, especially for high-access-volume workloads. AWS Secrets Manager is the most expensive managed option but offers the best native rotation support. GCP falls in the middle. Vault's self-managed costs are comparable to AWS Secrets Manager, but HCP Vault Dedicated is significantly more expensive -- justified only when you need dynamic secrets or multi-cloud management.

Rotation Strategies That Work in Practice

Secret rotation is conceptually simple but operationally tricky. The fundamental challenge is the rotation window: the period between when a new secret is created and when all consumers have switched to it. During this window, both the old and new secret must be valid, or you get downtime.

Dual-Secret Pattern

Maintain two active credentials at all times. When rotating, create a new credential (credential B) while keeping the existing one (credential A) active. Update the secret store with credential B. Wait for all consumers to pick up the new credential (based on your cache TTL or refresh interval). Then deactivate credential A. This pattern works for API keys, database credentials, and service account tokens. The rotation period should be at least 2x your consumer's cache TTL to ensure all consumers have switched over.

Version-Based Pattern

Store secrets with explicit version labels (CURRENT and PREVIOUS). Consumers always fetch the CURRENT version. During rotation, the old CURRENT becomes PREVIOUS, and the new secret becomes CURRENT. Both versions remain valid for a grace period. This is how GCP Secret Manager's versioning naturally works, and it maps cleanly to AWS Secrets Manager's staging labels (AWSCURRENT and AWSPREVIOUS).

Recommended Rotation Intervals

• Database credentials: 30 days for production, 90 days for non-production
• API keys for third-party services: 90 days, or per the provider's recommendation
• TLS certificates: 90 days (aligned with Let's Encrypt defaults) or shorter with ACME automation
• Service account keys: Avoid entirely if possible; use workload identity instead. If unavoidable, rotate every 30 days
• Encryption keys: Annually for KMS keys, or per your compliance framework's requirements

Practical Recommendations

After implementing secrets management across dozens of organizations, here is the decision framework I use.

If you are a single-cloud AWS shop with fewer than 1,000 secrets and no dynamic credential requirements, use AWS Secrets Manager. The native integration with RDS rotation, IAM, and EKS makes it the lowest-friction option. Accept the higher per-secret cost as the price of zero operational overhead.

If you are on Azure, use Key Vault. The cost advantage is enormous, the integration with managed identities is excellent, and the certificate management capabilities mean you do not need a separate tool for TLS.

If you are on GCP, use Secret Manager with Workload Identity Federation. The IAM model is the cleanest, and the versioned secrets approach maps well to GitOps workflows.

If you are multi-cloud or need dynamic secrets, invest in Vault. Use HCP Vault if you do not have a dedicated platform team. The operational overhead of self-managed Vault is only worth it if you have engineers who enjoy running distributed systems.