Cloud Cost Estimator

The Bill That Arrived Three Times Larger Than Planned

A familiar story in FinOps circles: a team scopes a new service using round, easy-to-remember numbers — "4 vCPUs, on-demand, should be about $100 a month" — gets budget approval, and ships it. A month later the invoice arrives well above that number, and the postmortem finds the gap wasn't compute at all: it was data egress to a CDN in a different region, a managed load balancer nobody priced separately, and an SSD volume sized for peak load rather than actual usage. None of those line items were wrong individually — they simply weren't part of the original back-of-envelope number, because nobody added them up before provisioning.

The fix teams adopt afterward is rarely "be more careful" — it's building a habit of pricing the whole shape of a workload, compute plus storage plus load balancer plus egress, before it ships, rather than pricing only the most visible line item and treating everything else as a rounding error.

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.

When Teams Reach for 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