DevOpsDreams

A Modern Terraform Reference Architecture for Amazon EKS Most EKS failures are not Kubernetes failures. They are boundary failures between Terraform state , VPC capacity, node provisioning, and workload identity. This guide lays out a production-ready reference architecture that keeps those seams explicit. TL;DR A modern Terraform reference architecture for Amazon EKS should separate network, cluster, and add-on state; reserve private subnet capacity for control-plane ENIs and pods; keep a small stable baseline of managed nodes; use Karpenter for bursty or heterogeneous workloads; and choose workload identity deliberately instead of treating IRSA and EKS Pod Identity as interchangeable. The goal is not just to create a cluster, but to make upgrades, add-on lifecycle, IAM boundaries, and node replacement predictable. If you design those boundaries early, EKS gets much easier to operate. A production EKS architecture works better when Terraform state, networking, compute, identity...

Terraform Security Best Practices for AWS: IAM Is Only One Layer Terraform security on AWS is not just a least-privilege IAM exercise. This guide shows how to harden runner identities, trust policies, state backends, validation gates, and provider dependencies so infrastructure changes fail safely instead of failing live. TL;DR Terraform security on AWS breaks in four places: the identity that runs Terraform, the policies and trust relationships it can assume, the state and plan artifacts it writes, and the provider or module dependencies it downloads. AWS and HashiCorp documentation point to a safer pattern: use temporary credentials and scoped roles, cap delegated access with permissions boundaries and organization guardrails, store state remotely with locking and recovery controls, keep secrets out of plans when possible, and pin plus lock providers and modules so reviewable code is the thing that changes. IAM matters, but it is not the whole attack surface. Terraform security i...

Terraform GitOps Bridge Modules for EKS: A Cleaner Way to Bootstrap Clusters and Hand Off to Argo CD Bootstrapping an EKS cluster is not the hard part. The hard part is handing cloud metadata , add-on dependencies, and day-2 ownership from Terraform to GitOps without making both systems fight over the same cluster. This guide explains how the GitOps bridge pattern solves that handoff. TL;DR The GitOps bridge pattern separates cloud provisioning from in-cluster reconciliation. Terraform creates the EKS cluster and external dependencies, then passes cluster-specific metadata to Argo CD. Argo CD uses that metadata to install and reconcile add-ons and workloads from Git. The key operational rule is simple: do not let Terraform and Argo CD both think they own the same add-on. The result is a cleaner day-0 to day-2 handoff and a more maintainable EKS platform. The Hard Part Is Not Creating the Cluster. It Is Handing It Off Cleanly. Most teams can get an EKS cluster on...

Terraform and AWS Organizations: Separate Governance from Provisioning in Multi-Account AWS Multi-account AWS gets messy when one layer tries to do every job. This guide shows a tighter pattern: use AWS Organizations for boundaries and guardrails, and use Terraform to provision into member accounts through explicit cross-account roles. TL;DR A strong multi-account AWS design starts by separating governance from provisioning. AWS Organizations should define account boundaries, OUs, and service control policy guardrails, while Terraform should run from a controlled execution layer and assume roles into member accounts. That keeps the management account thin, makes policy scope easier to reason about, and gives each environment its own state and blast radius. If you need account vending at scale, Account Factory for Terraform helps with account provisioning and customization, but it is not a substitute for disciplined workload Terraform. The Hard Part Is Not “How Do I Use Terraform Ac...

Terraform Drift Detection and Remediation: A Safer Operating Model for Real Infrastructure Terraform drift is rarely just a tooling nuisance. This guide shows how to detect real drift, decide whether to revert or reconcile it, and build a safer remediation workflow around plan , -refresh-only , import , and selective lifecycle rules. TL;DR Terraform usually exposes drift during normal planning because it refreshes managed objects before proposing changes. terraform plan -refresh-only is for reviewing state-only reconciliation , not for blindly fixing accidental drift. If the remote change is now the intended standard, update configuration first and then run a normal plan. Use import when Terraform should adopt an existing object, and use ignore_changes only for narrow, deliberate shared ownership . Build a classification workflow around drift events so emergency fixes do not silently turn into permanent configuration debt. Drift Usually Starts as a "Sma...