Cost estimation and finops

Cost Estimation and FinOps

Overview

Cost is an architecture property, not an afterthought invoice. 80% of a system's lifetime cost is locked in at design time: managed vs self-managed, region, HA topology, egress paths, log verbosity. The estimate belongs in the Ground phase, and the resulting document is a review artifact at the Evaluate gate — no architecture should reach Provision without a price tag.

Estimates are ranges, not points. Anyone who gives you a single dollar figure is guessing with false precision. A useful estimate is a scenario band (lean / expected / peak) with stated assumptions and a confidence level, verified against official pricing calculators.

The number that kills you is never the VM price. It's the one you forgot: egress, NAT gateways, log ingestion, cross-AZ traffic, snapshots, support plans. The hidden-cost checklist in Step 4 is the heart of this skill.

TCO = infrastructure bill + operations hours. A €40/month self-managed platform that needs 6 hours a month of your time costs more than a €300/month managed one at any sane hourly rate. Always compare with ops time priced in.

The Floor Rule (the selection criterion for every comparison). Of all the options that pass the floor — integrity (reliability, data durability, recovery), scalability (grows when it must), and security — choose the simplest, then the cheapest. Cost optimization never descends below that floor: a cheaper option that weakens backups, removes required HA, or loosens the security baseline is not a saving, it's a deferred incident with interest. Conversely, anything above the floor that cannot justify its cost gets cut — that is what "as cheap as possible" means in practice.

When to Use

• An architecture has been designed (Ground) and needs a price tag before provisioning
• Comparing providers or service models for a design (managed vs self-managed, hyperscaler vs low-cost)
• Preparing a budget proposal or migration business case
• Reviewing an existing deployment whose bill surprised someone
• Sizing non-production environments (they often cost 50%+ of total spend)

When NOT to use:

• Real-time billing incidents (bill spike right now) → that's diagnosis: check the billing console's cost explorer first, then this skill for the redesign
• Precision quoting for a contract — estimates here are orientation; formal quotes come from official calculators and sales

The Process

Step 1: Build the billable-resource inventory

Take the architecture (from the Mission Brief, the diagram-driven-design component inventory, or a Terraform plan) and enumerate every billable resource — the diagram's boxes plus everything the diagram forgot:

COMPUTE     VMs / nodes / serverless invocations / container instances
DATA        Managed DB (+HA standby), caches, object storage, block volumes, backup storage
NETWORK     Load balancers, NAT gateways, public IPs, egress GB, cross-AZ GB, VPN, DNS zones/queries
EDGE        CDN, WAF, TLS certs (usually free via managed services)
OBSERVE     Log ingestion GB, metric cardinality, trace spans, dashboard/alerts, retention
SECURITY    Secrets (per-secret + per-call), KMS keys/operations, scanning minutes
PLATFORM    K8s control plane, container registry, CI runner minutes, artifact storage
SUPPORT     Support plan tier (AWS Business ≈ 10% of bill!), provider commitments

Rule: if you can't point to the line in the pricing page, assume it's billed. Free is the exception, documented per provider.

Step 2: Understand the pricing model per component

Each component prices differently — misreading the model is the #1 estimation error:

Model	Examples	Trap
Per second/hour running	VMs, nodes, managed DBs	Dev/staging left on 24/7 (168 h/wk vs 40 h/wk = 4.2×)
Per request / invocation	Serverless, LB capacity units	Free at low scale, surprises at viral scale
Per GB stored	Object/block/backup storage	Cheap until retention and growth compound
Per GB transferred	Egress, cross-AZ, NAT processing	The classic bill-killer; inbound usually free, outbound never
Per GB ingested	Logs, traces, metrics	Chatty apps pay more for logs than compute
Per unit-time flat	NAT gateway (~$30+/mo each), LB base fee, K8s control plane, static IPs	Small flat fees × many instances × many envs = death by a thousand cuts
Per secret/key + per call	Secrets managers, KMS	Tiny per-unit, meaningful at scale

See references/cloud-cost-estimation-cheatsheet.md for per-provider pricing models, free tiers, and orientation figures.

Step 3: Price it — three verification channels

Never estimate from memory. Prices change, regions differ, new instance families appear. Use, in order of reliability:

