Understand the Azure Resource Manager Model

0:00Welcome to the content on understanding the Azure Resource Manager model. Say that three times fast. Azure Resource Manager model. Okay, the idea here is that in order to get ready for the advanced virtual networking topics that we're going to cover, they are advanced, we really need to make sure that we're all on the same page. Put it another way, if it's been a while since you've ridden a bike, we all need to make sure that we need to ride the bike smoothly and safely before we take off down the hill. So there's a few topics that we really need to prime ourselves on before we jump into the advanced topics.

0:36Things like VPNs, ExpressRoute, DNS, load balancing, all of that really, really fun stuff that we will absolutely cover. So first, we're gonna make sure we understand how Azure resources are deployed and laid out. Also upcoming, we're gonna be talking about things like dependencies that you actually need to install in your environment. Maybe that's going to be the AZ CLI, PowerShell, or things like maybe VS Code if you're gonna be deploying from ARM templates or Bicep files. Another really big part to understand that Microsoft likes to sneak in on these exams.

1:10I haven't taken a Microsoft exam yet that doesn't include PowerShell. So we'll also prime ourselves on PowerShell just to make sure we understand the PowerShell language. But that comes in a later set of videos. First, we're gonna focus in on just understanding the layout of Azure resources with the Resource Manager, things like resource groups, understanding regions versus availability zones, and stuff like that. So without further ado, let's get ready to understand the Azure layout of resources.

1:41Let's go.

0:00So to begin our journey, we're going all the way back to the basics. We're gonna be talking about something as a service, and this is actually really important for the virtual networking conversation, the advanced virtual networking conversation, because you will bleed between these as a service offerings. It's actually a really important understanding thing that you need to wrap your head around. We're gonna talk a little bit more and preview just a little bit about what it is that we're gonna cover when the time comes.

0:30But we're gonna start off with good old fashioned. The classic one, infrastructure as a service. This is what everybody begins their cloud journey with. And importantly because this is what we know, this is what we're familiar with, this is what we did for a decade or two there when we had virtualization brought into the scene. When we had a hypervisor, maybe it was ESXI, or maybe it was Hyper V, whatever the case is, is we could take this big physical server and we could dice it up into virtual machines, couldn't we?

1:06That would be VM, you know, one or VM2, and they would all serve their relevant purpose. But interestingly, one of the more powerful things that virtualization did, you know, at the high level, the systems engineer would see this and think like, oh, this is amazing. I can spin up virtual machines. But then by default, just where your head goes to is you're thinking, oh, well, virtualizing a network would be way too hard. So these virtual machines must be all on the same land segment. It's exactly what you would think. But if that's the case, you would actually be really wrong because virtualization did networking really well.

1:42So that VM1 could be on, say, the yellow land and VM2 could be on say, the blue land, and we absolutely have the ability to dice up our network and our virtual machines into multiple subnets, even if they were all running on the same physical piece of software, or same physical piece of hardware, excuse me. So all of a sudden, network engineers were still absolutely a part of the picture when it came to working with systems engineers and designing network layouts for their various workloads to run on top of the physical servers.

2:18Now, beyond that, some physical servers actually had built into the nix themselves some really powerful networking components such that these could actually serve as VTEPs part of the land fabric and infrastructure that could run throughout the data center. With infrastructure as a service, this is where we start to draw the line, and I do mean quite literally draw the line, I'm gonna use pink right here, and anything below the pink line is no longer something that you touch. So any of the physical hardware that's running here, or the backbone configuration for the data center where you're configuring VX lamb, that's all gone.

2:55Now with infrastructure as a service, we are renting infrastructure to run our virtual machines, but the software component, the software side of it right here, if I were to actually redraw this pink line a little more correctly, would be kind of like this. You still absolutely have control over the networking portion that your virtual machines would be running on. So infrastructure as a service is the thing that we usually dabble with first. Whenever we're getting started working with the cloud.

3:27None other than, because this is most familiar to the things that we were doing on premises, we just have a few less responsibilities because managing the hypervisor, the physical hardware itself, things like, you know, disc and raid configuration, or managing the networking fabric throughout the data center, that's all gone, and we get to just focus on designing subnets for our virtual machine workloads and infrastructure as a service. Now, this has all been primarily focused in on the networking side of things because you know, this is a networking certification exam, but you also gotta keep in mind from the systems engineer standpoint, this is really important.

