google_project_iam_member cost estimation
A project IAM binding is free. It grants a role to a member at the project level. It has no charge; it only enables access to resources that may cost money.
A google_project_iam_member grants a single role to a single principal (a user, group, or service account) at the project level, adding to the project's IAM policy without overwriting it. IAM bindings are free. There is no charge for the binding, for the number of bindings, or for evaluating them on every API call.
A binding has no cost driver of its own. Its only effect on your bill is enabling: it lets a principal call APIs and operate resources that may themselves be billed. Granting roles/compute.admin does not cost anything, but it lets that principal create VMs that do. So the cost conversation around IAM is about governance (who can create expensive things) rather than about the binding as a line item.
A practical note: google_project_iam_member is additive and safe for granting one role to one member, whereas google_project_iam_policy is authoritative and replaces the whole policy. Neither is billed. c3x treats project IAM bindings as free and prices the resources that the granted access is used to provision.
Terraform example
A minimal but realistic configuration that C3X can estimate.
resource "google_project_iam_member" "app_logging" {
project = "my-project"
role = "roles/logging.logWriter"
member = "serviceAccount:${google_service_account.app.email}"
}Pricing dimensions
What you actually pay for when you provision google_project_iam_member.
| Dimension | Unit | What's being charged |
|---|---|---|
| IAM binding | free | The role binding, and any number of bindings, have no charge and no evaluation fee. $0 |
| Resources the access enables | varies | Paid resources a principal creates or operates using the granted role carry their own cost. |
Optimization tips
Common ways to reduce google_project_iam_member cost without changing the workload.
Grant least privilege
The binding is free, but broad roles let principals create expensive resources. Scoping to the minimum role needed limits which costly actions are possible.
Bind roles to groups, not individuals
Granting roles to a group keeps the policy small and manageable at no cost, and makes it easier to audit who can provision paid resources.
Prefer additive bindings over authoritative policy
google_project_iam_member adds one binding safely. google_project_iam_policy replaces the entire policy and can accidentally remove access. Neither costs anything; the additive form is safer.
FAQ
Does a project IAM binding cost money?
No. IAM role bindings at the project level are free, with no per-binding charge and no fee for policy evaluation. Cost comes only from the resources the granted access is used to operate.
How does an IAM binding affect my bill?
Only by enabling access. A binding lets a principal call APIs and create paid resources. The binding itself is free; the VMs, buckets, and services it permits are what bill.
Is there a cost difference between iam_member and iam_policy?
No, both are free. The difference is behavior: iam_member adds one binding additively, while iam_policy is authoritative and replaces the whole policy. The additive form is the safer default.
Related resources
Estimate this resource in your own Terraform
Free, open source, no API key. C3X parses your Terraform and shows line-item cost for every resource, including google_project_iam_member.