If you use AWS Config with an organization wide aggregator, which Control Tower sets up by default these days, have your agent use it to find resources and related resources. You can build most of the graph from that alone without traversing accounts.
What’s the value of having a ton of silo’d accounts, especially for the use case demonstrated by the readme where there are multiple staging and production accounts?
Blast radius. One example… What happens when you give an identity s3:* on resource: *? It can read/modify every bucket in the account that doesn’t have a resource policy with an explicit deny.
If you use AWS Config with an organization wide aggregator, which Control Tower sets up by default these days, have your agent use it to find resources and related resources. You can build most of the graph from that alone without traversing accounts.
What’s the value of having a ton of silo’d accounts, especially for the use case demonstrated by the readme where there are multiple staging and production accounts?
Blast radius. One example… What happens when you give an identity s3:* on resource: *? It can read/modify every bucket in the account that doesn’t have a resource policy with an explicit deny.
This is not super uncommon, especially when selling to enterprises who demand complete data isolation.