4:08I'm gonna explain why this is really important for you, the network engineer to understand this. Everything that goes on in the virtual machine is your responsibility too. You should think about this as a toolbox where you're renting a toolbox that has every tool imaginable on it, but it's still up to you to build something. So from the software developer standpoint, this is a big part of it. The software, the developer standpoint, they're responsible for managing dependencies. What version of Node does it need?

4:38What version of Python does it need? What version of go does it need? And whenever we design software, our software itself, 99% of the time, is using what we call a package or a module or a library. Basically we're saying, Hey, out of the box, JavaScript can't do everything that I needed to do. So install this additional piece of software into JavaScript so that I have access to all of these things. A great example is PowerShell.

5:10You're gonna get a lot more familiar with PowerShell in some upcoming videos. PowerShell is extremely powerful and it is, well a shell, it's a scripting shell. But out of the gate, if you just installed PowerShell into your computer and then fired up PowerShell, you would not have the commands, they call them commandlets. To interact with Azure, you would have to install a module that comes with all the commands that you need to interact with Azure. Do you see what I'm saying? So if I had this virtual machine right here and I wanted this virtual machine to interact with Azure, I would have to make sure that PowerShell was installed, specifically PowerShell version seven, and then from there I'd have to install the module that gives it the ability to work with PowerShell.

5:56Only then have I met my dependencies to where I could actually start writing scripts to work with PowerShell. Do you see where I'm going with this? Virtual machines have overhead, and with that overhead most of the times comes cost. Virtual machines can be more expensive than you might be used to, but beyond that, more labor goes into running them. So much so that Azure, interestingly, actually recommends if you're doing a greenfield deployment or a new design, try to avoid infrastructure as a service.

6:30Check this out, you might not believe me. See, they have a whole document on it right here, updated just a few days ago, actually. Use platform as a service options. You scroll down a little bit and they actually tell you why you should choose platform as a service over infrastructure as a service, and then they offer you the alternative solutions that Azure offers. And this is a very, very small list of the things that Azure offers that are platform as a service. Now, ultimately, this comes from the document that's designed principles for Azure applications.

7:02You can kind of see where my mouse is right here, and if you go to the overview, it gives you the little bullet points right here. You scroll down just a hair about halfway, and you see this used managed services when possible use platform as a service rather than infrastructure as a service. So there you go. You are hearing it straight from their mouths and not from mine. This isn't just my opinion, even though that is my opinion, you're hearing it right now. That platform as a service, if you have the choice to use, it should be your choice. Well, why? And does that mean that you as the network engineer, no longer have a job?

7:37Absolutely not the case at all. Let's talk a little bit more about that. Bringing my doodling back onto the screen here a little bit. I'm gonna do a little bit of a racing to clear up some room. So gimme just one second while I clear this up and we can talk a little bit more about platform as a service and how it differs quite a bit from infrastructure as a service. Okay, so platform as a service. The idea with platform as a service, this is largely a developers playground. It's a developer's toolkit rather than a virtual machine.

8:10In fact, if we were comparing certification exams, you would see mostly infrastructure as a service on the AZ104 with a little bit of platform as a service on it. Whereas the AZ204 developing solutions for Azure is almost exclusively platform as a service. If I recall, there's not virtualization or virtual machines on that exam at all, but, and this is where I'm, I'm dead serious about this in my, this is where I will give you my opinion. In my opinion, the true power of the cloud, the true point of the cloud is right here.

8:47Platform as a service, and you as a network engineer, someone who's going for the AZ700 and are interested in advanced virtual networking, I would still say it's worth your time to at least watch the content on the AZ204, just so that you understand the workloads and the types of things that developers are gonna want to do and why. Because at the end of the day, there is little to no overhead with platform as a service. There is no operating system to patch.

9:18Most of the time there is no need to manage dependencies. You declare the dependencies upfront when you deploy the resource and Azure will handle the rests for you. It is also most of the time very cheap. In fact, I drew way too many dollar signs right there. It should probably only be like $1 sign. Resources like function apps and logic apps actually give you millions of runs upfront for free.

9:51Whereas a virtual machine, it's absolutely gonna cost you money the moment you deploy it. Also, lots of times the WAN infrastructure for the platform as a service is handled for you. So routing or public DNS to get to your platform as a service if it needs to be publicly accessible is handled for you. There are some exceptions to that, things like app services where you want to bring your own domain, but nonetheless, when it comes to things like function apps or logic apps, Azure's just like, Hey, we'll just tell you this is your domain, send traffic here.

