Cloud Cost Estimator

Why the Compute Line Item Is Rarely the Whole Bill

A common and entirely predictable gap in FinOps forecasting comes from pricing only the most visible line item on a workload — compute, expressed as a round number like "4 vCPUs on-demand should be about $100 a month" — and treating everything else as noise too small to bother itemizing. In practice, the charges that don't scale with vCPU count are frequently what push a real invoice well past the number that got budget approval: data egress to a CDN or a different region, a managed load balancer billed separately from the compute behind it, and storage sized for peak load rather than steady-state usage all accumulate quietly because none of them show up if the estimate stopped at the compute rate card.

None of those additional line items are exotic or hidden — they're all published pricing, just spread across separate pages that a compute-only estimate never visits. The habit that actually closes this gap is pricing the full shape of a workload before it ships: compute, storage, load balancer, and estimated egress together, rather than treating the compute number as a stand-in for the total and reconciling the difference after the first invoice arrives.

Why Cloud Pricing Reads Like a Foreign Language

Unlike a fixed price list, cloud compute pricing is a layered structure: a published on-demand hourly rate that varies by instance family, region, and operating system, discounted by commitment mechanisms — AWS Reserved Instances and Savings Plans, Azure Reserved VM Instances, GCP Committed Use Discounts — that can each cut the effective rate by 30–72% depending on term length, plus spot and preemptible pricing that trades availability guarantees for a further 60–90% discount. On top of compute sits a second layer of charges that don't scale with vCPU count at all: per-GB storage rates that differ by disk tier, data egress priced per gigabyte that is dramatically cheaper within a region than across one, and managed-service surcharges, since a managed database or load balancer bills separately from the compute it runs on. None of this is secret — it's all published — but reconciling several separate pricing pages into one number for a single workload is tedious enough that most engineers do it rarely and imprecisely.

Turning Sliders Into a Monthly Number

The estimator applies publicly available list prices for common instance families and storage tiers across AWS, Azure, and GCP. Selecting vCPUs, memory, region, operating system, and commitment type looks up the matching rate table entry, multiplies it by 730 (the average hours in a month), and adds the selected storage and estimated egress line items on top to produce a single monthly total per provider. Toggling the commitment buttons re-runs the same multiplication against a discounted rate rather than the on-demand rate, which is why switching from on-demand to a 3-year reserved commitment or spot pricing changes the result instantly without touching any other input. All of this happens client-side against a rate table baked into the page — no API calls reach any cloud provider, which also means the numbers are a snapshot of list prices at a point in time rather than a live quote.

Common Moments to Run a Cost Estimate

• Architecture decisions: comparing the cost of the same workload across different instance types or cloud providers before committing to a design.
• Budget forecasting: producing a rough monthly figure for an engineering RFC or project proposal when finance asks for an infrastructure estimate.
• Right-sizing reviews: checking whether upgrading or downgrading an instance type is worth the performance trade-off by seeing the cost delta immediately.
• Multi-cloud evaluation: sanity-checking whether a workload currently on one provider would be materially cheaper elsewhere before investing in a full migration assessment.

Frequently Asked Questions