# Pricing Estimate > Look up Azure retail pricing for a service / SKU / region, compare options across regions or commitment types, estimate workload cost, and optionally retrieve negotiated prices via pricesheet download. WHEN: "how much will it cost", "estimate cost", "compare pricing", "cheapest option", "free tier", "price of", "compare regions", "DTU vs vCore", "negotiated prices", "pricesheet". INVOKES: get_retail_prices, list_dimensions, query_costs, start_pricesheet_download, get_pricesheet_status - Skill: `azure-samples/pricing-estimate` (Agent Skill) - Install (CLI): `npx skillmds@latest add azure-samples/pricing-estimate` - Raw SKILL.md: https://api.skillmd.com/api/skills/azure-samples/pricing-estimate/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: DevOps & Infra - License: MIT - Author: Azure-Samples (https://skillmd.com/u/azure-samples) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/azure-samples/pricing-estimate --- # Cost Estimation & Price Comparison Look up Azure retail pricing for a service / SKU / region, compare options, estimate monthly cost, and optionally retrieve negotiated prices via pricesheet download. > To check what SKUs the user is *allowed* to deploy under Azure Policy before pricing them, hand off to the **cost-guardrails** skill first. ## Step 1: Retail Price Lookup Call `get_retail_prices` with the user's service, SKU, region, and (optionally) `priceType` (`Consumption`, `Reservation`, `SavingsPlan`). For multi-option comparisons, call again with different parameters — regions (eastus vs westeurope), SKUs (Standard_D4s_v5 vs Standard_D4as_v5), or commitment types (Consumption vs Reservation vs SavingsPlan). > Need to discover what's available for a service? Call `list_dimensions` to see filterable options. > **⚠️ Disambiguate the meter.** `get_retail_prices` returns many meters per SKU/region — Linux vs Windows, Consumption vs Reservation (1yr/3yr) vs SavingsPlan, Spot/Low Priority, Dev/Test. Picking the wrong one can be 2–4× off. > > - If multiple meters match, ask the user the minimum disambiguation needed (OS? term? Spot?) or show the candidates in a short table — don't pick one silently. > - Always include `productName`, `skuName`, `armSkuName`, and `type` in the output so the user can verify the row. ## Step 2: Current Spend Baseline *(Optional)* If the user provides a scope, call `query_costs` with timeframe=MonthToDate, groupBy=ServiceName,MeterCategory to anchor estimates against what they actually pay today. ## Step 3: Monthly Estimate Combine unit price × estimated usage to project monthly cost. Show the formula explicitly — e.g., *"$0.192/hr × 730 hr/month = $140.16/month"* — so the user can see what was assumed. > **Reservation and Savings Plan prices have different shapes — handle them separately.** > - A **`Reservation`** row's `retailPrice` is the **purchase price** for the whole term (what you pay to buy the reservation) — e.g. a 1-year D4s v5 at `1038`, a 3-year at `1993` — even though `unitOfMeasure` reads `1 Hour`. Don't multiply these by 730. To compare against a pay-as-you-go *monthly* figure, normalize the term total first: divide a 1-year price by 12 and a 3-year by 36. > - A **`SavingsPlan`** row's `retailPrice` is the **discounted meter rate** — the per-hour price charged against matching usage to draw down your hourly savings-plan commitment. Like the pay-as-you-go rate it's already hourly (×730 for a monthly figure), not a term total. ## Step 4: Pricesheet — Optional Negotiated Comparison Retail prices may not match what the user actually pays under EA / MCA agreements. Offer: > Retail prices may not reflect your organization's negotiated rates. Want me to start a pricesheet download to compare? It's an async operation (typically 1–15 minutes) — I'll need your agreement type and billing scope. If the user says yes: 1. Confirm **agreement type** (`EA` or `MCA_BillingProfile`) and **billing scope** (`/providers/Microsoft.Billing/billingAccounts/{id}` for EA, `…/billingProfiles/{profileId}` for MCA). For EA, also confirm the **billing period** (`yyyyMM`). 2. Call `start_pricesheet_download` → returns `operationStatusUrl`. 3. Poll `get_pricesheet_status`. While `InProgress`, wait `retryAfterSeconds` between checks. On `Succeeded`, present the `downloadUrl` (SAS link, valid ~1 hour). The `downloadUrl` points to a ZIP of CSV files; the MCP server does not fetch it. To build a comparison, download and parse the ZIP yourself from the SAS URL, then offer a side-by-side retail vs negotiated table for the specific SKUs the user asked about. ## Presentation - **Price table** — Service, SKU, region, unit price, unit of measure, price type. - **Comparison matrix** *(if comparing)* — Options side by side. Call out which is cheapest and under what assumption (region, term, agreement). - **Monthly estimate** — `unit price × usage = $/month`, with the assumed usage stated. - **Commitment savings** *(if commitment types were queried)* — PAYG vs Reservation vs Savings Plan with the savings %. Put all three on the same period first (see Step 3): a Reservation is a term purchase price (÷12 or ÷36 for a monthly figure), while a Savings Plan is already an hourly meter rate (×730 for monthly, like PAYG). - **Free tier** — If applicable, the free-tier limit and when charges start. - **Retail vs negotiated** *(if pricesheet was processed)* — Side-by-side with savings %. Flag any SKUs where the negotiated rate is *higher* than retail (rare but possible with outdated agreements). > Prices shown are public retail (pay-as-you-go) unless the pricesheet was processed. Your actual rates may differ under an EA or MCA agreement.