Adopting Kubernetes as your container orchestration platform is a challenging task. Before considering application deployments, you must design a robust Kubernetes setup, install operational tooling, and build a platform on top of which we will host workloads. Kubernetes offers a vibrant ecosystem of popular open-source tools that we can leverage to build our production-grade clusters, commonly called addons. Selecting and implementing the appropriate tooling for your needs and integrating, and in the case of EKS, integrating the cluster to the rest of your AWS setup is a time-consuming and operationally heavy task.
What EKS Blueprints Are
AWS EKS Blueprints are open-source templates and reference architectures designed to simplify the deployment and management of Kubernetes clusters on Amazon Elastic Kubernetes Service. They include pre-configured modules for networking, add-ons like VPC CNI, CoreDNS, and Prometheus, and integrations with tools like Argo CD or IAM roles for service accounts.
The project exists because customers can utilize EKS Blueprints to configure and deploy purpose built EKS clusters, and start onboarding workloads in days, rather than months. Kubernetes is a powerful and extensible container orchestration technology that allows you to deploy and manage containerized applications at scale. The extensible nature of Kubernetes also allows you to use a wide range of popular open-source tools in Kubernetes clusters. However, with the wide array of tooling and design choices available, configuring an EKS cluster that meets your organization’s specific needs can take a significant amount of time. It involves integrating a wide range of open-source tools and AWS services as well as expertise in AWS and Kubernetes.
AWS customers have asked for patterns that demonstrate how to integrate the landscape of Kubernetes tools and make it easy for them to provision complete, opinionated EKS clusters that meet specific application requirements.
EKS Blueprints for Terraform has been designed to be consumed in the following manners:
- Reference
- Copy & Paste
Consumption Models and Intended Use
EKS Blueprints for Terraform are not intended to be consumed as-is directly from this project. In Terraform speak, the patterns and snippets provided in this repository are not designed to be consumed as a Terraform module. Therefore, the patterns provided only contain variables when certain information is required to deploy the pattern, such as a Route53 hosted zone ID, or ACM certificate ARN, and generally use local variables.
If you wish to deploy the patterns into a different region or with other changes, it is recommended that you make those modifications locally before applying the pattern.
The repository documentation describes two primary ways to use the patterns:
- Reference: Users can refer to the patterns and snippets provided to help guide them to their desired solution. Users will typically view how the pattern or snippet is configured to achieve the desired end result and then replicate that in their environment.
- Copy & Paste: Users can copy and paste the patterns and snippets into their own environment, using EKS Blueprints as the starting point for their implementation. Users can then adapt the initial pattern to customize it to their specific needs.
The patterns provided are intended to show users how they can achieve a defined architecture or configuration in a way that they can quickly and easily get up and running to start interacting with that pattern.
Consumption Comparison
| Aspect | Reference | Copy & Paste |
|---|---|---|
| Goal | Guide implementation | Starting point for implementation |
| Interaction | View configuration and replicate | Copy snippets into own environment |
| Customization | Full control, build from learning | Adapt initial pattern to specific needs |
| Terraform module use | Not as a module | Not as a module, modify locally |
Architecture Scope and Add-On Bootstrap
The patterns can be used by AWS customers, partners, and internal AWS teams to configure and manage complete EKS clusters that are fully bootstrapped with the operational software that is needed to deploy and operate workloads.
A simple blueprint will deploy a new EKS cluster with a managed node group. It will also bootstrap the cluster with vpc-cni, coredns, kube-proxy, aws-load-balancer-controller, metrics server, and cluster-autoscaler add-ons. Indicating that an add-on should be installed in an EKS cluster is as simple as setting a boolean value to true.
The following Terraform example represents a simple blueprint that will deploy a new EKS cluster with a managed node group:
```hcl
module "eks_blueprints" {
source = "github.com/aws-ia/terraform-aws-eks-blueprints?ref=v4.0.2"
EKS Cluster VPC and Subnet mandatory config
vpcid =
private
EKS CLUSTER VERSION
cluster_version = "1.21"
EKS MANAGED NODE GROUPS
managednodegroups = {
mg5 = {
nodegroupname = "managed-ondemand"
instancetypes = ["m5.large"]
min_size = "2"
}
}
}
```
Add-on enablement is handled via a separate module:
```hcl
module "kubernetesaddons" {
source = "github.com/aws-ia/terraform-aws-eks-blueprints//modules/kubernetes-addons?ref=v4.0.2"
eksclusterid = module.eksblueprints.eksclusterid
EKS Add-ons
enableamazoneksvpccni = true
enableamazonekscoredns = true
enableamazonekskubeproxy = true
enableamazoneksawsebscsi_driver = true
Self-managed Add-ons
enableawsforfluentbit = true
enableawsloadbalancercontroller = true
enableawsefscsidriver = true
enableclusterautoscaler = true
enablemetrics_server = true
}
```
Each add-on points to an open-source, upstream Helm repository.
Typical Add-Ons Bootstrapped
| Category | Add-On |
|---|---|
| EKS managed | amazon-eks-vpc-cni |
| EKS managed | amazon-eks-coredns |
| EKS managed | amazon-eks-kube-proxy |
| EKS managed | amazon-eks-aws-ebs-csi-driver |
| Self-managed | aws-for-fluentbit |
| Self-managed | aws-load-balancer-controller |
| Self-managed | aws-efs-csi-driver |
| Self-managed | cluster-autoscaler |
| Self-managed | metrics-server |
Design Caveats and Terraform Structure Guidance
There are a few caveats users should be aware of when using EKS Blueprints for Terraform:
- We recognize that most users will already have an existing VPC in a separate Terraform workspace. However, the patterns provided come complete with a VPC to ensure a stable, deployable example that has been tested and validated.
- Hashicorp does not recommend providing computed values in provider blocks, which means that the cluster configuration should be defined in a workspace separate from the resources deployed onto the cluster, such as addons. However, to simplify the pattern experience, we have defined everything in one workspace and provided instructions to provision the patterns using a targeted apply approach. Users are encouraged to investigate a Terraform project structure that suites their needs; EKS Blueprints for Terraform does not have an opinion in this matter and will defer to Hashicorp's guidance.
- Patterns are not intended to be consumed in-place in the same manner that one would consume a module. Therefore, we do not provide variables and outputs to expose various levels of configuration for the examples
These constraints reflect the project's role as patterns and snippets rather than production modules.
Community, Availability and Support Model
EKS Blueprints for Terraform and CDK are available today on GitHub. They can be used to provision EKS environments in any AWS Region where EKS is currently available. EKS Anywhere support is on our roadmap.
EKS Blueprints is free to use, and you pay for only the resources you deploy. For example, when you deploy an EKS cluster with a managed node group, you will incur standard EKS and EC2 charges.
EKS Blueprints is a community-driven open-source project, not part of an AWS service, so it is therefore not included in AWS enterprise support. All AWS services provisioned by EKS Blueprints, such as EKS, are fully supported. If you need help using EKS Blueprints, please create an issue in our GitHub repository
The EKS Blueprints community is open to everyone. We have a small but growing open-source community that is contributing to the project, and we want to grow our base of contributors. If you are interested in getting involved with the project, we welcome all contributions to Terraform or CDK projects, including bug reports, new features, corrections, or additional documentation.
To get started with EKS Blueprints, please visit either the EKS Blueprints for Terraform or EKS Blueprints for CDK repositories. There you will find links to complete project documentation and instructions on getting started.
Why Blueprints Accelerate EKS Adoption
The framework to facilitate and fast-track this process addresses the time-consuming and operationally heavy task of selecting and implementing appropriate tooling.
In this blog post, we will explore Amazon EKS Blueprints for Terraform, a set of patterns that make it easier and quicker for users to provision complete Amazon Elastic Kubernetes Service clusters.
If you are new to Terraform or interested in other Terraform concepts, these Terraform tutorials might be handy. Similarly, check Kubernetes blog posts if you are learning about Kubernetes.
We will cover what is Amazon EKS Blueprints for Terraform and how patterns simplify cluster provisioning.
Conclusion
The value of EKS Blueprints for Terraform lies in its positioning as opinionated, complete reference architectures rather than generic reusable modules. The project explicitly avoids module-style consumption, which means users gain clarity on how AWS recommends integrating networking, managed node groups, and a curated set of add-ons, but must accept local adaptation and workspace separation as part of the workflow.
Because patterns ship with a VPC and a single workspace definition, they provide a stable, deployable example that has been tested and validated. That completeness accelerates initial learning and prototyping, while the documented caveats about Hashicorp provider guidance and computed values push users toward a mature multi-workspace structure for production use.
The add-on model, where a boolean flag enables vpc-cni, coredns, kube-proxy, aws-load-balancer-controller, metrics server, and cluster-autoscaler, demonstrates how operational software can be bootstrapped declaratively. Each add-on points to an open-source upstream Helm repository, preserving transparency and upgradeability.
Cost and support expectations are also clear: EKS Blueprints is free to use, you pay for only the resources you deploy, and the project itself is community-driven and not included in AWS enterprise support, while the underlying AWS services remain fully supported. This separation makes the tooling suitable for teams that want fast onboarding to EKS in days rather than months, with the responsibility to adapt patterns locally before applying them to their own regions and environments.