DevOps services company: 3 cloud fees that decide your 2026 budget

Summary. Amazon EKS charges $0.10 per cluster per hour on a supported Kubernetes version and $0.60 once that version falls into extended support, a 6x jump of $0.50 per cluster hour, or about $365 per cluster per month. Google Kubernetes Engine charges exactly the same two numbers. On EKS, extended support is enabled by default, so the billing starts on its own the day standard support ends. Kubernetes 1.34 enters maintenance mode on 27 August 2026 and reaches end of life on 27 October 2026, and the community ships a new minor version roughly every four months with 14 months of support. The question a DevOps services company should answer for you is not which tools it likes. It is who owns that calendar.

Most DevOps proposals are a list of tools. The tools are largely commoditised. What separates a cheap engagement from an expensive one is whether someone is tracking a set of published dates, and what happens to your bill when nobody is.

The upgrade treadmill has a published timetable

Kubernetes releases a minor version approximately every four months. Each one gets roughly 14 months of patch support: twelve months as standard, then a two-month maintenance window where Release Managers cut fixes only for CVEs, dependency issues and critical core component problems. After that the branch is end of life and cherry picks close.

Kubernetes version	Enters maintenance mode	End of life
1.33	28 April 2026	28 June 2026
1.34	27 August 2026	27 October 2026
1.35	28 December 2026	28 February 2027
1.36	28 April 2027	28 June 2027

The project maintains release branches for the three most recent minor releases, which as of August 2026 are 1.36, 1.35 and 1.34. If you are on 1.33 you are already past end of life. If you are on 1.34 you have eleven days before maintenance mode and a little over two months before support stops entirely.

There is a second constraint that catches teams mid-upgrade. The version skew policy allows kubelet and kube-proxy to run up to three minor versions behind kube-apiserver, but kube-apiserver itself must not skip minor versions when upgrading, even on a single-instance cluster. A cluster three versions behind cannot jump forward in one move. It has to walk, one minor version at a time, with node drains between each step. That is the work item people underestimate, and it is why "we will catch up next quarter" tends to become a two-quarter project.

What the managed platforms charge you for falling behind

All three major providers now sell you time. The shapes differ enough to matter.

Platform	How long you can stay behind	What it costs
Amazon EKS	14 months standard, then 12 months extended, 26 months total	$0.10 per cluster hour standard, $0.60 extended
Google Kubernetes Engine	Up to 24 months on the Extended release channel	$0.10 per cluster hour standard, $0.60 in the extended period
Azure AKS	12 months community support, then 12 months LTS, about 24 months total	Requires the Premium tier plus the AKSLongTermSupport plan
Upstream Kubernetes	14 months, then nothing	Free, and unpatched afterwards

Three details decide whether this shows up as a surprise on an invoice.

On EKS, extended support is on by default. AWS states that for all new and existing clusters the upgrade policy is set to EXTENDED unless specified otherwise, and that billing for extended support starts at the beginning of the day the version reaches end of standard support. Nobody has to approve anything. EKS 1.33 reached end of standard support on 29 July 2026, so any 1.33 cluster has been billing at the higher rate since then. At $0.50 extra per cluster hour, a fleet of twenty clusters that quietly slips into extended support adds roughly $7,300 a month, or $87,600 a year, with no change in what the clusters actually do.

GKE prices it identically but scopes it differently. The $0.50 per cluster hour surcharge applies to clusters on the Extended release channel once the minor version passes the standard support period, and there is no additional charge for using the Extended channel while still inside standard support. So on GKE the Extended channel is a free option until you actually use it, which makes it a reasonable default. On EKS the default enrolls you in the paid outcome.

AKS routes it through a tier change rather than a line item. Long-term support requires moving the cluster to the Premium tier and explicitly selecting the AKSLongTermSupport plan, and it is a configuration change that does not reimage nodes. Two traps come with it. LTS supports only the two most recent patch versions, so a cluster that drifts off those loses support even while paying for LTS, which is why Microsoft's own guidance pairs it with --auto-upgrade-channel patch. And once a version's community support period has ended, you cannot disable LTS for that version.

