The main risks are configuration drift, inconsistent change control, and higher error rates during maintenance. Manually built clusters, node groups, and add-ons can diverge from the documented baseline, which makes upgrades and security changes harder to predict. Over time, that weakens governance and increases the chance that a routine update breaks production workloads.
Why unmanaged EKS changes become a governance problem
When EKS infrastructure sits outside Terraform for too long, the technical issue stops being just drift and becomes a control problem. The longer manual or ad hoc changes remain unmanaged, the harder it is to prove what is deployed, who approved it, and whether the live cluster still matches the intended baseline. That matters for patching, access control, and recovery planning, especially when teams depend on a stable platform to support application releases and incident response. The risk is not only that the environment changes, but that the organisation loses confidence in the version of the truth it is governing. In practice, many security teams encounter the mismatch only after a routine change or upgrade exposes it.
For broader operational context, NIST’s NIST Cybersecurity Framework 2.0 is useful because it treats governance, change visibility, and recovery readiness as connected outcomes rather than separate chores.
How unmanaged EKS and Terraform drift show up in practice
The practical failure mode is usually incremental. A team makes a quick console change, a cluster add-on is patched manually, or a node group is replaced outside the code path. At first, the change may look harmless, but the Terraform state, the real cluster, and the team’s documented assumptions begin to diverge. Once that happens, every later update becomes harder to reason about because the next plan no longer describes the full reality of the environment.
This is especially visible in Kubernetes platforms because EKS combines managed service settings with cluster-level components, IAM-linked access, networking, logging, and workload dependencies. A manual exception in one layer can affect others. For example, a security setting may be changed in the console, but the automation still believes the prior baseline exists. The result is not just messy records. It is a higher likelihood that upgrades, scaling events, or add-on changes behave differently from what engineers expect.
- State and reality no longer match, so planning becomes less reliable.
- Emergency fixes can be overwritten later because Terraform still treats the old setting as desired.
- Security reviewers lose a clean audit trail for when the platform changed and why.
- Operational teams spend more time reconciling differences than improving the cluster.
The point is not that every manual action is immediately dangerous. The issue is that unmanaged change compounds, and once the gap is wide enough, even routine maintenance can trigger avoidable outages. Where the environment is already inconsistent, this guidance breaks down because no single Terraform run can safely recover a baseline that has never been kept current.
What to watch for when the cluster no longer matches the code
Tighter infrastructure discipline often increases short-term effort, requiring teams to balance speed against reproducibility. That tradeoff becomes sharper when EKS is shared by multiple application owners or when platform changes are frequent. In those cases, the main question is not whether drift exists, but whether it is still bounded and observable.
There are a few edge cases that change the answer. A temporary break-glass change during an incident may be acceptable if it is documented and rapidly reconciled. A long-lived exception is different because it becomes part of the effective platform, even if it never entered source control. Likewise, teams sometimes assume that managed Kubernetes services remove the need for strict infrastructure governance. They do not. They reduce some operational burden, but they do not eliminate the need to keep cluster configuration, add-ons, and supporting access paths aligned with the intended state.
If the environment includes regulated data, strict uptime targets, or multiple delivery teams, the cost of drift rises quickly because the blast radius of an unexpected change is larger. The useful distinction is between a controlled exception and an unmanaged divergence. Once the latter is normalised, the organisation is no longer operating from a reliable baseline.
Risk and Threat Considerations
Long-lived infrastructure drift creates exposure because it weakens the organisation’s ability to trust the effective security posture of the EKS environment. The main risk is not a single bad change, but the gradual loss of control over configuration, permissions, and system dependencies.
Failure mechanism: Manual edits, console-based adjustments, and undocumented add-on changes bypass the code review and state reconciliation that Terraform normally provides. That can leave privileged access paths, security settings, or cluster components in a condition that no longer matches the intended control design, increasing the chance of misconfiguration persisting unnoticed.
Impact: The cluster becomes harder to audit, harder to recover consistently, and more vulnerable to upgrade failure, security gaps, and accidental exposure during maintenance or incident response.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK address the attack and risk surface, while CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | 4 — Secure Configuration of Enterprise Assets and Software | EKS drift is fundamentally a secure-configuration consistency problem. |
| Recommendation — Enforce baseline configuration checks so manual EKS changes cannot persist unnoticed. | ||
| NIST CSF 2.0 | GV.OV-01 — Outcomes Are Measured and Reviewed | Unmanaged EKS change erodes governance visibility and reviewability. |
| CM.01 — Configuration Management | Terraform-managed EKS depends on disciplined configuration control. | |
| RC.RP-01 — Recovery Plan is Executed | Drift makes restoration and maintenance outcomes less predictable. | |
| Recommendation — Track cluster drift as a governance signal and review exceptions before they become normal. Maintain an authoritative configuration baseline and reconcile deviations quickly. Test recovery paths against the recorded EKS baseline, not the assumed one. | ||
| MITRE ATT&CK | T1562 — Impair Defenses | Untracked cluster changes can weaken logging or security controls that defenders rely on. |
| Recommendation — Hunt for unmanaged changes that alter visibility or weaken protective controls. | ||
Practitioner Guidance
What to prioritise: Treat drift detection as an operational control, not a cleanup task. The immediate priority is to know which parts of EKS are managed, which are exceptions, and which changes still need to be reconciled back into code.
What to verify: Confirm that the live cluster, Terraform state, and documented ownership model agree for the items that most affect security and stability: cluster settings, node groups, add-ons, access paths, and logging. If those do not line up, the environment should be treated as partially ungoverned rather than merely “out of sync.”
Decision rule: If a change cannot be reproduced, reviewed, and reverted through the normal delivery process, it should be treated as a temporary exception with an explicit expiry and a named owner. If it is permanent, it belongs in the infrastructure codebase.
Practitioner takeaway: The real danger is not that EKS drifts once, but that teams stop knowing which version of the platform is authoritative; once that happens, every future change carries hidden risk.
Related resources from NHI Mgmt Group
- What breaks when Terraform state and runner infrastructure are not managed carefully?
- What breaks when managed-service admin access is left in place too long?
- What breaks when credentials are managed outside infrastructure as code?
- When should organisations prioritise drift detection and remediation for Terraform-managed infrastructure?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 7, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
