Amazon Elastic Kubernetes Service provides the control plane and API compatibility for running Kubernetes on AWS, but translating that into a production ready cluster with networking, observability, security controls, and operational add-ons remains a complex engineering task. EKS Blueprints for Terraform addresses that gap by offering open source templates and reference architectures designed to simplify the deployment and management of Kubernetes clusters on Amazon Elastic Kubernetes Service. The project supplies pre-configured modules for networking, add-ons such as VPC CNI, CoreDNS, and Prometheus, and integrations with tools like Argo CD or IAM roles for service accounts. The goal is to move teams from months of design and integration work to days of workload onboarding.
What EKS Blueprints Are and Why They Exist
EKS Blueprints is a collection of Infrastructure as Code modules that help configure and deploy consistent, batteries-included EKS clusters across accounts and regions. The project was introduced to make it easier and faster to adopt Amazon Elastic Kubernetes Service by providing opinionated patterns that bootstrap a cluster with Amazon EKS add-ons as well as a wide range of popular open source add-ons, including Prometheus, Karpenter, Nginx, Traefik, AWS Load Balancer Controller, Fluent Bit, Keda, Argo CD, and more.
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, commonly referred to as add-ons, in Kubernetes clusters. 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.
EKS Blueprints helps implement relevant security controls needed to operate workloads from multiple teams in the same cluster. The patterns demonstrate how to integrate the landscape of Kubernetes tools and make it easy to provision complete, opinionated EKS clusters that meet specific application requirements.
The project is implemented in two popular IaC frameworks, HashiCorp Terraform and AWS Cloud Development Kit, which help automate infrastructure deployments.
Terraform Implementation Model
The Terraform side of EKS Blueprints contains a collection of Amazon EKS cluster patterns implemented in Terraform that demonstrate how fast and easy it is for customers to adopt Amazon EKS. 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.
Customers can utilize EKS Blueprints to configure and deploy purpose built EKS clusters, and start onboarding workloads in days, rather than months.
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.
EKS Blueprints for Terraform is 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.
Consumption Patterns for Terraform Blueprints
EKS Blueprints for Terraform has been designed to be consumed in the following manners:
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.
This design choice reflects the intent to provide learning material and starting points rather than a black box module.
The following table summarizes the intended consumption model.
| Consumption Mode | Purpose | Typical Action |
| Reference | Learn patterns and configuration decisions | View how networking, IAM, and add-ons are wired |
| Copy & Paste | Fast start with customization | Copy snippets, adjust variables, apply locally |
Core Components and Add-on Landscape
A typical blueprint provisions the cluster control plane, VPC and subnet wiring, managed node groups, and a suite of add-ons. Add-on customization is boolean driven, and each add-on points to an open-source, upstream Helm repository.
Commonly bootstrapped Amazon EKS managed add-ons include:
- VPC CNI
- CoreDNS
- Kube Proxy
- AWS Load Balancer Controller
- Metrics Server
- Cluster Autoscaler
- EBS CSI Driver
Commonly bootstrapped self-managed add-ons include:
- Fluent Bit
- AWS EFS CSI Driver
- Karpenter
- Prometheus
- Nginx
- Traefik
- Keda
- Argo CD
The framework also supports IAM roles for service accounts and security controls for multi-team operation.
Example Blueprint Deployment
The following Terraform example represents a simple blueprint that 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:
hcl
module "eks_blueprints" {
source = "github.com/aws-ia/terraform-aws-eks-blueprints?ref=v4.0.2"
# EKS Cluster VPC and Subnet mandatory config
vpc_id = <vpc_id>
private_subnet_ids = <private_subnet_ids>
# EKS CLUSTER VERSION
cluster_version = "1.21"
# EKS MANAGED NODE GROUPS
managed_node_groups = {
mg_5 = {
node_group_name = "managed-ondemand"
instance_types = ["m5.large"]
min_size = "2"
}
}
}
Add-ons are applied in a separate module:
hcl
module "kubernetes_addons" {
source = "github.com/aws-ia/terraform-aws-eks-blueprints//modules/kubernetes-addons?ref=v4.0.2"
eks_cluster_id = module.eks_blueprints.eks_cluster_id
# EKS Add-ons
enable_amazon_eks_vpc_cni = true
enable_amazon_eks_coredns = true
enable_amazon_eks_kube_proxy = true
enable_amazon_eks_aws_ebs_csi_driver = true
# Self-managed Add-ons
enable_aws_for_fluentbit = true
enable_aws_load_balancer_controller = true
enable_aws_efs_csi_driver = true
enable_cluster_autoscaler = true
enable_metrics_server = true
}
This structure separates cluster provisioning from add-on installation and makes the configuration declarative and repeatable.
Security and Multi-team Operations
EKS Blueprints helps you implement relevant security controls needed to operate workloads from multiple teams in the same cluster. Patterns include IAM roles for service accounts, network segmentation via private subnets, and managed node group isolation. The project is designed to be a better, more flexible CI/CD for Terraform, offering maximum security without sacrificing functionality.
Because the blueprints are templates rather than sealed modules, teams can inject organizational guardrails, policy checks, and secret management before applying the pattern.
CDK Parity and Framework Choices
EKS Blueprints is implemented in both HashiCorp Terraform and AWS CDK. With CDK, you can do the following:
- Kubernetes add-on customization
- Each add-on points to an open-source, upstream Helm repository
The choice between Terraform and CDK is typically driven by existing IaC standards, language preference, and team familiarity. Both paths provide the same reference patterns and add-on catalog.
Community, Pricing and Support Boundaries
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 the 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 the GitHub repository.
The community is open to everyone. There is a small but growing open-source community contributing to the project, and contributions are welcome for Terraform or CDK projects, including bug reports, new features, corrections, or additional documentation.
Conclusion
EKS Blueprints for Terraform lowers the activation energy for production grade Amazon EKS by providing proven patterns for networking, node provisioning, and add-on bootstrapping. The project is explicitly designed as reference material and copy-paste starting points rather than a drop-in module, which encourages teams to understand, adapt, and own their infrastructure. By standardizing on VPC CNI, CoreDNS, AWS Load Balancer Controller, metrics and autoscaling primitives, and optional observability and GitOps tools, teams can achieve consistency across accounts and regions while retaining the flexibility to tailor security, scaling, and operational requirements. The dual Terraform and CDK support, combined with a community driven model, makes EKS Blueprints a durable foundation for organizations adopting Kubernetes at scale on AWS.