Cloud Cost Scenario Modeller
A transparent cloud-cost modeller for estimating monthly compute, storage and internet-egress spend. It exposes which assumption contributes most so teams know where better measurements or optimisation will matter.
Who this Lab is for
Designed for
- Cloud and platform engineers
- FinOps practitioners
- Architects comparing infrastructure scenarios
Use it when
- Producing an early architecture cost estimate
- Testing sensitivity to scale or unit-price changes
- Explaining cost drivers during a design review
A complete run, step by step
Set average compute
Enter the average running fleet and a blended hourly rate after commitments and discounts.
Add persistent storage
Include the expected footprint and applicable GB-month rate, including snapshots where relevant.
Estimate billable egress
Use outbound traffic that is actually charged at the correct volume tier.
Test scenarios
Change the least certain assumptions and save reports for the credible low, expected and high cases.
What you will need
Prepare the following information before starting. Use measured evidence where possible; defaults are examples and should not be treated as recommendations.
Average running instances
Monthly average after autoscaling.
Cost per instance-hour
Blended committed and on-demand rate.
Storage
Persistent storage footprint.
Storage cost per GB-month
Include snapshots where relevant.
Internet egress
Billable outbound data.
Egress cost per GB
Use the applicable volume tier.
What the result tells you
Your report includes
- Monthly compute, storage and egress estimates
- Total modelled infrastructure cost
- Identification of the dominant cost driver
How it is determined
The model multiplies each usage quantity by its unit rate and standard monthly time. It then compares component totals to identify the assumption with the greatest direct sensitivity.
Component arithmetic is deterministic, but the model includes only compute, storage and internet egress at user-supplied blended rates.
Model assumptions
- • A month contains 730 billable hours.
- • Entered rates already reflect tiers and discounts.
- • Support, requests, observability, backup, tax and other services are excluded.
Authoritative references
Customer-facing web platform
Situation
A service averages 18 instances, stores 2.4 TB and transfers 1.8 TB to the internet each month.
Result
The model separates compute, storage and egress, allowing the team to see whether commitments, retention changes or delivery architecture deserve deeper analysis.
Use the result with engineering judgement
- Taxes, support plans, request charges and every managed-service fee are not included.
- Provider discounts and tiering must be reflected in the entered unit rates.
- This is an engineering estimate, not a billing forecast or financial commitment.
Questions before you begin
Which currency does the Lab use?
The current model uses pounds sterling. Convert provider pricing consistently before entering rates.
Should I use list price?
Use list price for a conservative early estimate, or a documented blended rate when commitments and discounts are known.
Can I compare two architectures?
Yes. Save a run for each scenario and compare the component totals and dominant cost assumptions.
Cloud Cost Model is under review
This legacy judgement-based Lab has been retired. Existing saved reports remain available, but new execution is disabled.
Open deterministic utilities