Auditing AWS infrastructure with Neo4j: questions inventory cannot answer

AWS infrastructure audits often require answering relationship-based questions, such as whether security controls cover all in-scope workloads or whether systems outside a compliance boundary can reach customer data, which flat inventories cannot reliably address. The post proposes building a typed Neo4j graph from AWS Config configuration data, supplemented by Resource Explorer for inventory validation and Cloud Control only for unsupported resource types, with explicit nodes and relationships for accounts, workloads, networks, identities, policies, controls, data stores, findings, and immutable evidence snapshots. This model enables direct queries for missing GuardDuty coverage, bounded network reachability, and segmentation failures using connected-components analysis, while distinguishing network exposure from actual IAM-authorized exploitability. Vector search can help identify potentially sensitive but unclassified resources, though human review and sources such as Amazon Macie remain necessary for auditable classification. Nightly snapshots and resource fingerprints support drift detection, while an agent memory service can retain investigation history, accepted exceptions, and reusable playbooks without duplicating infrastructure data. The post emphasizes limitations including collection latency, incomplete network modeling, the need for IAM policy evaluation, and the security sensitivity of an organization-wide collector, then recommends event-driven updates, broader network coverage, snapshot metrics, and links from findings to Terraform modules and responsible teams.

Use this post, company, and trend context to find content marketing opportunities, perform competitive analysis, or address product feature gaps via the Plushcap MCP server or the Plushcap API.