The end of the runway is not negotiable on any of them. AWS puts it plainly in the EKS user guide: "Amazon EKS doesn't allow control planes to stay on a version that reached end of extended support." At that point EKS auto-upgrades the control plane, gives no advance notification of the timing, and a cluster upgraded that way cannot be rolled back. In-place upgrades you perform yourself can be rolled back, but only within 7 days.

There is one more asymmetry worth pricing. On EKS, the automatic upgrade covers the control plane only. Managed node groups and self-managed nodes stay where they are, and Fargate pods need a rolling restart to pick up a new kubelet. An unattended cluster does not land on the far side of an upgrade in a working state. It lands half-upgraded.

The CI bill has a rounding rule

The second fee that moves budgets is continuous integration, and the mechanism is not the headline rate.

GitHub rounds the minutes and partial minutes each job uses up to the nearest whole minute. Billing is per job, not per workflow. A matrix of 50 short jobs that each finish in 20 seconds bills as 50 minutes, not the 17 minutes of wall clock they actually consumed. The practical consequence is that shaving seconds off a fast job saves nothing at all, while collapsing many tiny jobs into fewer larger ones saves real money.

The rate spread matters just as much as the rounding:

Runner	Per-minute rate (USD)	Relative to Linux 2-core
Linux 1-core (x64)	$0.002	0.3x
Linux 2-core (x64)	$0.006	1x
Linux 2-core (arm64)	$0.005	0.8x
Windows 2-core (x64)	$0.010	1.7x
macOS 3-core or 4-core	$0.062	10.3x
Linux 96-core	$0.252	42x

A macOS runner costs more than ten times a Linux 2-core runner per minute, and arm64 Linux is cheaper than its x64 equivalent at every size. A test matrix that runs everything on macOS "for consistency" is a costed decision that usually nobody costed. Included minutes cannot be used for larger runners, and larger runners are not free even on public repositories.

We go deeper on the cloud side of this in our cloud FinOps guide for Indian teams and on provider-by-provider comparison in FinOps for AI cloud cost across AWS, Azure and GCP.

The third fee is the one nobody invoices

Runtime deprecation on managed compute is the quiet one, because it produces no bill until it produces an outage or an emergency project.

AWS Lambda deprecated the nodejs20.x runtime on 30 April 2026. It blocks new function creation on 1 February 2027 and blocks updates to existing functions on 3 March 2027, both extended beyond the standard 30-day and 60-day intervals. Functions keep being invoked indefinitely, which is exactly what makes it easy to ignore. AWS is explicit that deprecated runtimes are provided as-is, may contain vulnerabilities, and that responsibility for them transfers to you at the deprecation date.

The same shape applies to add-ons. On AKS, support for the managed Open Service Mesh add-on ends on 30 September 2027, and support for Microsoft Entra pod-managed identity ended in September 2025. These have their own lifecycles independent of the Kubernetes version, so a cluster can be fully supported while a component inside it is not.

Supply chain defaults changed too, and they land in the pipeline rather than the cluster. npm 12 blocks dependency install scripts by default, skipping preinstall, install, postinstall and prepare unless the package is listed in an allowScripts entry, managed with npm approve-scripts. Pipelines that assumed those hooks ran will fail on upgrade, quietly and in a way that looks like a flaky build.

# List dependencies whose install scripts are not yet approved
npm approve-scripts --allow-scripts-pending

For anything you publish, trusted publishing removes long-lived npm tokens from CI entirely, using OIDC from GitHub Actions, GitLab CI or CircleCI. It needs npm CLI 11.5.1 or later and Node.js 22.14.0 or higher, and it generates provenance attestations automatically on GitHub Actions and GitLab. Self-hosted runners are not supported yet.

What to buy, and what to keep in-house

The honest split, based on where the recurring cost actually sits:

