Cloud & DevOps engineering

In depth

Where cloud waste actually hides

The biggest line items on a cloud bill are rarely mistakes anyone made — they are defensible decisions nobody revisited. One of the most common sources of waste is Kubernetes resource requests set generously during an incident and never touched again, leaving clusters running at a fraction of what they reserve. No engineer was wrong at any point; the organization simply had no mechanism for asking whether last year's caution was still this year's requirement.

The same categories are where every audit we run looks first. Compute provisioned for a peak that already passed. Development and staging environments running nights and weekends — often a sizeable annual line on its own. Storage that only ever accumulates: orphaned volumes, snapshot chains nobody prunes, gp2 disks that should have become gp3 years ago. Data transfer nobody modeled, because two chatty services ended up in different availability zones and every request between them is metered. And duplicated databases, because each team provisioned its own replica to be safe.

This is why cloud cost optimization services are engineering work, not procurement. A cost dashboard reports the numbers; it cannot tell you which of them are safe to change. Separating waste from headroom means reading the workload, the incident history, and the traffic pattern behind each line item. Done properly, that reading produces a ranked backlog of opportunities — each with an estimated monthly value, an effort score, and a risk note — which is what lets leadership approve reductions line by line instead of on faith.

FinOps as an engineering practice

Most FinOps programs fail the same way: a reporting layer gets bolted on, a monthly cost meeting appears on calendars, and six months later the bill looks the same — because nobody who provisions infrastructure ever sees a price. The version that works treats cost as an engineering signal, visible in the same places engineers already look and enforced by the same machinery that enforces everything else.

In practice that means four mechanisms. Tagging enforced at provision time, so an untagged resource fails the Terraform plan instead of becoming next quarter's mystery spend. A unit metric both finance and engineering watch — cost per 1,000 transactions for a payments business, cost per active tenant for SaaS — so growth stops hiding waste and waste stops masquerading as growth. Budget alerts routed to the team that owns the spend, in the channel it already reads. And paved-road Terraform modules, so the cheapest sane configuration is also the laziest one to choose.

The honest tradeoff is that the savings curve flattens. The first quarter's wins are mechanical — right-sizing, schedules, storage tiering — and each gain after that is a small architecture project: moving batch work to spot instances with checkpointing, collapsing cross-zone chatter, consolidating databases. Commitment discounts like Savings Plans add further savings, but only once usage has stabilized; buy them first and you lock in the waste at a discount. A practice, unlike a one-off cut, is what holds the line — because the guardrails that enforce it outlive the project instead of leaving with the consultants.

Reliability standards that make on-call sustainable

Cost and reliability get pitched as a tradeoff. In practice they fail together, because both are symptoms of infrastructure nobody fully owns. Our DevOps consulting engagements usually open the reliability work with an alert audit: how many times did a human get paged last month, and how many of those pages required action? The lopsided answer — many pages, few of them actionable — is a pattern the industry knows well, and it is how real incidents get missed: the rotation learns that a page usually means nothing.

The standards we install are unglamorous and specific. Every alert that pages a human maps to a user-facing symptom and links to a runbook; if nobody can write the runbook, it becomes a ticket instead of a page. SLOs are set from what users actually tolerate, and error budgets turn the ship-faster-versus-stabilize argument into arithmetic rather than a standing meeting. Deploys move into business hours, because a rollback you have rehearsed is safer at 2pm with the team present than at midnight with one tired engineer.

Choosing an SLO below 100% is the uncomfortable part, and we say so upfront. A payment path and an internal reporting tool may need different objectives. Choose each target from the business impact, dependencies and cost of meeting it, then measure the actual result. Writing that distinction down is what frees money and attention for the systems where reliability is the product.

The result is measurable in pages per engineer per week, and it is built to hold after we leave, because none of it lives in anyone's head: alert rules and SLOs are versioned in Terraform, runbooks are linked from the alerts themselves, and postmortems produce tracked actions instead of resolutions to be more careful next time.