10:22One of the most useful things that you'll get started with when learning about platform as a service is the storage account. This is the most widely deployed resource in all of Azure, and it does exactly what you think it does. It stores data. Maybe that's files, maybe that's JSON payloads or maybe that's kind of column nerd data. Kind of like what you would see when you open Excel where there's columns and rows. The point is, with platform as a service, you are not deploying virtual machines and sizing discs or anything like that.

10:53You just have a place to send data and they just bill you per gigabyte. But this is where the network engineer is gonna come in. What if our data is sensitive? What if our data is really, really important? We don't want to have a storage account deployed and we access it over the web maybe via www. or maybe via SFTP, or depending on what we're doing, maybe even using SMB, there are some portions of a storage account that support that. Now I put www., you should consider that as both HTTP or HTTPS.

11:28The point is, we may not want to expose our data publicly, even though if we put it behind something like in like, you know, identity to secure it, no, there are absolutely ways to deploy platform as a service offerings and connect them privately to a virtual network in the actual, you know, the actual configuration. And the only way traffic can make its way to this platform as a service that you owned is through your virtual network. These are using things called end points.

11:59Now there's a couple different kinds of end points, and they meet two different kinds of objectives, but we'll talk about that later when the time comes. The point is, is I want to allay some of your fears right now that at least I had when I was getting started was, oh, if all of these developers wanna use platform as a service, then they'll never want to use infrastructure as a service and therefore they'll never want to use virtual networks. While it's true that they probably could get around using virtual networks, that would probably be exposing data at some point along the way in such a way that that is a really bad idea.

12:33So designing your own network infrastructure, subnet infrastructure and routing infrastructure and including platform as a service offerings through that particular infrastructure is absolutely something that you can and will want to do. But again, a bunch of these platform as a service offerings all do a lot of different things. You have loosely coupled asynchronous architectures. You have event-driven architectures, you have message driven architectures, you have web front ends, you have storage backends, and that's why I kind of recommend just peeking under the hood over at the AZ204 because understanding what those resources do and how communication is expected to flow from one of those to the next will actually benefit you tremendously when designing a network to facilitate that flow.

13:25Now, there is one final as a service that I'm gonna mention right here, even though there are many more as a services that exist nowadays. The last one that we're gonna talk about is good old fashioned software as a service. Nine times out of 10, this is a public facing resource, kind of like having Excel online. Everybody needs to be able to get to this software somewhere in the world that they are and then authenticate, log in, and then get access to their data and the application itself that they use to manipulate the data. That being said, it is potential or possible that your company might design software via software as a service, but then offer access to it only privately.

14:09In this case, a lot of the times you're building something like VPN architectures between yourself and your customer so that they access the traffic securely within Azure over a VPN rather than going over the public internet. Even though A VPN is usually going over the public internet, at least it's through an encrypted tunnel. Now, like I say, we really are gonna cover a lot of ground in this set of videos talking about how all of these things work as we progress through this playlist. So now that we understand the as a services and where our objectives as network engineers might lie, we can progress on and talk about how Azure is laid out.

14:48I hope this has been informative for you, and I'd like to thank you for viewing.

0:00Okay, I absolutely love recording this particular video. I've recorded it a few times now throughout my career at CBT Nuggets, and this is still one of my favorite things to do because Microsoft has done such an incredible job of highlighting the work that they've done into building Azure. So what we're gonna talk about now, something really important, that's the difference between regions and availability zones, and this is again, something that you'll have to consider when designing any of the networking portions of your solutions. This is a really big fundamental thing to understand.

0:33So what I want you to do is I want you to Google Azure Region Maps. Go ahead, bring up a browser, I'll wait. Or actually you could just pause it and come back to it when you got it. Okay, now that you got it, find one that looks like choose the right Azure region for you. If you see right here is azure.microsoft.com/explore/geographies. So we'll give that a click and it's basically just giving a little splash page about it. But what I really want you to do is come down here and click Explore the Globe. So it brings up this data centers page. And then right here where you see Azure Global Infrastructure, click learn more.

1:07Now this part may take a little bit of time to load up, but when it loads up, you now have an interactive map that you can click and drag upon and spin around. This is showing you all of the infrastructure that Azure has deployed around the world and these are effectively your options for the places that you can deploy and begin designing. So here we go, I'm gonna kind of focus in on North America right now. That's where I am and that's where I'll be doing a lot of my deployments for these videos here.

