In July I wrote about capacity constraints in Europe and why North Europe is feeling it most. My conclusion then was that we’d be working within those constraints for years, and that customers should plan for them rather than be surprised by them. Within the last week, Microsoft have added some weight to this and put some key dates into the calendar that customers need to be aware of.
There are really three separate changes bundled together: a new lifecycle model for VM series, a price increase for older VM generations, and regional price increases for select VMs and storage. They overlap in ways that are easy to confuse, so I’ll take them one at a time.
1. A new VM lifecycle model
Microsoft now groups Azure VM series into three lifecycle stages:
- Current: v6 and v7 series
- Extended: v4 and v5 series
- End of life: v1 to v3 series
The first hard date attached to this is the recently announced retirement of the Dv3, Dsv3, Ev3 and Esv3 series on 15 November 2029. After that date they will be retired and customers will need to move to supported VM series. That’s three years away, but as always something you want to get ahead of and not leave to the last minute. What we are seeing more and more of in Azure is that there are several benefits to moving up to newer VM families or off IaaS completely where possible. This will become more apparent throughout this post.
There’s also some welcome news. Microsoft has lifted the capacity growth restrictions that were in place on v4 VMs. This is essentially a reversal on the decision to no longer allow quota increases (where capacity is available) for this series. That seemed like a strange decision to me at the time and I was wondering whether it meant the v4 series was going to also be announced for retirement in the next 6 to 12 months. It may yet be, but for now it’s considered as part of the ‘extended’ lifecycle model.
2. A 25% price increase for v1 and v2 series Virtual Machines
From 1 February 2027, prices for v1 and v2 VMs rise by 25%. The announcement says this applies to pay-as-you-go, Enterprise Agreement and Microsoft Customer Agreement rates. This is a global price increase across all Azure Cloud regions. Most of the v2 series are due to retire on 1st May 2028 anyway, so you should already be well underway in your planning to get off these series by now. This is Microsoft’s move to accelerate this process as many customers still have a lot of v2 VMs allocated to compute resources today. Primarily, these will be NVA appliances and database servers from my experience.
3. Regional price increases for select Virtual Machines and storage
Separately, also from 1 February 2027, prices for most other VM series and select Azure Storage services rise by between 8% and 17% in seven Azure regions:
- North Europe (Ireland): 17%
- France Central: 11%
- France South: 11%
- West Europe (Netherlands): 9%
- Norway East: 9%
- Norway West: 9%
- Southeast Asia (Singapore): 8%
Microsoft’s stated rationale is to improve consistency in pricing across regions, to reflect market conditions in each region, and to support continued investment in capacity and hardware. Historically, North Europe has been one of the largest and cheapest Azure regions for compute workloads, which is a big part of why it became the default for so many Irish and EU customers. So some of this is likely a move towards the global consistency Microsoft describe.
However, there are two sides to this. If you read my previous post, you will note I mentioned the big challenges we are facing in Ireland with our local North Europe region with regard to data centre builds and power supply. This is reflected here, as North Europe will see the largest increase of the seven affected regions. My view is that supply and demand is likely a significant factor here, as the North Europe region continues to face power and capacity constraints. This will have a significant impact on Irish customers who are primarily hosted in this region.
Microsoft list the following VM series as excluded from the regional increase:
- v1: Bv1, D, Ds, F, Fs, G, Gs, L, NP, HC
- v2: Av2, Amv2, Dv2, Dsv2, Fsv2, Lsv2
- v7 (Intel): Dsv7, Ddsv7, Dlsv7, Dldsv7, Esv7, Edsv7
The v1/v2 listing just means they are instead impacted by the higher 25% global cost increase previously mentioned rather than a combined increase of global + regional. On the v7 series, it’s important to note that the excluded sizes are the Intel ones. At the time of writing, these v7 families are currently only available in Sweden Central and Germany West Central within the EU, so for most customers in North Europe or West Europe there’s no excluded v7 option to move to today. Check the Azure products by region page for the current picture, as this will change.
Storage is trickier to understand as Microsoft have listed storage types rather than specific product SKUs. The notice names the following Azure Storage services as not part of the price update:
- Azure Container Storage
- Azure Managed Lustre
- Blob Features
- Change Feed
- General Block Blob
- Import/Export
- Queues
- Queues v2
- Standard Page Blob
- Storage Actions
- Storage Bandwidth
- Storage Discovery
- Tables
- Transaction Optimized SKU
- Azure NetApp Files: Cross Region Replication
Anything that isn’t on that list isn’t automatically confirmed as in scope for an increase, because the notice only says “select” storage services will increase. One thing that I don’t see on the exclusion list is Managed Disks. Microsoft hasn’t said either way whether Managed Disks are in scope or not, but hopefully this will get confirmed soon. If Managed Disks are in scope, then a 17% increase across both compute and storage would be a considerable blow for Irish customers, particularly those who are legally or contractually required to keep data in-country.
Do reservations and savings plans protect you?
The obvious question for anyone with existing Azure commitments is whether they protect against any of this. Microsoft’s notice tells you to compare the new regional pricing with your reservations, but it doesn’t say how existing reservations or savings plans are treated. From Microsoft’s documentation, the two work differently: a reservation is bought at a price that stays fixed for its term, while a savings plan is a fixed hourly commitment that buys whatever the current rate is. That difference matters a lot from 1 February, and the reservation exchange policy changes on the same day, so there’s a timing angle as well.
Reservations
A reservation is bought at a fixed price for a one or three-year term, set by the VM SKU, region and term you choose. The logic here would be to purchase or exchange reservations prior to 1 February 2027, which should lock in the current price for another 1 or 3 years. A few important notes here. Reservations are already blocked for anything older than v4 series, so you will need to be on a v4 series at least to purchase a corresponding VM reservation. Secondly, Microsoft have also announced a change to the reservation exchange policy commencing coincidentally on 1 February 2027. This prevents exchanges of reservations bought on or after that date for services (including VMs) that are covered by Compute Savings Plans, while reservations bought before it keep one final exchange operation. In other words, for workloads that are staying put, get your reservations in place prior to this date.
Savings plans
Savings plans are different, and this is where people may get caught out. Microsoft’s documentation says savings plan prices can change in the same way as pay-as-you-go prices, and that current savings plan pricing is used when applying the benefit, regardless of when the plan was bought. The hourly commitment is fixed, but the rate it buys isn’t. If the savings plan rates for affected meters rise on 1 February, the same hourly commitment covers fewer hours and the rest is billed at the higher pay-as-you-go rate. In other words, these don’t protect you against cost increases but are still a valid way to obtain discounted costs for flexible compute workloads.
Alternative regions
If the way out of the regional increase is to change region, the obvious question is: where? Sweden Central and Germany West Central aren’t among the seven affected regions, and they’re also the only EU regions where the Intel v7 sizes that are excluded from the increase are available today. As I said in my last post, Sweden Central also had full capacity across all three availability zones and as of the time of writing this post it was still being recommended by Microsoft to customers along with Italy North. Capacity and availability will always vary by size, zone and region so where possible try to verify capacity availability for the specific sizes you need in your target region with Microsoft.
There are some challenges to think about before anyone moves:
- Data residency. This will vary greatly depending on where you are based in the world. For EU customers, generally any EU regions are OK to use but if you have strict compliance or contractual obligations to host data in a specific country then it’s probably time to revisit this and look to get allowances to extend this to any EU regions and give yourself some choice and flexibility.
- Latency and network design. Azure networking services make design relatively straightforward in my opinion but you need to make sure you architect this properly and don’t design a solution that has traffic hairpinning between regions. Latency is another matter and this will be workload specific. You may have a situation where you simply have to keep certain workloads closer to home as you are limited by the speed of light here.
- Data transfer. Moving data costs money, and so does traffic between regions afterwards. Smart planning will limit this but not prevent it in a multi-region design.
- DR and region pairing. The concept of paired regions matters less than it used to. Many newer regions aren’t paired, and Microsoft’s own guidance is not to rely on managed failover between pairs. Customers will likely be spread across two or three regions, and DR has to be considered per workload, on the basis of where it’s placed and where it fails over to.
- Landing zone and quota. Each VM family has a separate quota per region, per subscription. Where constraints exist it can be difficult to near impossible to get quota increases when you desperately need them so plan ahead as much as possible. Make no assumptions when deploying your landing zones. Quotas need to be checked first as otherwise your landing zone may not be ready for any workloads to land into.
- Capacity. If the price rise sends large numbers of customers to Sweden Central, its advantage may not last. I recommended it on the basis of what’s available today and said it could change. That’s my own view, not something Microsoft has said, but it’s a good reason to plan early.
v6 and v7 need a modernisation project
I’m recommending that any new VMs built today should go onto the ‘current’ lifecycle SKUs where supported. This means the v6 and v7 VM series that both run on Azure Boost technology. However, something that is catching a lot of people out is that you can’t simply perform a VM resize operation from a v1-v5 VM series to a v6 or v7 VM series. Moving to v6 or v7 series is a planned upgrade, not a resize, and the main reason is the move from SCSI to NVMe storage controllers.
Microsoft’s modernisation guide lists what changes at the platform level:
- Storage interface. Disks are presented over NVMe, so the OS image must include NVMe support
- Networking. The MANA network adapter needs a current driver and OS support. I covered this in an earlier post on MANA and what it means for your NVAs
- Boot mode. v6 and v7 require Generation 2 (UEFI) and support Trusted Launch
- Image. You need a current Generation 2, NVMe and MANA-ready marketplace or Azure Compute Gallery image
This brings a whole lot of complexity to what most of us are used to in terms of a simple VM resize operation. There are ways to achieve this, and Microsoft provides conversion scripts but the process involves potentially installing NVMe and MANA drivers, converting to a Gen2 Trusted Launch image and converting from SCSI to NVMe. Read here if you want to know what’s involved – Modernize to the v6 and v7 VM series.
If you can’t move (or don’t want to)
Moving region isn’t the right answer for everyone. If you have data residency requirements, latency-sensitive workloads or simply can’t justify the project, you’ll be paying the new rates in North Europe, so the aim becomes reducing what you pay. A few places to start:
- Rightsize first. A smaller VM is cheaper and easier to place, and the increase is a percentage, so every size you drop reduces it. Azure Advisor is a good starting point for oversized VMs
- Turn off what doesn’t need to be on. Dev/test, idle and forgotten VMs are the easiest savings. Schedule shutdowns where you can
- Reserve what’s stable and staying put. As covered above, 3 year commitments give a bigger discount and longer price protection prior to the increase, but be aware of cancellation limits and upcoming change to the exchange policy
- Move up a generation, or off IaaS. Microsoft positions v6 and v7 on better price-performance over previous series, so test whether a smaller size does the job. Bear in mind that moving up a series may still come with an increased cost from next year, but you may get better price-performance, e.g. a D4as_v7 may have similar or better compute performance than a D8s_v3. PaaS services are also a valid consideration where suitable, and they aren’t mentioned in this cost increase notice
Before 1 February 2027
- Inventory your VMs by series and region, deal with v1 and v2 first, as they take the 25%
- List your reservations and savings plans, with end dates and renewal settings
- Decide before the end of January whether to use the unrestricted exchange window to make any reservation exchanges
- Any new VM deployments should go to v6 or v7 only unless not supported by a vendor, e.g. virtual appliance. Otherwise, start planning which VMs in your estate can move to these series with the least effort
Conclusion
None of this should come as a surprise. In July I said the quota and capacity picture in North Europe would stay tight for years, and Microsoft have now put dates and percentages on it. For EU customers, changing region is one way to avoid the regional increase, but it comes with real costs and won’t suit everyone, so it’s an option to weigh, but not a conclusion. If you’re staying, reservations are expected to hold their price if locked in before 1 February 2027, savings plans won’t, and the reservation exchange rules change on the same day as the price increase.
For many existing workloads, moving to v6 or v7 series VMs is a modernisation project rather than a simple resize operation. Start building on these current series today but otherwise identify and plan what can be moved to these series easily rather than assume it’s going to be straightforward.
Whatever you decide, this is more than a price rise. It may be time for that modernisation project you’ve been putting off for years.
Disclaimer: This post reflects my own interpretation of Microsoft’s announcements and documentation as of the publication date. The views expressed are my own and do not represent those of my employer or Microsoft. Pricing, availability, policies and service lifecycles may change, and terms under EA, MCA and CSP agreements may differ. Always refer to Microsoft’s official documentation and your own agreement before making financial, architectural or procurement decisions.
