Azure Cost Calculator

Workflow

1. Identify the resource type(s) the user wants to estimate
2. Locate the service reference: a. File search — search for files matching

   references/services/**/*<keyword>*.md

   (e.g., "Cosmos DB" →

   services/**/cosmos*.md

   ) b. Category browse — if search returns 0 or ambiguous results, read the category index in references/shared.md and list the matching category directory c. Broad search — list or search

   references/services/**/*.md

   to see all available files d. Discovery — if no file exists, use

   scripts/Explore-AzurePricing.ps1

   to find the service in the API
3. Read only the matching service file(s) for query parameters, cost formula, and the exact

   serviceName

4. Run

   scripts/Get-AzurePricing.ps1

   with the parameters from the service reference
5. Present the estimate with breakdown: unit price, multiplier, monthly cost, assumptions

Reference Index (load on demand)

Critical Rules

1. Never guess prices — always run the script against the live API
2. Filter values are case-sensitive — use exact values from the service reference file
3. Infer currency and region from user context — if unspecified, ask the user or default to USD and eastus. The API supports all major currencies (USD, AUD, EUR, GBP, JPY, CAD, INR, etc.) via the

   -Currency

   parameter.
4. State assumptions — always declare: region, OS, commitment type, instance count
5. Ask before assuming — if a required parameter is ambiguous or missing (tier, SKU, quantity, currency, node count, traffic volume), stop and ask the user before proceeding. Do not silently pick a default. The only exceptions are constants defined in service reference files (e.g., mandatory default CU counts) — those are pre-approved defaults.
6. Default output format is Json — do not use Summary (invisible to agents)
7. Lazy-load service references — only read files from

   references/services/

   that are directly required by the user's query. Never bulk-read all service files. Use the file-search workflow (Step 2) to locate the specific file(s). If the user asks about App Service and SQL Database, search for each and read only those files — not the other 20+.
8. Use

   pwsh -File

   , not

   pwsh -Command

   — on Linux/macOS, bash strips OData quotes from inline commands. Always use

   pwsh -File scripts/Get-AzurePricing.ps1 ...

   .

Universal Traps

1. serviceName

   and all filter values are case-sensitive — always use exact values from the service reference file. Never guess from portal/docs names.
2. Unfiltered queries return mixed SKU variants — without

   productName

   /

   skuName

   filters, results mix Spot, Low Priority, and OS variants. Always filter to the specific variant needed.
3. Multi-meter resources need separate queries — many resources have multiple cost components (compute + storage, fixed + variable). Run one query per meter with

   -MeterName

   .

4. Write-Host

   output is invisible to agents — always use

   -OutputFormat Json

   (the default). Never use

   Summary

   format.

Batch Estimation Mode

1. Partial reads — read only lines 1–45 of each service file. These lines contain: YAML front matter, primary cost description, trap warning, and the first (most common) query pattern.
2. Full read triggers — only read the full service file if:
   • The partial read does not contain a usable query pattern
   • The user requests a non-default tier, SKU, or configuration
   • The service has complex multi-meter billing that needs the full meter table
   • The query returns 0 or unexpected results
3. Parallel queries — run

   Get-AzurePricing.ps1

   calls in parallel where possible. Independent services have no query dependencies.
4. Skip redundant references — do not re-read shared.md or pitfalls.md between services. Read them once at the start.