How should security teams identify AWS resources that are not covered by Infrastructure as Code?

Why IaC Coverage Gaps Become Security Gaps

When AWS resources exist outside Infrastructure as Code, the organisation loses a reliable source of truth for ownership, change history, and approved configuration. That matters because undocumented assets are harder to harden, harder to monitor, and easier to miss during incident response or audit evidence collection. For security teams, the issue is not just drift in configuration. It is drift in governance, where a resource may be live, reachable, and privileged without a managed lifecycle.

Teams often focus on whether the resource is technically deployed, but the more important question is whether it can be explained, reviewed, and safely changed. Unmanaged infrastructure tends to accumulate when projects move fast, emergency fixes are made manually, or legacy services outlive the code that created them. The result is a blind spot that can undermine access reviews, logging standards, tagging discipline, and decommissioning decisions. In practice, many security teams discover these resources only after an audit request, an incident, or a cloud bill anomaly forces the inventory question.

For a cross-cutting governance lens, the NIST Cybersecurity Framework 2.0 helps teams treat visibility, ownership, and controlled change as part of normal security operations rather than a one-time cleanup exercise. NIST Cybersecurity Framework 2.0

How Security Teams Find AWS Assets Outside Terraform

The practical method is to reconcile two inventories: what Terraform says should exist and what AWS actually has. That comparison can be done through AWS native inventory sources, cloud security tooling, or scripts that query accounts and regions for deployed resources. The key is to compare at the resource level, not only at the account or service level, because a single account can contain both governed and unmanaged assets.

Security teams usually need to normalise the data before comparison. Names, tags, regions, and account structure can differ from the repository layout, so a simple string match is rarely enough. A better approach is to create an asset catalogue that records resource identifiers, owners, creation source if known, environment, and whether the item is expected to be managed by code. That lets teams separate true exceptions from resources that are deliberately excluded, such as short-lived test assets, emergency break-glass changes, or third-party managed components.

• Export the Terraform-managed resource list from the repository state or module outputs.
• Enumerate live AWS resources across accounts and regions using the same asset categories.
• Compare the two sets to identify resources with no code path, missing ownership, or missing tag lineage.
• Validate each gap to determine whether it is drift, shadow IT, a legacy exception, or a resource pending import.
• Record the decision to import, retire, or formalise the exception under change control.

This is most effective when paired with continuous checks rather than a quarterly spreadsheet review. If the comparison is only periodic, unmanaged resources can persist long enough to become the default production path. The guidance breaks down when resource metadata is inconsistent across accounts or when teams do not enforce a common tagging and ownership model.

Where IaC Drift Is Deliberate, Temporary, or High-Risk

Tighter IaC discipline often improves visibility but increases operational overhead, because every exception must be explained and maintained. Teams therefore need to distinguish between acceptable short-term divergence and unmanaged permanent drift. A temporary manual change made during an outage is not the same thing as a resource that has never had a code owner, but both should be tracked until they are either codified or removed.

One common edge case is tooling that creates supporting AWS resources automatically, such as logging, encryption, or networking dependencies. Those resources may not appear in the same repository path as the primary workload, yet they still need an ownership model and an import strategy if the organisation expects complete governance. Another edge case is shared services created by a platform team but consumed by multiple product teams. In that situation, the absence of a single Terraform file does not mean the asset is unmanaged; it means the ownership boundary is more complex and must be documented clearly.

Security teams should also treat high-risk resources differently from low-risk drift. A public-facing security group, IAM role, or storage endpoint with no managed code path deserves faster escalation than an internal test resource with low blast radius. The practical judgment is to separate cosmetic drift from exposure-bearing drift, because they do not carry the same urgency or remediation path. Guidance on exception handling remains organisation-specific, but the consensus is that exceptions should expire unless they are consciously renewed.

Practitioner Guidance

What to prioritise: Start with resources that can expand exposure quickly if they are unmanaged: internet-reachable services, identity and access objects, logging and monitoring dependencies, and shared network components. Those items are more likely to create hidden blast radius than isolated test assets.

What to verify: Confirm that every suspected gap has an owner, an environment classification, and a documented disposition. If a team cannot explain why a live resource is outside Terraform, it should be treated as an exception needing action, not as a harmless inventory anomaly.

What good looks like: A mature program can show a repeatable reconciliation process, an exception register with expiry dates, and a clear decision for each unmanaged AWS resource. The goal is not perfect theoretical purity; it is a live estate that can be governed, reviewed, and recovered without guesswork.

Practitioner takeaway: The most useful control is not just finding unmanaged AWS resources, but forcing a decision on each one so the gap cannot remain an invisible part of production.

Related resources from NHI Mgmt Group

• How should cloud teams enforce AWS Foundational Security Best Practices across Infrastructure as Code?
• How should security teams handle exposed AWS credentials in code repositories?
• How should security teams prevent secrets from being hardcoded in Infrastructure as Code?
• How should security teams manage backup policies in Infrastructure as Code environments?