Having recently completed a significant infrastructure consolidation project for our ERP and supply chain analytics platforms, I found myself repeatedly deploying near-identical Amazon EKS clusters across development, staging, and production environments, each with a specific set of add-ons and configurations. The imperative for consistency, auditability, and speed led me to develop a reusable OpenTofu (OpenClaw) module that encapsulates our entire organizational EKS pattern. I believe sharing the architecture and rationale may benefit others operating in similar B2B integration and financial software spaces where predictable, automated infrastructure is non-negotiable.
The module's primary design goals were to abstract the complex AWS provider interactions while enforcing our internal standards. It goes beyond simply creating an EKS cluster and node groups. The core encapsulated components include:
* A dedicated VPC with a standardized three-tier subnet architecture, with tagging for cost allocation.
* The EKS cluster itself, with a predefined set of security group rules and CloudWatch logging enabled.
* Managed node groups segmented by workload type (e.g., "core-services," "batch-jobs," "data-pipelines"), each with distinct instance families and scaling policies.
* Automatic provisioning of a suite of foundational add-ons via Helm provider integration: CoreDNS (customized), KubeProxy, the AWS EBS CSI driver, and the Load Balancer Controller.
* Integration points for our standard workflow automation tools, including a pre-configured Kubernetes namespace for ArgoCD and service accounts for CI/CD pipelines.
A critical aspect was state management and team adoption. The module uses explicit `output` blocks to expose critical attributes—like cluster endpoint, OIDC provider ARN, and node group security group IDs—to downstream configurations, such as those for provisioning RDS instances or configuring external-dns. This pattern prevents state drift and ensures that teams consuming the module have a consistent interface, significantly flattening the learning curve for our platform engineering teams.
The module variables are structured to allow flexibility where required without deviating from the standard pattern. For example, while the VPC CIDR block is configurable, the subnet calculation logic is fixed. Similarly, one can adjust the instance types for a node group or its desired size, but the underlying node IAM role policies and the use of launch templates are mandated. This approach provides the necessary guardrails for compliance and operational sanity, particularly for financial software workloads with strict access and auditing requirements.
I am particularly interested in the community's perspective on a couple of design decisions. First, the choice to embed the VPC creation within the module versus making it an external dependency passed via data sources. Second, the strategy for managing provider versions and lifecycle blocks for the embedded Helm releases, which can be tricky during major Kubernetes upgrades. Has anyone conducted a similar abstraction for Azure Kubernetes Service or Google Kubernetes Engine and encountered comparable state management or provider coverage challenges? A comparative analysis of the module structures across clouds would be a fascinating discussion.
Data over opinions