Azure's February 2027 Price Increase: What Is Confirmed, Why Europe Pays Most, and Whether to Make Your Infrastructure Portable

Key points:

• Two separate Azure increases start on 1 February 2027. In-scope VM and storage meters rise 17% in North Europe (Dublin), 11% in France Central and France South, 9% in West Europe (Amsterdam), Norway East and Norway West, and 8% in Southeast Asia (Singapore). Separately, the oldest v1 and v2 VM series rise about 25% in every region.
• The "up to 25%" figure is a global increase on legacy VMs. It applies worldwide to legacy series (Av2, Dv2, Dsv2, Fsv2, Lsv2, D, Ds, F, Fs, G, Gs, Bv1 and others), and those series are excluded from the regional increase, so the two do not stack. Europe is hit hardest because six of the seven regions with a regional increase are European.
• Microsoft announced it through Azure Service Health notices, with no public blog post. The regional percentages, the exclusion lists and the reasons ("changing regional market conditions", standardized rates, data center and hardware investment) come from that notice. Whether existing reservations and savings plans are repriced is not stated in it, so confirm with your Microsoft account team.
• Reservations get less flexible on the same day. Reservations bought on or after 1 February 2027 for services covered by savings plans can no longer be exchanged (Microsoft Learn).
• Portability is the right response when Azure is more than a third of your bill and most of it sits in an affected region. Start with the cheap moves (resize off legacy series, check other regions, re-plan commitments), then make the workload layer cloud-neutral with Kubernetes, Postgres and infrastructure as code. Qovery runs that layer the same way on AKS, EKS, GKE or Scaleway Kapsule in your own account.

Most Azure price stories die in a week. This one lands in the exact regions where European teams put their production workloads, three weeks after the EU Data Act makes leaving a cloud provider cheaper than it has ever been.

I read every primary source I could find, because the headline circulating ("Azure up 25% in Europe") is wrong. The 25% applies worldwide to old VM series. The European increase is 8% to 17%, and the rest of this post covers what Microsoft confirmed, what it costs, and how to decide whether to make your infrastructure portable.

What exactly did Microsoft announce for February 2027?

Microsoft notified customers of two price increases effective 1 February 2027: a regional increase of 8% to 17% on in-scope VM and storage meters in seven regions, and a global increase of about 25% on legacy v1 and v2 VM series. Both came through Azure Service Health notices in early October 2026. There was no public blog post or Learn article.

The notice text has been reproduced on Microsoft's own Q&A forum by a customer asking for clarification, and reported by Techzine on 16 October 2026. Licensing specialists noted there was no public announcement, only information sent to customers and partners (Cloudy with a chance of licensing).

The regional increase, by region:

Sources: Azure Service Health notice as quoted on Microsoft Q&A and Techzine.

According to Techzine, Microsoft attributed the change to "changing regional market conditions, standardized rates across regions, and ongoing investments in data center capacity and new hardware."

What is excluded from the regional increase?

The notice excludes these series and services:

• Legacy v1 series: Bv1, D, Ds, F, Fs, G, Gs, L, NP, HC.
• Legacy v2 series: Av2, Amv2, Dv2, Dsv2, Fsv2, Lsv2 (these get the separate global increase instead).
• New v7 Intel series: Dsv7, Ddsv7, Dlsv7, Dldsv7, Esv7, Edsv7.
• Storage services: Azure Container Storage, Azure Managed Lustre, Azure NetApp Files cross region replication, Blob features, Change Feed, General Block Blob, Import/Export, Queues, Tables, Storage Actions, Storage Bandwidth, Storage Discovery, the Transaction Optimized SKU and Standard Page Blob.

Everything not excluded is in scope. In the Q&A thread, a community answer reads the notice as covering all other VM series, which means the v3, v4, v5 and v6 D and E families that run most production fleets today. Analyses from nOps and Aidan Finn read Managed Disks as in scope too. Microsoft does not state this directly. It is a reading of the exclusion list, so check your own notice.

Is Azure really raising prices by up to 25%, and does that hit Europe hardest?

Partly. The "up to 25%" figure is real, but it applies worldwide to legacy v1 and v2 VM series. The European part of the story is the regional increase of 8% to 17%, and Europe takes the brunt of it because six of the seven affected regions are European.

Two details people keep getting wrong:

1. The two increases do not stack. Legacy v1 and v2 series are on the exclusion list for the regional increase. A Dv2 VM in Dublin pays about 25% more, not 25% plus 17%.
2. v3 is not "legacy" for this purpose. Dv3, Dsv3, Ev3 and Esv3 are not in the v1 or v2 list, so in the seven regions they take the regional increase. They also lose new reservation purchases and renewals after 1 July 2026 and retire on 15 November 2029 (Microsoft Learn, retired VM sizes modernization guide).

The legacy increase follows a retirement schedule Microsoft published long ago. Dv2, Dsv2, D, Ds and Ls retire on 1 May 2028, and Av2, Amv2, Bv1, F, Fs, Fsv2, G, Gs and Lsv2 retire on 15 November 2028. One-year reservations for all of them stopped being available after 1 July 2026 (Microsoft Learn). Charging about 25% more on hardware that retires a year later tells you to move now.

