Going through my mails early this morning, I received following question in one of my mailing lists (paraphrased):
I’m tasked to set up DEV, Staging, QA, and UAT environments in Azure. Is a combination of subscriptions a good approach for billing purposes?
Since it’s a very interesting question coming up at many companies taking their first steps into the cloud, I decided to not only reply to the mail but also write up this blog post. It is important enough to spend some time on before getting started.
Subscriptions
First of all, there is no fixed rule on how to do this and as often ‘it depends’ on the size of your company, the amount of expected different loads, etc. Just looking at the number of subscriptions: for a small company deploying 1-2 solutions to Azure, managing 5+ subscriptions can be a hassle while a large company (or specific loads like e.g. IoT SaaS solutions) might run into subscription limits if they onboard everything on a limited set of subscriptions. What I’ve used with success at smaller clients is separate subscriptions for the landing zone platform (identity, connectivity, …) and then one subscription for prod and one for non-prod, all regulated by management groups and good naming conventions.
Microsoft improved their documentation on Azure a lot the last few years. You can use this page as sort of decision tree for the number of subscriptions: Subscription decision guide - Cloud Adoption Framework.
Billing
Going a step further and looking at billing, you again have multiple options ranging from advanced billing profiles to simply group the invoice data (CSV) on tags. Note that even without billing purposes (e.g. cost center tag), it’s wise to put tags on your resource groups / resources (owner, project, creation date, …).
Using tags also easily allows you to switch the grouping of your billing, let’s say that everything in project modus (eg. tag LifeCycle = "Project") gets billed to a certain business unit (e.g. R&D) and when it’s in maintenance it’s billed to the target business unit for which it’s purposed (based on tag BU). Good luck moving resources around to different subscriptions when you do subscription-based billing instead. And you probably still need a DEV and UAT environment even in maintenance, so does this end up on the same production subscription that is billed to business unit x in this scenario?
Security
Looking at security: first of all you can start off with management groups above your subscriptions. Within your subscriptions, you can indeed use RBAC on the resource groups and I typically suggest the least access required (also known as ’least privilige principle’) to do the job, e.g. devs are Contributor on DEV (and only on the resource groups linked to their project), but only Reader on higher environments (and maybe Owner on a sandbox environment to try out things). With good Azure Active Directory group management, this is minimal overhead, but could save you a lot of “accidental costs” in the long run. Finally all deployments should be done through CI/CD pipelines (with a service principal), so only this account and admin accounts have higher access tiers on resources.
Azure Governance is a very important aspect in your move to the cloud. Above article is only a small part of setting up a good cloud governance. Don’t hesitate to reach out if your organization needs help in moving to the cloud.