The cloud split the cost equation: instead of a one-time capex for server racks, you pay per second of compute, per GB of storage transferred, per million Lambda invocations. The result is that cost is now an engineering-shaped problem — every code change shifts a curve. FinOps (Financial Operations) is the discipline of treating cloud cost with the same rigour as latency or uptime.

This topic is the engineer’s view of cost.

Why Cloud Spend Needs Engineering Discipline

Three properties combine to make cloud cost a uniquely engineering-shaped problem:

1. Cost follows code — every architectural decision (sync vs async, region choice, instance class, caching layer) is a cost decision. Finance cannot fix cost problems caused by code; only engineering can.
2. Cloud credits expire — the engineer’s instinct to over-provision “to be safe” turns into seven-figure spend over a year.
3. The bill arrives late — a costly deploy on Monday is a bill-emailed-on-Friday problem; the operator has almost no live signal.

The answer is the FinOps loop: visibility → predictability → optimisation, applied to spend the way it has long been applied to reliability.

The Unit Economic Metric

The most useful metric is cost per unit of work:

• SaaS API: cost per million requests
• Streaming platform: cost per viewer-hour
• E-commerce: cost per order
• ML inference: cost per inference (or per minute of GPU)

The unit economic lets the team ask, “we want to halve cost per request” instead of the harder-to-act-on “we want to halve cloud spend”. Unit economics surface the actual cost of growth — increasing requests is good if unit costs fall faster than request counts rise.

A service that reports cost-per-unit-of-work in its own dashboards, alongside error rate and p99, is mature FinOps. Most teams have only the first two.

Tagging Strategy as Cost Data

Cloud providers bill by tag — a label applied to every resource. Without tags, you have line items but no place to attribute them. With tags, you have a data engineering problem: every resource gets labelled with team, service, environment, cost_center, version.

The two-tier strategy that scales:

1. Mandatory tier — team, environment, service. Without these three on every resource, the bill is opaque.
2. Optional tier — cost_center, version, feature_flag, customer. Useful for business attribution (which customer causes spend?) and used by finance apps.

Two implementation truths:

• Tag enforcement requires policy as code — AWS Service Control Policies, GCP Org Policies, Azure Policies reject RunInstances calls that omit mandatory tags. Self-attestation by humans fails at scale.
• Tag propagation requires tooling — Cost Explorer / BigQuery Billing Export show spend by tag only if tags are present. Organisations that succeed at FinOps ship tag-defaulting mechanisms (e.g., every EC2 instance inherits the team of its ASG) rather than relying on per-resource annotations.

Cost Levers

Four levers move cloud spend materially:

Right-sizing

The default is over-provisioned because the worst case (tail latency spikes) is visible and front-page; the median case (silent oversizing) is invisible and back-office. Two habits flip this:

• Use observed percentiles, not the maximum — size the instance to its previous-week p95 load, with a known headroom (typically 30%). p100 sizing is a permanent tax.
• Right-size iteratively — choose a candidate size at 1.3× observed p95. Watch for one week. If p99 latency is still inside SLO, continue down. The iteration is the discipline; the stop-point is data-driven.

Committed-Use Discounts

Reserved Instances (AWS), Committed Use Discounts (GCP), Reserved VM Instances (Azure) all play the same role: commit to X hours of compute in exchange for a discount of 30-70% relative to on-demand.

The honest accounting: most steady-state compute is a commitment candidate. The risk is over-commitment: buying 5 years of c5.2xlarge that you’re not using in 2. The discipline:

• Cover 80% of your baseline (the load you’d have if the world took a quiet month).
• Buy shorter commitments first — 1-year commit before 3-year; you learn what you actually need before locking in.
• Convertible commitments let you change instance families between commits, useful when the workload shape evolves.

Spot / Preemptible

Spot instances (AWS), Spot VMs (GCP), Spot (Azure) are cloud capacity at 60–90% discount in exchange for two-minute interrupt notice. The right workloads:

• Stateless, horizontally-scaled workers (CI runners, batch processors, image renderers).
• Bucketable / resumable workloads — small units of work that survive disruption.
• Anything that can tolerate a queue rebuilding from a previous checkpoint (Spark jobs,plet processing).

The wrong workloads: anything that requires long-lived connections to users (database, web tier).

The engineering pattern that unlocks spot at scale: a graceful-termination handler — on the two-minute notification, the workload saves state, finishes in-flight requests, and exits cleanly. The signal comes via instance metadata service; the handler has 120 seconds.

Multi-region and Data Transfer

Data transfer is the silent cost line at scale. Egress between availability zones in the same region is free; cross-region is 1–10× more expensive; cross-cloud is the most expensive of all. The architecture’s choice — synchronous cross-region replication, say — can dominate the cheapest path on the bill.

Two reflexes:

• Trace egress before architecture decisions — calculate the cross-region-transfer cost of a multi-region synchronous write before committing to the architecture. Many synchronous multi-region designs are financially infeasible at scale.
• CDN as a cost lever, not just a latency lever — serving bytes from a CDN edge is cheaper than serving from your origin in many cases, and faster.

FinOps as a Cross-Functional Practice

FinOps is intentionally cross-functional: engineering chooses options, finance approves commits, product prioritises the trade-off. The three archetypes:

The practice lives or dies on the rhythm: a monthly review where the team looks at cost per unit-of-work, chooses a lever, and tracks the change until the next review. A team that only reacts to a big bill six months too late has lost the loop.

Practice Trajectory

1. Compute your biggest service’s cost per unit of work. Compare to last quarter; describe in one sentence what changed.
2. Map every AWS role / GCP service account to a team tag. Identify resources that are tagged ambiguously — those are dark spend.
3. Take one EC2 / VM family of a saturated service and right-size. Pick the size at 1.3 × p95 load; deploy for one week; observe SLOs.
4. Compute the discount yield of committing 95% of one instance family’s steady-state baseline to a 1-year reservation. Identify a team that could pocket the difference; introduce them to finance.
5. Take one batch workload currently on on-demand. Convert to spot with graceful-termination. Compute the cost delta — this is often the whole FinOps pitch.

When It’s the Right Tool