A related problem is multi-cloud orgs trying to copy this advice into other clouds. For example, at $dayjob, the cloud guy is trying to replicate the AWS accoun

A related problem is multi-cloud orgs trying to copy this advice into other clouds. For example, at $dayjob, the cloud guy is trying to replicate the AWS account structure into Azure, where it's largely unnecessary. In Azure the equivalent of an account is a subscription, but then there's a second hierarchy level in the form of resource groups. Combined with tagging, this makes it very easy to do internal charge-backs or RBAC. They've even added a feature to redistribute the costs of shared resources: https://azure.microsoft.com/blog/simplify-financial-reporting-with-cost-allocation-now-in-preview/ https://azure.microsoft.com/blog/simplify-financial-reportin... Splitting things across accounts or subscriptions is complex and results in all sorts of strange limitations. For example, some resources can't be connected to each other across subscription boundaries, so you have to duplicate them. Another example is Kubernetes (EKS or AKS). The typical thing to do is to create a single cluster with multiple node pools, all in the same account or subscription. Then this is split using namespaces. All of this will be in one account, and can't be "associated" with other accounts or subscriptions. The second a shared platform like this is introduced, the fine-grained account model breaks down.