Azure's extended support "penalty" is quieter than AWS — and that's what makes it dangerous

AWS charges you the moment your RDS instance or EKS cluster slips into extended support. It shows up on your bill. You could see it and plan your response.

Azure's approach to extended support is different. For Kubernetes at least, it's more polite. No surprise invoice. No opt-in trap. But that politeness is exactly what I think makes it genuinely more dangerous in practice.

The landlord who stops fixing the roof

Think of it like a landlord who, instead of raising your rent when the building starts aging, just quietly stops maintaining it. No notice. No extra invoice. You're still paying the same amount, still living there, completely unaware that last month someone patched the window with tape instead of replacing it.

That's AKS on Free or Standard tier. When your cluster's Kubernetes version exits the standard 14-month support window, nothing happens to your bill. The cluster keeps running. You feel fine.

What you don't feel is that the security patches have stopped.

No CVE mitigations. No backports. The window is open and Azure has left the building.

The scary part isn't the scenario itself. It's that nothing in your environment changes to signal it. No alert, no degraded status, no line item on the invoice. Your infrastructure looks identical on Monday morning whether it's fully patched or silently exposed.

The engineering teams who discovered their clusters were on EOL versions during a cost audit, not a security review? That number is higher than it should be.

For Kubernetes, at least, opt-in means you're in control

If you want security patches beyond the 14-month standard window, you move to Premium tier at $0.60/cluster/hour. That's Azure's LTS option. The billing model is clean: more time in extended support, more you pay. Upgrade and get out, it stops. No Year 2 escalation, no tiered multiplier.

And critically, for Kubernetes, this is opt-in. Azure doesn't enroll you automatically. You choose Premium or you stay on Free/Standard and accept the security gap. That's a different trade-off than AWS, where EKS extended support at $0.60/cluster/hour kicks in automatically the moment your version ages out. On AWS, you're opted in by default and have to actively choose to leave. On Azure, you're opted out by default and have to actively choose to pay.

Neither is obviously right. But at least with Azure's model, the decision is yours to make deliberately rather than discover retroactively on a bill.

That courtesy, though, does not extend to managed databases.

Before we get to databases: what's entirely exempt

If you run Azure SQL Database or Azure SQL Managed Instance, none of what follows applies to you. Full stop.

These are versionless PaaS services. Microsoft controls the SQL Server engine version internally and updates it continuously. There's no version for you to pin, no EOL cliff to fall off, no extended support concept that applies. This isn't Azure being generous. It's a different architectural model entirely.

It's worth calling out because it's a genuine cost advantage if you're comparing clouds for SQL Server workloads. AWS RDS for SQL Server and GCP Cloud SQL for SQL Server both charge extended support fees. Azure doesn't, because it removed the choice that creates the problem in the first place.

Databases: this is where Azure drops the courtesy

For Azure Database for PostgreSQL and MySQL, the enrollment model flips completely. And it starts billing on April 1, 2026.

From April 1, 2026, any instance running PostgreSQL 11, 12, or 13, or MySQL 5.7, enters paid extended support automatically. No opt-in. No action required on your part. If the version is affected and the instance is running, the meter starts.

This is the same mechanic AWS used when it launched RDS extended support in early 2024, and it's the one that caused the most bill shock. The charge doesn't announce itself. It just appears.

The billing model is per vCore/hour, consistent with AWS RDS. Microsoft hasn't published exact rates yet, which is frustrating this close to the billing date, but based on what AWS charges ($0.10/vCPU/hour, escalating to $0.20 in Year 3) and what GCP followed with, I'd budget $0.10–0.20/vCPU/hour as a working assumption until Azure publishes the actual number.

If Azure prices it at $0.10/vCPU/hour, which seems the most likely floor, a 16-vCore PostgreSQL 12 instance running continuously adds roughly $14,000/year in surcharges on top of its regular cost. At $0.20, double that. And no, reserved instance discounts don't offset it. Same rule applies on all three clouds.

Now here's the counterargument worth acknowledging: sometimes staying on an EOL version is a deliberate business decision. Kubernetes minor version upgrades can break add-ons, deprecate APIs, require weeks of testing. A risk-weighted engineering team might legitimately decide the upgrade risk outweighs the extended support cost for a quarter or two. That's fine, as long as it's a conscious choice. What I see more often is teams who are on old versions not because they decided to stay, but because nobody tracked the EOL dates. That's the version of this story that ends in either a security incident or a surprise bill.

Building extended support detection into our cost analysis at CloudYali, the Azure database case is the one that surfaced the most overlooked instances. Precisely because there's been no financial signal pushing teams to look. That changes on April 1st.

If you're reading this before April 1st, open a terminal

Run this right now.

# List all Azure DB for PostgreSQL Flexible Server instances and their versions
az postgres flexible-server list \
  --query "[].{name:name, version:version, sku:sku.name, rg:resourceGroup}" \
  --output table

# Same for MySQL
az mysql flexible-server list \
  --query "[].{name:name, version:version, sku:sku.name, rg:resourceGroup}" \
  --output table

If anything comes back showing PostgreSQL 11, 12, or 13, or MySQL 5.7, those instances will start incurring charges on April 1, 2026. You have time to start the upgrade conversation. You don't have time to ignore it.

For AKS:

az aks list \
  --query "[].{name:name, k8sVersion:kubernetesVersion, tier:sku.tier}" \
  --output table

Free or Standard tier clusters on versions older than 14 months from GA are your unpatched security exposure. Premium tier clusters on old versions are your cost exposure. Both need a plan, even if the plan is "we've decided to stay here for 60 days and we've accepted that trade-off."

The final bill

The landlord analogy from the top holds all the way through.

For Kubernetes, Azure is still the absent landlord. Nothing breaks, nothing bills, but the building quietly stops being maintained. For databases starting April 1, Azure is adding a new line item: you can stay in the aging apartment, but now there's a premium for it.

The three clouds have all landed on the same underlying message: version currency has a price now, one way or another. AWS makes you pay money immediately. Azure made you carry security risk first, and is now adding money on top for databases. The difference is no longer about whether you'll pay. It's about what form the cost takes and whether you see it coming.

April 1, 2026 is when the first Azure database extended support bill lands. If you haven't audited yet, that's the only deadline that matters right now.

About the Author

Nishant is the founder of CloudYali, a FinOps platform that surfaces cloud cost anomalies and extended support exposure across AWS, GCP, Azure, AI and Data Cloud Platforms like Databricks, Snowflake, MS Fabric. Before they show up on your bill.