I mean, there is no right and wrong answer I suppose. You can have all the code for your project in one file. Forget a class per file or whatever, maybe it works for you.
What I saw is that the more you co-locate in an AWS account or Azure subscription, the higher the bar goes on ensuring your cost reporting and access control are also completely aware of resource group boundaries.
You really want to know is that $ for project A or B?
You really want to ensure folks on project A have access to their cloud resources, but not project B.
You can do that even in AWS, combine them and use IAM to segment things.
I think there is just more room for error if you combine.
Also I think Azure has some per subscription quota limits and you may not want team A and B competing for them.
Again, no right answer, but I know we've done projects to split accounts and have never done one to combine them..
I’m quite sure all the scenarios you mentioned can be managed leveraging resource groups and AAD settings. OTOH I can agree that for big engineering groups managing settings can become a challenge. IMO it’s not a matter of correct config, but about a threshold over which a single sub takes more effort to maintain.
What I saw is that the more you co-locate in an AWS account or Azure subscription, the higher the bar goes on ensuring your cost reporting and access control are also completely aware of resource group boundaries.
You really want to know is that $ for project A or B? You really want to ensure folks on project A have access to their cloud resources, but not project B. You can do that even in AWS, combine them and use IAM to segment things. I think there is just more room for error if you combine.
Also I think Azure has some per subscription quota limits and you may not want team A and B competing for them.
Again, no right answer, but I know we've done projects to split accounts and have never done one to combine them..