Which Kubernetes model fits your team: self-managed or EKS and AKS
If your data must stay in facilities you control, or your network may be air-gapped, a self-managed Kubernetes control plane on VMs or bare metal is the model to evaluate first. If your workloads can run in a public cloud region that satisfies your residency rules and your team has little appetite for running etcd and the API server, Amazon EKS or Azure Kubernetes Service (AKS) is usually the faster path. Neither answer is automatic. The deciding conditions are data residency rules, whether connectivity to a cloud provider is permitted, the size of your existing VM and bare metal estate, and how many engineers can own control plane operations day to day.
Choose self-managed when a residency or sovereignty rule places control plane data, Secrets and audit trails under your own administrative boundary, when the environment cannot reach a cloud API, or when you already run a VM or bare metal fleet with virtualization and storage skills in house. The cost of that choice is ownership. With kubeadm, which the Kubernetes documentation describes as a bootstrapping tool that leaves machine provisioning and add-ons out of scope, your team owns high availability layout, etcd snapshots and restores, certificate rotation, and version upgrades that follow the one-minor-version-at-a-time skew policy. Ask whether the platform team can staff that rotation without it competing with application delivery.
Be fair to the managed services on upgrades and SLAs. EKS and AKS run the control plane for you, and AKS publishes a financially backed uptime SLA on its Standard tier, which self-managed clusters do not get from a vendor. EKS bills $0.10 per cluster per hour for clusters on a Kubernetes version in standard support and $0.60 per cluster per hour in extended support, according to the Amazon EKS pricing page, so confirm which of your planned versions will fall into extended support before you commit. Also confirm whether your regulator accepts a provider SLA as a control, since that is a question for your compliance lead and not something the pricing page answers.
How self-managed, EKS and AKS differ on published facts
This table sets the published EKS and AKS control plane rates and tier limits against the open-source Kubernetes license and release window. Read the cells marked to confirm as the questions to put to each vendor before you rely on a comparison, because the published pages do not give every value a buyer needs.
| Dimension | Self-managed Kubernetes (kubeadm) | Amazon EKS | Azure AKS |
|---|---|---|---|
| Control plane fee | No control plane fee from the Kubernetes project; you pay for the VMs or servers that host control plane nodes and etcd | $0.10 per cluster per hour on a version in standard support, $0.60 per cluster per hour on a version in extended support (Amazon EKS pricing page) | Free tier has no control plane charge; Standard and Premium tiers carry charges (confirm current rates on the Azure pricing page) |
| Availability commitment | None from the upstream project; uptime depends on your design, such as three or more control plane nodes behind a TCP load balancer | Confirm the published control plane availability commitment with AWS for your region | Free tier has no SLA; Standard tier has a financially backed API server uptime SLA for production; Premium adds long-term support |
| Scale and workload limits | Set by your own hardware and etcd sizing; Kubernetes recommends a five-member etcd cluster in production | Confirm node and cluster limits with AWS for your configuration | AKS states Free tier clusters are not meant for more than 10 nodes or for workloads that need high availability |
| Version and support window | Project maintains the three most recent minor releases; 1.37 (end of life October 28, 2027), 1.36 (June 28, 2027), 1.35 (February 28, 2027) as of September 2026; patch support about one year per minor | Standard support versus extended support windows; confirm which versions are in each state and the end dates with AWS | Premium tier adds long-term support; confirm the supported version windows and their end dates with Azure |
| Control of etcd and control plane | Full control: you choose stacked or external etcd, encryption at rest, backup schedule and restore process using etcdctl and etcdutl | Control plane is operated by AWS and not exposed for direct etcd administration; confirm which control plane settings you can change | Control plane is operated by Azure; confirm which control plane settings you can change and which add-ons are managed |
| Data and network location | Runs wherever you place it: your data center, cloud account or air-gapped network | Runs in AWS regions; confirm which regions, Outposts or local options fit your residency rules | Runs in Azure regions; confirm which regions and private connectivity options fit your residency rules |
| Licensing | Kubernetes is open source under Apache 2.0, so the software itself carries no license fee | Managed service under AWS terms; the Kubernetes components are open source, but the service itself is a paid managed offering | Managed service under Azure terms; the Kubernetes components are open source, but the service itself is a paid managed offering |
What you run yourself when you choose self-managed Kubernetes
Self-managed Kubernetes means you own the control plane, and kubeadm will not do that work for you. kubeadm init and kubeadm join give you a fast path to a minimum viable cluster, but kubeadm only bootstraps. It does not provision machines, and it leaves add-ons such as dashboards, monitoring and cloud-specific components out of scope. Before you compare costs with EKS or AKS, list every component you will install and operate yourself: the CNI, ingress, certificate management, metrics, logging, backup of cluster state and the upgrade tooling. The kubeadm reference sets out what the bootstrap tool covers and what it leaves to you.
A production control plane needs at least three control plane nodes behind a TCP load balancer in front of kube-apiserver on port 6443, as the kubeadm high availability guide describes. Your etcd plan is the most consequential piece. Etcd should run with an odd number of members, and Kubernetes recommends five members in production. Each member needs a backup plan, with snapshots taken using etcdctl snapshot save and restores performed with etcdutl. Confirm who runs those snapshots, where they are stored, how often you test a restore, and who is on call when quorum is lost. Managed services hide the control plane, etcd and its backups behind the provider, so these tasks move to your team rather than disappearing.
Whether etcd runs on the control plane nodes (stacked) or on its own hosts (external) is a separate decision with its own failure and hardware trade-offs, covered in the sibling topic on stacked etcd versus external etcd. For this choice, ask your platform team whether it can staff upgrades, certificate rotation and etcd recovery on a schedule. Then check the version policy: the Kubernetes project maintains only the three most recent minor releases, so you must keep moving. Your EKS or AKS quote should be compared with that recurring operational load, not only with the control plane fee.
How data location, identity and secrets change under each model
Moving from a managed control plane to a self-managed one changes where etcd data sits, who authenticates users, and who protects Secrets. Each card below is a control you own under self-management and must either build or confirm with the managed provider. Checking these early shapes both the architecture and the evidence an auditor will ask for.
Where control plane and etcd data sit
On a self-managed cluster, etcd holds cluster state on hosts you choose, in stacked or external layouts. You decide the region, the failure domain and who can reach the etcd endpoints. On EKS and AKS the control plane runs in the provider's managed environment, so the question becomes which region hosts your workloads and what the provider documents about where control plane data is held. Ask the provider for that documentation in writing and confirm it against your residency rules.
User identity without a provider
Kubernetes does not store human users as API objects. Self-managed clusters authenticate users with X.509 client certificates, bearer tokens including OpenID Connect and JWT, webhook token authentication or an authenticating proxy. You must wire an OIDC issuer, map groups to RBAC and plan certificate rotation yourself. On EKS and AKS, identity usually flows through the cloud provider's IAM or Entra integration, which changes who administers access and how offboarding is evidenced. Confirm which path your auditors will accept.
Secrets in etcd by default
Kubernetes Secrets are stored unencrypted in etcd unless you configure encryption at rest. A self-managed build must enable encryption, restrict list and watch access with least-privilege RBAC, and back up etcd without leaking key material. Where Secrets must stay outside the cluster, the Secrets Store CSI Driver can pull values from an external store. Check whether your managed provider encrypts etcd by default and whether you can supply your own key, because that answer differs by provider and tier.
Air-gapped and sovereign operation
A self-managed cluster can run inside a disconnected network, with container images, Helm charts and OS packages mirrored in from an internal registry. Managed services depend on provider endpoints for the control plane and most add-ons, so a fully disconnected design needs a provider-specific review. Plan how you will patch Kubernetes versions offline, how you will verify images, and who holds the signing keys. Confirm each dependency with the provider before you commit to either model.
CIS Kubernetes Benchmark as a reference
The CIS Kubernetes Benchmark gives you a control-by-control reference for hardening the control plane, worker nodes and policies. Self-managed builds must apply and document these settings themselves, including API server flags, etcd peer security and kubelet configuration. Managed providers apply some controls on your behalf and leave others to you. Obtain the benchmark version your assessor expects, run a scan against your own build, and record which controls are inherited from the provider and which are yours.
Evidence for assessors
DeployOpen prepares controls, configuration and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications. Independent auditors and certification bodies make those decisions. Under self-management, you own the evidence trail for etcd backups, certificate rotation, encryption settings and access reviews. Under EKS or AKS, you will still need the provider's own compliance documentation for the shared responsibility split. Agree early which party produces each artifact.
When self-managed fits and when EKS or AKS fits best
When workloads, keys or operational data cannot leave a network you control, a managed control plane is hard to justify. Self-managed Kubernetes on VMs or bare metal keeps the API server, etcd and node images inside your own facilities, and it can run without a route to a public cloud control plane. EKS and AKS can meet many residency requirements through regional placement, but whether a managed control plane satisfies your specific rule is a question for your legal and compliance team, not a default you can assume.
- Where the advantage applies: Networks with no outbound path to a cloud provider, or rules that require the cluster state itself to stay on premises.
- Where it can go wrong: You take on etcd backups, certificate rotation and upgrade sequencing that a managed service would otherwise absorb, and an unpatched control plane in an isolated network is a security exposure.
- Image and update supply: Plan how Kubernetes binaries, container images and add-ons reach the air-gapped network and how they are verified before install.
- Secrets at rest: Kubernetes stores Secrets unencrypted in etcd by default, so encryption at rest must be configured on your own clusters.
- Questions to confirm: Ask your auditors which evidence they expect for control plane operations, and confirm with the cloud provider exactly where control plane data is processed in each region you would use.
Before choosing, write down the residency rule in plain terms and test each option against it with your compliance lead.
Teams that already run hypervisors and bare metal often have the hardware, monitoring and operating procedures in place. Adding a self-managed Kubernetes cluster on those hosts reuses that investment, and the control plane stays on the same network paths as the rest of the estate. The advantage depends on whether those hosts have spare capacity and staff who already run Linux, storage and networking at a level Kubernetes will demand.
- Where the advantage applies: Organizations with stable on-premises capacity and a workload mix that does not change often enough to justify moving it into a cloud account.
- Where it can go wrong: Adding a control plane to an estate without spare capacity or patch discipline creates a second platform that competes for the same hosts and maintenance windows.
- Stacked or external etcd: A three-node control plane is the minimum for high availability, and the topology choice decides which hosts fail together.
- Load balancing: A TCP load balancer in front of the API server on port 6443 is part of the design, not an afterthought.
- Kubernetes lifecycle: Upstream Kubernetes maintains only the three most recent minor releases, so upgrades are a recurring project.
Check whether your hypervisor or storage vendor supports the Kubernetes node layout you plan to run, and confirm that version with the vendor.
A small platform team has to decide how many hours per month it can give to control plane work. Managed services shift control plane patching, availability and API server operations to the provider, while the team keeps node groups, add-ons, policies and workloads. Self-management gives full control of the control plane, but every task the provider would have handled becomes a team task with its own on-call burden. The trade-off is about capacity, not technical preference.
- Where managed fits: A team of a few engineers with no one already trained on etcd, certificates or kubeadm upgrades.
- Where self-managed fits: A team that already runs Linux and infrastructure automation and can staff an upgrade rotation every few months.
- Upgrade cadence: Kubernetes releases happen approximately three times per year on a cycle of about 14 weeks, so the team must plan for that rhythm.
- Version skew: kube-apiserver must be upgraded one minor version at a time, before the other control plane components and kubelets.
- Cost components: Managed services charge a control plane fee in addition to your compute, while self-managed clusters move that cost into staff time and hardware. Ask a partner for a written scope before comparing totals.
Estimate the hours your team can actually spare for control plane operations, then compare that figure with the upgrade and on-call load in the written plan.
Organizations that already run workloads on more than one cloud often want one Kubernetes operating model across all of them. A self-managed distribution can run the same way on each provider's virtual machines and in your own data center, which keeps tooling, policies and runbooks consistent. Managed services are fine inside one provider, but each one has its own networking, identity and add-on conventions, so the shared layer is more work to build and keep aligned.
- Where the advantage applies: Teams that want identical cluster builds, policies and GitOps workflows across providers and on-premises sites.
- Where it can go wrong: Running self-managed clusters on several clouds multiplies the control plane operations you own, so the total effort grows with each site.
- Conformance: The CNCF Certified Kubernetes conformance program checks that distributions support the required Kubernetes APIs, which helps when workloads move between environments.
- Identity: Kubernetes authenticates users through X.509 certificates, OpenID Connect and other methods, so plan one identity source that every cluster trusts.
- Mixed estates: A managed cluster on one provider and a self-managed cluster elsewhere is a valid pattern if each team owns its own runbook.
Confirm the cluster versions and add-on sets each site needs, and write down who owns each control plane.
A team that already builds on AWS or Azure, and whose identity, networking and monitoring are set up there, usually gets the most from the managed service. Integration with the provider's IAM or Entra ID, load balancers and node management is part of the service design, and the platform team can focus on workloads. The case for self-management weakens when the team would have to rebuild those integrations by hand.
- Where managed fits: Workloads that already depend on provider-native services, where the control plane sits inside the same account and network boundary.
- Published control plane pricing: Amazon EKS charges $0.10 per cluster per hour for clusters on a Kubernetes version in standard support and $0.60 per cluster per hour for versions in extended support, according to the Amazon EKS pricing page. Plan upgrades to avoid extended support charges.
- Azure tiers: The AKS pricing page lists a Free tier with no control plane charge and no SLA, and a Standard tier with a financially backed API server uptime SLA for production. The AKS pricing FAQ states that Free tier clusters are not meant for more than 10 nodes or for workloads that need high availability.
- Exit cost: Moving off a managed service later means rebuilding control plane operations, so write down the provider-specific dependencies now.
- Cost comparison: Compare your full node and staff costs, not only the control plane fee.
Before you commit, check the current EKS and AKS pricing pages and your provider agreement, since these figures can change.
What your team runs in each model
This table maps who owns each recurring Kubernetes duty when you run your own control plane on VMs or bare metal compared with EKS and AKS. Read each row as a question to answer for your team before choosing, since the owner column shifts with the service tier you buy. The main takeaway is that managed services move control plane patching and etcd operations to the provider, while upgrade sequencing, certificates at the node level and add-ons stay with your team in every model.
| Duty | Self-managed on VMs or bare metal | EKS or AKS |
|---|---|---|
| Control plane patching and upgrades | Your team runs kubeadm upgrades for kube-apiserver first, then controller manager, scheduler and kubelets, one minor version at a time | Provider performs control plane upgrades, but your team still schedules and tests minor version changes on its side |
| etcd backup and restore | Your team owns snapshot schedules, off-host storage and restore drills using etcd tooling | Provider operates etcd; your team owns workload backups and any cluster configuration kept outside the API |
| Control plane certificate rotation | Your team owns certificate expiry tracking and rotation on every control plane node | Provider manages control plane certificates; your team manages client credentials and workload identities |
| Minor version cadence | Your team tracks roughly three Kubernetes releases per year and plans to keep within the three most recent minor releases | Your team picks a supported version and plans upgrades within each platform's support window |
| Version skew order | Your team enforces that kubelets stay at most three minor versions behind kube-apiserver across the fleet | Provider enforces control plane skew; your team still manages node pool upgrades |
| Add-on lifecycle (CNI, ingress, metrics, storage drivers) | Your team installs, patches and retires every add-on, including those a managed service would bundle | Your team owns add-on versions and compatibility, though some are provider-managed options |
| Security patch window per minor release | Your team must upgrade within the roughly one-year patch window each minor release receives, including pre-release time | Your team must follow the provider's published support and extended support dates for the version it runs |
| On-call for control plane incidents | Your team is first responder for API server, etcd and scheduler failures, with an escalation path you define | Provider handles control plane incidents; your team is on call for workloads, nodes and networking |
What each model costs and what drives the bill
Self-managed Kubernetes moves the bill from a vendor invoice to your own budget lines. Running kubeadm-built control planes on VMs or bare metal means paying for the hardware or VM capacity for at least three control plane nodes, the load balancer in front of kube-apiserver on port 6443, the worker nodes, and the etcd backup storage. Staff time is usually the largest recurring item: someone must patch the control plane, rotate certificates, test etcd restores with etcdutl, handle Secrets encryption at rest, and plan minor-version upgrades. Those upgrades are projects, not line items, and they recur roughly every 14 weeks because Kubernetes ships about three minor releases a year. Support contracts are optional and recur if you buy them. Ask any implementation partner, including DeployOpen, for a written quote built from your agreed scope, which should separate one-time build and hardening work from recurring upgrade and support retainers.
Managed services bill the control plane separately from everything else. The Amazon EKS pricing page lists $0.10 per cluster per hour for clusters on a Kubernetes version in standard support and $0.60 per cluster per hour for versions in extended support, so an EKS cluster left on an older version costs six times more for its control plane. Those fees are recurring and run for as long as the cluster exists, whether or not it is busy. Worker compute, storage, load balancers and data egress are billed on top, and they often dominate the total. For AKS, the tier you pick sets the control plane terms: the Free tier carries no charge and no SLA, and Microsoft's AKS pricing FAQ says it is not meant for more than 10 nodes or for high availability workloads. Confirm the current Standard and Premium terms with Microsoft or your Azure account team before you model the bill, because tier prices and included features change.
Compare the two models on the same spreadsheet, with the same recurring items. Put the one-time build, the monthly infrastructure, the staff hours per month for patching and upgrades, the backup storage and any support contract in each column, then add the extended support and egress lines for the managed side. Self-managed costs fall when you consolidate clusters, reuse hardware you already own, or automate upgrades. Managed costs rise with cluster count, node count and any version that falls into extended support. The break-even point depends on your team's rate and your data residency or air-gap constraints, which may remove the managed option entirely.
How to move a workload between self-managed and managed Kubernetes
This sequence moves one workload from a self-managed cluster to EKS or AKS, or back, without a cutover gamble. It ends with a tested parallel cluster, a traffic switch you can reverse, and a documented exit path.
Inventory API versions and cluster add-ons
The platform engineering team lists every API group, custom resource definition, admission webhook, ingress controller, CNI plugin, storage class and load balancer annotation the workload depends on, on both the source and target. Check each API version against the target's supported Kubernetes minor version, since the source and target can sit on different releases. Kubernetes maintains only the three most recent minor releases, so confirm the target version's support window in the Kubernetes releases page before you commit to it. Done means a signed-off matrix that marks each dependency as portable, replaceable or blocking.
Confirm conformance of the target distribution
The security architect and platform lead check that the target runs a conformant Kubernetes distribution. The CNCF Certified Kubernetes conformance program verifies that a distribution supports the required APIs, so a conformant workload should not need code changes for core resources. Ask EKS or AKS to confirm the exact version and any managed add-on behavior that differs from upstream, and record it in the matrix. Done means a written confirmation for the target version and a list of managed-service deviations the team has accepted or planned around.
Export manifests and GitOps state
The delivery team exports workload manifests from the source cluster and confirms that the Git repository is the single source of truth, so the desired state is not held only in live objects. Strip cluster-generated fields such as status, UIDs and resource versions, then render Helm or Kustomize output for the target's overlays. If you use Argo CD or Flux, register the target cluster with the controller and reconcile the same repository against it. Done means a diff between source and target rendered output that contains only environment-specific values you can name.
Move secrets through an external store or encrypted backup
The security engineer moves secrets without copying them in plain text. Kubernetes stores Secrets unencrypted in etcd by default, so the source backup must be encrypted at rest, or the secrets should live in an external store reached through the Secrets Store CSI Driver. Re-issue credentials for the target where possible, and rebind workload identity to the target's IAM or Entra ID model rather than copying service account keys. Done means every secret the workload uses resolves on the target from its new source, and no plain-text secret file exists in the migration repository.
Stage a parallel cluster and run the workload
The platform team deploys the workload to the target cluster alongside the live source, without public traffic. Run smoke tests, synthetic transactions and the pod security checks your baseline requires, and confirm that persistent volumes bind to the target storage classes. Expect the storage step to be the hardest part if the source uses a self-hosted CSI driver, so test restore of stateful data on the target before proceeding. Done means passing functional and restore tests on the target, with results saved as evidence for your change record.
Shift traffic with a reversible switch
The operations lead moves traffic in stages, for example by changing DNS weights or the external load balancer pool, and watches error rates, latency and saturation dashboards at each stage. Keep the source cluster running and its routing unchanged until the target has carried production traffic through your agreed review window. If a stage fails, route traffic back to the source before investigating. Done means the full workload is served from the target, the rollback path has been exercised once in a non-production window, and the change record names the person who approved each stage.
Plan the exit path before decommissioning
The architecture owner documents how the workload would leave the target later, whether to self-managed Kubernetes, another managed service or another cloud. Record which identity mappings, storage classes, load balancer annotations and managed add-ons would need replacing, because those dependencies drive the cost of switching. Confirm the managed provider's pricing terms for the control plane in the current pricing pages, and ask the provider for the exact fees for your version and tier. Done means a written exit runbook reviewed by the architect and stored with the workload's operational documentation.
Questions buyers ask before choosing Kubernetes hosting
How much total effort does running self-managed Kubernetes take?
The effort is mostly recurring, not a one-time setup. Self-managed Kubernetes means your team owns the control plane, the etcd datastore, certificates, node upgrades, add-ons and backups, while EKS and AKS bill for the managed control plane and take on part of that work. Kubernetes ships roughly three minor releases a year, and the project maintains only the three most recent minor versions, so upgrades arrive on a fixed clock. Drivers of effort include the number of clusters, how many control plane nodes you run, how much add-on tooling you add, and how often you patch. Ask any partner to split the estimate into initial build, first upgrade cycle and ongoing operations, and to state which of those they carry under the written scope.
Can an internal team run self-managed Kubernetes without outside help?
Yes, many teams do, but the answer depends on whether they can cover etcd, certificates, upgrades and incident response without a single point of failure in skills. The kubeadm documentation covers bootstrapping only and leaves add-ons such as dashboards and monitoring out of scope, so your team must choose and operate those pieces. Kubernetes high availability needs at least three control plane nodes behind a TCP load balancer, and etcd should run with an odd number of members and have a tested backup plan. Before deciding, check whether at least two engineers can perform an etcd restore and a version upgrade from documentation alone, and whether on-call coverage exists for the control plane.
How long does a self-managed Kubernetes build or migration take?
No researched figure is available for build or migration duration here, so treat any number you hear as unverified until it is tied to a written scope. The duration depends on the number of clusters, the topology you choose, how many workloads move, the state they hold, your change windows and how much hardening and documentation you require. Ask for the engagement scope, deliverables and milestones in writing before work starts, since most DeployOpen engagements are fixed-scope and timelines follow from that agreement. Ask the managed provider to confirm the migration steps for your workloads as well.
What does the work need from the team day to day?
The work needs Kubernetes operators who understand the control plane, not only application deployers. Core skills include kubeadm or equivalent bootstrapping, etcd snapshot and restore using etcdctl snapshot save and etcdutl, certificate lifecycle, node OS patching, networking and load balancer configuration, and RBAC. Security work adds encryption at rest for Secrets, since Kubernetes stores them unencrypted in etcd by default, and identity integration, since users authenticate through certificates, OpenID Connect or webhook tokens rather than a built-in user store. Plan for the version skew rules too: the API server must move one minor version at a time before other components. Confirm which of these skills exist in your team and which you will buy in.
Can EKS or AKS meet air-gapped or data residency requirements?
Managed services are designed to run in the provider's cloud regions, so they cannot meet a fully air-gapped requirement by themselves, and residency depends on which regions and services you select. Self-managed Kubernetes on your own virtual machines or bare metal keeps the control plane, etcd and Secrets inside networks you control, including disconnected ones. Before deciding, confirm with the provider where control plane data is processed and stored, which regions are available to you, and what their contractual terms say about data location. Do not assume a regional choice satisfies a residency rule until your compliance lead has reviewed the provider documentation for your specific services.
What does extended support cost on Amazon EKS?
Amazon EKS charges $0.10 per cluster per hour for clusters on a Kubernetes version in standard support and $0.60 per cluster per hour for versions in extended support, according to the Amazon EKS pricing page. The difference is a recurring cost per cluster, so it grows with the number of clusters and the time you run an older version. Staying on a version in standard support avoids the higher rate, which makes upgrade cadence a cost decision as well as a security one. Check the current figures on the pricing page before budgeting, since rates can change, and include the extended support rate in any cost comparison against self-managed clusters, where the control plane hosting cost is your own infrastructure.
What does Azure AKS charge for the control plane, and what does the SLA cover?
AKS offers a Free tier with no control plane charge and no SLA, a Standard tier with a financially backed API server uptime SLA for production, and a Premium tier that adds long-term support. The AKS pricing FAQ states that Free tier clusters are not meant to run at scale beyond 10 nodes or to support workloads that need high availability. Choosing a tier is therefore tied to the production profile of your workloads. Confirm the current tier prices and SLA terms on the Azure pricing page, and remember that a self-managed control plane has no vendor SLA, so your own availability design and on-call process carry that responsibility.
What is included in a DeployOpen Kubernetes engagement?
DeployOpen plans, implements, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own infrastructure, including Kubernetes on virtual machines and bare metal. Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. Ongoing support, upgrades and continuous testing are available as retainers. DeployOpen does not publish a price list, so a quote follows from the written scope. DeployOpen prepares systems and evidence for compliance assessments but does not issue audit reports or certifications. Ask for the scope document to list the control plane layout, backup and restore testing, upgrade responsibilities and handover, so you can compare it against a managed service.
What to confirm with the vendor and your own environment
The most important open items are the ones the published facts do not settle. Before you commit to either side, ask the managed provider for the current service level terms that apply to your cluster tier, and confirm in writing what the Premium long-term support scope covers on AKS, including which Kubernetes versions, which add-ons and which node operating system images are included. On EKS, ask which AWS regions host the control plane you would use, where cluster metadata and logs are stored, and whether any data residency commitment is contractual or only a description of current practice. Also confirm whether your cluster would move to extended support pricing if your chosen Kubernetes minor version ages out, and who in your organization approves that charge.
On the self-managed side, the open items are about your own operating model. Write down the kubeadm version policy you will hold: how often you upgrade one minor version at a time, how you test that upgrade against the version skew rules for kubelets and the control plane, and who signs off on skipping a release. Confirm your etcd backup plan with a restore test in a separate environment, and record the recovery point objective and recovery time objective your business owners accept, since the upstream documentation gives you the snapshot and restore tools but not your targets. Check how often a restore has actually been rehearsed rather than assumed.
Finally, check with your auditors before you assume either model is acceptable. Ask whether your audit scope accepts a provider-managed control plane, where the provider's responsibility ends and yours begins, and which evidence you must hold yourself, such as configuration of encryption at rest for Secrets in etcd and access logs for the API server. Ask the same question for a self-managed control plane, because the evidence burden moves to your team. Put these answers in the written scope before procurement, so the comparison rests on your environment rather than on general statements about either platform.
Primary sources for this comparison
This sequence walks through the sources to check before comparing self-managed Kubernetes with EKS and AKS, from published control plane fees and tier terms to kubeadm scope, etcd layout, upgrade windows and conformance. Each step closes with an output your team can file.
Record the EKS control plane charges
Open the Amazon EKS pricing page and note the control plane charge for each cluster. Amazon EKS charges $0.10 per cluster per hour for clusters on a Kubernetes version in standard support and $0.60 per cluster per hour for versions in extended support. Your team records which versions you plan to run and when they move into extended support. The output is a cost line per cluster, with worker nodes, load balancers and storage listed separately because they are billed outside the control plane fee.
Record the AKS tier terms
Read the Azure Kubernetes Service pricing page and note the Free, Standard and Premium tiers. The Free tier carries no control plane charge and no SLA, while the Standard tier adds a financially backed API server uptime SLA for production and the Premium tier adds long-term support. The AKS pricing FAQ states that Free tier clusters are not meant to run at scale beyond 10 nodes or to support workloads that need high availability. The output is a written tier choice for each environment, checked against the SLA wording in your own subscription.
Map the scope the upstream tool covers
Review the kubeadm reference to see what the upstream tool handles. kubeadm init and kubeadm join are the best-practice fast paths to a minimum viable cluster, and the tool bootstraps clusters while leaving machine provisioning to you. Dashboards, monitoring and cloud-specific add-ons are out of its scope, so your team owns them. The output is a list of components you install, operate and patch yourself, mapped against what EKS or AKS manage for you.
Design the highly available control plane layout
Follow the kubeadm high availability guide to choose between stacked etcd and an external etcd cluster. The guide describes both topologies, calls for at least three control plane nodes and a TCP load balancer in front of kube-apiserver on port 6443. Kubernetes documentation says etcd should run an odd number of members and recommends five members in production, so count every host and load balancer you will operate. The output is a host inventory with control plane, etcd and load balancer roles, each with a named owner.
Set the upgrade calendar against release support
Use the Kubernetes release cycle page to plan upgrades on the project's schedule. Kubernetes releases come about three times per year on a cycle of roughly 14 weeks, and the project maintains the three most recent minor releases. As of September 2026, 1.37 was listed as end of life October 28, 2027, 1.36 on June 28, 2027, and 1.35 on February 28, 2027. Your team upgrades kube-apiserver one minor version at a time, ahead of the other components. The output is a dated upgrade calendar that you own, set beside the extended support windows each provider publishes.
Confirm conformance for the chosen distribution
Check the CNCF Certified Kubernetes conformance program before you commit to a distribution. The program checks that vendor and community distributions support the required Kubernetes APIs, and CNCF states there are over 90 Certified Kubernetes offerings. Conformance confirms the API surface, but it does not tell you who patches, backs up or hardens the cluster. The output is a written record of the distribution, its certified version and the party responsible for each layer.
Turn findings into a scoped quote request
Convert the control plane findings into a written scope before comparing totals. The provider fees on EKS and AKS are only one line, and self-managed clusters add host, etcd backup, certificate rotation, upgrade, monitoring and on-call work that someone must price. Ask for each item to be listed with its owner and frequency. DeployOpen does not publish a price list, and a quote follows from the written scope. The output is a scope document that both internal teams and any implementation partner can price against.
How DeployOpen scopes, builds and supports self-hosted Kubernetes
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure, including cloud accounts, data centers and air-gapped networks. For Kubernetes, that means the control plane, etcd, add-ons and upgrade path are designed and handed over as a working system your team can operate.
How we scope
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
- The written scope names the hosting targets, whether VMs or bare metal, and the control plane topology you choose.
- Scope also records data residency, air-gap requirements and which identity provider the API server will trust.
- A quote follows from the written scope, so the cost reflects the work defined rather than a fixed package.
How we build
- Build covers control plane bootstrapping, etcd layout and encryption at rest for Secrets in etcd.
- Access is configured with least-privilege RBAC and client authentication aligned to your identity source.
- Add-ons such as monitoring, logging, ingress and the CNI are selected, integrated and tested against your requirements.
- Hardening is checked against the CIS Kubernetes Benchmark, with the controls mapped and documented for your auditors.
How we hand over
- Handover includes runbooks for etcd backup and restore, certificate rotation and node replacement.
- Upgrade procedures follow the Kubernetes version skew policy, with a documented order for control plane and node upgrades.
- Evidence for compliance assessments is delivered as configuration and test records, not as audit reports or certifications.
- Your team receives architecture documentation and a recorded walkthrough of day-two operations before the engagement closes.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover.
- Retainers can cover Kubernetes minor version upgrades on the release cadence your team chooses to follow.
- Backup verification and etcd health checks can be included in the retainer scope, so restore tests are repeatable.
- Ask any provider, including DeployOpen, to confirm response times and responsibilities in writing before you sign.
