Building Amazon EKS clusters with Terraform is a common pattern for teams that want repeatable infrastructure with version control and CI/CD. When that workflow is coupled with GitHub Actions, the result is a pipeline that can plan, validate, and apply infrastructure changes from pull requests to main branch deployments. The Terraform AWS EKS module from terraform-aws-modules provides a consolidated community module for EKS resources, while HashiCorp tutorials and the AWS EKS Blueprints framework show how to structure VPC, security groups, IAM roles, Auto Scaling Groups, and add-ons. The combination of modular Terraform code and GitHub Actions enables state management in S3 with DynamoDB locking, OIDC-based AWS credential configuration, and automated scaling policies.
Introduction
Terraform EKS provisioning can be approached with the official HashiCorp tutorial workflow, with modularization for maintainability, and with GitHub Actions for continuous delivery. The reference patterns cover cloning an example repository for learn-terraform-provision-eks-cluster, using the public EKS module to create VPC, security groups, IAM roles and policies, and Auto Scaling Groups. They also cover splitting configuration into vpc and eks modules, storing state remotely, and deploying add-ons such as ArgoCD, metrics server, cluster autoscaler, and AWS Load Balancer Controller via the EKS Blueprints framework. Module configuration examples show EKS Auto Mode compute_config handling, version pinning, and control plane options.
HashiCorp Tutorial Workflow for Terraform EKS Provisioning
HCP Terraform is a platform that you can use to manage and execute your Terraform projects. It includes features like remote state and execution, structured plan output, workspace resource summaries, and more.
Select the Terraform Community Edition tab to complete this tutorial using Terraform Community Edition.
This tutorial assumes that you are familiar with the Terraform and HCP Terraform workflows. If you are new to Terraform, complete the Get Started collection first. If you are new to HCP Terraform, complete the HCP Terraform Get Started tutorials first.
For this tutorial, you will need:
In your terminal, clone the example repository for this tutorial.
$ git clone https://github.com/hashicorp-education/learn-terraform-provision-eks-cluster
Change into the repository directory.
$ cd learn-terraform-provision-eks-cluster
This example repository contains configuration to provision a VPC, security groups, and an EKS cluster with the following architecture:
The configuration defines a new VPC in which to provision the cluster, and uses the public EKS module to create the required resources, including Auto Scaling Groups, security groups, and IAM Roles and Policies.
Open the main.tf file to review the module configuration.
Modular Configuration and GitHub Actions Pipeline
Breaking the configuration into modules improves maintainability:
```
module "vpc" {
source = "./modules/vpc"
VPC configuration parameters
}
module "eks" {
source = "./modules/eks"
EKS configuration parameters
vpcid = module.vpc.vpcid
subnetids = module.vpc.privatesubnet_ids
}
```
Create a workflow file in .github/workflows to define the deployment process:
name: Terraform AWS Workflow
on:
pull_request:
branches: [ main ]
push:
branches: [ main ]
jobs:
terraform:
runs-on: ubuntu-latest
permissions:
id-token: write
contents: read
steps:
- uses: actions/checkout@v3
- name: Configure AWS Credentials
uses: aws-actions/configure-aws-credentials@v2
with:
role-to-assume: arn:aws:iam::123456789012:role/github-actions
aws-region: us-west-2
- name: Setup Terraform
uses: hashicorp/setup-terraform@v3
- name: Terraform Init
run: terraform init
- name: Terraform Plan
if: github.event_name == 'pull_request'
run: terraform plan -no-color
- name: Terraform Apply
if: github.ref == 'refs/heads/main' && github.event_name == 'push'
run: terraform apply -auto-approve
Store Terraform state in S3.
terraform {
backend "s3" {
bucket = "terraform-state-bucket"
key = "eks/terraform.tfstate"
region = "us-west-2"
dynamodb_table = "terraform-state-lock"
encrypt = true
use_lockfile = true
}
}
Automating EKS with GitHub Actions is a reliable way to manage your new cluster.
The workflow shown uses OIDC permissions with id-token write and contents read, configures AWS credentials via role assumption for us-west-2, and separates plan on pull_request from apply on push to main. State is stored in S3 with encryption enabled and DynamoDB locking.
Remote State and Backend Configuration
Remote state configuration is critical for team collaboration. The backend block used in the reference workflow specifies:
- bucket = "terraform-state-bucket"
- key = "eks/terraform.tfstate"
- region = "us-west-2"
- dynamodb_table = "terraform-state-lock"
- encrypt = true
- use_lockfile = true
This pattern ensures state consistency across GitHub Actions runs and prevents concurrent modifications.
EKS Blueprints Framework and Add-on Deployment
Deploy ArgoCD using the EKS Blueprints framework:
module "kubernetes_addons" {
source = "github.com/aws-ia/terraform-aws-eks-blueprints//modules/kubernetes-addons"
eks_cluster_id =
The completed pattern shows:
module "kubernetes_addons" {
source = "github.com/aws-ia/terraform-aws-eks-blueprints//modules/kubernetes-addons"
eks_cluster_id = module.eks_blueprints.eks_cluster_id
enable_argocd = true
enable_metrics_server = true
enable_cluster_autoscaler = true
enable_aws_load_balancer_controller = true
argocd_helm_config = {
values = [templatefile("${path.module}/values.yaml", {})]
}
}
The EKS Blueprints ecosystem includes supporting modules:
- terraform-aws-eks-blueprint-addon
- Note the singular form Terraform module which can provision an addon using the Terraform helm_release resource in addition to an IAM role for service account (IRSA).
- terraform-aws-eks-blueprint-addons
- Note the plural form Terraform module which can provision multiple addons; both EKS addons using the awseksaddon resource as well as Helm chart based addons using the terraform-aws-eks-blueprint-addon module.
- terraform-aws-eks-blueprints-teams
- Terraform module that creates Kubernetes multi-tenancy resources and configurations, allowing both administrators and application developers to access only the resources which they are responsible for.
Related projects that users should be aware of include:
- terraform-aws-eks-ack-addons
- Terraform module to deploy ACK controllers onto EKS clusters
- crossplane-on-eks
- Crossplane Blueprints is an open source repo to bootstrap Amazon EKS clusters and provision AWS resources using a library of Crossplane Compositions (XRs) with Composite Resource Definitions (XRDs).
- terraform-aws-observability-accelerator
- A set of opinionated modules to help you set up observability for your AWS environments
Terraform AWS EKS Module Configuration
Terraform module which creates Amazon EKS (Kubernetes) resources
- Frequently Asked Questions
- Compute Resources
- User Data
- Network Connectivity
- Upgrade Guides
Please note that we strive to provide a comprehensive suite of documentation for configuring and utilizing the module(s) defined here, and that documentation regarding EKS (including EKS managed node group, self managed node group, and Fargate profile) and/or Kubernetes features, usage, etc. are better left up to their respective sources.
Caution
Due to the current EKS Auto Mode API, to disable EKS Auto Mode you will have to explicity set:
compute_config = {
enabled = false
}
If you try to disable by simply removing the compute_config block, this will fail to disable EKS Auto Mode.
Example module usage with EKS Auto Mode enabled:
```
module "eks" {
source = "terraform-aws-modules/eks/aws"
version = "~> 21.0"
name = "example"
kubernetes_version = "1.33"
Optional
endpointpublicaccess = true
Optional: Adds the current caller identity as an administrator via cluster access entry
enableclustercreatoradminpermissions = true
computeconfig = {
enabled = true
nodepools = ["general-purpose"]
}
vpcid = "vpc-1234556abcdef"
subnetids = ["subnet-abcde012", "subnet-bcde012a", "subnet-fghi345a"]
tags = {
Environment = "dev"
Terraform = "true"
}
}
```
Only after applying with enabled = false can you then remove the compute_config block from your configurations.
A variant for creating just IAM resources for EKS Auto Mode for use with custom node pools:
```
module "eks" {
source = "terraform-aws-modules/eks/aws"
version = "~> 21.0"
name = "example"
kubernetes_version = "1.33"
Optional
endpointpublicaccess = true
Optional: Adds the current caller identity as an administrator via cluster access entry
enableclustercreatoradminpermissions = true
Create just the IAM resources for EKS Auto Mode for use with custom node pools
createautomodeiamresources = true
computeconfig = {
enabled = true
}
vpcid = "vpc-1234556abcdef"
subnet_ids = ["subnet-abcde012", "subnet-bcde012a", "subnet-fghi345a"]
tags = {
Environment = "dev"
Terraform = "true"
}
}
```
EKS Provisioned Control Plane allows you to provision a control plane with increased capacity for larger workloads.
Automatic Scaling Configuration
Implement automatic scaling based on resource utilization:
resource "aws_autoscaling_policy" "cluster_autoscaling" {
name = "eks-cluster-autoscaling"
policy_type = "TargetTrackingScaling"
target_tracking_configuration {
target_value = 75.0
predefined_metric_specification {
predefined_metric_type = "ASGAverageCPUUtilization"
}
}
autoscaling_group_name = aws_eks_node_group.main.resources[0].autoscaling_groups[0].name
}
This policy targets 75.0 percent average CPU utilization for the Auto Scaling Group backing the EKS node group.
Module Parameter Comparison
The following table summarizes key configuration points drawn from the reference material.
| Component | Example Value | Purpose |
| source | terraform-aws-modules/eks/aws | Terraform AWS EKS module |
| version | ~> 21.0 | Module version pinning |
| name | example | Cluster name |
| kubernetesversion | 1.33 | Kubernetes version |
| endpointpublicaccess | true | Public control plane access |
| enableclustercreatoradminpermissions | true | Admin access entry |
| computeconfig.enabled | true | EKS Auto Mode enabled |
| vpcid | vpc-1234556abcdef | VPC identifier |
| subnetids | subnet-abcde012, subnet-bcde012a, subnet-fghi345a | Private subnets |
| tags.Environment | dev | Resource tagging |
GitHub Actions Workflow Steps
The reference workflow defines a sequence of steps for Terraform execution in CI.
- uses: actions/checkout@v3
- name: Configure AWS Credentials
- uses: aws-actions/configure-aws-credentials@v2
- with role-to-assume and aws-region us-west-2
- name: Setup Terraform
- uses: hashicorp/setup-terraform@v3
- name: Terraform Init
- run: terraform init
- name: Terraform Plan
- if: github.eventname == 'pullrequest'
- run: terraform plan -no-color
- name: Terraform Apply
- if: github.ref == 'refs/heads/main' && github.event_name == 'push'
- run: terraform apply -auto-approve
Blog and Community Context
Back to Blog RSS August 29, 2025 • terrateam terraform aws eks kubernetes github-actions infrastructure automation Deploying an AWS EKS Cluster with Terraform and GitHub Actions
Conclusion
The combination of the Terraform AWS EKS module, modular VPC and EKS separation, remote S3 state with DynamoDB locking, and GitHub Actions CI/CD provides a complete path from code to running EKS cluster. HashiCorp tutorials establish the baseline workflow for provisioning VPC, security groups, IAM roles and policies, and Auto Scaling Groups via the public EKS module. The terraform-aws-modules/terraform-aws-eks module adds versioned configuration for EKS Auto Mode, control plane access, and compute configuration with explicit enable/disable semantics. The EKS Blueprints framework extends this with add-on provisioning for ArgoCD, metrics server, cluster autoscaler, and AWS Load Balancer Controller, plus supporting modules for multi-tenancy and observability. GitHub Actions automates plan on pull request and apply on main push with OIDC AWS credential assumption, ensuring auditable, repeatable deployments. Automatic scaling policies based on ASG average CPU utilization round out operational readiness for production workloads.