# EKS Anywhere: self-managed Kubernetes on VMware, bare metal and Nutanix using EKS Distro

> EKS Anywhere brings the same Kubernetes distribution that powers managed EKS to on-premises infrastructure. It supports VMware vSphere, bare metal via Tinkerbell, and Nutanix, and is designed to operate with no dependency on AWS services after initial setup.

**aws/eks-anywhere** — Run Amazon EKS on your own infrastructure 🚀

- Repository: https://github.com/aws/eks-anywhere
- Website: https://anywhere.eks.amazonaws.com
- Stars: 2,100 · Forks: 328
- Language: Go
- License: Apache-2.0
- Published: 2026-10-09 · Updated: 2026-10-09 · Language: en
- Canonical page: https://hysenlabs.com/projects/aws-eks-anywhere

## EKS Distro as the base: same Kubernetes build that AWS runs for managed EKS

EKS Anywhere does not bundle its own build of Kubernetes. It builds on Amazon EKS Distro, which is the same distribution that powers EKS on AWS. This matters for version alignment: when AWS releases a new Kubernetes minor version for managed EKS, EKS Anywhere tracks that same version via EKS Distro rather than maintaining a separate fork. The consequence is that a cluster spec validated against EKS Anywhere should run workloads without requalification against a different Kubernetes variant.

The README states the goal plainly: full lifecycle management of multiple Kubernetes clusters that are capable of operating completely independently of any AWS services. That goal distinguishes EKS Anywhere from a managed service wrapper. The cluster runs on the customer's own infrastructure, and the management plane stays inside the customer's network rather than residing in an AWS region.

Conformance certifications underline this. The repository carries CNCF conformance badge links for Kubernetes 1.25, 1.26, 1.27, 1.28, 1.29, 1.30, 1.31, 1.32, 1.33 and 1.34. Each certificate corresponds to a pull request in the cncf/k8s-conformance repository. Conformance means the API surface and workload behavior match the upstream Kubernetes specification, which matters for portability across providers.

## Three infrastructure providers: VMware vSphere, Tinkerbell bare metal and Nutanix

The go.mod file shows three distinct infrastructure integrations in the direct dependencies. VMware support comes from github.com/vmware/govmomi v0.51.0, which is the Go client library for the VMware vSphere API. Bare metal provisioning uses github.com/tinkerbell/tink v0.12.2, Tinkerbell's workflow engine. Nutanix clusters are handled through github.com/nutanix-cloud-native/cluster-api-provider-nutanix v1.3.2 and github.com/nutanix-cloud-native/prism-go-client v0.3.4.

The repository also includes support for AWS Snowball Edge, reflected in github.com/aws/eks-anywhere/internal/aws-sdk-go-v2/service/snowballdevice. Snowball Edge is an AWS edge computing device for deployments in disconnected or physically remote locations, and its presence as an internal dependency means EKS Anywhere can target that device class in addition to on-premises VMs and servers.

Each provider covers a different hardware acquisition path. The VMware path assumes an existing vSphere environment. The bare metal path uses Tinkerbell to bootstrap machines from scratch, which requires pre-provisioned network and DHCP/TFTP infrastructure. Nutanix runs hyperconverged infrastructure. A local Docker provider also exists, visible in the repository topics, and covers development and testing scenarios rather than production deployments.

## Tinkerbell and bmclib bring out-of-band hardware control to the bare metal path

Bare metal provisioning in EKS Anywhere depends on more than the Tinkerbell workflow engine. The go.mod dependency github.com/bmc-toolbox/bmclib/v2 v2.1.1 adds BMC (Baseboard Management Controller) support. A BMC is the hardware management interface built into servers, and bmclib provides a unified API for Redfish, IPMI and vendor-specific protocols across different server hardware. In practice, the bare metal provider interacts with BMC interfaces to power cycle machines, set boot order and monitor hardware state during provisioning.

The examples/tinkerbell/ directory in the repository holds example configurations for the Tinkerbell provider. Its contents are not reproduced here, but the directory's existence confirms that workflow templates for Tinkerbell provisioning ship with the project.

This dependency chain sets the prerequisites for the bare metal path clearly. You need not just a Kubernetes cluster, but operational BMC access to each server, network infrastructure that supports PXE booting, and Tinkerbell services running alongside EKS Anywhere. For organizations that already manage bare metal at this level, the toolchain fits into what they have. For those new to bare metal provisioning, Tinkerbell and BMC management add meaningful operational complexity before the first node joins a cluster.

## The CLI setup lives at anywhere.eks.amazonaws.com; the go.mod sets Go 1.26 as the build floor

The README does not provide installation commands or a cluster creation walkthrough. It points to https://anywhere.eks.amazonaws.com/docs/getting-started/ for those steps and to https://anywhere.eks.amazonaws.com/ for full documentation. For anyone evaluating EKS Anywhere, the official documentation site is the starting point, not the GitHub README.

What the go.mod does confirm is the Go version floor. The module requires Go 1.26:

```toml
module github.com/aws/eks-anywhere

go 1.26.0
```

This is relevant only if you plan to build from source. For standard adoption, EKS Anywhere distributes a CLI and cluster images through its own release pipeline, and the getting started documentation covers that path. The Makefile in the repository is for internal development: it defines integration test environment variables like INTEGRATION_TEST_UBUNTU_AMI_ID, INTEGRATION_TEST_STORAGE_BUCKET and INTEGRATION_TEST_INSTANCE_PROFILE, none of which are part of a standard cluster deployment.

The repository structure shows a cmd/ directory for CLI commands and a controllers/ directory for Kubernetes controllers. The designs/ directory holds design documents for architectural decisions, which is a useful resource for understanding why the project is built the way it is.

