Home / Nerdio Academy / Microsoft Azure / Azure IT Fundamentals: Tenants, Subscriptions, and Resource Groups

Azure IT Fundamentals: Tenants, Subscriptions, and Resource Groups

Vadim Vladimirskiy
Vadim VladimirskiyFounder & CEO, Nerdio
0 commentsApril 13, 2019Videos

Joseph Landes:
In this session, you will learn more about the basic building blocks of Microsoft Azure, tenants, subscriptions, and resource groups. Think of these as the core elements needed to build a strong foundation in Microsoft Azure. It’s the first step in understanding how to build your cloud practice. We’ll take you through examples of each using the Microsoft Azure portal and Nerdio for Azure. By the end of this session, you will feel prepared to take the first step towards spinning up your first customer in Microsoft Azure.

Vadim Vladimirskiy:
Azure, as we all know, is a Microsoft cloud platform. It has both Infrastructure-as-a-Service and Platform-as-a-Service components. It has many hundreds of different types of products in there. We’re going to be focusing primarily on Infrastructure-as-a-Service, so VMs, discs, networks, virtual network cards, things like that. Those are what is referred to as Infrastructure-as-a-Service components, as opposed to things that are referred to as Platform-as-a-Service components. Those are packaged services that get to be consumed in a serverless way.

What do I mean by serverless way? For instance, Azure has a PaaS service called Azure Files. Azure Files allows a user to create an SMB share and map to it from their desktop or server, just like that share was running on top of a file server. But you can do that all without using a file server. You kind of accomplish the things that are normally run as the roles of servers which are IaaS or Infrastructure-as-a-Service, but using PaaS services within Azure. There are lots of examples. There’s things like Azure SQL which is the alternative to running an SQL server on top of the VM. There is VMN gateway which is the alternative of running a VM with VPN software on it, et cetera. We’re going to focus primarily on Infrastructure-as-a-Service, but we are going to talk about some specific Platform-as-a-Service components.

The first thing to understand is how Azure and just the Microsoft Cloud is structured. At the very top level, you have something that is referred to as a tenant, also known as a directory. A tenant or a directory normally has the format of what’s called a tenant ID. So in this case you can see let’s say nerdio1013.onmicrosoft.com. That is sort of an identifier, a human readable identifier of a particular directory or tenant. The reason it’s called a directory is because each directory has an Azure AD service associated with it. Every Microsoft service is always integrated with Azure AD. Even if you’re not using Azure itself and you’re using only Office 365, there is an Azure AD deployment associated with that particular Office 365 service.

Again, top level tenant or directory, kind of the same thing. A lot of times it’s also referred to as the account, kind of the all encompassing thing. This ID that sits in front of the onmicrosoft.com is globally unique, which means that nerdio1013, if somebody wants to create nerdio1013 as a new tenant, they will be told that it’s already used and they won’t be able to use it because it’s a globally unique thing.

Then once you have an account, I am sorry, an account directory or a tenant, then in order to leverage Azure, you need to create something that’s called a subscription. Let’s take a look at what subscriptions are. First of all, let me just point out a couple things here. You can see I have a little navigation menu on the left. This is a very useful little menu of shortcuts that are commonly used. If you want to get to all of the Azure’s services, you simply click on All services and you can click and you can search here. You can see, this is a list of all the various services that are available within Azure and then if you click the little star, that adds it to your list.

I’m specifically going to look at subscriptions. What you’ll see here right now is I am logged in as my email address. I am in a particular directory. I am in the getnerdio.net directory. This directory is this one right here. It’s the nerdio1013 which is what I’m a part of right now. Within that directory or tenant I have a subscription called Nerdio Template VMs. And there are different types of subscriptions.

Let’s click on the subscription and see what type of subscription it is. If we click on the subscription, it comes up to a view that’s going to be very common throughout Azure. You can see this is a CSP subscription. As a result of it being a CSP subscription, you don’t see any cost information. A CSP subscription means that I am being provided the subscription by a reseller service provider, cloud service provider, and I as the end customer in this particular case, even though I have access to the subscription, I don’t see my cost information. This is one type of a subscription that you can use.

Let’s jump back up. If I had no subscription listed in this particular view, then anytime I go to deploy a resource, let’s say a VM, a disc, Azure SQL, what have you, the very first thing it asks me to do is what subscription it gets put into, and if there’s no subscription available, it obviously can not deploy it. So it will ask me to create the subscription.

Let’s see what it looks like if I want to create a new subscription as the customer or the end user of this platform. I’m going to click Add over here, and it’s going to open up in that subscription box and you will see here the various types of subscriptions that are available. There’s what’s called a Free Trial subscription which gives you I think $200 to spend to try Azure out. There’s something called a Pay-As-You-Go subscription which is as the name implies it’s a pay-as-you-go. You add a credit card as a payment method, and then as you consume resources, your credit card gets billed.

