AWS Secrets Manager vs Google Cloud Secret Manager

AWS Secrets Manager

IAM roles support access without long-lived credentials on AWS compute services. Each API call is billed, making caching relevant to frequent reads.

Google Cloud Secret Manager

Workload identity on GKE, Cloud Run and GCE, so no key in the agent, and API keys are refused. Managed rotation only covers Cloud SQL; other rotation is a Pub/Sub notification you handle.

AWS Secrets Manager

1. Give the agent's task or instance role secretsmanager:GetSecretValue on the specific secret ARN, not a wildcard
2. Cache the value for the run, or read through the Workload Credentials Provider on localhost; each GetSecretValue is billed and logged
3. Use BatchGetSecretValue with a filter when you need several secrets at start-up; it's limited to 100 calls a second
4. Pass a ClientRequestToken on PutSecretValue so a retry can't create a second version, and don't write more than once every 10 minutes
5. Read VersionStage AWSPREVIOUS if a rotation lands mid-run and the new credential isn't live yet

Google Cloud Secret Manager

1. Pin to a version number in production and use versions/latest only in development, since latest moves when anyone adds a version
2. Grant roles/secretmanager.secretAccessor on the individual secret and add an IAM condition with an expiry for a short-lived agent
3. Turn on Data Access audit logs for secretmanager.googleapis.com if you need a record of each read
4. Read once per run and cache; accesses past 10,000 a month are metered
5. Use a regional secret (projects/*/locations/*/secrets/*) when the data must stay in one place, and note the higher write quota there