TCP #135: The GuardDuty org-wide gotchas that break your Terraform run
Delegated admin, per-feature enablement, severity routing, and the multi-region and provider traps, all as code
You decided to enable GuardDuty org‑wide as code. Good. Now you’re going to hit the gotchas that the console hides, but Terraform does not.
The console’s org‑wide enablement is a smooth process because AWS paper-overs the underlying complexity. Terraform does not. When you enable GuardDuty across an organization with Terraform, you run into reality:
GuardDuty is regional
Delegated administration has strict ordering
Auto‑enable behaves differently for existing vs new accounts
Member association is not the same as feature enablement
Teams that don’t know this up front get a rollout that half‑works:
GuardDuty on in one region, missing in three
New accounts get it, existing ones don’t (or the reverse)
Delegated administrator set, member accounts not associated
Every one of these is a coverage gap that appears to be a success in the one dashboard you happen to be staring at.
This issue is the map of those gotchas and the code structure that avoids them.
Why the Gotchas Are Expensive
A half‑enabled detection system is more dangerous than an un‑enabled one, because it creates false confidence.
The team believes GuardDuty is running org‑wide. The audit evidence says it is enabled. But coverage has holes:
A region never turned on
Accounts that predate the auto‑enable setting
A feature enabled in the delegated administrator but never propagated
The threat that lands in one of those holes is undetected, and nobody knows the hole exists until an incident review finds it. Discovering it after the fact means a multi‑week backfill project instead of a plan and an apply.
The gotchas are cheap to handle before rollout and expensive after. Doing this as code only pays off if the code encodes the handling so the gaps never open.
How the Gaps Open
These coverage gaps are not due to carelessness. They are the predictable result of GuardDuty’s architecture meeting an org‑wide rollout.
Regional service. GuardDuty is regional. Enabling it is a per‑region action. Teams think in terms of “the organization,” focus on accounts, and then cover only their primary region while silently omitting the others.
Auto‑enable subtlety. Auto‑enable controls whether new member accounts are enabled for GuardDuty. It does not retroactively turn it on for existing accounts. Teams that set auto‑enable and assume full coverage miss every pre‑existing account.
Feature enablement vs association. Associating a member account with the delegated admin brings findings into view. It does not automatically enable additional protection features. Teams that associate all accounts and assume malware protection is on have coverage associated with accounts, not feature coverage.
The console flow hides most of this. Terraform surfaces it. That’s a feature, not a bug: the code forces explicit decisions, and explicit decisions do not turn into silent gaps.
The Decision Framework and the Gotchas
Structuring Terraform correctly requires resolving four things. Each has a gotcha.