1:39Now you see the green dots, these are your actual regions. Now, important talking point immediately out of the gray, when you think about regions, you might think regions equals a data center, wrong, regions do not equal a data center. Regions equal data centers plural, specifically those data centers are known as availability zones. And availability zones are a big talking point.

2:10Fundamentally, when you think about deploying stuff in the cloud, the big reason why you deploy stuff in the cloud is you expect the cloud to keep your stuff alive. And a big part of that is we expect them to keep it alive in such a way that even when there's failures in a single data center, we expect some sort of failover or changing of traffic to take place. That's not always automatic, sometimes it's on us to design for that to happen, but they give us options by doing that, by deploying availability zones.

2:43In other words, whenever we look at something like East US, let's actually click on East US here for a second. When we scroll down just a hair, you see all sorts of cool information. When we see the availability zones, it says it's available with three zones. You should really think about this as here's East US, which is located in Virginia, and with the three availability zones, you should think about that as three availability zones like AZ1, AZ2 and AZ3.

3:16These are geographically close data centers, as in they're all within Virginia, but they're just far enough apart to where if some type of like natural disaster or some sort of event happens in availability zone one, it's unlikely to impact availability zone two or availability zone three. So with a lot of our workloads like virtual machines, we get the option to deploy them within different availability zones.

3:46For instance, a good compute layout would of course have multiple virtual machines operating in some form of a cluster. So I might have VM one in availability zone one and communicating and maybe replicating data or something like that to VM two in availability zone two or VM three in availability zone three. Now as a network engineer, your head might immediately go to, ah, they're in separate buildings, therefore there must be a huge amount of latency. How is replication going to be reliable and importantly synchronous?

4:21Or are we going to have to rely on something like asynchronous communications and replications? That is not the case, the connections between each of these availability zones are extremely high throughput, private fiber connections. It's not a stretch to expect to see these hovering around the 10 millisecond latency times between any of these availability zones. Now, when we start to stretch and think about replicating or communicating to regions outside of say, the East US perhaps maybe we're looking at something like the West US over here, see there's West US too, which is in Washington.

5:01This was open in 2007 and it has three availability zones. When we're talking about having something like a West US, let's just make up something like availability zone two, communicating over here to the East US availability zone three, this is where we could start to incur latency, but it's still extremely fast traffic and communication between Azure regions because it's all using Microsoft's backbone to communicate between resources.

5:32So it is possible that you may have to switch to something like an asynchronous architecture between regions, but within a region and between availability zones, you can absolutely rely on synchronous communications and architectures that way. So take a moment right now to start poking around and getting used to some of these regions. In particular, I'm gonna spend the most of my time right here in the South Central US, why? Because that's where I am. Well, not specifically, this is Texas and I'm right next door in Louisiana.

6:02I was born in Texas, there's that. But also take a look at the things that go around these Azure regions and support them like the wind farms or maybe like solar farms. Also, notice another pretty important thing is these little blue dots. What are these all about? These are actually points of presence. This is gonna be a big factor for you to consider if you're looking at doing something like express route or importantly content caching. Using content delivery networks. Specifically, that's the Azure front door resource.

6:33Also, one last thing I wanna point out is check out the white dots. These are regions that are coming soon. So here's East US three, which looks like it's gonna be right around Atlanta. Down here we have Mexico, which looks like it'll be near Mexico City. Even down here we have Chile. Also, not too surprisingly, you see a huge amount of expansion that's gonna be taking place throughout Asia and India. So we needed to take a moment to pause and make sure that you understood the differences between a region and a data center, which is more specifically availability zones.

7:06One final thing that you can do for fun is do take a tour. That's kind of fun too. You can do virtual Microsoft data center and it'll actually take you to a virtual data center where you could actually like click around and explore what goes on inside the data center. Do something like enter the lobby here and it'll zoom in and you'll actually feel like you're in the lobby of an Azure data center, which is pretty cool. You can learn a lot about the Azure data centers and what it is that they do by just poking around and clicking at like what the security teams look like.

7:37It's worth pointing out things that like the staff that works here is obviously, you know, under a tremendous amount of pressure to keep things secure, but they even have Azure regions that are specifically for government entities, and all the staff that works there have government secret clearance, which I think is a pretty interesting thing. So this has been understanding Azure regions, data centers and availability zones. I hope this has been informative for you, and I'd like to thank you for viewing.

