Secure Google Cloud Billing Analytics with BigQuery and Looker Studio

Cloud billing data deserves the same care as other sensitive enterprise data. It can reveal infrastructure usage, negotiated pricing, project names, resource identifiers, and the operating footprint of individual business units.

A well-designed billing analytics platform must answer three questions:

  • Who can access the billing data?
  • What can they do with that data?
  • How much does the analytics platform itself cost to operate?

The recommended architecture combines corporate identity, organization policies, a dedicated Google Cloud project, carefully scoped BigQuery permissions, and controlled dashboard access.

1. Start with a Dedicated Billing Analytics Project

Create a separate Google Cloud project for centralized billing analytics—for example, finops-billing-analytics.

This project should contain the BigQuery datasets used for billing exports and reporting. Separating these resources from application projects makes access reviews, operational ownership, and analytics cost tracking easier.

For a larger organization, consider two projects:

Project Purpose
Billing data project Stores raw billing exports and curated reporting datasets
Analytics execution project Runs analyst queries and dashboard queries, with its own cost controls

This separation lets analysts query approved data without receiving broad permissions over the project that stores the raw exports.

Cloud Billing exports directly to BigQuery tables. A Cloud Storage bucket is not required for the standard BigQuery export architecture. A bucket may be useful for a separate archival or data exchange workflow.

A recommended dataset structure is:

Dataset Recommended purpose
billing_raw Original billing export tables
billing_curated Normalized views and reporting tables
billing_reporting Aggregated datasets approved for dashboard consumption

Keep the raw export as the source of truth. Apply business logic—such as department allocation, environment classification, and cost-center mapping—in the curated layer.

2. Use Managed Corporate Identities and SSO

Employees should access Google Cloud through managed corporate identities.

If the organization already uses Microsoft Entra ID, Active Directory with an appropriate federation service, Okta, or another identity provider, integrate that identity system with Google Cloud. A common approach provisions users into Cloud Identity or Google Workspace and federates authentication to the corporate identity provider.

Workforce Identity Federation is another option for supported Google Cloud access scenarios. Evaluate the chosen identity approach against the applications employees will use, including dashboard access.

The goal is consistent identity management across the employee lifecycle:

  • Provision access when an employee joins.
  • Change group membership when responsibilities change.
  • Enforce MFA through the identity architecture.
  • Remove access when an employee leaves.
  • Maintain tightly controlled emergency administration accounts.

A separate on-premises directory is not inherently necessary. Use the existing corporate identity system where practical.

Create groups around responsibilities, such as:

Grant permissions to these groups wherever possible. This makes access easier to review than a collection of individual grants.

3. Restrict IAM Sharing at the Organization Level

Use domain-restricted sharing to limit which principals can receive IAM access.

Google Cloud provides several approaches, including the managed constraint:

constraints/iam.managed.allowedPolicyMembers

The legacy constraint is:

constraints/iam.allowedPolicyMemberDomains

These approaches accept different policy values; the legacy constraint should not be treated as a simple email-domain string allowlist.

Configure the policy around approved corporate principals and explicitly required workload identities. Review existing IAM bindings separately: enabling the restriction does not automatically remove previously granted access.

Also account for Google-managed service identities. Billing export depends on a service account that must retain the required dataset permissions.

Domain restrictions establish an IAM sharing boundary. They do not replace SSO, MFA, data permissions, or dashboard-sharing controls.

4. Protect the Billing Data with VPC Service Controls

For sensitive billing analytics, use a VPC Service Controls perimeter around the projects hosting the protected BigQuery resources.

The perimeter protects access to supported services and helps constrain data movement across the boundary. It complements IAM: a principal must satisfy both the applicable permissions and perimeter requirements.

Because billing exports reside in BigQuery, protect the BigQuery project. If the architecture also uses Cloud Storage, include the relevant storage projects and service restrictions.

Plan the perimeter around the actual workflows:

  • Billing export ingestion.
  • Queries from approved users.
  • Queries submitted from a separate analytics project.
  • Dashboard connections.
  • Scheduled reporting and transformation jobs.
  • Approved data exports.

Start with a dry-run configuration, inspect violations, and validate these workflows before enforcement.

Looker Studio’s BigQuery connection supports VPC Service Controls, but interactive access and background reporting have different requirements. Scheduled deliveries and extracts may fail when access relies solely on the viewer’s IP address. Configure the documented service-account and perimeter access paths for automated reporting.

5. Separate Cloud Billing Permissions from BigQuery Permissions

