Cost is an architectural concern, not a finance concern. The decisions that determine your cloud bill are made in pull requests touching Terraform files and Kubernetes manifests — weeks before the invoice arrives. By the time finance highlights the line items, the spend has already happened.
Cloud waste consumes 30–50% of cloud budgets. The bulk is not accidental extravagance — it is the accumulated result of architectural decisions made without cost visibility at the time they were made.
1. FinOps Maturity — Where You Actually Are
Most organisations overestimate their maturity by one stage. The diagnostic: can you tell, within five minutes, which team or service generated a specific line item on last month's bill? If not, you're in Crawl regardless of how sophisticated your dashboard looks.
Most organisations see 15–20% waste reduction from showback alone — just making costs visible changes behaviour.
2. Commitment Tiers as Architecture Decisions
The commitment model constrains the operational assumptions your workload can make:
- On-Demand — unpredictable burst, new workloads not yet baselined
- Savings Plans — 20–66% discount, flexible across instance types
- Reserved Instances — 40–72% discount, locked to specific instance family
- Spot/Preemptible — up to 90% discount, two-minute eviction notice
The rule: baseline on on-demand for 2–4 weeks before committing. Savings Plans before Reserved Instances for flexibility.
3. Cost Allocation Tagging
Only 22% of companies have allocated 75%+ of their cloud costs. The gap is almost always a tagging gap.
Four mandatory tags enforced at provisioning time: team, environment, service, cost-centre. Resources without them are rejected at creation — not documented for later.
4. Showback Before Chargeback
Chargeback requires teams to trust the attribution model. That trust requires correct tags, understood allocation logic, and fair shared-cost treatment. None of that exists at the Crawl stage.
Introduce showback first, run it for a full quarter, fix attribution disputes, then move to chargeback.
5. Kubernetes Cost Attribution
When 50 services share a node pool, standard billing reports are useless. OpenCost (CNCF) and Kubecost provide per-pod and per-namespace cost breakdowns based on actual utilisation relative to node cost.
ResourceQuotas are the Kubernetes-native cost governance primitive — apply one to every tenant namespace.
6. Pipeline Cost Gates
The highest-leverage FinOps capability: a cost gate in CI/CD that shows projected cost impact before merge. Infracost analyses Terraform plans and returns a monthly dollar diff in the pull request.
If the projected increase exceeds a threshold, the check fails and the PR cannot merge without explicit override.
7. Guardrails That Block, Not Just Alert
- Instance type restrictions — SCPs/Azure Policy restrict GPU and large families in non-production
- Idle resource cleanup — unattached volumes, orphaned IPs detected and remediated by policy
- Dev environment cost caps — CronJobs scale non-production to zero outside business hours
8. Structural Wastes to Eliminate First
- Egress cost from co-located-on-prem services now crossing AZs
- Overprovisioned node pools with untuned autoscaler scale-down
- Cross-region data transfer not modelled before architecture decisions
- Unused reserved capacity below 70% utilisation
- Storage in standard tiers that should be in lifecycle-managed cold storage
Read the Full Article
This is a summary of the fourth post in the Cloud Architecture series. The full article includes Infracost GitHub Actions workflow, Azure Policy JSON for tag enforcement, Kubernetes ResourceQuota and CronJob manifests, commitment tier decision matrix, and a comprehensive cost architecture checklist:
👉 Cloud Cost Architecture: Engineering FinOps Into the System, Not Onto It — Full Article
The full article includes:
- FinOps Crawl/Walk/Run maturity assessment with next actions per stage
- Commitment tier decision matrix with discount ranges and risk profiles
- Azure Policy JSON for mandatory tag enforcement at provisioning
- Kubernetes ResourceQuota manifest for namespace cost governance
- Infracost GitHub Actions workflow with threshold-based cost gate
- CronJob manifest for non-production scale-to-zero outside business hours
- Structural waste audit across egress, node pools, data transfer, reservations, and storage
- Complete cloud cost architecture checklist (15 items)
Top comments (3)
Strong framing. Cost as a design constraint rather than a monthly cleanup is the right model, and it shows up first in defaults: instance families, log retention, and whether non-prod inherits prod-grade redundancy it never needs. The counterpoint I would add is that architecture-time decisions still drift at runtime, so you need a feedback loop that catches when a service quietly outgrows the assumptions it was designed under. We treat cost like an SLO with an owner and an expected range per service, which keeps the engineer-it-in discipline from decaying once the system is live. How do you handle the retrofit case, where the architecture is already bolted-on and you cannot start clean?
The SLO framing is exactly right — without an owner and an expected range, cost visibility becomes a shared dashboard that everyone reads and nobody acts on.
The drift point is the one most teams underestimate. Architecture-time cost assumptions have a half-life, and it shortens as the service grows. A service designed for 1,000 RPM at a known data transfer profile looks completely different at 50,000 RPM two years later — same architecture, entirely different cost behaviour. Treating cost as an SLO with an expected range is what surfaces that gap before it compounds.
On the retrofit case: you cannot retrofit architecture, but you can retrofit accountability, and that is most of the leverage. Structural waste in bolted-on systems concentrates in predictable places — non-prod running at production-grade redundancy, compute sized for peak that never arrives, log groups on infinite retention, egress patterns nobody modelled. None of these need architectural changes: non-prod scale-down is a CronJob, rightsizing is an autoscaler config, log retention is a policy, egress is topology-aware routing.
The sequencing that works: tag enforcement first, then showback per service, then the cost SLO in the same observability stack as latency and error rate — not in a monthly finance review. When cost is a metric, the engineer who owns the service sees the drift before anyone else does.
What you genuinely cannot retrofit: commitment tier decisions and multi-AZ choices. Those you manage through utilization reviews and natural refresh cycles. Everything else is additive.
Cost is an architectural concern not a finance concern, I've seen this firsthand where a simple misconfigured auto-scaling group led to a $50,000+ surprise bill, the decisions that determine your cloud bill are made by architects and engineers, we reduced our costs by 37% after implementing a cost-aware design, what's the biggest cloud cost surprise you've encountered so far?