Segregation for mutually-exclusive systems/environments

Hi icelava,

AWS strongly recommends the usage of separate accounts for systems that are unrelated, especially if users of one system should not have visibility into another because of data sensitivity. See this article for a more in-depth explanation of multi-account architectures: https://aws.amazon.com/organizations/getting-started/best-practices/

One alternative that you alluded to for viewing different collections of traces separately within the same account is X-Ray Groups: https://docs.aws.amazon.com/xray/latest/devguide/xray-console-groups.html

Using X-Ray groups, you can pre-define a filter expression to view the service map and trace list for only traces with a certain attribute, like an annotation or segment name. This way as long as all of your subsystems are sending data to the same account with some distinguishing attribute, each team can have a Group that filters only for the traces of their subsystem/environment. As you pointed out though, this does NOT prevent teams from potentially seeing each other's groups, so if data sensitivity is a major concern then multi-account architecture is the best approach.

I don't know; when one looks at the highly elaborate and flexible feature set of IAM policies and permissions in conjunction with other AWS services, a one-size-fits-all X-Ray service really appears like a product that was rushed to market.

Does it make sense to state anybody with access to an AWS account should be able to read/write to all S3 buckets and files?

Edited by: icelava on Nov 10, 2021 4:46 AM

Hi icelava,

Thank you for the feedback, we understand the current architecture of X-Ray has limitations around fine-grained control for accessing data and the workarounds I described are not sufficient for cases involving sensitive data. I will file a formal feature request for this use case so our product team has it in on their radar, and update this issue if it is on our roadmap.

"Wait for roadmap"