About CloudCostKit

What this site is for

The site is designed for practical planning work: estimating bills, checking cost drivers, comparing bounded architecture options, and validating whether a number is directionally safe enough to carry into a real budget conversation.

Who this site serves best

• FinOps and finance teams: turn usage signals into budget conversations faster.
• Platform and SRE teams: isolate the real drivers behind networking, compute, storage, and logs.
• Application teams: compare runtime, request, storage, and transfer choices with fewer hidden assumptions.
• Technical buyers: sanity-check pricing structure before deeper procurement work.

How a page earns publication

• It must answer a distinct user question, not just mirror an adjacent keyword.
• It must define clear boundaries, included line items, and common failure patterns.
• It should improve a real workflow such as estimating, comparing, validating, or explaining.
• It should connect to the next useful step, such as a paired calculator, guide, checklist, or policy page.

How the site is maintained

• Calculator pages and guide pages are maintained as connected workflows rather than isolated content pieces.
• High-interest pages are reviewed first when pricing structure, traffic patterns, or user intent changes.
• Similar topics are split by intent so parent pages, comparison pages, and support pages do not collapse into duplicates.
• Corrections, wording problems, broken links, and unclear assumptions are part of normal maintenance, not afterthoughts.

Pages that affect the largest planning decisions are reviewed first: core calculators, high-traffic hub pages, and pages that receive correction reports or show signs that the workflow is no longer carrying its role clearly.

See the Editorial Policy for the publishing and corrections workflow, and Methodology for the estimation standard behind the tools.

How pages get rewritten, merged, or retired

• If two pages start answering the same question, the stronger workflow page keeps the main role and the weaker page is rewritten, merged, or de-emphasized.
• If a narrow page cannot support a distinct estimate, comparison, or validation job, the site favors strengthening the parent page rather than keeping a thin standalone page alive.
• If a calculator or guide no longer reflects safe pricing boundaries, it is revised before it is promoted further in navigation.
• If a page creates confusion without adding decision value, reducing its prominence is considered healthier than preserving page count.

The goal is not to publish the highest number of URLs. The goal is to keep a smaller set of pages that each do a clear job in the estimating workflow.

A page is no longer considered strong enough when it repeats another page's job, hides a key boundary, or keeps causing avoidable user confusion after clarification attempts.

A weak page can stay live for reference and still lose strong placement in navigation, hub recommendations, and suggested next steps.

What the site will not pretend to do

• It is not an official provider pricing page or procurement quote.
• It is not a replacement for billing exports, internal ownership data, or contract-specific discounts.
• It is not a one-click answer for an entire cloud bill without workload boundaries.
• It does not treat a calculator output as trustworthy until boundaries, units, and assumptions are checked.

CloudCostKit does not replace provider billing exports, negotiated contract pricing, procurement review, or financial sign-off.

Source and validation policy

Calculators accept your own pricing because provider rates vary by region, tiering, discounts, and product options. Official provider pricing pages remain the source of truth, and estimates should be validated against billing exports or usage metrics whenever possible.

• AWS: aws.amazon.com/pricing
• Azure: azure.microsoft.com/pricing
• Google Cloud: cloud.google.com/pricing

Contact and corrections

If you find a factual issue, a broken tool path, a weak boundary explanation, or a calculator result that looks directionally wrong, please report it through the Contact page.

Reports about overlap, stale page roles, or pages that feel too thin are useful too. Those reviews help decide whether a page should be expanded, merged into a stronger parent, consolidated, or reduced in prominence.

The reports most likely to trigger visible change are the ones that identify the exact page, the exact weak step, and the exact boundary or interpretation that no longer holds up in a real planning workflow.