Amazon EKS Distro: Kubernetes builds, artifacts, and source limits

What Amazon EKS Distro solves

Amazon EKS Distro, or EKS-D, defines versions of Kubernetes and its dependencies that are used by Amazon Elastic Kubernetes Service to create clusters. It is aimed at organizations that want a Kubernetes distribution aligned with the software deployed by EKS while retaining the option to run those artifacts outside the managed control plane. That distinction matters. EKS-D is not an AWS account, a hosted cluster service, or a cluster installer. It is a release and artifact distribution associated with Kubernetes clusters.

The README states that EKS-D incorporates upstream Kubernetes updates and extended security patching support, and that it follows the Amazon EKS Kubernetes release cycle. The available manifests map EKS-D release identifiers to specific upstream versions. For example, `v1-36-eks-9` corresponds to Kubernetes `v1.36.4`, while `v1-34-eks-24` corresponds to `v1.34.11`. This explicit mapping gives infrastructure teams a concrete release unit to evaluate when they need to trace a cluster version to its upstream patch level.

The project is primarily written in Shell, but the repository also contains Go code and several named component directories. The practical focus is packaging Kubernetes, container networking plugins, CoreDNS, etcd, the AWS cloud provider, and the AWS IAM authenticator. It is therefore most relevant to platform engineers, Kubernetes operators, and organizations seeking EKS-aligned components rather than developers looking for a general-purpose cluster creation CLI.

The EKS-D release and artifact pipeline

The repository layout separates release metadata, component definitions, build tooling, documentation, and development infrastructure. The `Makefile` reads the default release branch from `release/DEFAULT_RELEASE_BRANCH` and the supported branches from `release/SUPPORTED_RELEASE_BRANCHES`. Release identifiers are assembled from those values and production release files. This indicates that release selection is data-driven through files under `release/`, rather than being embedded only in the README.

The `Makefile` also defines a fixed component set named by `ALL_PROJECTS`. It includes `kubernetes_release`, `kubernetes_kubernetes`, `containernetworking_plugins`, `coredns_coredns`, `etcd-io_etcd`, `kubernetes_cloud-provider-aws`, and `kubernetes-sigs_aws-iam-authenticator`. Several of these are classified as internally built projects by `INTERNALLY_BUILT_PROJECTS`. The repository therefore models EKS-D as a collection of versioned upstream projects, not as a single patched Kubernetes source tree.

Published images and artifacts remain the durable output described by the README. New manifests are linked from `https://distro.eks.amazonaws.com`, and each Kubernetes minor line has a release table containing a manifest and upstream Kubernetes version. The repository does not provide a concise, current cluster deployment tutorial, so the documented path is to select a release manifest from the EKS Distro site rather than assume that importing the repository Makefile provisions a cluster.

Preparing the source tree for EKS-D development

The repository does contain a `setup` target in its `Makefile`, but the README's deprecation notice changes how that target should be interpreted. The target runs two scripts from `development/ecr/ecr-command.sh`: one to install the public ECR credential helper and one to log in to the public ECR registry. A conventional invocation of that documented Make target is shown below. It prepares local registry access rather than creating a Kubernetes cluster.

make setup

The underlying commands are visible in the target definition:

development/ecr/ecr-command.sh install-ecr-public
development/ecr/ecr-command.sh login-ecr-public

These commands require the relevant scripts, `make`, and AWS command-line access in the local environment. The Makefile also defines `RELEASE_AWS_PROFILE`, `AWS_ACCOUNT_ID`, and `AWS_REGION`, with a default region of `us-west-2`. Those variables affect release and image-repository configuration in the Makefile, but the README does not give a complete first-build procedure or a verified cluster installation sequence.

For a first real use, the supported route in the current documentation is artifact selection. Choose a Kubernetes minor line, open its linked manifest, and confirm that the manifest release matches the desired upstream patch version. The repository does not document what command should apply that manifest, whether a particular cloud environment is required, or which prerequisites must be satisfied for production use. Inventing those steps would go beyond the README.

Kubernetes version choices exposed in the manifests

The release tables make EKS-D's versioning model unusually clear. A release such as `v1-37-eks-3` maps to upstream Kubernetes `v1.37.0`, while later Kubernetes lines use their own EKS-D sequence. The suffix is therefore meaningful within the distribution's release history, but the README does not state a semantic-version compatibility policy for every dependency. Users who select by an EKS-D label alone risk overlooking the upstream patch release embedded in the corresponding row.

The repository's release-status table lists development build jobs for Kubernetes 1-29 through 1-36. The release tables also include 1-32 through 1-37 entries, with 1-37 shown at release 3. These lists serve different purposes: one concerns development build status, while the other associates downloadable manifests with upstream versions. A release can therefore appear in one context without implying the same status in the other.

For platform teams, the useful first verification is mechanical: take the selected manifest URL, record its EKS-D release, and compare the Kubernetes version in the release table. The README does not explain upgrade compatibility, rollback, skew policy, control-plane component configuration, or how a live EKS cluster relates to a separately operated EKS-D cluster. Those decisions cannot be resolved from this repository alone.