Then there are other types of subscriptions which are ultimately pay as you go, but they have support associated with them. For example, this is developer support. This is professional support. This is standard support. You pay a surcharge in addition to any consumption within the subscription that you have for the support that you are getting.

Now what you don’t see here is the CSP subscription. A CSP subscription is something that the reseller who owns this particular tenant gets to add into the subscription, I’m sorry, into the account. Most of our MSB partners are going to be CSPs. They may not be direct CSPs which means they don’t transact with Microsoft directly. They go through a distributor like a Tech Data or Sherweb or Ingram or something like that. But they basically will be able to go in and add the subscription from a different portal and make it appear in this particular screen.

Then once you have a subscription, let’s click on it. Within the subscription you have something called Resource groups. It’s important to keep in mind that the subscription is mostly a billing construct. Everything must live inside of a subscription because it got it, it has to be billed, but the way you segregate things for organizational and technical purposes, kind of isolate things from each other inside of Azure within a single billing subscription is by creating resource groups that are sort of functionally focused. If you can have … Imagine you have a subscription that’s a direct pay subscription. You’re a big company and you have multiple applications that are kind of independent of each other. What you’ll do is you’ll create multiple resource groups, one for each application, and then within each resource group you would create your various resources which are the services that you can see here on the left that you get billed for by Microsoft.

Let me just kind of make a visual representation here. Within subscriptions you have resource groups. And within the resource groups you have resources. This is where you get billed. You get billed at this level. And the subscription could be, we talked about it, it could be CSP subscription, it could be a pay-as-you-go. It could be what’s called EA, which is an enterprise agreement that large companies use. It could be what’s called MPN, the Microsoft Partner Network where Microsoft sponsors a subscription for you to use for testing purposes and demo purposes. There are many different types, but sort of the thing that makes them all different is how they’re billed, like who’s responsible for the billing, how it gets transacted. EA for example is something you negotiate and pay for upfront. CSP something you pay for on a monthly basis. Pay-as-you-go obviously you pay as you go. MPN is normally prepaid and sponsored. There’s free. All sorts of different versions of the billing arrangement.

Now when you are talking about granting access and getting access to things within Azure, so accounts, so users, let’s not call them accounts because that’s not really accurate, let’s call them users. Users live at this level. Users live at the Azure AD tenant/directory level. You can have a user. For instance in this case it could be admin@tenant.onmicrosoft.com. Then you can decide what this user has access to within a particular subscription, and the way you do that is by assigning that user what’s called a role.

For NFA to work as an example, in order for you to use an Azure subscription, you need to provide a user that is an owner on a particular subscription. An owner obviously means it can do everything within that subscription. They create resources, delete resources, assign other users, create other users, et cetera. This a prerequisite for NFA provisioning is that this user is an owner on the particular subscription.

Let me show you what it looks like inside of a resource group. If we go into a particular resource group, let’s look at the templates resource group we have that we use. You can see there’s a bunch of different resources. We can see what they are. There is a DMS zone. There is a virtual machine. There is a virtual network interface. There is a public IP address, automation account, all kinds of stuff that make a lot of sense to some of you and probably make no sense to others. But all of these are resources and these resources interact in a certain way, and these work resources are completely isolated from anything living in another resource group, other than in the fact that they all get billed together on one invoice because they’re part of the same subscription.

Then one other thing that I wanted to bring up now that we understand subscriptions is this topic that comes up fairly frequently with partners where they have a deployment model they may be using today or that some other vendors and competitors like CloudJumper for example uses and advocates, and it’s sort of loosely termed hoteling. The concept of a hoteling RDS deployment is when you have a shared active directory force and you have dedicated segregations within that force. It could be separate force subdomains. It could be a single domain with different OUs for different organizations, but you guys get the concept where you have a common forest which means you have a common network, which means things are running within the same subscription and the same resource group in Azure specifically, and then you have the ability to leverage and we’ll talk about this, the pros and cons in just a second, but you have the ability to leverage resources either in the shared way or you can use software and access list to restrict permission.

Often times we have to kind of go through the pros and cons of doing the hoteling versus what we call single stack. Single stack is what we’re all very familiar with. This is what we’ve done in Legacy and NPC and NFA. This is where you deploy each and every customer completely independently of any other customer and you have segregation at the very minimum at the network level. So there isn’t any sharing in active directory. There isn’t any sharing of resources. It’s all segregated.