So if you run modern VM series in Dublin, your number is 17%. If you run old Dv2 machines in Frankfurt, your number is about 25%, and a resize to a newer series fixes it.

What is still unconfirmed?

The notice does not say whether existing reservations, savings plans or negotiated Enterprise Agreement and MACC prices are repriced. People asked directly in the Microsoft Q&A thread and got no official answer.

Until your account team says otherwise, I would assume:

• Pay-as-you-go: takes the full increase on 1 February 2027.
• Existing reservations: the reservation price was set when you bought it. Get written confirmation that it holds until the end of the term.
• Savings plans: the commitment is in dollars per hour, so if the underlying meter rate rises, the same commitment covers less usage. Ask how the discounted rate is calculated after 1 February.
• Enterprise Agreement and MCA with price protection: read your contract. Price protection terms differ per agreement.

I would not plan a budget around any answer you only got verbally.

How do the reservation changes on 1 February 2027 make this worse?

They remove your escape hatch. From 1 February 2027, reservations purchased for services that savings plans cover (Azure Virtual Machines, Azure App Service, Azure SQL Database and similar) can no longer be exchanged. Reservations bought before that date keep one final exchange (Microsoft Learn, reservation exchange policy changes).

The details that bite:

• A renewal counts as a new purchase. An auto-renewed reservation that renews after 1 February 2027 is governed by the new terms and is not exchangeable.
• Cancellations stay capped. Total canceled commitment cannot exceed $50,000 USD in a rolling 12-month window per billing profile or enrollment.
• Trade-in to a savings plan stays open. You can always trade a reservation for a savings plan, with no time limit.

Put the two changes together and the timing is awkward. Prices go up in the regions you are in, and on the same day, commitments you buy to soften that increase become harder to move to another region or VM family. A three-year reservation bought in February 2027 is a three-year bet on staying exactly where you are.

How much will the increase actually cost a typical European team?

For most teams, the bill impact is smaller than the headline percentage, because only VMs and some storage are in scope. The exposed share is what matters, and you can calculate it in an afternoon from Azure Cost Management.

As an illustration, take a company spending $60,000 per month on Azure, all in North Europe:

That is about $90,000 a year for a mid-sized European SaaS company, enough to justify a project but not, on its own, a rushed migration.

Run the same table with your own numbers. The two figures to watch are the share of spend on in-scope meters and the share sitting in the seven affected regions.

What can you do before 1 February 2027 without leaving Azure?

Start with the cheap moves. Most teams can claw back a large part of the increase without touching their architecture.

1. Get off v1 and v2 series now. Microsoft's own guide maps Dv2 and Dsv2 to Dsv5, Dsv6 and newer, and Fsv2 to Dlsv6 or Falsv6 (Microsoft Learn). Newer series usually have better price-performance, and you avoid both the 25% and the 2028 retirement.
2. Consider v7 Intel sizes where they fit. Dsv7, Ddsv7, Dlsv7, Dldsv7, Esv7 and Edsv7 are excluded from the regional increase. Check regional capacity and OS support first: Microsoft notes that v6 and newer sizes require NVMe and Generation 2 images.
3. Price the same workload in another European region. Sweden Central and Germany West Central are not on the list. Moving regions has real costs (latency, data residency commitments, re-provisioning), and Techzine reports Azure MVP Aidan Finn's warning that West Europe has had capacity constraints for some time. Treat a region move as a project.
4. Use your last reservation exchange wisely. If you hold reservations bought before 1 February 2027, plan the one final exchange for the size and region you want to run in during 2027 and 2028.
5. Prefer savings plans for anything you might move. They apply across regions and eligible services, and reservations bought after 1 February will not be exchangeable.
6. Audit idle and oversized resources. The Flexera 2026 State of the Cloud report found wasted cloud spend rising to 29%, the first increase in five years. Rightsizing usually beats any price change.

None of this requires a strategy debate. Do it in Q4 2026 regardless of what you decide about portability.

Is it time to make your infrastructure portable across clouds?

Yes, if three things are true: Azure is a large share of your bill, most of that spend sits in one of the seven affected regions, and you expect more changes of this kind. Portability then costs less than the next increase. If Azure is a small line item or your workloads are deeply tied to Azure-only PaaS, fix sizes and regions first and keep portability as a slower, deliberate project.

"Portable" here means you could move a workload to another provider in weeks rather than quarters, at a cost you have measured. It does not require running everything on two clouds at the same time. We wrote a full guide on how to test cloud portability before you actually need to switch, and a separate one on keeping multi-cloud leverage without running two platforms.

Three things make the timing better than usual.

The EU Data Act removes switching charges from 12 January 2027

From 12 January 2027, providers of data processing services can no longer charge switching charges, including data egress charges, for the switching process. Between January 2024 and January 2027 they could only charge reduced, cost-based fees (EU Data Act, Article 29). The rule covers the one-off switching process. Providers can still charge cost-based egress for parallel multi-cloud use (DLA Piper analysis).