Cloud Billing access and BigQuery access serve different purposes.

Permission to view a billing account does not automatically grant access to its exported BigQuery tables. Likewise, access to the export tables does not automatically grant access to the billing account.

Billing Account Viewer

Grant:

roles/billing.viewer

on each billing account that the user must inspect.

This is appropriate for people who need billing-account visibility without full administrative authority. If an analyst only uses approved BigQuery reports, billing-account access may be unnecessary.

Billing Account User

Grant:

roles/billing.user

to principals that need to associate projects with a billing account.

This can include a provisioning service account, but it is not a role intended exclusively for service accounts.

Linking a project also requires the corresponding project-side permission, commonly provided by:

roles/billing.projectManager

Grant Billing Account User on the billing account and Project Billing Manager on the relevant project. Neither is ordinarily required for an analyst reading billing exports.

Export Setup Requires Additional Permissions

Read-only billing access is insufficient to configure exports.

Google’s documented setup roles distinguish between export types:

Export type Billing-side setup role BigQuery-side setup role
Usage cost export Billing Account Costs Manager or Billing Account Administrator BigQuery User on the destination project
Pricing and CUD metadata exports Billing Account Administrator BigQuery Admin on the destination project, plus the documented project permissions

Treat setup access separately from ongoing analyst access. Preserve the permissions assigned to the billing export service identity.

6. Use Least-Privilege BigQuery Roles

For a read-only analyst, the usual starting point is:

Permission Role Grant location
Read approved data roles/bigquery.dataViewer Approved dataset, table, or view
Submit query jobs roles/bigquery.jobUser Project where queries execute

These permissions address separate needs: reading data and running a job.

If the query runs in a dedicated analytics project, grant Job User there and Data Viewer on the approved data resources in the billing project.

Basic Roles and Legacy Dataset Access

Avoid broad project roles such as Owner, Editor, and Viewer for routine billing analytics.

BigQuery has historical default dataset access entries associated with project basic roles:

Project basic role Legacy special group Dataset access Corresponding predefined data role
Viewer projectReaders READER roles/bigquery.dataViewer
Editor projectWriters WRITER roles/bigquery.dataEditor
Owner projectOwners OWNER roles/bigquery.dataOwner

These special groups are BigQuery access constructs, rather than corporate groups created in your identity provider.

Review default dataset entries explicitly. Removing a default entry does not negate permissions inherited through another applicable IAM grant.

Administrative Roles: Grant Only What the Responsibility Requires

Role Appropriate responsibility
roles/bigquery.dataEditor Maintain tables and data in approved datasets
roles/bigquery.dataOwner Manage dataset data and access
roles/bigquery.admin Broad BigQuery administration within the granted scope
roles/bigquery.connectionAdmin Manage BigQuery connections
roles/bigquery.resourceAdmin Manage capacity, reservations, and related resources

BigQuery Admin granted on one dataset does not provide project-wide job administration. Project-level operations require permissions at the appropriate project or higher scope.

Connection Admin and Resource Admin are generally unnecessary for reading ordinary billing export tables. Reserve them for the administrators responsible for those functions.

7. Consolidate Multiple Billing Accounts Carefully

A centralized reporting platform can analyze exports from multiple billing accounts. Keep each account’s export tables identifiable and consolidate them through a curated reporting layer.

Recommended practices include:

  • Retain billing_account_id in reporting data.
  • Normalize project, department, and environment mappings.
  • Include credits when calculating net costs.
  • Distinguish usage date from invoice month.
  • Separate currencies unless an explicit conversion method is applied.
  • Reconcile dashboard totals against billing records.

Standard exports support broad cost analysis; detailed exports add resource-level information where supported. Choose the export type based on the reporting requirement.

If different teams must see different accounts, use separate datasets or appropriately configured authorized views and row-level controls. A dashboard filter alone should not serve as an access boundary.

8. Control Looker Studio Report Access and Data Credentials

Looker Studio report sharing and underlying BigQuery access are separate controls. Looker Studio and Looker are also distinct products; this section concerns Looker Studio dashboards.

For reports, assign ownership, editing, and viewing access according to responsibility:

Access Recommended audience
Owner Accountable report maintainer
Editor Approved dashboard developers
Viewer Finance, management, and business stakeholders

Then choose the data credential model deliberately:

Credential model How data access works
Owner’s credentials Queries use the data-source owner’s access; viewers may not need their own dataset access
Viewer’s credentials Each viewer needs their own access to the underlying data
Service account credentials Queries use a dedicated non-human identity

