FinOps in Action: Building a BigQuery Cost Guardrail in Rust

Discover how to build a stateless Rust reverse-proxy that intercepts BigQuery queries and blocks expensive executions before they happen: the $50 “typo”.

We’ve all been there. A data analyst is exploring a new dataset, or a data scientist is running a quick experiment in a notebook. They write a simple “SELECT ”*, forget to filter by a partition column on a multi-terabyte table, and hit “Execute”.

In BigQuery, where you are billed by the amount of data scanned, that single click can cost hundreds of dollars.

While Google Cloud offers robust “Custom Quotas” that are great for overall project-level budgets, they operate mostly at the macro level. I needed a more granular, proactive approach: something that could intercept a specific query and alert the user before a single cent was spent, without disrupting the rest of the team.

I wanted a Sentinel.

The Concept: Proactive vs. Reactive

The goal was to build a system that could evaluate the financial impact of a query before it actually ran.

Google’s BigQuery API has a hidden gem for this: the “dryRun” flag. When you submit a query with “dryRun: true”, BigQuery doesn’t execute the job. Instead, it returns an estimate of the “totalBytesProcessed” — completely free of charge.

The plan was simple:

1. Build a Reverse Proxy that sits between the client and BigQuery.
2. Intercept the incoming JSON payload.
3. Perform a “Pre-flight” check using the “dryRun” flag.
4. Calculate the cost using the current regional TiB price.
5. If it’s over the limit: block the request.
6. If it’s within budget: forward the original query.

Why Rust?

For a proxy handling analytical traffic, latency is the enemy. I chose Rust (specifically the Axum framework and Tokio runtime) for three reasons:

1. Zero Latency: we are adding an extra hop in the network. Rust’s performance ensure this overhead is measured in milliseconds, not seconds.
2. Memory Safety: handling raw HTTP streams and mutating JSON payloads requires a language that prevents memory leaks and crashes.
3. Minimal Footprint: the final Docker image (based on “debian-slim”) is tiny and starts instantly on Google Cloud Run, allowing us to scale to zero when not in use.

The Architecture: The “Double-Hop” Pattern

The core of the logic lies in how we handle the HTTP stream. The proxy doesn’t just forward bytes; it understands the BigQuery protocol.

1. Zero-Trust Authentication

The Sentinel is stateless. It doesn’t store credentials. It extracts the OAuth2 “Bearer” token from the client’s request and passes it to Google. We delegate all IAM and security enforcement to Google Cloud, ensuring the Sentinel doesn’t become a security liability.

2. Payload Mutation

Using “serde_json”, the proxy clones the incoming request and injects the “dryRun: true” field. This mutated version is sent to the BigQuery endpoint first.

3. The Guardrail Logic

Once BigQuery returns the estimated bytes, the Sentinel applies the cost formula:

If the result exceeds the “BQ_MAX_COST_PER_QUERY” environment variable, the proxy cuts the connection and returns an “HTTP 403 Forbidden” with a detailed JSON explanation of the violation.

Transparent Integration

The best part of this architecture is that it’s invisible to the end user. Most modern data tools allow you to override the API endpoint.

Whether you are using the Python Client Library, dbt, or Looker, you only need to change one line of configuration to point to the Sentinel’s URL instead of “bigquery.googleapis.com”.

The authentication remains the same, the SQL remains the same, but the project’s budget is now protected.

Lessons Learned & FinOps Impact

Building this tool reinforced a key FinOps principle: Shift-Left for Costs. By moving cost awareness from the end-of-month bill to the very second a query is written, we empower teams to be more responsible with cloud resources.

Since implementing this guardrail, we’ve seen a significant reduction in “accidental” expensive queries and, more importantly, an increase in developer awareness regarding partition and clustering optimization.

Open Source

I have open-sourced the BigQuery Cost Sentinel to help other teams gain control over their data spend. If you are struggling with unpredictable BigQuery bills, feel free to check out the repository and let me know your thoughts!

[embed]GitHub - llerandi/bq-cost-sentinel: Queries to BigQuery are sent to a Reverse Proxy to determine… Queries to BigQuery are sent to a Reverse Proxy to determine their cost before being sent, so that they can be allowed…github.com