Pick the secrets manager that lives in the cloud your workloads already run in. The AWS Secrets Manager vs Azure Key Vault vs GCP Secret Manager choice then comes down to three things the product pages bury: how each one bills, which one rotates secrets for you, and how hard each one makes an accidental delete.
I pulled every number below from the vendors’ own pricing, quota and rotation pages on 2026-10-28, and I ran the cost scenarios myself. But I did not create secrets in any of the three clouds for this post. The AWS and Azure flags match the installed CLIs (aws-cli 2.38.6, azure-cli 2.90.0). The gcloud commands come from Google’s docs only, because gcloud would not start on the machine I wrote this on.
What Is the Difference Between AWS Secrets Manager vs Azure Key Vault vs GCP?
All three store secret strings encrypted, keep versions, and gate reads with IAM. The differences that change your design are size and rate limits, who ships rotation, and the billing unit. AWS bills per secret, Azure bills per operation, and Google bills per active secret version.
| AWS Secrets Manager | Azure Key Vault | GCP Secret Manager | |
|---|---|---|---|
| Max secret size | 65,536 bytes | 25 KB | 64 KiB |
| Read limit | 10,000 GetSecretValue per second, per Region |
4,000 transactions per 10 seconds, per vault | 90,000 access requests per minute, per project |
| Versions | 100 per secret, unlabeled ones pruned | No cap, but backup fails past 500 | Not stated on the quotas page |
| Billing unit | Per secret, plus per call | Per operation | Per active version, plus per access |
| Built-in rotation | Yes, via Lambda or managed rotation | No for secrets | No, notification only |
Converted to seconds, AWS allows 10,000 reads per Region, but Azure allows only 400 per vault, and every operation except create shares that budget. Google sits between them at 1,500 per project.
So a fleet that cold-starts and fetches secrets at once can hit throttling on Azure first. Spreading hot secrets across vaults helps, up to the subscription-wide cap of five times the per-vault limit. That advice is my inference from Microsoft’s service limits table, not Microsoft guidance.
How Much Do AWS Secrets Manager vs Azure Key Vault vs GCP Secret Manager Cost?
For 100 secrets and 1 million reads a month, list prices work out to $45.00 on AWS, $3.00 on Azure and $8.61 on GCP. AWS costs the most because it charges $0.40 per secret every month. Azure’s pricing lists no storage charge for secrets, so you pay only for operations.
| Storage | Reads | |
|---|---|---|
| AWS | $0.40 per secret per month | $0.05 per 10,000 calls |
| Azure (Standard) | None listed | $0.03 per 10,000 operations |
| GCP | $0.000082192 per active version per hour after 6 free versions | $0.03 per 10,000 accesses after 10,000 free |
I took the Azure rate from Microsoft’s retail prices API for East US. For Google I multiplied the hourly rate by 730 hours, which is about $0.06 per version per month.
| Secrets | Reads per month | Active versions each | AWS | Azure | GCP |
|---|---|---|---|---|---|
| 100 | 1,000,000 | 1 | $45.00 | $3.00 | $8.61 |
| 1,000 | 10,000,000 | 1 | $450.00 | $30.00 | $89.61 |
| 100 | 1,000,000 | 5 | $45.00 | $3.00 | $32.61 |
The last row is the GCP trap. Google bills enabled and disabled versions, but not destroyed ones. So old versions you never destroy keep costing money. AWS avoids this because it bills per secret and prunes unlabeled versions itself once a secret passes 100.
These list prices in USD exclude free-tier credits, KMS, Pub/Sub, and the Lambda or function you run for rotation. Also check the live pricing pages before you commit.
Which Secrets Manager Rotates Secrets for You?
Only AWS rotates a secret end to end. Azure and Google deliver the trigger and leave the rotation code to you. Because of that, the gap matters more than the price difference if you manage database passwords.
AWS calls a Lambda function on your schedule. The function runs four steps: create_secret, set_secret, test_secret and finish_secret. You set the schedule with a cron() or rate() expression plus a window Duration. Secrets owned by other AWS services use managed rotation instead, which needs no Lambda. Per the rotation docs, if any step fails, Secrets Manager retries the whole rotation during the open windows.
aws secretsmanager rotate-secret \
--secret-id MySecret \
--rotation-lambda-arn arn:aws:lambda:<aws-region>:<account-id>:function:my-rotation-function \
--rotation-rules "{\"ScheduleExpression\": \"cron(0 16 1,15 * ? *)\", \"Duration\": \"2h\"}"Azure autorotates keys, not secrets. For a secret, Key Vault publishes a SecretNearExpiry event to Event Grid 30 days before expiry. Event Grid calls a function you wrote, which creates the new version and then updates the target service. Microsoft’s own tutorial warns there can be a lag between those two steps. During that window, the secret in Key Vault can’t authenticate. Event Grid also retries for two hours if a step fails.
GCP sends a SECRET_ROTATE message to a Pub/Sub topic and stops there. The rotation docs set rotation_period to a minimum of one hour, and next_rotation_time must sit at least five minutes ahead. Also, scheduled rotations are skipped while another is in flight. Failed sends retry for up to seven days, then the rotation is canceled.
gcloud secrets create SECRET_ID \
--replication-policy "automatic" \
--next-rotation-time="NEXT_ROTATION_TIME" \
--rotation-period="ROTATION_PERIOD" \
--topics="projects/your-project-id/topics/your-topic-name"How Do You Create and Read a Secret in Each Cloud?
Each CLI takes a file instead of a literal value, and you should use that path. AWS warns that command history and shell utilities can expose parameters, and Google discourages piping through echo for the same reason. So pass the value from a file, then delete the file afterward.
# AWS
aws secretsmanager create-secret --name MyTestSecret --secret-string file://mycreds.json
aws secretsmanager get-secret-value --secret-id MyTestSecret --query SecretString --output text
# Azure
az keyvault secret set --name MySecretName --vault-name MyKeyVault --file /path/to/file --encoding utf-8
az keyvault secret show --name MySecretName --vault-name MyKeyVault --query value -o tsv
# GCP
gcloud secrets create SECRET_ID --replication-policy="automatic"
gcloud secrets versions add SECRET_ID --data-file="FILE_PATH"
gcloud secrets versions access latest --secret=SECRET_IDWithout a version argument, each reads the newest value, but each names it differently. AWS returns the AWSCURRENT stage by default, az keyvault secret show uses the latest version, and Google accepts latest as the version ID. For Azure access, Microsoft recommends Azure RBAC and calls access policies legacy. If you authenticate from a pipeline, our Azure service principal guide covers the identity side.
What Are the Deletion and Recovery Gotchas?
All three make deletion harder than you expect, but the rules differ. Know them before an incident, because a deleted secret can block you from recreating it under the same name.
Azure Key Vault turns soft delete on for new vaults, and you can’t switch it off. Deleted secrets stay recoverable for 7 to 90 days, with 90 as the default. You set that interval only at vault creation, so you can’t change it later. While a secret sits in the deleted state, you can’t create another secret with the same name in that vault. Purge protection is optional and also off by default. The az keyvault create command exposes --retention-days, --enable-purge-protection and --enable-rbac-authorization.
AWS makes the secret inaccessible immediately and schedules deletion after a recovery window of at least seven days. Plus, nothing is billed for a secret marked for deletion. ⚠️ Note: --force-delete-without-recovery skips the window, and you can’t undo it. Also, a replicated primary secret can’t be deleted until you remove its replicas.
On Google, the replication policy is permanent: the locations can’t be updated after you create the secret. With user-managed replication, an outage in one chosen region makes creates and updates fail rather than leaving data inconsistent.
Which Should You Choose: AWS Secrets Manager vs Azure Key Vault vs GCP?
Choose the store in the cloud where the workload runs, then let one of these exceptions override that.
| If you need | Pick |
|---|---|
| Turnkey database-password rotation | AWS, the only one that ships it, so budget $0.40 per secret per month |
| Thousands of small secrets at low cost | Azure, the cheapest in every scenario above, with GCP second |
| Bursty reads | AWS, which gives the most headroom per Region, so plan vault layout on Azure |
| All three clouds or on-prem | A neutral store, because reading across clouds means managing a credential for the other cloud’s IAM |
For the neutral-store route, our HashiCorp Vault authentication guide covers how workloads sign in. If you already picked Azure, our Key Vault best practices post goes deeper on access control. For Terraform users, ephemeral values keep secrets out of state.
What I Did Not Test
I did not measure latency, real throttling behavior, or a full rotation run on any cloud. I also did not test organization policies or cross-account access. Everything above comes from the vendors’ documentation and my own arithmetic on their list prices. Treat the cost table as a model of your bill, not a quote.
Frequently Asked Questions
Q: Which is cheaper, AWS Secrets Manager or Azure Key Vault?
A: Azure Key Vault, at list price. At 100 secrets and 1 million reads a month it costs $3.00, against $45.00 on AWS. AWS charges $0.40 per secret per month, while Azure lists no storage charge for secrets.
Q: Does Azure Key Vault rotate secrets automatically?
A: Not natively. Key Vault autorotates keys, with a minimum interval of seven days. For secrets, you wire an Event Grid event to a function that writes the new version and updates the target service.
Q: Does GCP Secret Manager rotate secrets on its own?
A: No. It publishes a SECRET_ROTATE message to a Pub/Sub topic on your schedule. You build the subscriber that creates the new version and deploys it.
Q: Can I recover a deleted secret in AWS Secrets Manager?
A: Yes, during the recovery window, which is at least seven days. Use restore-secret before the DeletionDate. A secret deleted with --force-delete-without-recovery is gone for good.
Quick Summary:
– AWS bills $0.40 per secret, Azure bills per operation only, and GCP bills per active version, so old undestroyed GCP versions cost money
– At 100 secrets and 1 million reads a month, list prices came to $45.00 on AWS, $3.00 on Azure and $8.61 on GCP
– Only AWS rotates secrets end to end. Azure and GCP send a trigger and you write the rotation code
– Azure reads are capped at 400 a second per vault, against 10,000 a second per Region on AWS
– Azure soft delete can’t be disabled, and Google’s replication locations can’t be changed after creation
– I verified the AWS and Azure flags against the installed CLIs and ran no secrets in any cloud
Before you commit, plug your own secret and read counts into the three price formulas above, then decide between AWS Secrets Manager vs Azure Key Vault vs GCP Secret Manager on your numbers.
Related guides
- Best Practices for Azure Key Vault: Safeguarding Your Secrets
- Step-by-Step Guide for Creating AWS IAM User, Access Key, and Secret Key:
- A Comparative Overview of CI/CD Tools in Azure, GCP, and AWS
- Switching Cloud Accounts: AWS, GCP and Azure Fast
- Building and Publishing Docker Images for AWS, Azure, and GCP
- Creating a GCP Service Account and Key: Step-by-Step Guide