terraform-aws-eks-blueprints: EKS cluster patterns you copy, not a module you call

What terraform-aws-eks-blueprints actually is

The README opens by calling the project a collection of Amazon EKS cluster patterns implemented in Terraform. The unit of delivery is a pattern, not a reusable library: a directory of Terraform that stands up a cluster and the operational software around it. The repository's top level reflects that, with a patterns/ directory next to docs/, mkdocs.yml and the usual community files.

The README is unusually direct about the consumption model. Patterns "are not intended to be consumed as-is directly from this project" and "are not designed to be consumed as a Terraform module." Variables appear only when a pattern needs a specific input, such as a Route53 hosted zone ID or an ACM certificate ARN, and the rest is local variables. Outputs are deliberately not exposed the way a module would expose them, to avoid confusion about how the code is meant to be used.

That answers the first question a reader usually has. If you arrived looking for something like terraform-aws-modules/eks/aws, a module you reference with source and version, this is a different shape of artifact. It is closer to a worked example you fork into your own repository.

Who the patterns are for, and the integration work they remove

The stated audience is AWS customers, partners and internal AWS teams. The motivation section describes the problem plainly: Kubernetes is extensible, a wide array of tooling and design choices exists, and configuring an EKS cluster that meets an organization's needs takes significant time because it means integrating open source tools and AWS services while holding expertise in both.

The promise is a starting point rather than a finish line. The README says customers can use the blueprints to configure and deploy purpose-built clusters and start onboarding workloads "in days, rather than months." Treat that as the project's claim about its own value, not a measured result.

The practical fit is a platform or infrastructure engineer who already knows Terraform and EKS and wants a reference that wires the pieces together: cluster, node groups or Fargate profiles, and addons. Topics on the repository include bottlerocket, eks-addons, eks-fargate and fargate, which tells you which integration paths the patterns cover. If you have never written Terraform, the patterns will not teach you the language; they assume you can read HCL and judge whether a given choice suits your account.

How a pattern is structured and where state lives

Each pattern is a self-contained Terraform configuration. Because the README says patterns generally use local variables and only declare variables when information is required to deploy, the data flow is flat: you edit the pattern's files, set the few required values, and run Terraform against it. There is no module boundary to pass inputs across.

That flatness has a direct consequence for state. Nothing in the README describes a shared backend configuration shipped with the patterns, so the state location is whatever you configure when you copy the code into your own repository. If you plan to run several clusters from several copies, backend and naming become your responsibility, and the GitLab component listed under related projects exists precisely because one community use case needed environments named after branches and project IDs to allow many clusters in the same account and region.

Addons are handled outside this repository. Two supporting modules are named explicitly: terraform-aws-eks-blueprint-addon (singular), which provisions an addon using the Terraform helm_release resource plus an IAM role for service account, and terraform-aws-eks-blueprints-addons (plural), which provisions multiple addons using both aws_eks_addon and Helm chart based addons through the singular module. A third, terraform-aws-eks-blueprints-teams, creates Kubernetes multi-tenancy resources so administrators and developers see only what they are responsible for. Those are separate projects with their own release cycles, and the README points at them rather than absorbing them.

Installing terraform-aws-eks-blueprints and running a first pattern

There is no package to install. The README's consumption section gives two modes: reference, where you read a pattern to see how a result is achieved and replicate it, and copy and paste, where you take the pattern into your own environment as a starting point. The homepage at aws-ia.github.io/terraform-aws-eks-blueprints is the documentation entry point, and the repository carries a patterns/ directory.

Start by cloning the repository so you can read and copy a pattern locally.

git clone https://github.com/aws-ia/terraform-aws-eks-blueprints.git
cd terraform-aws-eks-blueprints/patterns
ls

You should see the pattern directories. Pick one whose addon set and node model match what you intend to run, then copy it into your own repository rather than working inside the clone. The README recommends making region or other modifications locally before applying the pattern.

Once the pattern is in your repository, initialize Terraform and review the plan before anything is created.

terraform init
terraform plan
terraform apply

