Methodology
This page is the estimation standard behind CloudCostKit. It explains how calculator outputs are built, when a model should no longer be trusted, what is intentionally out of scope, and how a fast estimate should be checked against real billing and usage data.
The estimate model behind the site
- Driver first: start with requests, GB transferred, GB-month stored, or hours before pricing detail.
- Boundary first: separate transfer paths, retention paths, request classes, or storage copies before combining rates.
- Scenario based: keep baseline and peak views instead of relying on one blended monthly average.
- Validation required: an estimate becomes more useful only after it is checked against billing or usage data.
What a calculator output means on this site
- It is a planning model: meant to give a directional estimate around the main bill drivers.
- It is not a final quote: providers bill by region, tiering, discounts, rounding, request units, and product-specific rules.
- It is intentionally bounded: pages define what is included and excluded so the user can see where hidden line items might still exist.
On this site, reviewed means the page's visible scope, assumptions, and validation path were checked again against the job the page is supposed to do.
Reviewed does not mean universally safe, complete for every workload, or ready to replace provider-specific review.
When not to trust the estimate yet
- A provider changes pricing tiers, regional rules, or included allowances in a way the current workflow does not reflect.
- The workload gains new boundaries such as replication, cross-region movement, CDN, retention, or add-on services that were not in the original estimate.
- An incident, launch, retry loop, or bot spike changes peak behavior enough to dominate cost.
- The estimate no longer aligns with a recent billing slice after the driver assumptions have been rechecked.
Validation loop before trusting a number
- Write down the primary drivers behind each line item, such as requests, GB, GB-month, or hours.
- Confirm the unit system before pricing: GB versus GiB, per 10k versus per 1M, monthly versus hourly, and similar boundaries.
- Separate baseline behavior from peak or incident behavior instead of averaging everything together.
- Compare the estimate with a real billing slice or usage sample and adjust the drivers before adjusting the rates.
- Keep only the changes that improve alignment with repeatable billing behavior.
What a review-ready estimate package looks like
- Named workload scope: which application, environment, or traffic path the estimate covers.
- Driver sheet: the measurable units behind the number, such as requests, runtime hours, GB transferred, or retention days.
- Boundary notes: what is inside the estimate and what adjacent charges still sit outside it.
- Scenario split: baseline, peak, migration, or incident behavior shown separately instead of blended beyond recognition.
- Validation reference: a bill slice, usage export, or provider unit definition used to sanity-check the model.
- Open questions: discounts, regional changes, burst paths, retries, or add-ons that still need confirmation before sign-off.
If those pieces are missing, the output may still be useful for rough planning, but it is not ready to carry a serious review conversation on its own.
`Last updated` does not mean every provider document changed that day or that the estimate is universally safe in every scenario.
When a model has been pushed past safe use
- The same page is trying to stand in for multiple products, traffic boundaries, or pricing mechanisms that should be estimated separately.
- The final number depends more on hidden discounts, bundled allowances, or contract details than on the visible usage drivers.
- A single average has flattened launch spikes, retries, seasonality, or incident behavior that meaningfully change the bill.
- The missing line items are no longer edge cases and now dominate the total answer.
- The estimate can no longer be reconciled to a recent billing sample without inventing new assumptions after the fact.
When that happens, the right fix is usually to split the workload into cleaner boundaries or move to a deeper provider-specific review, not to keep stretching one simplified calculator.
Stop using a calculator as your main decision tool when the estimate depends more on missing contract terms, hidden bundled allowances, or unmodeled adjacent services than on the page's visible drivers.
Common exclusions that change the answer
- Networking: internet egress, cross-region, cross-AZ, origin-to-CDN, retries, and failover traffic.
- Observability: ingestion, retention, scan or query volume, and burst behavior during incidents.
- Storage: requests, replication, lifecycle copies, early deletion rules, and transfer charges.
- Runtime and managed services: support tiers, monitoring add-ons, backup storage, and adjacent services outside the page scope.
Where this page stops
- Guides explain billing boundaries, traps, and support questions for specific topics.
- Editorial Policy explains how pages qualify for publication, refresh, and correction review.
- About explains what the site is for and what it does not claim to replace.
- Contact is the right place to report a mismatch, weak assumption, or broken workflow.
Data and pricing source policy
Most calculators accept user-provided pricing because rates vary by region, discount model, and product options. Official pricing pages and billing exports remain the source of truth.
- AWS pricing overview: aws.amazon.com/pricing
- Azure pricing overview: azure.microsoft.com/pricing
- Google Cloud pricing overview: cloud.google.com/pricing
Privacy and browser-side handling
Calculator inputs are processed in your browser. Some pages may store values in browser storage so your inputs persist between visits. See Privacy Policy and Cookie Notice.