The problem and the implementation
The problem
Cluster infrastructure and platform controllers need different change cycles. Combining them can make upgrades harder to reason about and leave deployment dependencies hidden in a single workflow.
What the source shows
The public example separates the VPC, EKS cluster and node groups from Helm-managed add-ons. Remote-state outputs connect the two layers, so engineers can review an infrastructure change separately from a controller upgrade.
System flow
- 01
Cluster Terraform root
- 02
VPC + EKS + IAM
- 03
Published state outputs
- 04
Add-ons Terraform root
- 05
Helm controllers
Key decisions and trade-offs
- 01
Separate the lifecycle boundaries
Keep the AWS foundation and cluster add-ons in distinct Terraform roots. Document the order of operations and which team owns each layer.
- 02
Make cost and availability choices explicit
The example uses system and application node groups, Spot application capacity and environment-dependent NAT settings. Validate these against workload availability needs.
- 03
Review access before adoption
Narrow example IAM permissions and establish the runner network path to the cluster. Review state access and staging recovery before a production rollout.
Demonstrated result and its limits
The repository provides a reviewable foundation and explicit dependencies between layers. It is a public implementation example, not a published client benchmark or a guarantee of provisioning time.
What to validate in your environment
A project acceptance plan should include Terraform validation, a reviewed plan, endpoint reachability, controller readiness and a staged upgrade or rollback exercise.
Inspect the evidence
These links identify the source revision used for this write-up.