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

Security teams should compare the live cloud estate against the Terraform repository to find resources that exist in AWS but have no managed code path. That gap review helps expose drift, undocumented assets, and control blind spots. The practical goal is full cloud visibility, so teams can decide whether to import the resource, retire it, or bring it under governed change control.

Why This Matters for Security Teams

Unmanaged AWS resources are not just a hygiene issue. They can become hidden entry points, data stores, or privilege anchors that never appear in Terraform, review workflows, or change approval records. That makes them hard to inventory, hard to monitor, and easy to miss during incident response. NIST Cybersecurity Framework 2.0 treats asset visibility as a core prerequisite for risk management, and that same logic applies when cloud reality diverges from code.

The gap is especially dangerous in AWS because teams often assume the infrastructure-as-code repository is the source of truth even when console changes, one-off experiments, and inherited accounts have already created drift. This is where findings from NHIMG research on 230M AWS environment compromise and Codefinger AWS S3 ransomware attack matter: attackers exploit what teams fail to catalogue, govern, or retire.

In practice, many security teams discover non-IaC resources only after access review, cost anomalies, or an incident has already exposed the blind spot.

How It Works in Practice

The practical method is a live-to-code reconciliation workflow. Start by pulling an authoritative list of AWS resources from the account or organization level, then compare that inventory against the deployed Terraform state and repository definitions. The goal is not only to find resources with no code path, but also to identify resources that exist in code but are no longer present in AWS, which helps surface drift in both directions.

Teams usually get the best results when they combine multiple discovery sources: AWS Config, Resource Groups Tagging API, CloudTrail, and account-level inventory exports. Terraform alone may miss resources created outside the pipeline, while AWS-native discovery may not tell you whether a resource is actually governed by code. A good review process asks three questions for each asset: was it provisioned by code, does it still need to exist, and if it stays, how will it be brought under managed change control?

• Classify resources as managed, unmanaged, or partially managed.
• Check whether the resource has an owner, a ticket, and a documented purpose.
• Import legitimate resources into Terraform when the code path is missing.
• Retire orphaned assets when they are no longer needed.
• Apply monitoring and tagging standards to every exception until it is resolved.

Current guidance suggests treating this as an ongoing control, not a one-time cleanup, because unmanaged AWS assets tend to reappear whenever teams create urgent fixes outside the pipeline. The same visibility problem that shows up in AWS has also driven broader NHI failures, as described in NHIMG research on the The State of Non-Human Identity Security and the LLMjacking: How Attackers Hijack AI Using Compromised NHIs threat pattern, where exposed identities and secrets become the easiest path to abuse.

These controls tend to break down in multi-account AWS organizations where teams inherit legacy resources, shadow IT creates ad hoc services, and tagging is inconsistent across business units.

Common Variations and Edge Cases

Tighter discovery usually increases operational overhead, so security teams need to balance visibility against the cost of constant reconciliation. There is no universal standard for perfect IaC coverage, especially in environments with brownfield AWS estates, vendor-managed accounts, or emergency production changes.

One common edge case is a resource that was originally created outside Terraform but later imported into state. That asset is not unmanaged anymore, but it still deserves review if the import was incomplete or the settings differ from approved baseline. Another is shared infrastructure, where one platform team owns the account and several application teams consume resources through service catalogs or delegated admin paths. In those cases, the question is less “is it in Terraform” and more “is there a governed owner and change record behind it?”

Security teams should also watch for exceptions such as ephemeral test accounts, third-party managed services, and AWS-native resources created by higher-level services. Best practice is evolving toward policy-backed inventories and continuous drift detection, rather than relying on periodic spreadsheet audits or manual console review. The practical standard is simple: if a resource cannot be tied to a trusted code path or documented control owner, it should be treated as an unmanaged exposure until proven otherwise.

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?