Managed Kubernetes services
Managed Kubernetes on AWS, Azure and Google Cloud, Run 24/7
Your cloud provider runs the Kubernetes control plane. Our rotation runs the rest around the clock: version upgrades, nodes, add-ons, monitoring and the incident at 03:00, with a named engineer on a critical incident within 15 minutes.
- ~150 repositories on Kubernetes on AWS today
- P1 response in 15 minutes
- Rates from $45 per hour
What are managed Kubernetes services?
Amazon EKS, Azure AKS and Google GKE run the Kubernetes control plane for you. Your team still owns version upgrades, worker nodes, add-ons, workloads, alerts and incidents. Managed Kubernetes services from Valletta hand that half to a 24/7 rotation of senior engineers working to written response targets, a playbook and change control.
On Amazon EKS, for example, managed node groups and self-managed nodes are not upgraded automatically when the control plane is, so somebody has to plan and run every node upgrade. That work, and the alert that fires on a Sunday night, is what this service covers.
See the full 24/7 DevOps support serviceWhat does managed Kubernetes operations cover?
We run the day-to-day life of your clusters: Kubernetes version upgrades for control plane, nodes and add-ons, node and cluster lifecycle in Terraform, monitoring and alerting in your tooling, and incident response on the priority ladder. Every change goes through tiered notice, a named verifier and a rollback point.
Version upgrades
Upgrades planned against the provider’s support calendar, control plane first, then node groups and add-ons, each with a rollback point.
Node and cluster lifecycle
Node groups, scaling and cluster configuration managed as code, in Terraform where your estate uses it, so every change is reviewed and repeatable.
Monitoring and alerting
We work in your tooling, such as Datadog and PagerDuty, and instrument the parts of the estate that are not yet visible.
Incident response
A named engineer on a P1 within 15 minutes, hourly updates, a 4-hour restoration target and a root cause analysis in 3 working days.
Change control
Tiered notice, a named verifier and a rollback point on every change to your clusters.
Access control
Least privilege, MFA and an audited break-glass path. Access is set up in the first onboarding phase.
How long is a Kubernetes version supported?
The Kubernetes project maintains the three most recent minor releases and gives each about one year of patch support. Amazon EKS keeps a version in standard support for 14 months, then 12 months of extended support at extra cost per cluster hour, and then upgrades the control plane automatically. Upgrades are a recurring job.
| Platform | Support window | What it means for you |
|---|---|---|
| Kubernetes (upstream) | Release branches for the three most recent minor versions; about 1 year of patch support each | A cluster that is never upgraded falls out of patch support within about a year |
| Amazon EKS | 14 months of standard support, then 12 months of extended support at an additional cost per cluster hour | At the end of extended support EKS upgrades the control plane automatically; nodes and add-ons stay behind until you upgrade them |
| Azure AKS | Published in Microsoft’s AKS supported versions policy | Plan upgrades against Microsoft’s calendar for your cluster |
| Google GKE | Published in Google’s GKE versioning policy | Plan upgrades against Google’s calendar and your release channel |
Sources: kubernetes.io releases page and the Amazon EKS user guide, both checked 13 November 2026. For AKS and GKE we link the providers’ own policies below.
What happens when a cluster breaks at 03:00?
An engineer who is already on shift picks it up, because follow-the-sun cover has no out-of-hours tier. For a P1 a named engineer takes ownership within 15 minutes, updates you every hour and works to a 4-hour restoration target. Weekends and public holidays run on a paged on-call rotation with the same P1 targets.
| Standard targets | P1 Critical | P2 High | P3 Medium | P4 Low |
|---|---|---|---|---|
| Named engineer responds | 15 min | 30 min | 4 hours | 1 working day |
| Updates while open | Every hour | Every 4 hours | Daily | On change |
| Restoration target | 4 hours | 8 cover hours | 5 working days | Best effort |
| Root cause analysis | 3 working days | On request | - | - |
A response means a qualified engineer who has publicly taken ownership of the incident, never an automated reply. P2 response at weekends is 2 hours. Final targets are set per engagement against your scope and written into the contract.
Where do you run Kubernetes in production today?
Our rotation runs a Kubernetes estate on AWS for a multi-venue platform across the UK and the US: about 150 repositories behind booking, payment, kiosk and in-venue game systems that trade evenings and weekends. The engineers who would cover your clusters already run production Kubernetes on AWS with a written, audited playbook.
~150
repositories on a Kubernetes estate on AWS
2
countries of venues, trading evenings and weekends
24/7
booking, payment, kiosk and in-venue game systems
Stack: AWS, Kubernetes, Terraform, Datadog, PagerDuty, GitHub Actions, Octopus Deploy, Jira and Zendesk.
How much do managed Kubernetes services cost?
Managed Kubernetes operations are part of our 24/7 DevOps support, billed from $45 per hour. Every tier includes the same rotation, priority ladder and reporting, and tiers differ by how much hands-on engineering time comes with the cover. Send us your stack and current support setup for a side-by-side comparison and a fixed proposal.
Sources
- Kubernetes, Releases (accessed 13 November 2026)
- Amazon EKS User Guide, Understand the Kubernetes version lifecycle on EKS (accessed 13 November 2026)
- Microsoft Learn, Supported Kubernetes versions in Azure Kubernetes Service (accessed 13 November 2026)
- Google Cloud, Versioning in Google Kubernetes Engine (accessed 13 November 2026)
Frequently asked questions
EKS, AKS and GKE are managed control planes: the provider runs the Kubernetes API servers. Managed Kubernetes services from Valletta cover what the provider leaves to you: upgrades of nodes and add-ons, cluster configuration, monitoring, alerts and incidents, run by a 24/7 rotation with written response targets.
Yes. We support Kubernetes on AWS, Azure and Google Cloud. Our production reference today is a Kubernetes estate on AWS with about 150 repositories, run around the clock. The same rotation, priority ladder, change control and access control apply on every cloud, and upgrades follow each provider’s published support calendar.
The Kubernetes project patches only its three most recent minor releases, each for about a year, and Amazon EKS keeps a version in standard support for 14 months. In practice a cluster needs a planned minor upgrade regularly, with nodes and add-ons upgraded after the control plane, or it drifts out of support.
After 14 months of standard support the version moves into extended support, billed at an additional cost per cluster hour. When the 12 months of extended support end, Amazon EKS upgrades the control plane automatically, without a notice beforehand, and your nodes and add-ons stay on the old version until someone upgrades them.
Yes. We work in your tooling where you have it and instrument what is not yet visible. On the Kubernetes estate we run today the stack is AWS, Kubernetes, Terraform, Datadog, PagerDuty, GitHub Actions, Octopus Deploy, Jira and Zendesk, so we are used to fitting into an existing delivery pipeline.
Engineers on the rotation work under least-privilege access with MFA, and an audited break-glass path covers emergencies. Every change carries tiered notice to your team, a named verifier and a rollback point. Access is set up in the first onboarding phase, together with a map of your estate and tested runbooks.
Compare it against your own numbers
Send us your stack and current support setup. We come back with a side-by-side cost comparison and a fixed proposal.
Prefer to talk?