Terraform modules for Amazon EKS managed node groups centralize the creation of worker capacity that AWS controls end-to-end. The pattern separates cluster control plane creation from node pool provisioning, allowing multiple node groups with specific instance types, GPU requirements, or autoscaling parameters to be instantiated from a single module definition.
Module Purpose and Core Behavior
The Terraform module to provision an EKS Managed Node Group for Elastic Kubernetes Service is designed to create one logical node group per instance. It can be instantiated multiple times to create EKS Managed Node Groups with specific settings such as GPUs, EC2 instance types, or autoscale parameters.
The module creates an EKS Managed Node Group for an EKS cluster. It assumes you have already created an EKS cluster, but you can create the cluster and the node group in the same Terraform configuration. A full-featured root module exists for this combined workflow.
This module always uses a launch template to create the node group. You can create your own launch template and pass in its ID, or else this module will create one for you. The AWS default for EKS is that if the launch template is updated, the existing nodes will not be affected. Only new instances added to the node group would get the changes specified in the new launch template.
A critical security behavior is documented for remote access. When SSH access is enabled without specifying a source security group, this module provisions EKS Node Group nodes that are globally accessible by SSH (22) port. Normally, AWS recommends that no security group allows unrestricted ingress access to port 22.
Managed Node Group Lifecycle and Value Proposition
Running Kubernetes on AWS means running EKS. And if you want your worker nodes managed by AWS - patched, updated, and drained gracefully during upgrades - managed node groups are the way to go. They handle the EC2 lifecycle so you can focus on your workloads instead of babysitting instances.
EKS Managed Node Groups provide AWS-managed compute capacity for EKS clusters, where AWS handles the lifecycle of the underlying EC2 instances while providing integration with EKS cluster operations like scaling, updates, and node registration.
EKS Managed Node Groups are created through the main EKS module by defining eksmanagednode_groups configurations. For information about self-managed node groups using Auto Scaling Groups, see Self-Managed Node Groups. For serverless compute using AWS Fargate, see Fargate Profiles. For user data and bootstrap configuration, see User Data Configuration.
A production-ready setup with Terraform typically covers the VPC, IAM roles, the cluster itself, node groups with different instance types, and launch template customization.
Network Architecture for Node Placement
The reference architecture for deploying an EKS Cluster and EC2 node group using Terraform consists of a VPC with 2 public subnets and 2 private subnets in different Availability Zones. Each public subnet contains a nat gateway that allows private subnets to access the Internet.
The EKS nodes will be create in the private subnets.
EKS needs subnets across at least two availability zones.
Prerequisites for a Terraform build include the AWS provider configured and a VPC with subnets ready. If starting from scratch, the VPC can be built as part of this setup.
A common provider block used in this context is:
```hcl
terraform {
requiredversion = ">= 1.5.0"
requiredproviders {
aws = {
source = "hashicorp/aws"
version = "~> 5.0"
}
}
}
provider "aws" {
region = "us-east-1"
}
```
Kubernetes clusters managed by Amazon EKS make calls to other AWS services on your behalf to manage the resources that you use with the service.
VPC Module Composition
One example uses a custom AWS_VPC module to create the vpc, subnets, internet gateway, nat gateways etc.
hcl
module "aws_vpc" {
source = "github.com/erozedguy/AWS-VPC-terraform-module.git"
networking = var.networking
security_groups = var.security_groups
}
Variable definitions for networking:
hcl
variable "networking" {
type = object({
cidr_block = string
vpc_name = string
azs = list(string)
public_subnets = list(string)
private_subnets = list(string)
nat_gateways = bool
})
default = {
cidr_block = "10.0.0.0/16"
vpc_name = "terraform-vpc"
azs = ["us-east-1a", "us-east-1b"]
public_subnets = ["10.0.1.0/24", "10.0.2.0/24"]
private_subnets = ["10.0.3.0/24", "10.0.4/24"]
nat_gateways = true
}
}
Security group variable example:
hcl
variable "security_groups" {
type = list(object({
name = string
description = string
ingress = object({
description = string
protocol = string
from_port = number
to_port = number
cidr_blocks = list(string)
ipv6_cidr_blocks = list(string)
})
}))
default = [{
name = "ssh"
description = "Port 22"
ingress = {
description = "Allow SSH access"
protocol = "tcp"
from_port = 22
to_port = 22
cidr_blocks = ["0.0.0.0/0"]
ipv6_cidr_blocks = null
}
}]
}
The nodes are EC2 t3-micro instances managed by EKS in the referenced implementation.
Outputs and Module Artifacts
The module surfaces a set of outputs for integration and inspection.
| Name | Description |
|---|---|
| WARNINGclusterautoscaler_enabled | WARNING |
| eksnodegroupamiid | The ID of the AMI used for the worker nodes, if specified |
| eksnodegroup_arn | Amazon Resource Name (ARN) of the EKS Node Group |
| eksnodegroupcbdpet_name | The pet name of this node group, if this module generated one |
| eksnodegroup_id | EKS Cluster name and EKS Node Group name separated by a colon |
| eksnodegrouplaunchtemplate_id | The ID of the launch template used for this node group |
| eksnodegrouplaunchtemplate_name | The name of the launch template used for this node group |
| eksnodegroupremoteaccesssecuritygroup_id | The ID of the security group generated to allow SSH access to the nodes, if this module generated one |
| eksnodegroup_resources | List of objects containing information about underlying resources of the EKS Node Group |
| eksnodegrouprolearn | ARN of the worker nodes IAM role |
| eksnodegrouprolename | Name of the worker nodes IAM role |
| eksnodegroup_status | Status of the EKS Node Group |
| eksnodegrouptagsall |
Related projects in the ecosystem include:
- terraform-aws-eks-cluster - Terraform module to provision an EKS cluster on AWS
- terraform-aws-eks-workers - Terraform module to provision an AWS AutoScaling Group, IAM Role, and Security Group for EKS Workers
- terraform-aws-ec2-autoscale-group - Terraform module to provision Auto Scaling Group and Launch Template on AWS
Additional modules referenced are terraform-aws-ec2-instance-group for provisioning multiple general purpose EC2 hosts for stateful applications.
Operational Considerations
Because the module always uses a launch template, changes to the template do not retroactively update existing nodes. Only new instances added to the node group would get the changes specified in the new launch template. This behavior matches the AWS default for EKS.
Multiple instantiations allow heterogeneous node groups within the same cluster, for example a general purpose group and a GPU-specific group, each with distinct autoscale parameters, instance types, or node labels.
SSH remote access must be explicitly constrained. Enabling SSH access without specifying a source security group results in nodes that are globally accessible by SSH (22) port, which contradicts AWS best practice that no security group allows unrestricted ingress access to port 22.
Conclusion
Terraform modules for EKS Managed Node Groups provide a declarative path to AWS-managed worker capacity with launch template driven instance configuration and VPC isolated placement. The module assumes an existing EKS cluster or can be paired with a cluster module in the same configuration. Launch templates are always used, with the option to supply a custom template ID or let the module create one. Existing nodes are not replaced on template updates, only new instances pick up changes.
Production deployments typically build a VPC with public and private subnets across at least two availability zones, with NAT gateways in public subnets enabling private subnet internet access for the nodes. Node groups are placed in private subnets, often using instance types such as t3-micro for initial workloads, and can be multiplied for different workload profiles.
Outputs expose the node group ARN, ID, launch template identifiers, IAM role ARN and name, remote access security group ID, and resource metadata for downstream dependencies. Security warnings around unrestricted SSH ingress are central to safe configuration.