02INFRASTRUCTURE AS CODE · LAB
AWS infrastructure with Terraform.
Terraform modules for VPC, EKS, IAM, and managed node groups, with explicit inputs and remote-state configuration.
Terraform
Amazon EKS
Amazon VPC
Private worker nodes
Private worker nodes
Infrastructure code and architecture lab. Some repository inputs require configuration before use. This is not a claim of a currently deployed or production-ready cluster.
The problem.
Cloud resources are connected. I wanted an infrastructure layout that makes those dependencies visible rather than hiding them in a sequence of console clicks.
The approach.
- Organize VPC, EKS, managed node groups, and IAM into separate Terraform modules.
- Describe subnets, routing, cluster access, and control-plane logging explicitly.
- Keep remote-state configuration separate from application deployment concerns.
- Review the cost and availability trade-offs of networking choices before applying.
Decisions that mattered.
Modules around responsibilities
Separate networking, cluster, node-group, and IAM configuration so dependencies can be reviewed without treating the entire infrastructure as one file.
Private nodes need a plan
Private subnet placement alone is not a complete security design. Routing, outbound access, IAM, and cluster access all need explicit decisions.
Review before apply
Validate inputs, check supported service versions, and review a Terraform plan. NAT gateways and managed clusters also carry costs even when application traffic is low.
Evidence & scope.
The public repository contains the module layout and documents required configuration. Infrastructure has not been applied or cloud resources created as part of this website work.
Explore the repositoryWhat I took away.
A useful infrastructure module should make its assumptions visible, especially around access, ownership, and cost.
UP NEXT / 03