One of the most frequent questions I get about Azure once a client starts using it, is how should we structure our Resource Groups. The short answer is of course the typical consulting response, “it’s up to you”. But there are some things I like to think through when designing resource groups to ensure the best security and usability down the road.

The first thing to consider is the security boundaries of the resources. So, who will use these resources, who will own them, manage them, etc. A whiteboard can be really helpful here, or you can break it down as shown in the following table.

Resource

Owner

Users

Admins

Sec Req’s

Subnet

Sql

DBA 1

Websites

DBAs

PCI

101

Web

Dev B

Public users

Dev’s

PCI

203

AD1

IT

Websites, DBAs, SQL

IT Ops

103

You don’t have to list out all of your resources, but getting some of the most used and common items into this list can help identify overlapping boundaries and make it easier to decide how to group things. In the example above we have some pretty distinct administrative groups and users, so it might make the most sense to create resource groups for Databases, Web Servers, and Supporting Infrastructure. You can further refine access controls by role to each Resource Group. For a full list of built-in roles and how to create customer roles, check out this article: https://azure.microsoft.com/en-us/documentation/articles/role-based-access-built-in-roles/

The example we have been using is pretty security conscious, but assumes a pretty sizable operations and development group. Let’s say this is a smaller company and the DBA’s in our chart are really one person who happens to be a developer and DBA for our client. The Dev’s consist of a half developer, half IT sys admin and IT Ops is a the multi-hat director, IT Admin. In this case usability is a major consideration and putting everything into one resource group by application may make more sense, or even larger buckets depending on how many applications and resources there are and how many resources they share.

So, while not a clear cut dos and don’ts list, these are the main considerations to take into account when designing your resource group structure. Once you have that somewhat defined, you can then use JSON templates to make sure things go to the right places during deployment. This is easily done with Visual studio which I plan to share more about in future posts. Jump into https://portal.azure.com and start building. Let me know how it goes.