0:00So if you don't already have a free Azure account, please take a moment to go to azure.com and click try Azure for free to get started trying Azure for free. Click start free from here and walk through the process of signing up for Azure. It will take a credit card on file, but you will get a certain amount of resources for free to use or to try out, depends on, you know, your region or stuff like that. But usually you get $200, a $200 statement credit for your first month in Azure.

0:30That should be enough to walk through this, you know, all the, the demos that we're gonna do in the AZ 700, should, but we're also gonna talk about ways that you can monitor that and protect yourself at the end of this particular set of videos. Once you've got your account stood up, your home away from home is now going to be portal.azure.com and I'm starting out by zooming in right now for an important reason. If I go back to 100% right here, first of all, you can't really see that probably on the screen that you're watching on, but second of all, when I zoom in, certain aspects of the screen are going to get cut off.

1:06I want you to be aware that I'm gonna be zoomed in and that your screen might not always look like my screen because of my zoom level. Okay, so the way Azure works is not entirely unlike every other public cloud that's out there like AWS or Google Cloud or anything else. You have a list of resources that you could pick from that you want to deploy and then you answer a few questions and they provision the resources for you. Now, where do you go to find these resources though? Well, when you land in Azure, you see this little hamburger menu in the top left, give that a click and you kind of see it broken apart into two spaces.

1:42You have the stuff that's above favorites, you see the little favorite star right there, and that's your home. This could be a monitoring dashboard and then this is all services. Give all services a click and you can see literally every single service that Azure offers that you can deploy right here. Hundreds of options, it's a lot and you can get lost pretty quickly. The other thing that I wanna point out right now, and this is a big talking point most, and by most I mean the overwhelming majority of these services are platform as a service services.

2:19There is no avoiding it. Accept this now, that you will encounter platform as a service in your journey and nay embrace it because that means you're probably doing something right. So there's a lot, but then there's some that are gonna be your staples, your go-tos, and that's why we go back to the hamburger menu here and everything that's under favorites is probably something that you're gonna want to encounter at some point. Now how can we actually work with this? Well, the first thing is is under favorites.

2:49You see this list? This list is editable first of all. If you hover over these like app services right here, it pops out this little window and if you no longer want app services here, you can just click the little star right here to remove it from your favorites. Beyond that, these are all movable, so I can move app services to the top. Actually, it's kind of acting weird. It's on my other screen right now. Honestly, it's kind of a wonky monitor that I'm using, this monitor's for like it's specific, it's like a gigantic tablet basically, and it has some resolution conflicts with upgrading to the latest Mac list.

3:22So just trust me on your screen, you see the little dot dot dots here. Click and drag these around and see if you can move these higher like I just did there. Hey there, it worked that time. That's cool. These are gonna be your heavy hitters. You see virtual machines, you see virtual networks, you see SQL servers and you see Entra ID, that was actually what was known as Azure AD just a couple weeks ago. They're rebranding it to Entra ID. Of course they're storage accounts and yeah, we're gonna spend a lot of time on load balancers in this set of videos too, so get ready for that.

3:53The thing is, with all of these resources, there are some fundamental, crucial clutch things that you have to have upfront. The first one is the thing that you created whenever you actually signed up, and that is a subscription. You see right here, this is my account, knox@knoxdata, and within that I can have multiple subscriptions. I can have a pay as you go subscription and I can have something like a Visa on file for that subscription, but then I might create subscription two.

4:32This might have prepayment for this particular use case and that may have a MasterCard on file, or it could be even as simple as I just separate my cost centers into different subscriptions. I can have an HR subscription which has the HR credit card on file. I could have an IT subscription, which has the IT credit card on file. Whenever you deploy a resource, no matter what resource it is in Azure, the very first question that they ask is, who's paying for it?

5:06What subscription does it belong to? Which card should we charge? Understand that right now, upfront, this is gonna be automatic, hence forth, moving forward, subscription mandatory for every resource you deploy. Now, there's another thing that's usually going to be required for every resource that you deploy. Not always, but usually, and that's the region. Where's it going? What data centers are going to host this? Sometimes within that you have the ability to choose the availability zone, but not always.

5:39For virtual machines, for sure, you get to choose the availability zone. When you start getting into things like platform as a service like function apps, you don't get to choose the availability zone because they're automatically going to deploy it across availability zones for redundancy purposes. Again, platform as a service. The point is not to worry about the infrastructure, they're just gonna handle that for you. So out of our mandatory things, we have subscription every resource, no matter what. Region, almost like 99% of things that you deploy in Azure will need a region.

