Cloud Cost Is an Architecture Problem, Not a Finance Problem

Personal content — not employer-related. This article is published in a personal capacity and shares thoughts and experiences based on public industry patterns — not a description of employer or client systems, and not professional instructions. It does not reflect the views, systems, projects, or policies of any current or past employer, client, or financial institution. See the full site disclaimer.

Finance sees the invoice. Architecture creates it. The durable cost improvements I saw did not come from better spreadsheets - they came from changing how data was partitioned, scheduled, and consumed.

Context: By early 2021, accelerated cloud adoption had left many organizations with bills that finance could not explain by product or domain. Cost-management tools improved visibility, but visibility alone did not create sustainable savings. Pipelines, warehouses, retention policies, and scaling behavior still had to change.

Why finance-only FinOps stalls

Monthly reviews can flag anomalies, allocate spend roughly, and enforce budgets after the fact. They cannot fix a nightly job that scans 200 TB because nobody added a partition filter. They cannot merge three duplicate pipelines owned by three teams. They cannot decide that a daily decision does not need an hourly job.

Those are architecture decisions with a cost attached.

Where the money usually goes in data platforms

Cloud data cost levers diagram

Driver	Lever that actually moved the number
Warehouse scan volume	Partitioning, clustering, serving tables
Job frequency	Match schedule to how fresh the decision needs to be
Storage growth	Retention, compaction, lifecycle
Orchestration fan-out	Fewer duplicate extracts, cleaner DAGs
Over-provisioned compute	Right-size; scale on p95, not on peak panic
Egress / cross-region	Locality by design

Practical example - cap a BigQuery job at 10 GB from the command line:

bq query \
  --use_legacy_sql=false \
  --maximum_bytes_billed=10000000000 \
  --parameter='start:DATE:2021-03-01' \
  --parameter='end:DATE:2021-03-31' \
  'SELECT *
   FROM `curated.fact_events`
   WHERE event_date BETWEEN @start AND @end'

What I started putting into architecture reviews

Expected bytes scanned per run - estimate before deployment
Cost-to-serve per domain - attribute pipelines to a product or business unit
Freshness versus schedule - hourly processing for a daily decision is waste
Materialize versus recompute - calculate repeated heavy joins once
Decommission plan - parallel legacy and cloud systems double spend

Engineers should see cost estimates the way they see latency estimates.

Guardrails that stuck

Architecture alone is not enough. We also needed:

Per-query byte caps on production service accounts
Budget alerts at 50%, 90%, and 100%, with domain tags
Terraform limits on expensive resource types
Reservations for steady baseline after right-sizing

Guardrails stop the bleeding. Redesign stops the wound.

Habits that helped without turning into blame

Show teams the marginal cost of a new pipeline. Celebrate deletion and retention wins, not only launches. Pair FinOps practitioners with platform architects each month. Put cost next to freshness SLOs on the same dashboards.

Finance owns the budget. Engineering owns the shape of the spend.

Closing

Cloud cost is an architecture problem because scan patterns, schedules, layers, and retention are design choices - not billing surprises. Architecture has to move first. FinOps keeps it honest.