Azure already offers free data transfer out to the internet for customers leaving Azure, but only if you cancel all Azure subscriptions associated with your account afterwards, and only for egress of Azure Storage data (Azure update, March 2024). The Data Act is broader and does not depend on the provider's goodwill.

Lock-in sits in the services around your containers

Moving containers between AKS, EKS, GKE and Kapsule is a known problem. Kubernetes is the standard: 82% of container users now run it in production, up from 66% in 2023 (CNCF Annual Cloud Native Survey). The expensive parts are the services wrapped around your containers.

The rule I give teams is that every new service picks the portable column unless the Azure-only option saves real engineering weeks. You do not need to rewrite what you have, only to stop adding new lock-in.

Price changes are no longer rare events

Microsoft also moved local currency pricing for Microsoft Commercial Cloud to one scheduled update per year, every January, starting in fiscal year 2027 (Schneider IT Management summary). That summary names Microsoft 365 and does not itemize Azure, so check with your reseller how it applies to your Azure agreement. Either way, price changes are becoming scheduled events, and a portability plan gives you something to negotiate with when they arrive.

Which response fits your situation?

Pick the row that matches your exposure. Most teams I talk to land on the second or third row.

For the sovereignty angle, we covered whether Microsoft's sovereign private cloud escapes the US CLOUD Act, which matters if you are considering a move within the Microsoft ecosystem instead of out of it.

When is staying fully on Azure the right call?

Staying on Azure is the right call when your exposure is small, your discounts are large, or your product depends on Azure services with no reasonable equivalent. Portability has a cost, and paying it to avoid a 9% increase on a fifth of your bill is bad math.

Stay put, and fix sizes and commitments, if:

• Your negotiated discount beats the increase. A strong Enterprise Agreement or MACC discount may already be worth more than 17% on the exposed share.
• You are deep on Azure-only services. Heavy use of Azure SQL Database features, Cosmos DB, Logic Apps or Entra ID integrations makes moving expensive. Make new services portable and leave old ones alone.
• Your customers are Microsoft shops. Some buyers require Azure, or reward it through marketplace purchasing, and that revenue is worth keeping.
• Your team is small. Two engineers should spend their time shipping product. Fix sizes, use savings plans, and revisit in a year.

Leaving a cloud is a project with real risk. Make sure the savings are bigger than the engineering time you will spend.

How does Qovery make the workload layer portable?

Qovery is an Agentic DevOps platform that deploys and operates your applications on Kubernetes in your own cloud account: AWS, GCP, Azure, Scaleway, or any existing Kubernetes cluster such as AKS, EKS, GKE or Kapsule. Qovery's control plane is separate from your infrastructure, so your workloads and data stay in your account and your bill stays with your cloud provider.

For an Azure price question, that design does three useful things:

• One workflow on every cloud. The same git-push deployments, environment configuration, preview environments per pull request and RBAC work on AKS and on EKS, GKE or Kapsule. Moving a service means redeploying it into a different cluster, with the same pipelines.
• Clone environments into a second cloud to test. Environment cloning lets you stand up a copy of a staging environment on another provider and measure performance and cost before you commit to anything.
• Infrastructure as code from day one. The Qovery Terraform provider, Helm and Terraform/OpenTofu services, and Blueprints for managed cloud services (for example Amazon RDS on AWS) keep the surrounding infrastructure declarative, so adding a target cloud is a configuration change.

Qovery does not move your data for you, and it does not build cross-cloud networking, which you set up with a VPN, Cilium Cluster Mesh, Tailscale or your cloud's interconnect. It removes the work that usually kills portability projects, which is rebuilding deployment, environments and access control for every new cloud.

You can start on the Free plan with one cluster of your own on AKS, then add a second cluster on another cloud when you run your first portability test.

How do I set this up with Qovery from Claude Code or Cursor?

Install the Qovery Agent Skills once, and your coding agent can deploy a service to a cluster in your own cloud account and compare it with what runs on Azure today. Use these commands, in order.

curl -fsSL https://skill.qovery.com/install.sh | bash

# 2. Or install them for the current project only
curl -fsSL https://skill.qovery.com/install.sh | bash -s -- --project

# 3. Add the Qovery MCP Server to Claude Code over OAuth, read-only by default
claude mcp add --transport http qovery https://mcp.qovery.com/mcp --callback-port 4242

# 4. Only if you explicitly want write access (also enable write access in the Qovery Console)
claude mcp add --transport http qovery "https://mcp.qovery.com/mcp?read_write=true" --callback-port 4242

Your agent asks you to approve each install command, and the MCP Server opens an OAuth login in your browser. The skills deploy (qovery-onboard, qovery-deploy, qovery-terraform and others); the MCP Server operates what already exists. Then ask in plain language, for example: "deploy this service to my GCP account with Qovery so I can compare it with the AKS version." Start from the AI agent quickstart or the Claude Code integration.