Why EKS-D source builds are no longer the target workflow

The most consequential limitation is the source-build deprecation. The README states that infrastructure for building EKS-D from source will no longer be maintained, including project directories and build scripts. It also says that remaining projects will continue to be built for the time being and that EKS-D will continue publishing images and artifacts to their current repositories and destinations. This creates a clear split: released artifacts remain available, while the repository's source-build implementation is being retired.

The `Makefile` still exposes many component names, image-repository variables, AWS account logic, and build-oriented project paths. Their presence can make the repository appear suitable for reproducing builds. The deprecation notice says otherwise. A team that adopts the source tree for a new internal build platform would be assuming maintenance of infrastructure that AWS explicitly says is no longer maintained. That can turn apparent reproducibility into an ownership burden involving missing fixes, obsolete scripts, and undocumented environment requirements.

This is not an archived repository, and the last push was on 2026-10-12, so repository activity alone should not be treated as evidence that source builds are supported. The README's component-specific end dates and its warning about source-build infrastructure provide the more relevant adoption boundary. Existing consumers of released EKS-D artifacts can continue using those outputs, but prospective source builders need a different plan.

Removed metrics-server and CSI sidecar components

The deprecation notice also changes the component picture inside EKS-D. Releases for new versions of metrics-server stopped being created as of 2025-01-16. Releases for new versions of the CSI sidecar projects stopped as of 2025-03-31. The README says EKS-D no longer uses these projects and therefore no longer continues building them.

For a cluster design that depended on EKS-D's packaged metrics-server or CSI sidecars, the transition is operationally relevant. The README directs users to `https://gallery.ecr.aws/csi-components` for CSI sidecar images. It does not provide an equivalent migration guide for metrics-server, nor does it say that every EKS-D manifest automatically replaces the removed components. As a result, operators should inspect the selected manifest and its workload requirements rather than assume that the distribution still supplies the former package set.

This is a concrete case where adopting EKS-D as a complete bundle may be the wrong approach. An organization needing a tightly coupled set of all former EKS-D components would have to account for the CSI artifact location and independently establish whether metrics-server is still required and where it should come from. The README only confirms the component deprecations and the CSI destination.

Amazon EKS Distro versus managed Amazon EKS

The closest documented alternative is Amazon EKS itself. The two are related rather than interchangeable. Amazon EKS creates and operates a managed Kubernetes service, while EKS-D is the Kubernetes distribution based on and used by that service. According to the README, teams can rely on the same versions of Kubernetes and dependencies deployed by Amazon EKS, including upstream updates and extended security patching support.

The practical difference is the operating boundary. A team selecting EKS-D may want published EKS-aligned artifacts for an environment that is not the managed EKS service, but the repository does not document the surrounding infrastructure needed to run those artifacts. A team choosing Amazon EKS delegates cluster service operation to AWS and starts from a service rather than a distribution manifest. The README does not compare control-plane availability, pricing, node bootstrapping, upgrades, networking, IAM integration, or support boundaries, so it cannot support a broader service comparison.

Other alternatives can include building an unmodified upstream Kubernetes release or selecting components from their upstream projects, but those approaches are not detailed in the repository. Their visible architectural difference is that they do not inherit EKS-D's selected versions, release cadence, and AWS component set. Whether that difference is desirable depends on the need for EKS alignment, which the README does not quantify.

Release maintenance and Apache-2.0 implications

The repository is not archived, and its last push was on 2026-10-12. Recent release entries include `v1-36-eks-9` on 2026-10-02, `v1-35-eks-15` on 2026-10-02, and `v1-34-eks-24` on 2026-10-02. Those dates show recent release publication, but they do not reverse the source-build deprecation. Artifact releases and source infrastructure have different maintenance boundaries in the README.

The project uses the Apache-2.0 license, and the repository includes `LICENSE` and `NOTICE` files. The presence of a permissive license can help with source availability and redistribution analysis, but it does not by itself confirm compatibility for a particular deployment. Teams still need to account for the licenses of Kubernetes and every separately built dependency. This article does not provide legal advice or assert a blanket dependency license outcome.

Users can subscribe to release notifications through the SNS topic `arn:aws:sns:us-east-1:379412251201:eks-distro-updates`. That is the clearest documented upgrade-awareness mechanism in the README. It does not document rollback, migration automation, compatibility windows, or a formal support policy, so those items require verification outside this repository before production adoption.

Editorial conclusion

Organizations that need EKS-aligned Kubernetes artifacts can evaluate the published EKS-D releases, especially when consistency with Amazon EKS matters. Operators should not adopt this repository as a source-build platform because its build infrastructure, project directories, and build scripts are no longer maintained. Before adoption, verify the exact Kubernetes patch level and release-manifest contents, then check whether the removed metrics-server and CSI sidecar components require separate artifact sources.

Frequently asked questions

Official sources

1. aws/eks-distro on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases