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 see it. You react.

Azure's approach to extended support is different — and 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 12-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 12-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 or Standard at $0.10/cluster/hour 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 of its 14-month standard support window. 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. GCP Cloud SQL for SQL Server charges extended support fees for EOL versions. Azure doesn't, because it removed the choice that creates the problem in the first place. AWS RDS for SQL Server, for the record, doesn't participate in the extended support program at all — AWS extended support covers only open-source engines (MySQL and PostgreSQL).

Databases: this is where Azure drops the courtesy

For Azure Database for PostgreSQL and MySQL, the enrollment model flips completely — and the billing clock is closer than most teams realise.

From August 1, 2026, any instance running PostgreSQL 11, 12, or 13, or MySQL 5.7, incurs paid extended support charges automatically. Enrollment actually happens a month earlier — July 1, 2026 — with a one-month grace period before billing starts. No opt-in. No action required on your part. If the version is affected and the instance is running, the meter starts. And if you're wondering whether you can opt out — the answer, per Microsoft's own documentation, is no. The only exit is upgrading.

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 has now published pricing on the Azure pricing pages, so check there for the current rate. As a reference point, AWS charges $0.10/vCPU/hour for Years 1–2, escalating to $0.20/vCPU/hour in Year 3. If Azure follows a similar 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 GCP. Azure's reservations documentation limits coverage to compute costs, meaning extended support charges follow pay-as-you-go billing regardless of your commitment level.

One more thing worth knowing: PostgreSQL 14 is also in scope, just on a later schedule. Standard support ends December 11, 2026, with extended support billing starting December 12, 2026. If your team thinks it's safe because it skipped ahead to 14, mark that date down now.

One practical note that's easy to miss: stopped servers are not charged. The billing only applies to instances in a running state. If you have dev or staging databases that can be stopped, that's worth doing while you plan the upgrade.

Now here's the counterargument worth acknowledging: sometimes staying on an EOL version is a deliberate business decision. PostgreSQL major version upgrades can break extensions, deprecated configuration parameters, and SQL behaviour differences that take real engineering time to resolve. A risk-weighted 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. July 1 enrollment changes that.

If you haven't audited yet, now is the time

You have until July 1 before enrollment happens, and until August 1 before billing starts. That's more runway than it sounds — major version upgrades take planning, testing, and coordination. Start 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 are on the extended support clock. Start the upgrade conversation now, not in June.

For AKS:

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

Free or Standard tier clusters on versions outside the 12-month community support window 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 August, 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.

August 1 is the billing start. July 1 is when enrollment happens. The time to act is now — not next month when the grace period is already gone.

Nishant is the founder of [CloudYali](https://cloudyali.io), a FinOps platform that surfaces cloud cost anomalies and extended support exposure across AWS, GCP, and Azure — before they show up on your bill.