Before apply, check the pattern for the inputs the README says are declared only when required, such as a Route53 hosted zone ID or an ACM certificate ARN, and supply real values. Because patterns do not expose outputs the way a module does, read the configuration to learn the cluster name and endpoint rather than expecting a documented output block. The README does not document a rollback procedure, so plan the destroy path yourself.

The consumption model is the main limitation

The clearest constraint is the one the project states about itself. Because patterns are not a module, you do not get versioned inputs, a stable interface, or upgrade paths that a module maintainer would owe you. Upstream changes land in the default branch, and pulling them means diffing your adapted copy against the pattern. The repository's own release list shows v5.0.0 tagged on 2023-08-09, with v4.32.1 and v4.32.0 earlier in 2023, while the default branch was pushed on 2026-09-22. If you pin to a tag you get a known point; if you track main you get whatever the patterns look like now.

There is a second, quieter cost. Copy and paste means the code becomes yours, including its bugs and its defaults. The README's note that variables are exposed only when required is convenient for a demo and inconvenient for a fleet: the same pattern applied in ten accounts will need ten sets of local edits unless you refactor it toward a module yourself.

Finally, this is the wrong tool if you want a supported product with a compatibility contract, or if your organization has standardized on a module registry and a policy that forbids vendored infrastructure code. The project does not claim to be that, and reading it as one will lead to disappointment.

How it differs from terraform-aws-modules/eks/aws

The most common alternative engineers weigh is terraform-aws-modules/eks/aws, the community EKS module. The difference is not feature coverage, it is the interface. That module is referenced with a source address and a version constraint and configured through documented variables; it is designed to be called, and its inputs and outputs are the contract.

terraform-aws-eks-blueprints takes the opposite position on purpose. Its README says patterns will not expose variables and outputs the way Terraform modules do, to avoid confusion around the consumption model. So the comparison is: a module that gives you a stable surface and expects you to supply the addons and opinions, versus a pattern collection that supplies the opinions in code and expects you to own the surface.

For addon-heavy clusters there is a middle path inside the same family. The plural module terraform-aws-eks-blueprints-addons provisions multiple addons, both through aws_eks_addon and through Helm charts via the singular module. Teams that want the module contract for addons while keeping cluster creation under their own module can take that piece and leave the patterns behind. The README lists both modules as separate projects, so their versioning is independent of this repository.

Licence, maintenance and what upgrading costs

The repository is licensed Apache-2.0, with a LICENSE and NOTICE.txt at the top level. Apache-2.0 permits commercial use and modification and includes a patent grant; it also requires that you preserve copyright and licence notices and state significant changes. Since the recommended workflow is copying code into your own repository, that notice obligation travels with the copy. This is a description of the licence text, not legal advice, and your counsel should review how you attribute vendored files.

The last push to the default branch was on 2026-09-22, two days before this article's reference point, so the repository is receiving changes. That is not the same as a stable release cadence: the newest release listed is v5.0.0 from 2023-08-09. The gap between branch activity and tagged releases is the upgrade cost in one number. If you track tags, you are on code from 2023. If you track the branch, you inherit changes without a release note to read.

Budget for two ongoing tasks that the patterns push onto you. First, re-diffing your adapted copy against the upstream pattern when you want a fix. Second, tracking the separate addon modules, since terraform-aws-eks-blueprint-addon, terraform-aws-eks-blueprints-addons and terraform-aws-eks-blueprints-teams version independently of this repository.

Editorial conclusion

Adopt terraform-aws-eks-blueprints if you want a working reference for a complete EKS cluster with addons and are willing to copy and adapt the code under your own state and naming. Do not adopt it if you need a versioned module with stable inputs and outputs; the README states the patterns are not designed to be consumed as a Terraform module, and the addon modules live in separate repositories (terraform-aws-eks-blueprint-addon and terraform-aws-eks-blueprints-addons). Before you start, verify which pattern directory matches your target region and addon set, and confirm the addon module versions you will pin, because the latest release listed is v5.0.0 from 2023-08-09 while the default branch received commits on 2026-09-22.

Frequently asked questions

Official sources

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