Buy the treadmill. Version tracking, upgrade rehearsal, node pool rotation, add-on lifecycle and the deprecation calendar are unglamorous, continuous, and badly suited to a team that also has a product roadmap. This is the work that costs you $0.50 per cluster hour when it lapses.

Buy the initial platform build. Pipelines, infrastructure as code, environment topology, observability and the deployment path are front-loaded and benefit from people who have done it repeatedly.

Keep on-call ownership. Whoever writes the service should carry the pager for it. Outsourcing the pager separates the people who can fix a defect from the people who see it, and that gap shows up as mean time to recovery.

Keep architectural decisions. A partner should cost your options and say which they would pick and why. The decision stays with you, because you carry it for years.

Do not buy a tool list. If a proposal leads with the vendors rather than with your version position and your bill, it has not looked at your estate.

What to ask a DevOps services company

1. What Kubernetes version are we on, and what is its end-of-life date? The answer should be a date, and it should be checked against the upstream patch release page rather than a provider console.
2. Are any of our clusters in extended support right now? On EKS this is the difference between $0.10 and $0.60 per cluster hour, and it happens without anyone opting in.
3. What is the upgrade path, given version skew? The API server cannot skip minor versions, so a cluster three releases behind needs three sequenced upgrades with node drains, not one.
4. Where does our CI spend actually go? Job count and runner class, not workflow duration, because minutes round up per job.
5. Which managed runtimes and add-ons hit a deadline in the next 18 months? Lambda runtimes, AKS add-ons and container base images all have separate calendars.
6. Who carries the pager, and what is the escalation path at 03:00? If the answer is vague, the runbook does not exist.

How we scope DevOps engagements

eCorpIT builds and runs cloud platforms for engineering teams: Kubernetes on AWS, Azure and GCP, infrastructure as code, CI/CD pipelines, observability and cost governance. Founded in 2021 and based in Gurugram, we work as senior-led teams, and we hold CMMI Level 5, MSME and ISO 27001:2022 certifications. We are an AWS, Microsoft and Google partner, which is directly relevant here because the deprecation calendars that drive this work are set by those three.

Our sequence on a DevOps engagement:

1. Position audit. Every cluster's version and its end-of-life date, which clusters are billing at extended-support rates today, runtime and add-on deadlines inside 18 months, and a CI spend breakdown by job count and runner class. The output is a dated list with a rupee and dollar figure attached.
2. Upgrade plan. A sequenced path that respects version skew, with rehearsal in a non-production cluster and a rollback position for each step.
3. Pipeline and IaC work. Reproducible environments, an allowScripts policy enforced in CI, secrets handled through OIDC rather than long-lived tokens.
4. Observability and on-call design. Alerts tied to service level objectives instead of raw resource metrics, with runbooks written by the people who will be woken up.
5. Standing upgrade cadence. A named window each quarter mapped to the published Kubernetes calendar, so the treadmill never becomes a project again.

Engagement runs as a scoped project or a monthly retained platform team. We quote after the audit, because the number of clusters and how far behind they are changes the work by an order of magnitude. Related reading: our Kubernetes 1.35 and containerd 2.0 migration guide, the AWS DevOps Agent build versus buy analysis, and our managed cloud FinOps service.

India-specific considerations

Two things change the arithmetic for Indian teams.

Cluster management fees are flat per cluster per hour and do not vary by region, so the $0.50 extended-support surcharge costs the same in Mumbai or Delhi as in Virginia while the engineering time to avoid it costs less. That ratio favours doing the upgrade work properly rather than buying time, more strongly than it does for a US or EU team paying US or EU salaries. Extended support is a bridge, not a strategy, and it is a worse deal here than elsewhere.

Second, running clusters past end of life sits awkwardly against the reasonable security safeguards expected of a data fiduciary under the Digital Personal Data Protection Act 2023, particularly when the end-of-life date is published more than a year ahead. We design platforms aligned with DPDP requirements and, where a client's obligations call for it, aligned with SOC 2 and ISO 27001 control expectations.

