Cost as a design constraint

Generated by Claude through GigAI (karthik446/gigai-learning-center 4c0cb514) on 2026-10-13.

Concept: Cost as a design constraint · also covers Cost efficiency, Cloud infrastructure · Lesson 17 of 31 in System design · version 1

On this page

Cost models and unit economics
Design levers that change cost
FinOps: visibility and accountability
Trading cost against reliability and performance

Cost is a design constraint like latency or availability: every architectural choice has a price, and the right design delivers the required outcome at the lowest sustainable spend. A designer should be able to state what a request, a tenant or a gigabyte costs, which components drive the bill, and what extra reliability would cost. Cloud well-architected frameworks and the FinOps practice give the vocabulary and the operating model.

docAWS Well-Architected cost optimization pillar (docs.aws.amazon.com)
docAzure Well-Architected cost optimization (learn.microsoft.com)
docGoogle Cloud Well-Architected cost optimization (docs.cloud.google.com)

How it is done in practice

Resources are tagged by team, service and environment at creation through infrastructure-as-code policy, so the bill can be allocated without manual work. Each team reviews its spend and unit cost monthly, with budget and anomaly alerts in between, and a central group buys commitment discounts for the measured baseline. Design proposals include a cost estimate with the dominant terms and the alternative considered. Rightsizing and lifecycle recommendations are worked as ordinary backlog items, prioritised by saving against effort and risk.

Technologies

AWS Well-Architected FrameworkAzure Well-Architected FrameworkGoogle Cloud Well-Architected FrameworkFinOps FrameworkAWS Cost ExplorerAWS BudgetsAzure Cost ManagementGoogle Cloud Billing reportsKubecostOpenCost

Diagram

flowchart LR
  I[Inform: tag, allocate, show unit cost] --> O[Optimize: rightsize, commit, tier, remove waste]
  O --> P[Operate: budgets, policies, reviews, automation]
  P --> I
  D[Design review with cost estimate] --> I
  S[Reliability target per component] --> D

flowchart LR
  I[Inform: tag, allocate, show unit cost] --> O[Optimize: rightsize, commit, tier, remove waste]
  O --> P[Operate: budgets, policies, reviews, automation]
  P --> I
  D[Design review with cost estimate] --> I
  S[Reliability target per component] --> D

Subtopics

Cost models and unit economics

Estimating the bill from the design

Build the cost model from the same numbers as the capacity model. Sum compute (instance hours at the planned replica count), storage (gigabytes per month by tier, times replication factor, plus backups), network (especially data leaving a region or the cloud, and cross-zone traffic), and managed service charges per request or per unit of throughput. Then divide by a business unit to get cost per thousand requests, per active user or per tenant. Unit cost is what makes spend comparable over time: total spend rising while unit cost falls is healthy growth, and the reverse signals a design problem.

Finding what dominates

In most systems a few lines account for most of the bill. Common surprises are data transfer between zones or out to the internet, observability data volume, over-retained storage and snapshots, idle non-production environments, and chatty calls to per-request-priced services. Identify the dominant term early, since it tells you where design effort pays back and where optimisation would be wasted.

Design levers that change cost

Match supply to demand

Paying only for what is consumed is a core principle of the cloud cost pillars. Right-size instances from measured utilisation rather than guesses, scale in during quiet periods, and stop non-production environments outside working hours. Choose the pricing model by workload shape: commitment discounts for the steady baseline, on-demand for the variable part, and spare-capacity or spot instances for interruptible, stateless or batch work that tolerates eviction. Serverless and per-request services suit spiky or low volume and become expensive at sustained high throughput, so recheck the choice as load grows.

Data and architecture choices

Storage cost is governed by tiering and lifecycle: move cold data to cheaper classes, set retention and expiry policies, compress, and avoid keeping more replicas than the durability target needs. Keep chatty components in the same zone or region to cut transfer charges, and put a content delivery network or cache in front of expensive origins. Batch and move work to asynchronous processing to smooth peaks and run on cheaper capacity. Prefer managed services where they remove operational labour, since engineer time is part of total cost.

FinOps: visibility and accountability

The practice

FinOps is the operating model in which engineering, finance and product share responsibility for cloud spend. The framework describes three phases that teams iterate through: Inform, which makes cost visible and allocates it to owners; Optimize, which identifies and prioritises savings such as rate commitments and usage reductions; and Operate, which builds the policies, automation and review cadence that keep it working. Allocation depends on consistent tagging or labelling of every resource by team, service and environment, plus a rule for splitting shared platform costs.

What engineers see

Teams receive showback or chargeback reports with their own spend and unit costs, budgets with alerts, and anomaly detection that flags sudden changes. Cost appears on service dashboards beside latency and error rate, and significant design changes include a cost estimate. The aim is not minimum spend but informed trade-offs: a team may choose to spend more for speed or reliability, as long as the choice is explicit and owned.

Trading cost against reliability and performance

Reliability has a price curve

Each additional increment of availability costs considerably more than the last: more redundant capacity, more regions, more engineering time and slower feature delivery. The site reliability engineering view is that a service should be as reliable as its users need and no more, since reliability beyond what users can perceive is waste. Users on a network that is itself less reliable than the service will not notice the difference. Set the availability target from the business value of the extra uptime compared with its cost, then manage against that target with an error budget.

Applying it in a design

Not every component needs the same tier. A checkout path may justify multi-zone active redundancy, while a reporting job can run on interruptible capacity and retry. State the target per component, cost the options, for example single zone, multi-zone and multi-region, and pick the cheapest that meets the target. The same reasoning applies to performance: quantify what lower latency or longer retention is worth before paying for it.

Sources

docAWS Well-Architected cost optimization pillar (docs.aws.amazon.com)
docAzure Well-Architected cost optimization (learn.microsoft.com)
docGoogle Cloud Well-Architected cost optimization (docs.cloud.google.com)
docFinOps Framework (www.finops.org)
bookEmbracing risk (SRE book) (sre.google)