AWS vs GCP vs Azure secrets managersReal pricing, real DX, real failure modes.

Every major cloud provider ships a secrets manager. They all solve the same core problem: stop putting plaintext credentials in environment variables, config files, and source code. The question is which one to use, and whether any of them cover your actual attack surface.

If you run on one cloud, this choice is mostly made for you. The ecosystem fit matters more than any feature delta. But the pricing models diverge in non-obvious ways, the developer experience gaps are real, and there is a class of problem none of them handle well.

What to know in 60 seconds

• AWS Secrets Manager costs $0.40 per secret per month plus $0.05 per 10,000 API calls. One hundred secrets costs $40/month before access charges.
• GCP Secret Manager costs $0.06 per active secret version per month plus $0.03 per 10,000 access operations. The same hundred secrets costs $6/month.
• Azure Key Vault charges per operation across three tiers: Standard, Premium (HSM-backed), and Managed HSM. Certificate management is built in.
• All three assume you have cloud-native workloads with ambient identity (IAM role, workload identity, Managed Identity). On a developer laptop, that assumption breaks.
• None of them are meaningfully better than the others on security. Pick the one your cloud identity model already supports.

AWS Secrets Manager: IAM-native and expensive at scale

AWS Secrets Manager is the oldest of the three and shows it. The API is verbose, the IAM policies are granular, and the pricing reflects AWS's general approach of charging for every unit of work.

Pricing. $0.40 per secret per month, $0.05 per 10,000 API calls. A medium-sized engineering organization with 500 distinct secrets across staging and production environments pays $200/month in storage fees before a single access call. Rotation Lambdas run against your Lambda quota and add invocation costs. At low secret counts the absolute dollar figure is small. At enterprise scale it adds up, and the per-call charge makes high-frequency reads expensive.

Rotation. Secrets Manager ships native rotation via Lambda functions for common AWS services: RDS, Redshift, DocumentDB, and a handful of others. You write a Lambda that rotates the value and registers it as the rotation handler. The rotation fires on your schedule. For custom rotation targets you write the Lambda yourself, which is straightforward but adds an infra footprint.

Access model. IAM policies control who reads what. An EC2 instance, Lambda, or ECS task with an attached IAM role can read a secret without any credentials in the code. That is the value proposition: the workload authenticates via instance metadata or task role, and the secret appears in response to an API call. Cross-account access works through resource-based policies.

Developer experience. The AWS SDK call to retrieve a secret is three lines in any language. The IAM policy setup is not. Debugging a permissions error in IAM involves deciphering policy evaluation logic, trust relationships, and potentially Service Control Policies. Developers new to AWS consistently find this the hard part.

Failure modes. AWS Secrets Manager has hit regional outages that blocked secret reads, taking down services that fetched secrets at startup rather than caching them. AWS recommends caching with a reasonable TTL. Some teams fetch once at boot and store in memory. Either approach reintroduces the question of what happens when the cache is cold and the API is down.

KMS backs secret encryption. Every read is a decrypt operation. KMS has its own pricing: $0.03 per 10,000 API calls. The total cost per secret read is Secrets Manager + KMS, a detail that sometimes surprises teams during their first bill review.

GCP Secret Manager: simpler API, better price at scale

GCP Secret Manager is cheaper and the API is smaller. If you use Cloud Run, GKE, or App Engine, the workload identity integration is cleaner than AWS's equivalent.

Pricing. $0.06 per active secret version per month, $0.03 per 10,000 access operations. A hundred secrets with one active version each costs $6/month in storage. Creating multiple versions of the same secret (each rotation creates a new version) increases cost if you keep old versions active. Version pinning is deliberate: you specify a version number or "latest" in the access call. Pinning a version means you read a known value; using "latest" means the value can change without a code deploy.

Version model. Every update creates a new version. Old versions persist until you destroy them. This makes rollback straightforward: pin the previous version number. It also means a naive rotation loop that never destroys old versions will accumulate active versions and inflate costs. A good practice is to destroy a version immediately after confirming the new one works.

Access model. GCP workload identity lets a Kubernetes service account or Cloud Run service identity map to a GCP service account without key files. The workload sends a short-lived OIDC token to the GCP metadata server, gets a GCP identity token back, and uses that to call Secret Manager. No credentials on disk. For GKE in particular, the Workload Identity Federation setup is well-documented and widely used.

Developer experience. The Secret Manager API is smaller than AWS's. Read a secret version: one API call, straightforward response. The gcloud CLI makes testing easy. IAM conditions for time-bounded or resource-bounded access are cleaner to write than the equivalent AWS condition syntax.

Failure modes. GCP Secret Manager is a global service with regional storage options. The access endpoint (secretmanager.googleapis.com) has had brief interruptions, but the service has a good reliability track record. The bigger operational risk is version sprawl: a rotation script that creates without destroying will produce dozens of active versions over months.

Azure Key Vault: certificate management and Managed Identity

Azure Key Vault handles secrets, keys, and certificates in a single service. If your organization manages TLS certificates, code-signing certificates, or encryption keys alongside application secrets, the consolidation is useful.

Pricing. Azure charges per operation, not per secret per month. Standard tier: $0.03 per 10,000 secret operations. Premium tier adds HSM-backed keys at $1.00/month per key plus higher per-operation costs. Managed HSM is dedicated hardware: $3.20/hour per HSM unit, which is a different cost class and appropriate for regulated industries with explicit HSM requirements.

