My anecdote on how we do it:

- We have AWS Org

- Each account has no root IAM and cost/pricing goes through root AWS Org Account

- You move between accounts with AWS SSO (now IAM Federation) - No more password per account

- AWS SSO standardizes boundaries across account with IAM policies, like eu-centeral-1 only for dev IAM etc.

- Inside Account more granular access with IAM Assume Roles

- Each account Cloudtrail to a central S3 for audit (Same region pricing works for diff accounts!)

- Each account is `project.env` like micro_service1.dev or company1_k8s+s3.prod

- That way, we have pricing per project built in where tag support ends (and it do have limits)

We came to this structure realization after we saw Azure Resource Groups and Google Projects. We also saw the 5 VPC soft limit AWS has per region and think it's kind of a clue from amazon: "pss.. this account soft/hard limits is sized for 1 project/deployment"

The only problems come from automating stuff, like Route53 records that can point automatically to load balancers in that account or as mentioned in the article, VPC2VPC, although we use serverless stuff like lambda and s3 and experience less of that.

But as time go on we realized, like the VPC example in the article, that those problems forced us to structure our stuff in a more SOLID way, which became a feature for us. Just like moving docker-compose to k8s is not creating app-mesh and ops problem, but REVEALING them. So the solution for the Route53 example is to have a separate subdomain zone in each account for automation and ADDING another account `main_route53.prod` with a root zone pointing to them.

Hope this helps for the curious.