Infrastructure automation

EKS Terraform Infrastructure

I designed a repeatable EKS foundation with explicit networking, identity and cluster boundaries. Terraform manages private IPv6 workers, AWS service access, remote state and controlled capacity.

My scopeVPC design · Identity · Terraform modules · Cluster foundation

Independent engineering projectScope & provenance

Designed and built in my own environment to demonstrate AWS and Terraform infrastructure capability. No former-employer configuration, identifiers or production data are used.

System type: AWS infrastructure foundation
Network footprint: 3 AZs and 6 subnets
Service access: 7 VPC endpoints
Node capacity: Desired 3, range 1-5

Engineering brief

The project rebuilds an EKS foundation as Terraform-managed infrastructure so networking, IAM, cluster configuration, node capacity and add-ons can be reviewed and reproduced through a consistent workflow.

The design also explores how private workers can operate without public IPv4 addresses or a default NAT Gateway dependency.

Infrastructure boundaries

VPC moduleOwns subnets, routes, IPv6 behavior, egress-only internet access and AWS service endpoints.
EKS moduleOwns the cluster, IAM integration, OIDC, node capacity, access configuration and foundational add-ons.
Remote stateKeeps infrastructure state outside the local workspace and separates parallel environment work.
CI workflowProduces an explicit plan before apply so infrastructure changes are visible before execution.

Networking decisions

Private worker nodes

Worker nodes are placed in private subnets and do not depend on public IPv4 addresses. Public subnets remain available for internet-facing load balancers where required.

IPv6-primary egress

An egress-only internet gateway allows outbound IPv6 connections without accepting unsolicited inbound traffic. This reduces reliance on NAT for general internet egress.

AWS service access

S3 uses a gateway endpoint, while required AWS APIs use interface endpoints. The design treats endpoint access as an explicit dependency for private nodes and IRSA-enabled workloads.

Implementation sequence

Remote state foundationPrepare isolated state storage and locking before applying the cluster infrastructure.
VPC and subnetsCreate public load-balancer subnets, private worker subnets, routing and IPv6 egress.
AWS endpointsProvide private access to the AWS services required by nodes and controllers.
EKS control plane and identityCreate the cluster, OIDC integration, IAM roles and access mappings.
Capacity and add-onsAttach worker capacity and deploy dependencies such as EBS CSI with the required identity configuration.
Platform handoffExpose outputs and access required by the platform-tools layer.

Tradeoffs & verification

Make private access an explicit dependency: Private workers use seven VPC endpoints for required AWS services, with IPv6 egress handled separately. Service access is part of the network design and deployment order.
Separate infrastructure responsibilities: VPC, identity and EKS modules provide distinct boundaries for reviewing changes. The tradeoff is a dependency sequence that must stay explicit when modules evolve.
Distinguish a foundation from an availability claim: The source inventory documents three availability zones, six subnets and a desired capacity of three nodes within a one-to-five range. An application availability target still needs workload-specific deployment and failure testing.

Infrastructure evidence

Source evidence: the three-AZ architecture and Terraform resource inventory. Select the image to inspect it.

Engineering outcome

The Terraform foundation separates networking, cluster identity and capacity into reviewable provisioning steps. Private workers and Kubernetes add-ons receive the access required for the next platform layer: Karpenter, ingress, observability and GitOps.