The per-operation model is friendly for low-frequency access patterns and expensive for services that call Key Vault on every request. Azure recommends using the Azure SDK's built-in cache and avoiding calls in hot request paths.

Certificate management. Key Vault can generate certificate signing requests, integrate with DigiCert and GlobalSign for automatic renewal, and store the private key without your application ever seeing it. The application retrieves the certificate from Key Vault when it starts. Auto-rotation fires before expiration. For teams that have burned time on expired certificates, this is a real operational improvement.

Access model. Managed Identity is the equivalent of AWS instance roles or GCP workload identity. An Azure VM, App Service, or AKS pod with a Managed Identity assigned can read from Key Vault without any credential on disk. The identity is provisioned by Azure and rotated automatically. Cross-tenant access is possible via federated identity credentials.

Developer experience. The Azure SDK wraps Key Vault reads cleanly. The portal UI is good for one-off inspection. The RBAC model shifted from legacy access policies to Azure RBAC in 2021, and some teams still mix the two models in older deployments. Legacy access policies and Azure RBAC coexist but do not compose in obvious ways, which creates confusion during permission debugging.

Failure modes. Key Vault has a soft-delete and purge-protection mechanism. Accidental deletion does not immediately destroy a vault or a secret: by default, soft-deleted vaults survive 90 days. Purge protection prevents permanent deletion during a configurable retention period. This protects against accidents. It also means an attacker with contributor rights cannot immediately destroy evidence, which is useful. Vault throttling is a real operational concern: the per-vault request limit is 1,000-2,000 operations per 10 seconds depending on the operation type, and shared vaults across many services can hit this.

They are all fine in cloud, all awkward on a laptop

Cloud-native secrets managers work because they assume ambient identity. An EC2 instance has an instance role. A Cloud Run service has a workload identity. An Azure App Service has a Managed Identity. The workload authenticates through the cloud infrastructure, and the secrets manager hands over the value. No long-lived credential on disk. The trust chain runs through the cloud provider's identity plane.

Take the same pattern to a developer laptop and the assumption breaks.

A developer's laptop has no instance role, no metadata server, no managed identity. To use AWS Secrets Manager from a laptop, the developer needs an IAM user with a long-lived access key and secret, or they need to federate through SSO and assume a role via STS. The SSO path works, and AWS IAM Identity Center makes it reasonably clean. But it requires configuration: setting up the SSO portal, configuring the AWS CLI profile, refreshing the token before it expires. Developers who do this correctly get close to ambient-identity behavior. Developers who take the shortcut put AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY in their .env file, which is the same problem the secrets manager was supposed to solve.

GCP's equivalent is Application Default Credentials via gcloud auth application-default login. The browser pop-up works. The credential expires in hours. Developers on machines with unstable network connectivity or strict browser policies hit friction.

Azure's path is az login with interactive authentication. It works. It also times out, prompts for MFA at unpredictable intervals, and does not survive reboot cleanly in all configurations.

GitGuardian's 2026 State of Secrets Sprawl found that AI-assisted commits leak secrets roughly twice as often as the baseline. The reason is not that cloud secrets managers fail in CI or in production, where ambient identity is in place. The leaks happen on developer machines where the credentials are long-lived, stored in dot-files, and copied across sessions.

The friction of federated authentication on a laptop is real enough that many teams accept the risk. Developers hold long-lived credentials locally because that is the path of least resistance. Those credentials end up in .env files, in shell history, and in the state files that AI coding agents write to disk.

Before you pick: a checklist

## Cloud secrets manager selection checklist

- [ ] Identified which cloud provider hosts the primary workload
- [ ] Verified that workload identity (IAM role / workload identity / Managed Identity) is available for all compute types in use
- [ ] Priced secret count * access frequency against each provider's model
- [ ] Confirmed rotation strategy: native (Secrets Manager Lambda), version-swap (GCP), or policy-based (Key Vault)
- [ ] Audited whether any service fetches secrets on every request (caching needed to avoid throttle/cost)
- [ ] Assessed certificate management needs (Key Vault if yes, others if no)
- [ ] Documented the developer local-access path and what long-lived credentials it creates
- [ ] Checked whether AI coding agents run locally with access to the same credentials
- [ ] Defined a policy for how long local developer credentials live before rotation
- [ ] Set up a scan for long-lived access keys or service account keys checked into repos

What this means for your stack

In cloud workloads with ambient identity properly configured, all three of these tools handle the job. The differences in pricing, API shape, and rotation support are real but not large enough to justify switching clouds or running multi-cloud secrets management. Run on AWS, use Secrets Manager. Run on GCP, use Secret Manager. Run on Azure, use Key Vault. If you run across all three, accept that you will operate three secrets managers, not one.

The unsolved gap is the developer machine. Cloud-native managers do not cover a laptop well because the identity model does not extend cleanly outside the cloud boundary. Teams that solve this with long-lived access keys or service account files are accepting a risk that the cloud managers were built to eliminate.

hasp is one working implementation of the laptop-local layer. curl -fsSL https://gethasp.com/install.sh | sh, hasp setup, connect a project, and the agent on your machine gets a credential injected into a single child process at exec time rather than reading it from ambient environment. The audit trail is local and append-only. Source-available (FCL-1.0), local-first, macOS and Linux, no account.

The cloud gets ambient identity right. Getting the same guarantee on a laptop requires a different tool built for that context.