On this page · 11 sections
- The upgrade calendar has a price tag now
- Serverless has the same calendar, with a harder edge
- What the CNCF data says about how teams are actually structured
- The tooling questions worth asking
- A screen that separates operators from tool users
- On salary data, and why this page does not print a number
- India-specific considerations
- Choosing an engagement shape
- FAQ
- How eCorpIT can help
- References
Summary. Falling behind on infrastructure versions now carries a published price. Amazon EKS charges $0.10 per cluster hour during standard support and $0.60 per cluster hour once a Kubernetes version enters extended support, a six-fold step that works out to roughly $4,380 extra per cluster per year. Google Kubernetes Engine lands on the same $0.60 total, made up of a $0.10 base management fee plus $0.50 for the extended channel. AWS Lambda blocks function updates on Node.js 20 and Python 3.10 from 3 March 2027, having already blocked new function creation on 1 February 2027. Kubernetes supports only its three most recent minor versions, currently 1.34, 1.35 and 1.36, with 1.36 released on 22 April 2026. Meanwhile the CNCF and SlashData Technology Radar published on 24 March 2026 found that just 28% of organisations have a dedicated platform engineering team. That gap between the calendar and the staffing is the whole problem.
The job title is the least useful part of a DevOps hire. "DevOps engineer" covers people who write Terraform, people who run PagerDuty rotations, and people whose entire experience is a managed CI pipeline. What separates them is whether they have ever owned a version upgrade with a billing consequence attached.
The upgrade calendar has a price tag now
Cloud providers used to absorb the cost of customers sitting on old Kubernetes versions. They stopped. AWS documented the change when it introduced extended-support pricing: standard support costs $0.10 per cluster per hour and runs for 14 months from a version's general availability on EKS, matching the upstream Kubernetes support window. Extended support then costs $0.60 per cluster per hour for the following 12 months, giving one version a 26-month total lifespan.
The mechanism matters as much as the number. Per the EKS upgrade policy documentation, a cluster carries a support type of either STANDARD, which auto-upgrades at no extra charge, or EXTENDED, which stays on its version and bills at the higher rate. Once a cluster is in extended support you cannot opt back out by flipping a flag. You upgrade or you pay.
Google Kubernetes Engine prices it almost identically: a $0.10 per cluster hour management fee on every cluster, plus $0.50 per cluster hour for the extended channel, which the pricing page itself states as "a total of $0.60 per cluster per hour", covering up to 24 months per minor version. Azure Kubernetes Service Long Term Support takes a different shape: roughly 12 months of community support across the three most recent GA minor versions, then one additional year on LTS, which requires the Premium tier and the --k8s-support-plan AKSLongTermSupport flag, and which supports only the two most recent patch versions.
| Provider | Standard support | Extended or LTS | Total version lifespan |
|---|---|---|---|
| Amazon EKS | $0.10 per cluster hour, 14 months | $0.60 per cluster hour, 12 months | 26 months |
| Google Kubernetes Engine | $0.10 per cluster hour | $0.60 per cluster hour total, extended channel | Up to 24 months |
| Azure Kubernetes Service | About 12 months, three recent GA minors | LTS one further year, Premium tier required | About 24 months |
| Upstream Kubernetes | Three most recent minor versions | None | About 14 months per minor |
Run the arithmetic on a fleet, because it is the argument that gets a hire approved. The difference between $0.10 and $0.60 per cluster hour is $0.50, or about $4,380 per cluster per year. Twenty clusters left on an out-of-support version cost about $87,600 a year in support surcharge alone, before a single workload runs. That is more than the fully loaded cost of the engineer who would have upgraded them.
As of August 2026 the EKS standard support version list covers 1.36, 1.35 and 1.34, with 1.36 tracking the upstream release of 22 April 2026 and 1.34 tracking 27 August 2025. Anything below 1.34 is billing at the extended rate today. Our walkthrough of the EKS 1.33 standard support cutover covers what that transition actually costs, and the Kubernetes 1.36 upgrade guide covers the breaking changes waiting at the top of the ladder.
Serverless has the same calendar, with a harder edge
Kubernetes at least degrades into a bill. Lambda degrades into a wall. The AWS Lambda runtimes page publishes three separate dates per runtime, and teams routinely read only the first one.
| Runtime | Deprecation date | Block function create | Block function update |
|---|---|---|---|
| Node.js 20 | 30 April 2026 | 1 February 2027 | 3 March 2027 |
| Python 3.9 | 15 December 2025 | 1 February 2027 | 3 March 2027 |
| Python 3.10 | 31 October 2026 | 1 February 2027 | 3 March 2027 |
| Python 3.11 | 30 June 2027 | 31 July 2027 | 31 August 2027 |
| Node.js 22 | 30 April 2027 | 1 June 2027 | 1 July 2027 |
| Node.js 24 | 30 April 2028 | 1 June 2028 | 1 July 2028 |
Deprecation means security patches stop. Block-create means you cannot stand up a new function on that runtime. Block-update is the one that hurts: after 3 March 2027, an existing Node.js 20 or Python 3.10 function cannot be updated at all. Not patched, not reconfigured, not fixed during an incident. Note that AWS has grouped several older runtimes onto the same 1 February and 3 March 2027 dates, so an organisation carrying a mix of Python 3.9, Python 3.10 and Node.js 20 functions faces all of them landing in the same fortnight rather than staggering.
Anyone screening DevOps candidates should ask how they would inventory Lambda runtimes across every account and region in an organisation. It is a genuinely awkward question with a real answer, and it is a much better filter than asking someone to define continuous delivery.
What the CNCF data says about how teams are actually structured
The CNCF and SlashData Technology Radar, published on 24 March 2026 at KubeCon and CloudNativeCon Europe in Amsterdam and based on a survey of more than 400 professional developers fielded in the fourth quarter of 2025, gives the most usable structural picture available:
- 28% of organisations have a dedicated platform engineering team.
- 41% run a multi-team collaboration model for internal developer platform management, the single most common arrangement.
- 35% use a hybrid platform to bring AI workloads onto their existing developer platform.
- 91% of developers said they would recommend GitHub Actions to peers.
- 94% gave Helm a four or five star reliability rating; 87% gave cert-manager the same for stability.
Chris Aniszczyk, CTO of the CNCF, said in that announcement: "Cloud native platforms have reached a point where developers are not just experimenting but standardizing on CNCF projects that make software delivery reliable at scale. What's especially notable about this research is how organizations are extending those same platforms to support AI workloads, showing how cloud native is the base layer of powering the next era of applications."
Liam Bollmann-Dodd, principal market research consultant at SlashData, added in the same release: "Developers are increasingly evaluating tools based on how well they fit into their internal platform architectures. What we see in this data is those technologies gaining traction are the ones that are reducing operational friction while enabling teams to standardize application delivery and management."
The 41% figure is the one to design a hire around. Most organisations do not have a platform team; they have platform work distributed across product squads, with nobody accountable for the upgrade calendar. That is precisely the shape in which a $0.60 cluster hour goes unnoticed for a year.
The tooling questions worth asking
Terraform's GitHub releases page shows v1.15.5, dated 27 May 2026, as the latest tagged stable release, with 1.16 in alpha. The licensing position has not changed since 2023: Terraform CLI is distributed under the Business Source License 1.1, not an open-source licence, which is what pushed a section of the market toward OpenTofu. A candidate who still describes Terraform as open source has not looked at the licence in three years. Our Terraform versus OpenTofu standardisation guide covers when that distinction changes a decision and when it does not.
On CI cost, GitHub's December 2025 changelog records a runner price cut effective 1 January 2026: Linux x86 from $0.008 to $0.006 per minute, Windows from $0.016 to $0.010, macOS from $0.080 to $0.062, with a $0.002 per minute Actions cloud platform charge already folded into those rates rather than billed separately. GitHub also planned to extend that $0.002 per minute charge to self-hosted runners in private repositories from 1 March 2026, then posted on the same page: "We're postponing the announced billing change for self-hosted GitHub Actions to take time to re-evaluate our approach." Self-hosted runner minutes remain free. GitHub states that 96% of customers saw no bill change from the runner price cut.
That postponement is worth testing a candidate on, because a lot of 2026 cost modelling was built on a charge that never arrived.
A screen that separates operators from tool users
- "We have twenty EKS clusters, eleven on Kubernetes 1.33. What is that costing us and what do you do first?" The complete answer prices the surcharge at roughly $4,380 per cluster per year, then triages by blast radius rather than upgrading alphabetically.
- "How do you find every Lambda function on a deprecated runtime across forty AWS accounts?" Looks for organisation-wide tooling instinct rather than a per-account click-through.
- "Our Terraform state is one file and one apply takes forty minutes. Walk me through splitting it." Tests whether they have lived with state, or only written HCL.
- "When would you deliberately pay for extended support instead of upgrading?" There are good answers: a regulated release freeze, a pending acquisition, a workload with a certified dependency. A candidate who says "never" has not run production under a compliance calendar.
- "What would you refuse to automate?" The best answers are specific and slightly uncomfortable: destructive database migrations, IAM policy widening, anything whose rollback path has never been tested.
Skip the whiteboard system-design exercise. Hand over a real, sanitised Terraform module and a real failing pipeline and watch for ninety minutes. The delta between candidates on that exercise is far larger than on any interview question.
On salary data, and why this page does not print a number
Published salary aggregates for DevOps roles do not survive checking. The figures that circulate for India and for global markets trace back to content sites citing each other, and the widely quoted "Stack Overflow Developer Survey" compensation numbers for platform roles could not be located on Stack Overflow's own published survey results. We would rather leave the number out than repeat one we cannot open a primary source for.
What can be said with confidence is the cost of the alternative. One out-of-support Kubernetes fleet, one blocked Lambda deployment during an incident, one certificate expiry with nobody owning cert-manager, and the surcharge arithmetic above stops being theoretical. Price the role against the avoided cost, benchmark locally against live offers you can actually see, and treat any blog-sourced salary band with suspicion.
India-specific considerations
For Indian organisations the version calendar collides with two local constraints. The first is the Digital Personal Data Protection Act 2023, which makes the question of which region a workload runs in an engineering question and not just a procurement one. Cluster upgrades that quietly move workloads between regions, or logging pipelines that ship personal data to a default global endpoint, are the failure modes worth screening for.
The second is that a great deal of Indian platform work sits inside global capability centres and managed-services contracts where the upgrade obligation is split across two organisations. Ask a candidate who has worked in that setting who owned the Kubernetes version in their last role, and what happened when the answer was unclear. It usually was unclear. Our cloud cost optimisation guide for Indian companies covers how those surcharges show up on an Indian cost centre, and our platform engineering and modernisation patterns page covers the operating model around them.
Choosing an engagement shape
The calendar should choose the engagement, not the org chart.
A bounded upgrade programme fits when the deadline is published and the scope is countable: move every cluster out of extended support, or clear every Lambda function off a runtime before 3 March 2027. Both are estimable because someone else set the date.
Retained platform capacity fits when the real problem is recurrence. Kubernetes ships three minor versions a year and supports three at a time, which means a permanent upgrade treadmill. An organisation without standing capacity to run it will be in extended support again within eighteen months of finishing the last remediation.
An embedded platform engineer fits when the constraint is the estate rather than the calendar: undocumented Terraform, a monolithic state file, or a pipeline nobody is willing to touch.
eCorpIT staffs all three. We do not publish a day rate, because the honest number depends on the state of your state file, and anyone quoting before seeing it is guessing.
FAQ
How eCorpIT can help
eCorpIT is a Gurugram-based engineering organisation founded in 2021, holding CMMI Level 5, MSME and ISO 27001:2022 certifications, with senior-led platform and DevOps teams and partnerships with AWS, Microsoft and Google. We run bounded upgrade programmes tied to published vendor deadlines, retained platform capacity for teams that keep slipping back into extended support, and embedded engineers inside existing squads. We design infrastructure aligned with Digital Personal Data Protection Act 2023 requirements, including regional workload placement and log routing. Send us your cluster inventory and runtime list at /contact-us/ and we will tell you what the surcharge is costing you today.
References
_Last updated: 19 August 2026._
