EKS Cluster

Amazon EKS is AWS’s managed Kubernetes control plane. zop.dev provisions a fully hardened cluster with autoscaling, secret encryption, ingress, certificates, and a complete monitoring stack pre-installed, turning a multi-week platform build into a single provisioning job.

A hardened cluster with add-ons, IAM, and Route 53 wiring

EKS cluster (upstream terraform-aws-modules/eks v20.31.6) with KMS key for secret envelope encryption, RSA-2048 TLS key, self-managed node group (AL2023 AMI, containerd), aws-ebs-csi-driver addon, 3 security groups, Kong admin load-balancer target group, Route 53 wildcard CNAME to the nginx LB, Karpenter discovery tags, 6 IAM policies, 2 roles, 3 IAM users with access keys (cluster_issuer, observability_s3, velero), and Secrets Manager entries for Kafka and observability. Helm add-ons installed: cert-manager, kube-prometheus-stack, grafana, velero, cluster-autoscaler, fluent-bit, kubernetes-event-exporter, karpenter, prometheus-msteams, reloader, secrets-store-csi-driver, AppDynamics cluster-agent, kubernetes-replicator, metrics-server, ingress-nginx.

Node config, Karpenter, logging, and alert thresholds

Kubernetes 1.34 (hardcoded); node_config {node_type, min_count > 0, max_count < 30}; control-plane logging for api, audit, authenticator, controllerManager, scheduler; enable_irsa true; authentication_mode API_AND_CONFIG_MAP; public endpoint on; karpenter_configs {enable, machine_types[], capacity_types on-demand|spot}; velero_schedule default 0 2 * * *; cluster alert thresholds (cpu/memory 80/20, node and pod count 80, nginx 5xx 5 percent, disk 20); fluent-bit sinks: loki, http, splunk, datadog, new_relic, slack, cloudwatch; optional Kong Enterprise with CIDR whitelist.

Kubernetes 1.34 and the AL2023 worker AMI

Kubernetes version is pinned at 1.34. Worker AMI defaults to amazon-eks-node-al2023-x86_64-standard-1.34 from owner 602401143452.

What gets created that you did not ask for

This is the part worth reading before you run it. Alongside the cluster you get 3 IAM users with access keys (cluster_issuer, observability_s3, velero), 6 IAM policies, 2 roles, 3 security groups, a Route 53 wildcard CNAME pointing at the nginx load balancer, and Secrets Manager entries for Kafka and observability.

The IAM users matter most. Long-lived access keys are the credential type most security reviews flag, and they are created here because several of the Helm add-ons predate IRSA support. They are real credentials with real permissions, and they need rotating like any other.

What you cannot change

Kubernetes 1.34 is hardcoded. Not a default; hardcoded. If you need a different version this module is not the path, and upgrading is a platform change rather than a variable.

Node group max count is capped at 30. min_count must be greater than zero, so the cluster cannot scale to nothing.

The add-ons are the real cost

Fifteen Helm releases install by default: cert-manager, kube-prometheus-stack, grafana, velero, cluster-autoscaler, fluent-bit, karpenter, metrics-server, ingress-nginx and more. kube-prometheus-stack in particular is not small. It runs Prometheus, Alertmanager and Grafana with persistent volumes, and on a small cluster the monitoring stack can outweigh the workload.

Velero also creates an S3 bucket and takes a snapshot on the default 0 2 * * * schedule, which bills for storage from day one.

Where it fits

This is a batteries-included platform build, not a minimal cluster. If you want EKS and nothing else, provisioning it here and deleting fourteen add-ons is more work than starting smaller.