Price History

Price changes signal market shifts and priority changes inside Microsoft. A price drop usually means increased competition or strategic push for that service. A price increase might indicate demand outpacing capacity or a deliberate pivot away from commoditization. Either way, your cost model becomes stale as soon as the price moves, and your historical estimates are no longer representative.

For teams forecasting three years ahead, a 10% price increase on a core service (e.g., Blob Storage or Functions) might flip a cost-benefit analysis. For teams mid-migration, a competitor service dropping in price might justify rethinking architecture. Price history lets you spot these shifts as they happen, not three months later when the invoice arrives.

Every night at 02:00 UTC, a refresh job queries the Azure Retail Prices API for all meters in UK South, GBP. It compares the fresh prices against the previous day's snapshot. If any meter has moved (gone up, down, or was added/removed), it's recorded as a change.

This means: you'll see changes within 24 hours of Microsoft updating prices. The site doesn't predict or interpolate; it only records actual movements detected during the refresh. If no changes happened overnight, the history is silent until the next movement. This avoids false positives and keeps the change log clean.

Each row in the history table shows:

• Service: Which Azure product (e.g., Storage, Functions, Log Analytics)
• SKU: The specific meter or unit being billed (e.g., "Hot Blob Storage" or "Standard Compute vCore-hours")
• Old / New: The previous and current per-unit price in GBP
• Change: The percentage movement. Positive = price increase; negative = price decrease
• Date: When the change was first detected

A +5% change on a high-volume meter (e.g., Blob Storage retrieval, which a large analytics workload might do terabytes of daily) could swing from a £50/month line item to £52.50. Multiply across multiple meters or services, and a 5% increase across the board is a real budget impact.

Scenario: You run a data pipeline that pulls 5 TB of data from Blob Storage Cool tier every day. Your current annual cost: (5 TB × 30 days × 12 months) × £0.015/GB retrieval rate = ~£27,000/year.

On 15 March, the price history shows "Cool Blob Retrieval" increased from £0.015/GB to £0.016/GB (+6.7%). Your new annual cost: ~£28,800/year. That's £1,800 extra.

You now have four options:

1. Accept the increase and raise your budget
2. Optimize the pipeline: reduce retrieval volume by 10%, landing you under the old effective cost
3. Move to Archive tier (cheaper per GB but has restore costs); recalculate if it's worthwhile given your access pattern
4. Explore a competing service: maybe BigQuery or Databricks is now more competitive than Blob Storage for this workload

You would never have known to consider these options if the price change wasn't visible. That visibility is what price history provides.

1. Identify which services consume that meter. The SKU tells you which service changed, but not which of your workloads are exposed. A Functions price increase affects all your Functions; a specific storage tier increase is narrower.

2. Recalculate affected workload costs. Use the calculator to re-estimate your monthly bill with the new rate. Multiply by your expected annual usage to assess the impact.

3. Weigh alternatives. If the impact is significant (e.g., 10%+ of that service's monthly bill), consider whether another architecture would be cheaper now. High-change scenarios (price increase + low utilization) might be candidates for immediate refactoring.

4. Monitor for reversals. Occasionally prices drop (rare, but it happens). If a service you moved away from drops in price, revisit whether repatriation makes sense.

Regional variance: This page tracks UK South only. Other regions may have different price movements (regions usually move together, but not always).

Discounts and commitments not reflected: Published prices don't account for EA discounts, reserved instances, or commitment plans. A price increase in the published table might be offset by your reservation, or vice versa.

New meters are added, old ones removed: Azure regularly introduces new offerings. If a new meter appears in the history, it's usually a new service or a new SKU variant, not a price change on existing usage.

No prediction: Price history is historical data only. We don't forecast future movements or suggest whether a price increase signals a trend or is a one-off adjustment.