FAQ

How often does Kubernetes release a new version?

The community releases a minor version approximately every four months and supports each for roughly 14 months. That is twelve months of standard patch support followed by a two-month maintenance window covering CVEs, dependency issues and critical core component fixes. After that the release branch reaches end of life and cherry picks close.

What does Kubernetes extended support cost on AWS and Google Cloud?

Both charge $0.10 per cluster per hour on a supported version and $0.60 once the version enters the extended period, a surcharge of $0.50 per cluster hour. That works out to roughly $365 per cluster per month. Amazon EKS enables extended support by default, so billing can begin without anyone opting in.

Which Kubernetes versions are supported in August 2026?

The project maintains release branches for 1.36, 1.35 and 1.34. Version 1.33 reached end of life on 28 June 2026. Version 1.34 enters maintenance mode on 27 August 2026 and reaches end of life on 27 October 2026, so it needs an upgrade plan now rather than in the autumn.

Can I skip Kubernetes versions when upgrading?

Not for the API server. Project policy requires kube-apiserver not to skip minor versions when upgrading, even on single-instance clusters. Nodes have more room: kubelet and kube-proxy may run up to three minor versions behind the API server, though the project warns against sitting there.

What happens if I ignore the end of extended support on EKS?

AWS states it does not allow control planes to stay on a version past end of extended support. It auto-upgrades the control plane with no advance notice of timing, and those clusters cannot be rolled back. The upgrade covers the control plane only, so managed and self-managed nodes stay behind.

Why is my GitHub Actions bill higher than my job durations suggest?

GitHub rounds the minutes and partial minutes of each job up to the nearest whole minute, and bills per job rather than per workflow. A matrix of 50 twenty-second jobs bills 50 minutes. Consolidating many small jobs saves more than optimising the runtime of any single fast one.

Should we outsource on-call along with DevOps?

Splitting the pager from the people who wrote the service separates detection from the ability to fix, which lengthens recovery. A better split is buying the upgrade treadmill, the platform build and the tooling, while keeping on-call ownership and architectural decisions with the engineers who carry them long term.

What should a DevOps engagement produce in the first month?

A dated position audit: every cluster's version and end-of-life date, which clusters are billing at extended-support rates now, managed runtime and add-on deadlines inside 18 months, and CI spend broken down by job count and runner class. Everything after that should be scoped against those numbers.

How eCorpIT can help

We start DevOps engagements with a dated position audit rather than a tool recommendation, because the recurring cost in this work comes from version drift and billing defaults, not from tool choice. Our senior-led teams handle Kubernetes upgrades, pipeline and infrastructure-as-code builds, observability and cost governance across AWS, Azure and GCP, and we hold CMMI Level 5, MSME and ISO 27001:2022 certifications. If you do not currently know which of your clusters are billing at extended-support rates, that is the question worth answering first. Start at /contact-us/.

References

1. Kubernetes patch releases - support period, maintenance mode and end-of-life dates for 1.33 through 1.36.
2. Kubernetes version skew policy - supported skew between components and the no-skipping rule for the API server.
3. Understand the Kubernetes version lifecycle on EKS - standard and extended support, default upgrade policy, auto-upgrade behaviour.
4. Amazon EKS pricing - $0.10 standard and $0.60 extended per cluster hour, with the 26-month worked example.
5. Google Kubernetes Engine pricing - cluster management fee and the $0.50 extended period surcharge.
6. Long-term support for Azure Kubernetes Service versions - Premium tier requirement, patch constraints, add-on lifecycles.
7. Actions runner pricing - per-minute rates and the round-up-per-job rule.
8. Lambda runtimes - runtime deprecation policy and the Node.js 20 block dates.
9. npm approve-scripts - default install-script blocking in npm 12.
10. Trusted publishing for npm packages - OIDC publishing from CI and provenance generation.
11. Node.js Release Working Group schedule - runtime support windows referenced for managed compute planning.

Last updated 16 August 2026.