Hacker News Reader

Comment by obert | Hacker News Reader

Why “should” one not put services in the same subscription?

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..

AWS Organizations are actually quite good for this. There's a "consolidated billing" function which puts everything under the same umbrella.

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.

Because one subscription is paid by exactly one entity/organization. Sometimes you split off services for legal/regulatory reasons.

yeah that’s a good reason, though it sounded like one should never do that. I believe the majority of small and medium enterprises are ok with a single bill, so putting all services in one subscription is fine. Logical organization can be done via resource groups.

Reply on news.ycombinator.com