Now that we understand subscriptions and resource groups, let’s go through this exercise very quickly. The common objections to doing a single stack deployment and probably the only and the biggest ones is the fact that you have additional infrastructure roles that cost you money. For example, if you have a hoteling environment, you can have a set of domain controllers that are commonly shared by multiple customers. So you basically take the cost of that Infrastructure-as-a-Service resource like a VM and you spread it across multiple customers. Whereas if you’re doing a single stack deployment and each and every customer has at a minimum to have one domain controller, one file server, one ADFS proxy, one RD gateway, connection broker if you’re using RDS connection, so basically all the infrastructure roles get deployed separately and cannot be leveraged in a shared scenario.

Now the effect of that if you look at the minimum sizing with all the applicable discounts of those roles is fairly minimal. So people think, “Okay, well I need all these extra machines. They’re going to cost me hundreds of dollars a month.” But really if you use discounts and reserve instances, which is something we’ll get in detail a little bit later, you can really bring the cost of these VMs down to $20 per month range. We’re talking about $100, $150, $200 for all of these additional roles, still additional cost, but not as much as people usually think. We’ll see what the advantages are of doing single stack and those outweigh those additional costs.

The other advantage or disadvantage of using single stack especially for someone who’s used to doing a hoteling environment, is now they have to kind of relearn a different way of managing the environment. They may be used to working out of a single active directory users and computers screen where they can manage all their customers in one place. Now they have to figure out how to jump from one customer to the other. You get the idea. Once you’re used to a certain way of managing it, you have to learn a new way if you’re going to single stack.

Now what are some of the pros of single stack and cons of hoteling? Obviously by having a single stack deployment, you eliminate the significant amount of complexity and risk by keeping each customer completely independent. Again, I think this requires no further explanation. You have complete isolation between customers, but you still have multi tenant management without having to log in and out of different accounts. Everything is at your fingertips with the NAP. So you have the NAP, which lets you very easily exit one account and log into another account, and do that very rapidly. There isn’t much lag between going from one to the other. Still complete isolation and easy management.

When you have a hoteling environment, any time you make a change that is at the shared component level, so imagine you’re changing the database schema because you’re deploying exchange or you’re installing something under the main controller, you have to conduct what’s called impact analysis on the entire environment because every time you make a change you have to know, well, how’s that going to interact with what customer A has differently than what customer B has.

In an environment when you have a small number of customers, that may not be a big deal, but you can imagine that that doesn’t scale very well because when you make changes to shared components, those can have unpredictable impacts on different customers that you couldn’t foresee. So there’s lots of impact analysis which becomes very difficult and expensive to conduct and ultimately still can result in high risk of issues.

You have the ability to eliminate kind of these global issues that arise when certain shared infrastructure components fail. Imagine you have active directory issues that affect the entire environment, all your customers are affected, or you have a shared RD gateway deployment, and there’s an issue there that’s affecting everybody at the same time. So you eliminate these global issues.

You can also eliminate the noisy neighbor problem. When you have people and the shared network environment, maybe hammering away at a particular resource, maybe hammering away at AD or at gateway or whatever the case may be. You can limit that as much as possible by having single stack because you have different customers. They’re split up. You still have kind of noisy neighbor at an employee to employee basis, but not customer to customer basis.

This is where some of the concepts we learned earlier comes into play. If you’re doing a hoteling deployment, that by definition means you’re deploying everything within a single resource group, which means you are within a single subscription, which means you’re getting billed on the same invoice without an easy way of attributing your spend and tracking the spend on a per customer basis.

The way NFA deploys the product is by doing it in a single stack which allows you to put it in single independent subscriptions and then track the spend very accurately on a per customer basis. If you have single stack deployment, you can delegate administration without the concern that somebody’s going to screw something up that’s going to have a global impact. Imagine again, hoteling environment, you don’t want to give someone global admin rights because or domain admin rights because they’ll be able to make changes that can affect all of your customers. In our case that’s not a problem. So they can do things, reset passwords, clear hung sessions, group memberships, et cetera. You can give full admin access or just selective access, et cetera.

Continue. You can, okay, we talked about it, give user domain admin rights without concern that they have anything outside of their own environment. It’s easier to show compliance with regulatory audits because you can claim, you can say that each environment is fully isolated because it is at the resource group level.

You then have a lot more flexibility with networking and VPM connectivity, so you’re flexible on how you design your network, how you set up your AD schema, you can do hybrid AD, which again we’ll talk about later on for those of you who are not familiar with that, but you can do hybrid AD for some customers and brand new greenfield deployments for others. You can have multiple Office 365 accounts linked to different customers, so a lot more flexibility in the architecture. You have more pricing model flexibility. Think of this as a service provider that’s trying to package this and go to market and sell this to a customer.

When there is hoteling, again because it’s so difficult to separate the usage of one customer versus another, you don’t have as much flexibility around how you price it. So you have to kind of blend things together and use averages. Whereas with single stack and different subscriptions, you do have a lot more flexibility on how to do it.

Videos in the series