6:14Now, the final thing that you have to have is known as a resource group. The resource group is not particularly complicated, but it is mandatory for pretty much every resource that you deploy. Quite simply, it's just a logical way to group resources together. For instance, I may be deploying application one, but application one is actually comprised of a bunch of different resources.

6:45It may have a virtual machine that serves as a backend worker, which requires a virtual network, which requires a network security group, which also requires a virtual nick. Those are all resources, but then this virtual machine might also communicate to a storage account and maybe an Azure SQL database is part of it too that it communicates to. And collectively, all of these resources together make application one.

7:16Now over here, I might create application two and it might live in a different region or it might live in a same region. Heck, it might even have the same virtual network that it deploys a virtual machine on top of, but it may need a separate Azure SQL database and a separate storage account. It makes sense to group these separately because application two requires a separate set of resources than application one, and we don't wanna muddy this up and get confused by looking at, oh, I'm in the application one resource group, but that VM was actually for application two, no, that's not good.

7:54We wanna keep things nice and clean like this. Importantly, we can also assign permissions to our users or other resources at the resource group level. Oh, hang on, let's bring that back. Here we go. At the resource group level. So if I grant Knox the admin role on application two, that means that by inheritance they get the admin role on all of the resources within the resource group.

8:25So you should think about the resource group also as a security boundary. Now, I can absolutely assign permissions on each individual resource in the entire resource group, but lots of times we know who our admin is or who our owners or stakeholders are for a specific resource group, and we can grant them the permissions at the resource group level. In fact, it's worth pointing out, permissions can be prescribed all the way at the subscription level. We assign someone a subscription admin, guess what?

8:58They get permissions to every single resource group that gets deployed within the, within the subscription, and that therefore gives them permissions to every single resource within the resource group. You get to pick effectively at which tier you want to apply these resources for specific people and these permissions. We do this by assigning roles. Roles are effectively a group of permissions. So if you're kind of thinking about it, we have a resource group, which groups well resources, I mean it's pretty straightforward.

9:34And then we have users, which of course can be grouped with classic security groups in Entra ID or on-premises if you're syncing from there. In the middle, we have roles which are groups of permissions. So if you see what we're doing here, we can give a group the owner role for a resource group. Do you see how we can kind of like blanket apply permissions or we could give them owner roles or permissions at, you know, a resource level or we could apply those permissions to an individual user, but it's, you see, you can kind of mix and match all of those together.

10:14Again, it's really important to understand what you have to have upfront in order to get started. Every resource you deploy, let's just go into virtual machines right now, click Create, Azure Virtual Machine. You'll see, what are the first several questions that you have right here? Subscription, resource group, region. Just gonna be a question that you have to answer for every single resource. And yeah, you'll probably have to give your resource a name too. I should probably throw that out there as well. That you're gonna have to come up with a clever name for some of your resources.

10:47Sometimes there's restrictions around those names, sometimes there's not. We'll cover that when the time comes. So for now, we understand the importance of the resource group and where it fits in to the entire resource model. The idea here is understanding the hierarchy of permissions from the subscription to the resource group and then to the resources themselves, and also why you might logically group them. The last thing I'll say is kind of just a different thing, is that you don't have to group resources based on their workload, meaning you don't have to group resources 'cause they all be belong to app one.

11:21You could group resources based on the intended permission that you want to assign. For instance, maybe I want to put all of my networking resources, regardless of which app they support into a resource group for networking. That way I could assign permissions to all of my network engineers. Separately, I could assign all of my compute layers like function apps, logic apps, virtual machines, container apps in a separate resource group, and then delegate those permissions to the systems engineers or DevOps engineers.

11:53You can get creative with this, again, with all the mixing and matching, you also don't have to do it based on a logical application or workload that's being supported. You can do it based on the type of resource like virtual networks. So with that being said, this has been understanding resource groups. I hope this has been informative for you, and I'd like to thank you for viewing.

0:00Now it's important to take a peek under the hood at Azure AD, or what is now known as Entra ID, and for a really important reason. And that's because permissions, you know, it's not just about allowing people to log into Azure and then poke around. It's about making sure that you understand where permissions and roles and how all of that comes from. At the beginning, it all begins with users. Now, a lot of users this day and age, are coming from hybrid environments, meaning that businesses are synchronizing their On Premises Active Directory up into Entra ID.