## etcdadm-bootstrap-provider and etcdadm-controller manage external etcd for Kubernetes control planes

Two direct dependencies in go.mod reveal how EKS Anywhere handles etcd, the key-value store at the core of every Kubernetes control plane. github.com/aws/etcdadm-bootstrap-provider v1.0.22 and github.com/aws/etcdadm-controller v1.0.28 are AWS-maintained projects built on top of etcdadm, a tool for bootstrapping and managing etcd clusters.

An external etcd deployment separates the etcd cluster from the Kubernetes API server nodes. This is a production topology where etcd runs on dedicated machines rather than co-located with control plane components, which simplifies backup, restore and upgrade operations for each component independently. The presence of these as direct dependencies means EKS Anywhere supports this topology by design rather than requiring manual etcd management on top.

The go.mod also lists github.com/aws/eks-anywhere-packages v0.4.5. This corresponds to the EKS Anywhere curated packages feature, which provides a set of tested software packages (such as cert-manager and other common cluster add-ons) distributed and versioned alongside the EKS Anywhere release. That feature means cluster add-ons do not need to be sourced from upstream Helm charts that may not align with the EKS Anywhere release cycle.

## Prow CI, cherry-picks and the September 2026 release cadence

Testing runs on Prow. EKS maintains a dedicated Prow instance at https://prow.eks.amazonaws.com/. The build status and conformance test status badges in the README point to AWS CodeBuild jobs rather than to public Prow job views, which means build results from the community Prow instance are not visible in the repository header. End-to-end tests live under test/e2e/ in the repository, and the README references a developer guide for running E2E tests locally.

Release management follows a cherry-pick model for backporting fixes to release branches. The CONTRIBUTING.md and a developer document at docs/developer/cherry-picks.md describe the process. Backports go through cherry-pick automation rather than manual merges, which is standard for projects maintaining multiple active release branches.

The recent release history covers v0.26.2 on 2026-09-10, v0.26.1 on 2026-08-13 and v0.25.4 on 2026-09-24. The last push to the main branch was on 2026-09-28. Two minor release lines were receiving updates through September 2026, which suggests overlapping support for at least two minor versions. The CHANGELOG.md at the repository root tracks changes per release.

## Where EKS Anywhere is the wrong tool: the AWS dependency trade-off and upgrade cost

The design goal of operating completely independently of any AWS services is meaningful but qualified by the go.mod. The direct dependencies include github.com/aws/aws-sdk-go v1.50.36, github.com/aws/aws-sdk-go-v2, github.com/aws/aws-sdk-go-v2/service/ec2 and github.com/aws/aws-sdk-go-v2/service/ecr. ECR (Elastic Container Registry) is the source for EKS Distro container images by default. Whether that constitutes a hard AWS dependency depends on whether you mirror the images to a local registry: the project supports airgapped deployments, but the documentation site rather than the README describes the steps.

For teams that already operate a cloud-managed Kubernetes platform, EKS Anywhere adds the overhead of maintaining a distribution rather than consuming a service. Cluster upgrades, etcd backup strategy, certificate rotation and hardware failure handling become operational responsibilities that managed EKS absorbs. The right use case is an organization that cannot or does not want to run workloads in an AWS region, not one that simply wants more control than managed EKS offers.

Security disclosures go through the AWS vulnerability page at aws.amazon.com/security/vulnerability-reporting rather than the GitHub issue tracker. Opening a public issue for a security problem is explicitly discouraged, which is typical for a company-backed project with a formal response process.

## Conclusion

EKS Anywhere suits teams that operate VMware vSphere, bare metal or Nutanix clusters and want Kubernetes tooling consistent with managed EKS. The EKS Distro base means workloads validated on AWS EKS carry over without requalification. Skip it if your organization has no on-premises hardware, no capacity to maintain a self-managed Kubernetes distribution, or no team with experience in bare metal provisioning and BMC management. Before adopting, confirm at anywhere.eks.amazonaws.com that your provider is listed, and check that the v0.26.x release covers your required Kubernetes minor version.

## FAQ

### What is EKS Anywhere?

EKS Anywhere is an open source deployment option for Amazon EKS that lets you run Kubernetes clusters on your own infrastructure using VMware vSphere, bare metal servers or Nutanix. It uses EKS Distro, the same Kubernetes distribution that powers managed EKS on AWS.

### Does EKS Anywhere require an AWS account?

The README states that its goal is clusters capable of operating completely independently of any AWS services. However, the default container image source is ECR, and airgapped setups that mirror those images to a local registry are documented on the official documentation site.

### What infrastructure providers does EKS Anywhere support?

Based on the repository dependencies and topics, EKS Anywhere supports VMware vSphere, bare metal via Tinkerbell, Nutanix and AWS Snowball Edge. A Docker provider exists for local development and testing.

### Which Kubernetes versions does EKS Anywhere certify?

The repository carries CNCF conformance certifications for Kubernetes 1.25 through 1.34. Each certification has a corresponding pull request in the cncf/k8s-conformance repository.

### Where do I find EKS Anywhere installation instructions?

The README points to https://anywhere.eks.amazonaws.com/docs/getting-started/ for installation steps and cluster creation. The GitHub README does not include those commands.

## Sources

- [aws/eks-anywhere on GitHub](https://github.com/aws/eks-anywhere)
- [License: Apache-2.0](https://github.com/aws/eks-anywhere/blob/main/LICENSE)
- [Project website](https://anywhere.eks.amazonaws.com)
- [README](https://github.com/aws/eks-anywhere/blob/main/README.md)
- [Releases](https://github.com/aws/eks-anywhere/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/aws-eks-anywhere