1. Infracost (if Terraform exists — this pack's default): infracost breakdown --path . produces the real number from real code, and infracost diff in a PR shows the cost impact of a change before apply. Wire it into CI as an Evaluate gate.
2. Official calculators: AWS Pricing Calculator, Azure Pricing Calculator, Google Cloud Pricing Calculator — save the shareable estimate link as evidence.
3. Provider pricing pages for low-cost providers (Hetzner, OVHcloud, DigitalOcean, Scaleway) — flat, simple, usually accurate as-is.

Every figure in the final document carries a source (calculator permalink or pricing page URL) and the date checked.

Step 4: Run the hidden-cost checklist

Before trusting any subtotal, answer for each item — present or safely absent?

□ Egress to internet          → priced per GB; the #1 surprise. Estimate monthly GB honestly.
□ NAT gateways                → ~$30+/mo EACH (×AZs, ×envs) + per-GB processing
□ Cross-AZ / inter-region     → per GB each way; chatty microservices multiply it
□ Load balancer base fees     → ~$16–25/mo each + capacity units
□ Public IPv4 addresses       → now billed on major clouds (~$3–4/mo each, incl. attached)
□ Snapshots & backup storage  → grows monotonically; retention policy = cost policy
□ Log/metric/trace ingestion  → instrument generously, pay generously; can exceed compute
□ Secrets & KMS               → per-secret and per-operation fees
□ Registry & artifact storage → images accumulate; lifecycle policies needed
□ CI/CD runner minutes        → private repos' free tiers run out
□ Support plans               → AWS Business ≈ 10% of total spend
□ Non-production environments → running 24/7 costs 4× business-hours-only

Each finding is either added to the estimate or documented as consciously excluded ("no egress beyond 100 GB/mo expected — flagged as assumption").

Step 5: Model scenarios and commitment levers

SCENARIOS (monthly)
  Lean      → minimum viable: smallest sizes, no HA, dev-grade managed services
  Expected  → the design as planned, realistic traffic
  Peak      → growth case: 2–3× traffic, autoscaling ceiling hit briefly

COMMITMENT LEVERS (compute/data plane, per scenario)
  On-demand          → baseline; highest flexibility
  1-yr commitment    → ~30–40% off compute (Savings Plans / Reservations / CUDs)
  3-yr commitment    → ~50–65% off — only for stable, well-understood baseload
  Spot / preemptible → ~60–90% off for interruptible, stateless, batch-tolerant work
  ARM instances      → ~20–40% better price/performance (Graviton, Ampere) where runtime allows
  Rightsizing        → the biggest lever in practice: most VMs run under 15% CPU
  Non-prod scheduling→ nights/weekends off ≈ −65% on those environments' compute

The document shows on-demand numbers with the commitment levers as a table — the decision of when to commit (after 1–2 months of measured reality) is stated explicitly.

Step 6: Produce the Cost Estimate Document

## Cost Estimate: <project> — <date>, prices verified <date>

### Architecture summary
[Components from the Mission Brief / diagram — one line each]

### Monthly estimate — EXPECTED scenario
| Component | Service (example SKU) | Spec | Est. $/mo | Source |
|---|---|---|---|---|
| Compute | 3× mid VM | 2 vCPU/4GB | $___ | [link] |
| Database | managed PG | 2 vCPU/8GB, no HA | $___ | [link] |
| ... |
| **Infra subtotal** | | | **$___** |
| Hidden-cost provisions | egress ~__GB, logs ~__GB, backups | | **$___** |
| **Total (orientation)** | | | **$___–___/mo ($___/yr)** |

### Scenarios
| Scenario | $/mo | Key assumptions |
| Lean | | |
| Expected | | |
| Peak | | |

### Commitment levers
| Lever | Applicable to | Est. saving | When to apply |

### Alternatives compared
| Option | $/mo infra | Ops h/mo | TCO note |
| Hyperscaler managed | | ~1 | |
| Mid-tier (DO/Scaleway) | | ~2 | |
| Low-cost self-managed (Hetzner/OVH) | | ~6 | ops hours × rate = real TCO |

### Assumptions & confidence
- Region, traffic GB, data growth, retention, env count: [stated]
- Confidence: LOW / MEDIUM / HIGH — and what would raise it
- Verification: [calculator permalinks, infracost output attached]

### Optimization levers (ranked for THIS design)
1. ...

The Provider Landscape (and where low-cost fits)

Hyperscalers (AWS / Azure / GCP) — choose when you need managed-service depth, compliance certifications, global footprint, enterprise support, or advanced networking. You pay a premium for not running things yourself.

Mid-tier (DigitalOcean, Scaleway) — choose for small teams wanting some managed services (K8s with free control plane, managed DBs) with flat, predictable pricing and excellent docs, at meaningfully lower cost than hyperscalers.

Low-cost (Hetzner, OVHcloud) — the best raw price/performance in the industry (a 2-vCPU/4GB VPS for ~€4–8/mo, generous included traffic — Hetzner includes ~20 TB egress, which alone can beat a hyperscaler bill). Choose for: learning, portfolios, MVPs, steady predictable workloads, EU data residency, and teams with the skills to self-manage. The trade: fewer managed services — you patch the database, run the backups (see backup-dr-and-capacity), and own the pager. Price that time honestly in the TCO comparison.

Oracle Cloud (OCI) Always Free — the most generous free tier available (ARM Ampere VMs up to 4 OCPU/24 GB, plus 2 small AMD VMs, object storage, and a load balancer — permanently free). Ideal for learning and small always-on services at €0. Ecosystem and UX trail the others; evaluate before committing real workloads.

Orientation estimates for three reference architectures live in references/cloud-cost-estimation-cheatsheet.md.

Rules for Honest Estimation

1. Region declared — prices differ 10–30% by region; pick it before pricing.
2. Every figure sourced and dated — calculator permalink or pricing page URL; "prices verified YYYY-MM-DD" on the document.
3. Orientation, never quotation — present ranges; label the confidence level.
4. Non-production counted separately — it's often half the total; scheduling it off is the cheapest win available.
5. Ops hours in the TCO — self-managed savings are real only if the team's hourly rate × maintenance hours doesn't exceed them.
6. Re-verify after 60–90 days of reality — the first real bill calibrates the model; update the estimate and the assumptions.

Interaction with Other Skills

• cloud-platform-foundations (Ground): sibling. Design decisions are made with their cost visible — managed vs self-managed is evaluated here, with numbers, not vibes.
• diagram-driven-design / interview-me (Define): their component inventory and budget constraints feed Step 1; the estimate's total goes back into the Mission Brief.
• terraform-infrastructure-as-code (Deploy): Infracost runs against the real Terraform — the estimate stops being a spreadsheet and becomes a CI gate.
• backup-dr-and-capacity (Govern): budgets, quotas, and cost reviews operationalize what this skill estimates.
• observability-and-alerting (Observe): retention and ingestion decisions made here directly drive the observability line item.

Common Rationalizations

Rationalization	Reality
"We'll estimate after it's running"	Then the estimate is called a bill, and it's too late to change the architecture that causes it. Estimate at design time, when changes are cheap.
"The VM prices looked cheap"	Compute is rarely the majority of a real bill. Egress, NAT, managed DBs, logs, and support routinely double the naive estimate. Run Step 4.
"Self-hosted is always cheaper"	Only if your time is free. Six ops-hours a month at any professional rate erases most self-managed savings on small setups. Price the hours.
"A single number is fine for the budget"	A single number is a lie with extra confidence. Ranges with stated assumptions survive contact with reality; point estimates don't.
"Spot instances will handle cost"	Spot is for interruptible work. Putting stateful or latency-sensitive paths on spot is a reliability decision disguised as a cost decision.
"Low-cost providers aren't serious"	Hetzner/OVH run serious production across Europe. The honest question is not "serious?" but "who operates what the hyperscaler manages for you?" — price that answer.
"Prices from memory are close enough"	Prices, regions, and instance families change constantly. Source and date every figure, or the document is fiction.

Red Flags

• An estimate with a single dollar figure and no range or assumptions
• No line items for egress, NAT, logs, backups, or support
• Non-production environments missing from the model
• Managed-vs-self-managed compared on infra price only, ops hours ignored
• Figures with no source, no date, no region
• An architecture approved for provision with no cost estimate at all
• First "estimate" being the actual invoice
• Committing to 3-year reservations before a single month of measured usage

Verification

• Every billable resource from the architecture is in the inventory (Step 1 checklist complete)
• Each figure has a source (calculator permalink / pricing page / infracost output) and a verification date
• The hidden-cost checklist ran; each item is priced or explicitly excluded with reason
• Three scenarios presented (lean / expected / peak) with assumptions
• Commitment levers tabulated with a stated "when to commit" policy
• At least one managed-vs-low-cost alternative compared with ops-hours TCO
• Non-production environments priced separately with a scheduling recommendation
• The document's confidence level is stated, with what would raise it
• A re-verification date (~60–90 days post-deploy) is recorded