0:34I'm going to tell you right now, I'm going to struggle with this, calling it Entra ID. It's been Azure Active Directory for me, for like six or seven years, and they just changed it like last week. So bear with me, as I say, Azure Active Directory's becoming Entra ID. It's right here on the screen. If I slip up, I mean Entra ID instead of Azure AD. Anyways, here's users. You can create users very simply with new user and create new users right here on the spot, and those users will have the ability to log into Azure.

1:05Now, of course, just like you have anywhere else in any other directory, you have the ability to group users together. If you go into the group section, you're really trying to create new security groups. Now, you might see Microsoft 365 groups. This is really for delegating permissions within the Microsoft 365 ecosystem, which is kind of separate from Azure. They both have the same identity store, they both have the same users, the same passwords. But when you're trying to delegate some permissions to say SharePoint or OneDrive for Business or something like that, you'd be looking at Microsoft 365.

1:42When you're back into Azure, you're looking at security groups. So that really just kind of highlights those. And, you know, this is more of an AZ-104 topic, but this is a bit of a crash course to make sure we all get brought up to speed. Now, when I navigate back to this, we have a couple other things that we can delegate permissions to. Applications are a big, like app registrations here. The idea with this is maybe I build a website, maybe it's like an intranet site, and before users are able to access data that might be stored in a database behind the scenes, or maybe a storage account, they have to get authenticated and we want them to get authenticated through Entra ID.

2:26We'll just allow Azure to handle letting people log in and log out or successfully authenticating. This is what app registrations do. Basically the idea here is the authentication is happening, basically it starts from outside of Azure, and the application communicates back to Entra ID and back and forth until the user gets authenticated. So when we're trying to build an application where we want a user to get authenticated with Azure Active Directory, but Entra ID, I already did it, then in this case we're registering our custom built app with Entra ID so that it can communicate back and forth and send, you know, grants or claims back and forth.

3:07Now this also deviates a little bit from something. It feels similar but not quite the same, and that's something called managed identities. Managed identities are really more like the good old fashioned service accounts that you used to run or maybe still do run on On Premises resources. A classic one is we may spin up a SQL Server on-premises and that SQL Server on a schedule has to take backups of the database.

3:39And what do we want to do? We want to put those data, those backups, on a file share like FS-NUG. Specifically, maybe we'll have a shared folder called Backup, something really clever like that. The thing is the SQL Server application will take the backup and generate the .bak file before it needs to log in to FS-NUG and place the file on the backups folder. It'll need NTFS permissions to do that. So back in the good old days, we created an account in Active Directory, specifically Active Directory Domain Services or Active Directory Users and Computers, and then told the SQL Server, use this account with this username and this password whenever you want to access the file share.

4:23Let that concept digest in your mind for just a second where you have a resource or an application trying to use Active Directory permissions to log into another resource. Now think about how this could work in Azure. I could potentially have a virtual machine that needs to access data in a storage account, or maybe I have an app service, which is basically just web hosting and it has a SQL Server backend.

4:54We can easily see where there's going to be some authentication in play here, right? The storage account wants to make sure that users are authenticated before we allow them access to storage. Or the database wants to make sure that the user or the front end application has credentials needed to access the database and change data there. In this case, this is a little bit different from an app registration because the app registration was all about my custom application that I built from scratch and I'm potentially running outside of Azure.

5:26I could even be running it on-premises. Whereas the virtual machine itself is an Azure resource and we want to give it permissions to an Azure resource. Rather than custom building some really wonky solution, I can just create what's known as a managed identity, which should be a synonym to you for a service account and assign it to this virtual machine. For all intents and purposes, this managed identity looks just like a user account.

5:59So I can go over to the storage account and assign a role that gives permissions to the storage account to the managed identity. See, come up here and search for managed identities and give it a click. See how easy it is to create a managed identity. If I choose Create right now, of course, I have to choose a subscription and a resource group. I'll just put this in AZ-104-demo. And I'll even choose a region and I can say, "Maybe I'll just use this for virtual machines." So I'll call this vmsid.

6:30I'll just hit Review and create, and Create. Now I have an identity named vmsid that I can assign to my VMs, and then I can go to things like my storage account and give permissions to vmsid. Boom, done. So I know that's a little bit, it's a really tough one. The first time you see it is understanding the difference between a managed identity and an app registration. I think the biggest and simplest way to put it is a managed identity is specifically for an Azure resource to access an Azure resource, whereas the app registration is really for an external application to use Azure AD to authenticate a user who's using that application.

