google_secret_manager_secret_version cost estimation

A google_secret_manager_secret_version stores one immutable payload (a specific value) of a parent secret. Adding a new version is how you rotate a secret: the old version stays until you disable or destroy it. Secret Manager's cost is driven almost entirely at the version level, which is why this resource, rather than the parent secret, is where the bill accrues.

Two charges apply. First, active secret versions bill a small flat rate per version per month; only enabled versions count, so destroyed or disabled versions stop billing. Second, access operations bill per 10,000: every call that reads a version's payload counts, and a workload that fetches a secret on every request instead of caching it can rack up access charges quickly. Replication into multiple regions can add per-location cost for user-managed replication.

So the two levers are how many active versions you keep and how often you access them. Leaving every historical version enabled after rotation, or reading a secret in a hot path without caching, are the common cost mistakes. c3x prices active versions and access operations and links this resource to the parent secret it belongs to.

Terraform example

A minimal but realistic configuration that C3X can estimate.

resource "google_secret_manager_secret_version" "db_password" {
  secret      = google_secret_manager_secret.db_password.id
  secret_data = var.db_password
}

Pricing dimensions

What you actually pay for when you provision google_secret_manager_secret_version.

Dimension	Unit	What's being charged
Active secret version	per version-month	Each enabled secret version bills a flat monthly rate. Disabled or destroyed versions do not bill. ~$0.06 per active version-month
Access operations	per 10k operations	Calls that read a version's payload, counted per access. Uncached hot-path reads add up fast. ~$0.03 per 10k accesses
Multi-region replication	per location	User-managed replication into several regions multiplies the per-version cost by location.

Optimization tips

Common ways to reduce google_secret_manager_secret_version cost without changing the workload.

Destroy old versions after rotation

Removes per-version monthly charge

Each active version bills monthly. Disabling then destroying superseded versions once nothing references them stops paying for secrets you no longer use.

Cache secret reads

Fewer billable access operations

Access operations bill per 10,000. Reading a secret once at startup and caching it, instead of fetching on every request, cuts access charges dramatically in hot paths.

Use automatic replication unless you need specific regions

Automatic replication is simplest and avoids the per-location multiplication that user-managed multi-region replication adds to each version.

FAQ

Does a secret version cost money?

Yes, a small amount. Each active secret version bills a flat monthly rate, and reading its payload bills per 10,000 access operations. Disabled or destroyed versions stop billing.

Why is my Secret Manager bill higher than expected?

Usually too many active versions kept after rotation, or a workload reading secrets on every request without caching. Destroying old versions and caching reads are the main fixes.

How do I estimate Secret Manager cost?

Count active versions times the monthly rate, plus expected access operations per 10,000, times replication locations. c3x prices versions and access and links to the parent secret.