<img height="1" width="1" style="display:none" src="https://www.facebook.com/tr?id=2012313439098820&amp;ev=PageView&amp;noscript=1">
Posted by Mike Racine

How to setup your Azure Subscriptions the right way

Granular control? Or a chaotic mess? Do you want to stuff everything into one subscription or break it up into hundreds? In this episode of #KnowOps, Dana shows us how to get the right number of subscriptions without going crazy.

Here is the article Dana mentioned: https://docs.microsoft.com/en-us/azure/cloud-adoption-framework/decision-guides/subscriptions/

Show Transcript

There's so much confusing and conflicting information online on how to set up your Asure subscription. It's just crazy. Today, I'm going to show you how to set it up right, for you. Dana Epp here, welcome to the channel for aspiring Asure administrators like you and me, who want to know Ops, and well master the Microsoft Cloud. I'm so happy to have you here. Thanks for coming by. If you haven't yet, smash the subscribe button so you can be notified each week when I produce new videos. When you look online, there's tons of resources that are going to be conflicting on exactly how you should be setting up your Azure subscriptions. Some say you should be putting everything in the same subscription. Other say it should be based on the environments that you have like Dev, and Prod, and Test. Others will tell you that it has to be done based on applications, or maybe even departments. And they're not wrong, they're also not right because it's all going to be dependent on how you want to build and set things up. But even with that said, there is some best practices that we can follow that will help us to make better decisions to make sure we're setting it up right for what you want to accomplish. So the best way to get started is to really think about what the purpose of a subscription is. It's a logical container that Microsoft uses to maintain their billing relationship with you, regardless if this is a web director, pay as you go, or an enterprise agreement, or if it's a free trial, or if it's a CSP subscription. At the end of the day, the billing relationship starts and stops at the subscription boundary. Now that doesn't mean you can't have multiple subscriptions, and multiple bills, but that's the best way that they try to kind of group it together. More importantly though, it's an administrative security boundary. When we start thinking about things like RBAC or rule based access control, and the ability to position and control who can see what, when, where and why, subscriptions are the way to handle it. And you can see that in all the tooling, when you look at the portal, or you look at the CLI it's a logical demark. So when you're in the CLI, and you want to go and work with resources, you have to switch to the subscription you want to have access to. That makes a lot of sense because it just makes all the tooling and all the decisions you're going to make all aligned very well. Now, that doesn't mean you can't do higher level things to manage and monitor everything. This is the purpose of things like management groups, because it gives you the ability of coalescing multiple subscriptions under a managed group, or multiple management groups to control an assigned policy and Governance and everything else that you might want to do from an administrative point of view. But when you ask me, the best way to get started is just to go simple. Now I'm not saying have just one subscription. That's, there's reasons why that doesn't make a lot of sense either, but you should start out by having a minimum of two subscriptions, one for production, and one for non production. And normally when you get started, that first subscription you set up will be that non production one. That allows you to have your ability to test and validate in working environments as required. And then when you start deploying and managing your resources for production use, that should go in a separate subscription. And then depending on how and where you deploy your resources, you can then start deciding if you want to do things regional. Base it on different data centers, base it on different departments. And as you get more complicated, now you can start advancing to use the management groups. But starts simple. Two subscriptions, and here's why. The first thing is, it makes cost management really simple, because now you can separate and slice and dice everything that you want to at that boundary. Now, you can still take advantage of resource groups and tags and everything to to filter and make that a little smoother, but when it comes to the billing relationship itself, it becomes much easier to separate the cogs that might relate to your production resources, and that of any of your non production or test environments. The second is from a security perspective, it's so much easier to have trust and knowing that devs don't have any access to the production infrastructure, but they do have access inside of the non production one. And then of course you can limit and scope it, you don't want to give all devs, you know, full subscription ownership rights, you want to isolate it down to those resources that they need. And this gives you that flexibility. This is where things like RBAC for resource groups and whatnot, gives you some more flexibility. The other side to this, though, is it allows you to create a separated and easy way of following on how some of the higher level services may function. An example is things like Azure DevOps. When you create the connection between the DevOps and the resources that you're going to run an Azure, that's typically done through a service principle that is then given permissions and access at the subscription level. So it's makes a lot of sense to want to try to isolate and control it there. It also means that you can then create different service principles for different subscriptions, so developers can work in the pipelines to be able to give access and automate through infrastructures code and configurations code to deploy to their test environments. And allows you to separate and isolate what happens in production, so that they don't have direct access to that information. So there you go, when you first get started, think about subscriptions in that way, logical containers for billing, logical containers for security isolation and separation as it relates to RBAC. If you then focus it that way, you can easily get started, and then take advantage of looking and seeing if you need other subscriptions to expand and grow out your organization. And then, you can use management groups to manage those subscriptions and adhere to governance and compliance as you need to through those management scopes, instead of worrying about it at the subscription level. Let me know what you think. Does that make sense to you? Does that resonate with what you would do? Or do you have a better way of doing it? Leave a note in the comments if you don't agree with me, and let's have that conversation online. I'd like for everyone to weigh in on this. I will leave in the description some links to some documentation Microsoft provides that helps you start looking at and making decisions on how you should roll out your subscriptions, based on their guidance. But as you get started, trust me on this. Try it, just using it a production and non production, see how that goes. And then start looking at more depth as required. Let me know if this makes sense, hit like, smash the subscribe button if you haven't. We'll talk to you the next episode.


Think about #Azure subscriptions as logical containers for billing, logical containers for security isolation, and separation as it relates to RBAC. #knowops @auditwolf






Topics: Cloud Operations (CloudOps), KnowOps