5 ms·

Resource groups seems awesome, and are nice in some ways, but they are sort of this slippery slope that encourage you to put more into a single subscription tha

Resource groups seems awesome, and are nice in some ways, but they are sort of this slippery slope that encourage you to put more into a single subscription than you probably should.

obert 4y ago
Why “should” one not put services in the same subscription?
- pwarner 4y ago
  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..
  - epberry 4y ago
    AWS Organizations are actually quite good for this. There's a "consolidated billing" function which puts everything under the same umbrella.
  - obert 4y ago
    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.
- kubanczyk 4y ago
  Because one subscription is paid by exactly one entity/organization. Sometimes you split off services for legal/regulatory reasons.
  - obert 4y ago
    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.

Resource groups seems awesome, and are nice in some ways, but they are sort of this slippery slope that encourage you to put more into a single subscription than you probably should.

obert 4y ago

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

pwarner 4y ago
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..
- epberry 4y ago
  AWS Organizations are actually quite good for this. There's a "consolidated billing" function which puts everything under the same umbrella.
- obert 4y ago
  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.
kubanczyk 4y ago
Because one subscription is paid by exactly one entity/organization. Sometimes you split off services for legal/regulatory reasons.
- obert 4y ago
  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.