Terraform ownership for a multi-service AWS estate

A Terraform estate that covers EKS, IAM, KMS, messaging, and the supporting AWS services will fail in one of two ways: everything in one state file until a plan is unreadable, or everything fragmented until nobody knows which root module owns a role. Both are ownership problems wearing infrastructure clothing.

Boundaries that held up

Cluster and identity separate from application resources. EKS, node IAM, OIDC provider, and cluster add-ons live in platform-owned roots. Service teams own the resources their workload needs — queues, buckets, IRSA roles scoped to their namespace — in roots they can plan without touching the control plane.

IAM as deliberately small modules. A role that three services share is a coupling you will regret. Prefer a role per workload with a clearly named policy, even when the policies look similar. Duplication in IAM is cheaper than an incident where rotating one team’s credentials breaks another.

KMS keys owned next to the data. Keys that encrypt a particular store belong with that store’s module, not in a global “security” stack that every change has to pass through.

Blast radius

State locking and CI plans catch conflicts; they do not limit damage. The question I ask of a new root is: if this apply goes wrong, what else goes with it? If the answer includes “every IRSA role in the account,” the root is too wide.

Practical checks:

• Can an application team apply their stack without credentials that can destroy the cluster?
• Does a failed apply in messaging take down identity changes mid-flight?
• Are terraform state mv operations rare, or a monthly ritual?

What I’d refuse next time

A shared “platform misc” root that accumulates leftovers. Leftovers are how ownership evaporates. If something does not fit an existing root, either extend the boundary on purpose or create a new one with a name that says what it is for — not misc, not shared, not legacy.