Owner’s credentials make report sharing a sensitive decision because recipients can see data through the owner’s permissions. Viewer’s credentials suit scenarios requiring individual data authorization. A dedicated service account can support centrally managed reporting where the connector supports it.

Restrict report sharing to approved corporate groups and give the reporting identity access only to the curated data it needs.

9. Understand Dimensions, Breakdown Dimensions, and Metrics

A useful dashboard separates what is being measured from how it is grouped.

Concept Meaning Billing example
Dimension Category used to group data Project, service, region, month
Metric Numeric measure Cost, credits, net cost
Breakdown dimension Additional grouping displayed within a chart Daily cost split by service
Drill-down dimensions Ordered levels for exploring detail Billing account → project → service → SKU

For example, a daily cost chart can use date as its primary dimension, net cost as its metric, and service as its breakdown dimension. Separate series show how services contribute to the total.

A drill-down hierarchy lets a viewer move from account-level spending to project, service, and SKU detail. Choose levels that answer increasingly specific business questions.

10. Partition and Cluster Reporting Tables

Partitioning divides a table into logical segments. Queries with suitable partition filters can scan only the relevant segments.

For a curated daily cost table, a useful starting point is:

  • Partition by usage date.
  • Cluster by frequently filtered fields, such as billing account, project, and service.
  • Require partition filters where appropriate.

Clustering organizes storage blocks around selected columns and enables block pruning. It is different from creating a conventional database clustered index. Column order and actual query patterns matter.

Inspect the existing partitioning of Google-managed export tables. Apply custom layouts primarily to reporting tables you maintain, rather than modifying the export structure indiscriminately.

11. Take Advantage of Columnar Storage

BigQuery already stores native table data in a columnar format. The practical optimization is to query only the columns needed.

Avoid SELECT * when a report needs only date, project, service, cost, and credits. Adding LIMIT does not necessarily reduce the amount scanned.

Nested and repeated fields can also be useful, but handle them carefully. Billing credits are a common example: directly flattening repeated credits can duplicate the parent cost across rows and overstate totals. Aggregate credits per billing row before aggregating overall costs.

12. Choose Storage Location and Billing Model Deliberately

Do not assume regional BigQuery storage is always cheaper than multi-regional storage. Compare current pricing for the relevant location and storage billing model.

Location decisions should consider residency requirements, supported billing export locations, query workloads, and data movement.

A BigQuery multi-region location does not automatically provide cross-region replication or regional redundancy. Evaluate replication or disaster-recovery capabilities separately if those are required.

BigQuery supports logical and physical storage billing. Compare actual compression and retention behavior before choosing a model. Apply expiration policies to temporary datasets and intermediate tables where appropriate.

13. Control Query Processing Costs

BigQuery supports two main compute pricing approaches:

  • On-demand: charges primarily depend on bytes processed.
  • Capacity-based: charges depend on compute capacity under the selected configuration.

For on-demand workloads, use dry runs and query estimates, maximum bytes billed, appropriate query quotas, and partition filters.

For dashboard workloads, pre-aggregate commonly requested results and set refresh schedules according to business needs. A monthly executive report rarely needs continuous refreshes.

Monitor expensive jobs through INFORMATION_SCHEMA.JOBS* and review repeated full-table scans.

14. Use Cached Query Results Where Eligible

BigQuery can reuse eligible cached query results. Queries served from the result cache do not incur query processing charges.

However, caching is conditional. Changes to source tables, query text, or certain query features can prevent reuse. Billing exports receive updates throughout the day, so repeated dashboard requests should not be assumed to produce cache hits.

Check the query job’s cache-hit information rather than treating caching as a guaranteed cost reduction.

15. Evaluate Reservations and Query Queues

Reservations allocate BigQuery compute capacity to workloads. They can improve workload isolation and make capacity management more predictable.

They do not guarantee a fixed savings percentage. Compare on-demand spending against expected capacity costs, utilization, autoscaling behavior, and any commitment terms. A small billing dashboard may be economical on demand; a heavily used enterprise analytics platform may benefit from reservations.

BigQuery query queues manage concurrency by allowing excess queries to wait for execution capacity. BigQuery determines concurrency dynamically, and supported reservation configurations allow additional controls.

Queues help manage contention; they do not independently reduce scanned data or eliminate capacity charges. Monitor queue time alongside query duration so that cost decisions also account for the user experience.

A successful billing analytics platform gives finance and engineering teams trusted cost visibility while keeping identity, data access, reporting authority, and analytics spending under explicit control.