FinOps

The first real invoice of BoxOffice's production environment arrives, and it is three times the estimate. Nobody can say why: the costs are spread over forty line items, half of them have names like USE1-NatGateway-Bytes and DataTransfer-Regional-Bytes, and no resource is tagged with the service that created it. In the cloud, every architectural decision is also a purchasing decision — and the bill is the one metric that every executive reads.

FinOps (cloud financial operations) is the practice of bringing financial accountability to the variable spending model of the cloud, so that engineering, finance and business make trade-offs between speed, cost and quality together¹. For a system designer it comes down to three skills: estimate what an architecture will cost, attribute what it actually costs, and optimize without breaking the SLOs².

The FinOps lifecycle

The FinOps Foundation organizes the practice in three phases that repeat continuously¹:

flowchart LR
    inform["Inform<br/>visibility: tags, allocation,<br/>showback, unit costs"] --> optimize["Optimize<br/>rightsizing, commitments,<br/>spot, architecture changes"]
    optimize --> operate["Operate<br/>budgets, anomaly alerts,<br/>policies, reviews"]
    operate --> inform

• Inform — you cannot optimize what you cannot see. Every resource carries tags (project, env, service, team); Kubernetes costs are split by namespace and label using the pods' resource requests (tools such as the CNCF project OpenCost⁴, or Kubecost). The result is showback (teams see their costs) or chargeback (teams are billed internally).
• Optimize — reduce waste (idle and oversized resources) and pay less per unit (commitments, spot, cheaper architectures).
• Operate — budgets with alerts, anomaly detection on daily spend, policies (no untagged resources, no GPU instances in dev), and a monthly cost review next to the SLO review.

Anatomy of a cloud bill

Pricing models

The usual portfolio is commit for the floor, on-demand for the daily wave, spot for the interruptible part — which only works if you know your baseline, i.e., after the Inform phase.

A cost model of BoxOffice

The model below estimates the monthly bill of the production architecture designed in this course. Every number is an assumption you can change — that is the point of a model: it makes the drivers explicit and lets you ask "what if?". Prices are approximate on-demand list prices for AWS us-east-1; confirm them with the provider's calculator before quoting them, and remember that other regions (including sa-east-1, São Paulo) are more expensive.

Total ≈ $5,042/month. The four on-sales add only $43 because the 24 extra nodes exist for 8 hours; keeping them 24/7 'just in case' would add ≈ $3,364/month. At 400,000 tickets per month the platform costs ≈ $0.013 per ticket sold.

Reading the model

• The peak is cheap; the baseline is not. Elastic capacity for the on-sales costs almost nothing because it exists for eight hours. Provisioning for the peak permanently would cost more than the entire rest of the compute bill. This is the economic argument for autoscaling, pre-scaling and waiting rooms (Capacity planning).
• Data services dominate compute. PostgreSQL, Redis and Kafka together cost more than the nodes running nine services. Before adding a fourth data store, ask whether an existing one can do the job.
• Bytes cost more than CPUs. CDN egress and log ingestion are two of the largest lines. Image compression, longer cache lifetimes, sampling debug logs and shorter retention change the bill more than tuning Java.
• Unit economics turns the bill into a business metric: cost per ticket sold (or per 1 000 requests, per active user). A bill that doubles while tickets triple is good news; a bill that grows while tickets are flat is a regression — track it like a performance regression.

Pay per request or pay per hour?

When is FaaS cheaper than always-on containers? The plot compares a function (100 ms per request at 512 MB, behind an HTTP API front door) with a minimum of two small container tasks behind a load balancer, each serving 50 requests per second:

Below roughly ten requests per second on average, paying per request wins — idle containers are pure waste. Above it, the per-request premium accumulates and always-on containers win, more so with commitments. Spiky traffic shifts the picture: what matters is the average, while containers must be sized for the peak (or autoscale). This is why BoxOffice runs the thumbnail generator and webhook receivers as functions and the purchase path as containers.

Optimization levers

The levers below follow the cost-optimization practices of the cloud providers' well-architected frameworks³. Each one saves money and each one, except the last, can hurt an SLO if applied blindly.

Estimating in a system-design interview

Interviewers rarely want dollars, but cost-awareness is a strong signal. A three-step habit is enough:

1. Name the drivers: "Cost is dominated by egress for images (CDN), the data tier, and peak compute."
2. Order of magnitude from your capacity estimate: "30 nodes for 8 hours a month is cheap; 30 nodes for 730 hours is not — so we autoscale and pre-scale."
3. One optimization with its trade-off: "Spot for workers, because they are idempotent and retry; never for the primary database."

How it connects

flowchart LR
    BILL["the bill: compute, managed services,<br/>storage, transfer, fixed items"] --> INF["Inform: tags,<br/>cost by pod requests"]
    INF --> OPT["Optimize: rightsizing,<br/>commitments, spot, ARM"]
    OPT --> OPS["Operate: budgets,<br/>anomalies, monthly review"]
    BASE["baseline vs peak<br/>→ autoscaling, pre-scaling"] --> OPT
    FAAS["per request vs per hour<br/>→ serverless break-even"] --> OPT
    UNIT["unit economics:<br/>cost per ticket sold"] --> OPS
    OPT --> SLO["every lever can hurt an SLO<br/>→ Reliability"]
    OPT --> LT["re-run the load test<br/>→ Performance"]
    BILL --> MAZ["Multi-AZ, second region:<br/>cost that buys availability"]
    BILL --> OBS["observability bill:<br/>cardinality, retention"]

Palette components: sql · cache · kafka (the data tier dominates compute) · cdn (egress) · nat (fixed hourly + per GB processed) · objstore (lifecycle tiers) · logs (ingestion) · serverless · worker (spot candidates) · payment (fees, a business cost). Scenarios: serverless-burst, multi-region (what a second region costs). Continues in: Compute — containers or serverless, Performance — capacity planning, Reliability — disaster recovery, Network & security — the cloud network (NAT gateways), Observability — signals (cardinality), Project — cost report.