One of the things that used to slow me down when designing Azure architectures was the pricing question.
You sketch out a solution, choose the services, think through HA, security, networking, and how it will land in Terraform or Bicep, and then someone asks: what does this actually cost?
That is usually where the flow breaks. You alt-tab to the Azure Pricing Calculator, start copying SKU names around, realise the portal name does not quite match the API name, wonder whether the reservation number is hourly or a lump sum, and lose the thread of the design conversation you were just having.
That friction is not huge on its own, but it is enough to push cost conversations later than they should be. Pricing becomes a validation step instead of part of the design process.
That is what I wanted to fix with the azure-pricing skill.
It gives GitHub Copilot live access to Azure pricing through the Azure MCP tool, so you can ask cost questions in plain English and get structured answers back in the same conversation where the architecture is being discussed. No tab switching. No stale figures from memory. No rough estimate dropped into a design doc with a disclaimer nobody reads.
The real value is not just fetching prices. It is making cost part of the engineering flow instead of a separate task someone remembers to do later.
Why this becomes a bigger problem over time
Cost estimation looks manageable when you are designing one service in one repo.
It gets messier across multiple teams, environments, and delivery streams. At that point, “roughly what will this cost?” shows up constantly in architecture reviews, platform decisions, environment design, and even code review when someone changes a service tier or deployment pattern.
The awkward bit is not getting a number. It is getting one you trust while the decision is still being made.
That is where live pricing inside GitHub Copilot becomes useful. It lets cost show up at the right point in the conversation: when someone is choosing Linux or Windows App Service, weighing PAYG against reservation, comparing regions, or estimating a Bicep or Terraform deployment before it lands.
That is where the pricing discussion should happen.
Skills as a way to distribute engineering knowledge
The pricing itself is useful. The platform engineering angle is more interesting.
A skill in .github/skills/ is not just prompt text. It becomes a way of packaging engineering behaviour: which tool GitHub Copilot should call, which defaults to apply, which edge cases matter, and how to turn raw output into something an engineer can actually use.
That matters because anyone can get a one-off pricing lookup working. The harder problem is making it repeatable across teams. Once the second or third repo starts using the same pattern, you do not want every engineer rediscovering the same API quirks from scratch. You want that knowledge versioned, reviewed, and shared like reusable workflows, templates, or internal platform tooling.
That is really what the azure-pricing skill is doing. It is not just exposing an API. It is capturing the practical details that make the API usable in real engineering work.
At that point, .github stops being just a config folder and starts behaving more like a distribution layer for operational knowledge.
How the azure-pricing skill works
The skill uses the Azure pricing MCP tool exposed by the ms-azuretools.vscode-azure-github-copilot VS Code extension. There is no separate mcp.json wiring to maintain here. Once the extension is installed and the tool is enabled, GitHub Copilot can invoke the Azure pricing MCP tool, which queries the Azure Retail Prices API on its behalf.
The tool accepts parameters such as sku, service, region, price-type, currency, and raw OData filter expressions.
In practice, the skill gives GitHub Copilot the structure around that tool. GitHub Copilot passes the relevant parameters to the MCP pricing tool, gets structured pricing rows back, and the skill turns that into something more useful than raw meter data: monthly estimates, annual estimates, reservation comparisons, savings callouts, and pricing tables that fit naturally into a wider architecture discussion.
The skill defaults to GBP on purpose. The underlying pricing source defaults to USD if you do not specify a currency, which is fine until you are in a UK design review and someone has to stop the conversation to ask whether the number is dollars or pounds.
A lot of good platform engineering is just removing those pointless little pauses.
Example outputs from using the skill
The simplest place to start is a single SKU lookup.
You can ask GitHub Copilot:
/azure-pricing How much does a Standard_D4s_v5 cost in UK South?
and get back pay-as-you-go, spot, reservation, and savings plan pricing in one response.
A typical result looks something like this.
Azure Pricing: Standard_D4s_v5 — UK South
| Field | Linux | Windows |
|---|---|---|
| SKU | Standard_D4s_v5 | Standard_D4s_v5 |
| Region | UK South | UK South |
| Price Type | Consumption | Consumption |
| Retail Price | £0.164/hour | £0.300/hour |
| Monthly Estimate | ~£119.72/month (730 hrs) | ~£219.00/month |
| Annual Estimate | ~£1,437/year | ~£2,628/year |
| Currency | GBP | GBP |
Commitment and Spot Options (Linux)
| Option | Price | Saving vs PAYG |
|---|---|---|
| Pay-as-you-go | £0.164/hr | — |
| Spot | £0.0213/hr | ~87% |
| 1-Year Reservation | ~£0.097/hr (£847 total) | ~41% |
| 3-Year Reservation | ~£0.061/hr (£1,595 total) | ~63% |
Reservation prices are lump-sum commitments: £847.46 for 1 year and £1,595.18 for 3 years, divided by 8,760 and 26,280 hours respectively to get the hourly equivalent.
A few useful callouts can sit alongside that output too:
- Windows Dev/Test: £0.164/hr, the same as Linux PAYG, because the Windows licence cost is waived under Dev/Test subscriptions.
- Spot pricing: useful for interruptible workloads only, since Azure can evict capacity with short notice.
- Azure Hybrid Benefit: can reduce Windows VM costs materially if you already hold eligible Windows Server licences.
That is useful on its own, but the more interesting scenarios are where pricing gets folded into engineering work rather than treated as a separate lookup.
One of the most practical uses is against Infrastructure as Code. You can point Copilot at a Terraform, Bicep, or ARM template and ask it to estimate the monthly cost of what is defined there. The skill parses the resources, maps them to the right SKUs where it can, calls the pricing tool per resource, and returns a structured estimate.
Estimate the monthly cost of this Terraform. Flag any consumption-based services where you need more info.
For fixed-price services, that is fairly straightforward. For usage-based services like Functions, Container Apps, or Cosmos DB serverless, the skill deliberately asks follow-up questions. That is by design. Pretending those services can be priced accurately without workload assumptions is how bad estimates get produced.
It is better for GitHub Copilot to ask for invocation volume, RU consumption, or replica runtime than to confidently return a number that falls apart under the first real usage pattern.
Region comparison is another useful case:
Compare the cost of Standard_D4s_v5 across UK South, West Europe, and East US.
That can be enough to show whether the price difference is meaningful or whether latency, residency, or operational preference should carry more weight.
Another practical example
Another useful test was a simple two-tier application in uksouth: App Service plus Azure SQL.
Nothing exotic. Exactly the kind of thing that comes up in delivery teams all the time.
Once the skill started returning live rates inline, the conversation got better immediately. Linux versus Windows App Service was no longer just a theoretical hosting choice. Reservation decisions stopped being hand-wavy. SQL pricing could be surfaced as compute plus storage rather than as a vague “database cost” bucket.
That changes the timing of the decision.
Instead of cost becoming a check at the end, it becomes something you can evaluate alongside service choice, operating model, and deployment pattern. That is where it should have been all along.
The cost-formulas reference
Alongside the skill, I added a references/COST-FORMULAS.md file.
That file documents service-specific calculation patterns that do not fit neatly into a single direct lookup. Blob Storage is the obvious example, where a useful estimate may involve storage, transaction, and egress components rather than one clean price point. SQL Database has the separate compute and storage pattern. Container Apps has per-second billing dimensions. Cosmos DB needs workload assumptions before its pricing becomes meaningful.
It also captures the live-tested gotchas and the clarifying questions the skill should ask before estimating usage-based services.
That matters because once a skill is used by more than one team, the question is no longer “does this work?” It becomes “does it behave consistently enough that people trust it?” The formulas and gotchas are part of that consistency story.
More prompts worth trying
These are the kinds of prompts that work well in practice:
How much does a Standard_D8s_v5 cost in UK South, including spot and reservation options? (GBP)
Compare P1v3, P2v3, and P3v3 App Service plan costs in UK South. Which offers the best value for a team running 2 environments?
Estimate cost for a Container Apps deployment with 3 replicas, 1 vCPU each, 2GB memory, running 8 hours a day on weekdays in UK South.
The prompt quality matters less than having the pricing logic available at the point where the conversation is already happening.
Final thoughts
The most useful part of the azure-pricing skill is not the API integration on its own. It is the way it changes when cost enters the conversation.
Bringing live pricing into GitHub Copilot shifts that left. Cost becomes something you can test alongside each meaningful decision: service tier, OS choice, region, reservation strategy, right-sizing, and non-production versus production assumptions.
That is a better engineering workflow.
And from a platform engineering point of view, the bigger win is that the knowledge does not stay personal. The API quirks, the OData fallback patterns, the currency default, the reservation conversion logic, the service naming oddities, and the workload clarifications for usage-based services now live in the skill and its references rather than in somebody’s head or old notes.
That is the part I care about most. Anyone can get a figure from a calculator. The craft is making the behaviour consistent enough that teams can rely on it without having to think about the plumbing every time.
The azure-pricing skill, along with the references behind it, lives in my github-copilot-agent-skills repo. It is open and designed to improve as more quirks turn up.