7:15Again, this is an absolutely colossal, massive, major topic in the AZ-204, and it's touched on a good bit in the AZ-104 as well, but in the AZ-204, you are quite literally writing code throughout pretty much the entire course for managed identities. And then a separate huge chunk of it is for app registrations too. So I wanted you to be aware of Entra ID. The big reason that I wanted you to be aware of Entra ID is that at some point in your journey you will encounter needing to have, understand where your users or groups are, or understanding what applications, like app registrations or managed identities do.

7:56I hope this has been informative for you, and I'd like to thank you for viewing.

0:00There's one last thing that I want you to be absolutely 100% aware of, and that is where do you go to keep track of your bill? As you're deploying new stuff and experimenting, how do you make sure you're not running up a huge, huge bill? Now, there's two separate places in Azure where you can go to look at this. Really one, but there, you know, there are two. Cost Management and Billing is gonna be the first place that you go. I really like Cost Management and Billing because right here, the spending forecast.

0:31Immediately I'm looking at this and seeing a forecast of 263 and that actually seems pretty high compared to what I did last month, which was under 50 and I'm like," Whoa! Where is this bill coming from? Where is this forecast coming from?" If I scroll on down a little bit more, I can see this month's top products by charges, and immediately I'm thinking," Oh yeah, I did deploy API management and I did have a big Azure app service that was running too." I need to go clean those resources up before I move on any further.

1:02All I have to do is delete those resources. That means they're gone permanently, but I won't be incurring a bill for them anymore on the per hour billing that I do. Now, under the Cost Management section, you can even see there is a cost analysis section where you can dig into these details a little bit more. Again, it's a lot of the same information that you just saw, but maybe broken down by service name, location, or subscription. Of course, you get the forecast up above, which is nice to have as well. Another thing that you may wanna take the time to do is go ahead and just set up cost alerts, but the real types of alerts that you would want to subscribe to, believe it or not, doesn't come under cost alerts.

1:43It comes under Budgets. And in this case, you would wanna create a budget for yourself. So I could give my budget a name, like "monthly budget" and if I scroll on down, I'm gonna take a look at my monthly budget forecast. It says, let's go ahead and put 551 as our monthly budget based on our forecasted amount and growth expectations over time, and once we start to approach this threshold, we'll start alerting you whenever you're exceeding that particular budget. Right here, we get to set up the alert conditions.

2:14We can actually say, if there's an actual percent of budget over a certain amount or a forecasted percent of budget over amount, let's say 90% of this budget happens, then email me. We'll say knox@knoxsdata.com. We'll click create and boom! I've now set up a budget and an alert for if I start to approach that budget when it's forecasting me going beyond 90% of that budget. So I know, a quick and short video for you to understand where you can go to understand your bill and where you're currently heading, based on your cost analysis and your forecast.

2:52I think this is a really important tool for you to see before you begin your journey because some of these resources, particularly like Express Route or these VPN gateways, they can rack up a pretty big bill pretty quick. So do keep that in mind before you proceed that you'll want to check this at least every other day if you're serious about going through this playlist and spinning up and trying new resources. I hope this has been informative for you, and I'd like to thank you for viewing.

0:00My challenge to you was the quick and easy one, but one that's probably gonna save you at some point in your journey or in your career, and that is to set up an alert based on a budget that you're gonna set for yourself. Now you can go into budgets, click under cost management and billing. Under the cost management section, go into budgets and add a new budget. Now the scope here, you see this green circle that says Knoxs Data, and that means every subscription within my tenant or within my account, it is worth pointing out that you can do some really cool things like setting budgets based on a subscription or even based on a resource group.

0:39So if you wanna set a budget for just a subscription or just a resource group, like the resource group name right there, you have the ability to set filters for that. Now, I'll come on down here and I'll set my other monthly budget just to give it a name and we'll set a threshold here of like $900. In this case, we're gonna go a little bit beyond the forecast, just so I can warn myself before I get to a really big bill. We'll go into the alerts and this time I'll set the actual and set it to 50% of budget.

1:09I wanna know when I'm starting to go close or like I'm, you know, I'm encroaching on above 50% of that budget. We'll go ahead and set my recipient email address right there. Hit create and validates to make sure everything looks good for a second. And boom, there we go, budget and alerts were created. Go ahead and set that up. It's gonna be a big deal for you, at least at some point in your journey. I hope this has been informative for you, and I'd like to thank you for viewing.