Hi everyone so welcome to this Azure 900 Azure fundamentals study Cram Reloaded or the 2022 version. So this is an update to the study cram I posted back in June 2020. That's about 150,000 views and I just finished creating an entire Azure 900 study course. So this is 8 1/2 hours of complete training. So this was the original study cram that this is replacing. And then there's the course that I just posted a few days ago. That's 8 1/2 hours. It's every single skill that's assessed. And there is a download of the complete handout. So that download has all of the different links for the different pieces of information. It has the whiteboards of all those detailed lessons. And so that I would recommend you go and watch. So the idea is go through that complete course. It's 8 1/2 hours of your life, but it will put you in a great position. And then watch this maybe a few hours before the course. Maybe watch it a couple of times just to refresh and get those ideas back in your brain. There's always this is useful. Please do go ahead, like, subscribe, comment and share and you can hit the Bell icon to get notified of new updates. So this is the cram for the AZ 900 exam. So that Azure 900 exam is what's going to go ahead and get you. That Azure fundamentals certification so we can go to the as 900 site. And it talks about what's kind of covered in the exam and the fact that it's going to get you that Azure fundamentals certification. What's great about this page is, well, yes, you can go and schedule the exam. But it has the skills measured document. So you can download this document and what it's going to do is walk through every single skill that is going to be assessed to. Ideally you want to be able to download this document and take off each of those individual things to feel confident. Yes, I'm ready. I know all of these things that I'm going to get tested on, and this is the structure of that eight and 1/2 hour course. There's basically a lesson per each of these skills assessed. Then there's. Actually a link to the Microsoft learning path. So yes, I've created that full YouTube course, but I recommend you do this as well. It's a great course, obviously it's text based, there's a few little videos sprinkled in, but it does have some exercises you can perform as well. So if you have the time, definitely would recommend you get to go through that as well. Do you really just put yourself in as good a position as possible? The more resources you can get, the better position you're going to be in. So with that said, let's kind of jump over and really just start cramming. So we think about the cloud. Azure is a cloud service and we use this term the cloud. So really when we think about a cloud. What are we really talking about? So understand what are the key principles and features we expect from a cloud. We expect to see agility. So agility in terms of there's lots of different requirements we have, there's lots of different types of service. So I want to be able to use the right service that meets my exact goal. My needs might evolve, so I want to be able to change what I'm doing as my needs change. I don't want to be stuck with a certain technology, but also my usage amount is going to fluctuate over time. So agility is all about types of service and amount of service and that really leads into this idea of kind of consumption based. I want to pay for what I'm actually using at any given second because again, that agility, there's seasonality. The amount of work may vary by hour, or day or week or year, month, maybe multiple years. So I want to be able to handle that by only paying for a need at any moment in time. We think about high availability, ha. I want to make sure that yes, the basic infrastructure that my service is running on is resilient to certain types of failure, but it's also mechanisms in place to help me architect my services to have high availability. Maybe distributing them over different racks, maybe distributing them over different datacenters in a small area, maybe spread over data centers with hundreds of miles between them. We also think about. Faster recovery, which builds into that high availability. But this time we definitely want that big distance. I want big distances, hundreds of miles. So there was some natural disaster. It's not going to impact all of our deployments. And that agility I talked about scalability. I don't want to worry about running out. I don't want these little islands of resource that of this island could run out. When we think about the cloud, we think about pooling resources together. So this massive amount available to me. So there's always enough resource to meet my needs. Now, when I think about a cloud, so this is just thinking, OK, these are the definitions of a cloud. There's different types of cloud. We often think about. Hey, yeah, the public cloud. But that's not the only type now, obviously. There is public cloud. So I have the idea of a public cloud. E.g. Azure. Azure is an example of a public cloud. When I think about a public cloud, this is typically externally hosted. Buy some provider. It's going to be multi tenant. It's not typically infrastructure dedicated to me. I might access it over the Internet now. It doesn't have to be exclusively over the Internet. There were certain ways I can get private connectivity. Could be a VPN, could be a private connection, but typically and by default it's going to be Internet facing. These are very much going to have the idea of being consumption based. I expect to pay for what I'm using that's going to be a key tenant of that and I think about many locations. I'm going to be able to pick, well, hey, yes, it's the cloud, but we still have to understand geography. So I can be maybe close to certain customers because that latency thing, the time things take can be a big impact and want to distribute things around. When I think about Azure, for example, well, there's this huge number of regions. So this is kind of an infrastructure map that we actually have available on the Azure website, if I skip the intro. And just explore the globe. What we can see is there's just a huge number of regions available. Actually make it 2D to make it quicker. All of these little blue dots, these are regions, these are all distinct sets of infrastructure where capacity is available. All over the world. So I can go and create resources there, so there's just a massive amount of these available to me. So that's the public cloud, but realize I can also have. Private cloud. Now really, what is a cloud? Take everything else away. Really what we're talking about is capacity. There's some capacity that exposes a certain set of resources that I can consume, and there's going to be certain APIs and interfaces to actually use that well. Likewise, I can have capacity on premises, it could explode certain resources like VMS or containers, and I have certain management infrastructure. Who maybe facilitate the idea of a cloud pulling things, user self-service, showback, chargeback, all of those types of things. So here I could have a private cloud that's basically running on my infrastructure so it's on premises. I might be able to do quotas and policies to help control. But I'm using my on premises infrastructure. So that's private cloud and then we have the idea of hybrid cloud. As you would expect with hybrid cloud is essentially both of them. Maybe I'm using private cloud on premises to host some work, maybe I'm using public cloud for other types of work. Maybe I run it on premises but in busy times that variable load. I burst out and start using the cloud. All of those things are available to me. So I have these different types of cloud. But absolutely Azure is an example of a public cloud. Now with that, there's things like operational expenditure, capital expenditure, and so those are all about how we pay for things. So I can often think about anything on premises that's typically going to be capx capital expenditure, IE I have to kind of pay for it up front. I buy my server, I buy my license, I buy my data center and then depreciate it over a certain period of time. So I have these assets that has a certain lifespan and the challenge with that is we have to do all that investment up front. So that could be fairly painful. I can compare that to the public cloud, what is going to be OpEx? Operational expenditure, I pay for it as I use it, which this OpEx really plays into that consumption based nature of the public cloud. I pay for what I use. There isn't this big upfront cost. I pay for it as I use it and that's really powerful because we've CapEx again I get certain assets and I have to use I have to use them for a certain period of time to get my value for money and I lack a certain amount of flexibility. Whereas when it's OpEx and I pay for what I use, I can change my mind. I can start using a certain type of resource and then say actually that's not the right one for me anymore, delete it, create a new type. I don't lose any money. I change for what I'm doing. If I'm using less, I payless, if I'm using more, I pay more. So if I think of any type of workload where there's some variable load. Typically the public clouds could be very uniquely suited for this to work. For example, you think about scenarios where maybe it's the idea that it's on and off. Maybe I'm a tax company and I only run for a few months a year. Maybe I'm a startup company and I'm growing really fast. Well, do I want to go and pay for all that hard work up front when I may fail? No. Maybe I just have these idea of variable loads and I just want to pay for what I'm using. So there's all these different scenarios where this consumption based nature really is key for this to be successful. So let's focus on this idea of the public cloud. Now one of the big focuses we have around the public cloud is this idea of shared responsibilities that both the customer I, me using Azure and the provider Microsoft. They have certain responsibilities for different aspects of the service. Now that responsibility will change depending on which service I'm using. We often think about there's different layers to a complete solution. I can think sure there's things like storage. There's network. There's the service, the compute itself, there's some type of hypervisor that basically creates VMS I can use. Then inside that VM there's an operating system, there's a run time like .net or J2E. Then I get my app. And then my data and realized that as a business, the things we really care about is the app and the data. That's what sets us apart from other companies. So that's where we really want to be out of focus. So when I think about those layers, that are what we care about. If we think on premises, well, we're responsible. For all of that. So here the customer. Is responsible for all of the layers. You may have different teams, but ultimately it's all you as the customer. When you start to move to the cloud, you typically start with IaaS infrastructure as a service. With infrastructure as a service, I can really think about this line. There. So now the hypervisor, all of the fabric, the server, the network, storage well. With IaaS, the responsibility is let's just say Azure. Microsoft as the provider are responsible for all of those things. You get a service offered to you, you don't manage any of that. What you get as the customer is for what is inside. That virtual machine. So that includes things like, hey, I can pick the operating system, is that windows? Is that Linux, but there's all the responsibilities for that. OK, responsibilities for that means I'm worrying about things like. OK, patching it. The backup. Config. Antivirus, firewall, the list kind of goes on. There's all these responsibilities that I have, but I have full access to the operating system, so I have all of that flexibility. So in this world we've IaaS, we're really talking about kind of virtual machines. And kind of virtual machine scale sets which we're going to come back to more detail of what those services are. But for those, hey I full access to the operating system. So the most flexibility, but I have all the responsibility as well. Then we get to platform as a service PaaS. So here the line of responsibility. Shift all the way to there, so now Azure is responsible. For basically everything, there's still an operating system, there's still runtimes, all those things happening. I'm not responsible for that. I may not even see it, depending on the type of service what I'm responsible for. Is my app and my data. So obviously if I'm creating a custom service, I'd rather use this as my company what differentiates me as my app and my data. I don't really want to be in the business of managing VMs and worrying about backup and patching and all of that stuff. So if I can, we like this idea of PaaS and you'll hear services like all Azure container instances, Azure Kubernetes services, app services. You'll hear about things like functions. And logic apps, serverless offerings. And again, we're going to come back to all of these, but these are Paas offerings. And then finally I'm going to do it in a different color. You have software as a service. The whole point of PaaS is it's providing these blocks. I can just focus on my app and my data and it's this is what provides the business function. The PaaS service on its own does not provide a business function. With SaaS, it's providing that business function. For example, this could be Microsoft 365, it's providing me SharePoint, it's providing me collaboration, it's providing me mail, whatever that might be. It's all provided I don't have any responsibility for the platform itself. I might do little things like administer users to enable them for a feature, but I'm not patching exchange or patching SharePoint. There's dynamics 365, there's all different types of SaaS, there's third party SaaS solutions, but I am not managing over those. And again, just the key point here. Is I kind of want to get as far that way as I can. Because I don't want responsibility if I can get away from it. OK, so let's dive into really what we think about when we think about Azure. A big focus is on kind of IaaS and Paas and there's a kind of a joke. There's no such thing as the cloud. It's just someone elses PC. And there's an element of truth to that. If we think about that idea of capacity, well, I need capacity, I need compute, so servers, I need network switches to connect things together, I need some storage. So that has to live in some physical space. I talked about regions already, that flexibility to have many locations and so a region is really one of the key building blocks when we think about Azure. So let's explore regions. So I can really think about the idea of Azure has many many regions. I showed them already and I can think about a specific region. Is east US or West US? And it's made-up of multiple physical locations, so I could think about, OK, well I have a region here. And within that region, there's multiple physical buildings. Now, what really defines the region is those buildings are all fairly close together. We talk about the idea of this two millisecond latency envelope. Don't worry about that too much. It's basically the longest amount of time saying can take from the region to the edge of the region to talk either very close together. So I might have a region like E. US. And then there's lots and lots of other regions. This could be a completely different region that would have its own buildings that might be W US, for example. So we have all of these different regions. And then the reason we have different regions is, well, there might be certain data sovereignty requirements. I might be in a certain country that requires me to have my data remember my app. In the same country, so there's requirements to host the data. So by having lots and lots of different regions, hey, I can stand up my services in a region in my country to meet data sovereignty requirements. Also, I want multiple regions so I can have DR. I want maybe hundreds of miles. Between them so that if there was some natural disaster it's not going to impact my other service. Also yes a latency is the boundary of a region, but might have customers all throughout the world. From the customer to the region takes time. So I want to be able to put my services all throughout the world, maybe says an instance close to my customers, so they get a really nice experience when using the service. Now. I'm talking about Azure and regions in Azure. The reality is there's actually more than one Azure environment. There are several. What we typically think about is kind of the commercial, like the regular Azure commercial that we all have access to. That's kind of how we think about it typically. But there's actually multiple regions. It's not just that commercial region and we can see this. So if I jump over for a second and we go and look at a command prompt, so if I just jump over to this makes a bit bigger for you, I can actually do a get. Easy. Environment. And notice what we see. We actually see there's Azure cloud kind of that regular commercial cloud. Then there's also a China cloud. And an Azure U.S. government cloud, now there is also an Azure German cloud, but that's actually getting a lot less investment now because of changes to regulations, changes to just regular regions. We're not going to typically see that used as much. But certainly we can think about, well, there's this China cloud and this US Gov cloud. So why are there these separate regions? And it's really about compliance and certain regulatory requirements that I need to meet. So yes, we have commercial which has a set of regions. But then there's also China. Now China has requirements that it has to be operated by a Chinese company. So the China environment is actually operated by 21 vianet and they're basically licensed the Azure technology. So it has its own sets of regions. And then obviously we have kind of the US Gov. Which has its own sets of regions, so they each have their different sets of regions. US Gov for example, has a whole bunch of other regulatory standards that it meets, for example CGS, ITAR. There's a whole bunch of these available for it. But the idea is if I'm a company, maybe a government entity, hey, I have certain additional requirements that are not met. By the commercial environment, well, I would use the US Gov. If I'm a Chinese company and I want my services hosted in China, I would use the China environment, which again has its own regions, has its own Azure AD, as does US Gov so these are all essentially completely separated. They're different physical facilities, they're different logically, they're different networks and different identity providers. They are really isolated. Environments to meet whatever regulatory requirements that I may have for my particular workloads. And even when we look at the regions, you'll notice, well, some of them are particular environments. So we have this idea. We have multiple regions for those different reasons. I want Dr capabilities to have a big distance between them. Regulatory, hey, I need the region in the same country. I am just, hey, I want it close to my customers. So these are all super important and that idea of for disaster recovery is actually a key concept. So there are pairings in Azure. Said. Certain regions appeared and we can actually go and look at these pairings. And what we can see is this is showing us all of the pairings that exist. Now what you're going to see here? Is that the pairings are in the same geopolitical boundary. For example, Asia replicates to Asia, Australia to Australia, Canada to Canada. The only exception is Brazil S currently goes to South Central US. This is because Brazil only had one region, so it had to replicate outside of Brazil, but South Central US does not replicate to Brazil if you go and look. You'll kind of see South Central actually replicates. To North Central US kind of see those there. So nothing ever replicates outside of the US from that capacity. You also see got like the US government regions here, US Gov. Arizona, Iowa. And you can also see those China regions as well. So we actually see these different environments as well, which all have. So not Canada, they all have their own regions. So those pairings are used by certain services. So there were certain services in Azure like storage and key Vault that use those pairings just behind the scenes. So that's how it does that resiliency. Additionally, those pairings are useful if I was deploying my own services, when Azure rolls out updates, it will not roll them out to paired regions at the same time they introduced a problem with a software update or you don't want to take down the primary and the Dr region. The same update. So it's going to stagger those updates as well. So I can think about a region as a really big blast zone. If there was a problem, it shouldn't impact other regions. However, even within a region, as we saw, there's multiple physical buildings. And what happens in many regions is those physical buildings, will they have independent power? Cooling. And networking I communications. So they're independent. So these are then exposed as availability zones. Now there's more than three buildings that can think about. There's lots of other buildings sitting in that region, for example. And I can now think that, OK, great, I could now put my services distributed over multiple buildings. So now I have resiliency if an entire building has a problem by distributing my services over multiple buildings. The way this is exposed. Is we're going to have something called a subscription. And for each region, if it supports availability zones, you'll actually see 3 availability zones. You'll see an A1, an AZ two and an A Z3. Now that may map like that for that subscription. If I had a second subscription for the same region, it will also see 3 availability zones. But they might map to completely different buildings. Mayas one could be that building my AZ 2 could be that building, my AZ3 could be that one. So there's no consistency between different subscriptions. The whole point of this is isolation within my subscription. Yes, as one will always be the same building AZ two will always be the same one, but there's no consistency between different subscriptions. When I think about services, services use these in different ways. For example, some services you will see are zone. Redundant. If it's zone redundant, it spans the availability zones just as part of the service, so it's automatically just redundant. There's nothing I have to do. Office services will be zonal. If it's zonal, it gets created in a specific availability zone, so I tell it the availability zone and it will go to that availability zone. But to get resiliency I need to create another instance in a different AZ because the whole point is I want to be distributed over multiple buildings. So some services it's just native. I can say hey I want to be zone redundant and it will make it resilient. Others have to get pinned to a particular zone and then I need to create multiple instances. To get that protection, if something happened to a building like a VM, a VM cannot span availability zones. A VM can't exist in multiple buildings. So we'd have to create zonal VMS. Now create maybe 3-1 in as one, one in a Z21 in a Z3. They're all provide the same service. We can see this. So if we jump over, if I actually go and look at a certain type of resource for example. If I was to look at a public IP address when we create a public IP, we actually get the choice. So I can say down here at the bottom availability zone and it's letting me pick the default is zone redundant. But also I could say actually I want to make it zonal, put it in a Z2. So for some services you'll get the choice, other services you won't. Of a services have no ability to span multiple availability zones like a virtual machine. It understands availability zones. So I can say here, use an AZ, but there's no option to be zone redundant. All I can say is pick which AZ I actually want to create it in because of the type of resource. So it's really important to understand kind of those concepts. And the key point here really is that. I'll pick the one. That makes the sense for what I'm trying to achieve. So if I think about how do I use these, if you see a question and it's hey, I need to deploy a service and I want to make sure my service can survive the failure of a data center. Ping availability zone, that's the answer if you don't have that option. Remember I'd have the same protection if I use multiple regions because obviously they're different data centers as well, but that's typically a very different architecture. That would tend to be more Dr purposes because of how we can synchronize data. So if it's hey and hey within a region, I need protection from a data center failing, do I use a availability set? Availability. zone Or resource group or any of those things. Hey availability zone is a distinct physical building. We've isolated power calling, networking. It helps me by deploying my services over AZs from any particular failure. So that's kind of a key point. So the regions and the availability zones, they're physical constructs. Then we get these logical components of resources we want to use. So the first kind of building block we're actually going to see is identity. So we'll often hear about Azure AD. So I'm going to draw Azure Active Directory. And you might just hear it called AAD. So Azure AD is a cloud. IDP an identity provider. It's used by Azure and many many other types of service. Within there I have things like users, I have groups. I can have devices, I can have applications defined. I've all these various things in my Azure AD and it speaks cloud. What do I mean by that? Different types of protocols conducts authentication, authorization. So it speaks things like hey, Openid connect. SAML WS Fed Oauth 2. They're all things we typically think about for the cloud in how things can work together. Now I talked about authentication, authorization. So what am I really talking about? So authentication and I can really break some of these down South, we typically think about these around authentication. Authentication is all about proving. Who I am, that's what authentication is about. You may see it written as all. N so who am I? I want to prove I am. Who I say I am, or an app or service principal is. Typically we prove that by a number of ways. Something I know I know is typically like a password or a pin. It might be something I have. It could be a token, some sort of device that I can put in, or maybe it's a time based that shows a code. It could be my PC, it could be my phone. Well, it's something I am, IE a biometric. Fingerprint 3D face scans, smiling at the thing. So I want to prove who I am by one of those kind of things. And what we like in authentication today is the idea of MFA multi factor authentication IE. Two plus of these and I want just one of them. I want at least two of them. Hey maybe it's something I have my PC and then a pin for that PC that will be multi factor authentication. Maybe it's going to be a code from my phone while the code from my phone I have the phone. And then it's maybe unlocked with my biometric. So I want multifactor authentication to get that really strong authentication, give me more confidence. I really am who I say I am. You'll hear about things like hello for business that uses your PC and a trusted platform module chip inside the PC and then you unlock it with maybe a biometric or PIN and it's something I have the PC. So with that unlock, it's MFA now MFA is available to all users. The Azure AD, if I turn on security defaults, I don't get to configure very granularly how that's going to work, but I can get it for everyone for certain actions. If I have Azure AD premium, then I can control the multifactor authentication through things like conditional access, which we're going to talk about. Global administrators always get the full kind of MFA set of capabilities, and Office 365 users get a subset of MFA for the Office 365 apps. So authentication is who I am. Then we talk about well. Authorization. So authorization is really about. What? Ohh trying write too fast. What I can do? So I've proved who I am. With authentication now, once I'm authenticated, it knows who I am. Authorization says what I can do, and often we'll hear about things like role based access control as a whole part of controlling well, what exactly can I do? Now I talked about with Azure AD, we like this idea of conditional access which can really feed in to do I require MFA if I have that premium P1 or premium P2 license and it's a big part of hey driving some of that authorization. So I can think about conditional access. Kind of seeing as that Gateway anytime I ask Azure AD for a token which is how we actually go and communicate to other things. So what I can do with conditional access is based on certain conditions. I can have requirements, so I specify conditions and then I add requirements. For example, hey you need to MFA, you have to be on a trusted device, you have to be hybrid Azure AD joined and if we super quickly just jump over. If we go and look at Azure Active Directory. And we look at security. And on the security, we look at conditional access. We can create policies and we can see, hey look, we have assignments, we can assign it to certain users and groups or certain roles. I can target certain cloud applications. So any application that trusts Azure AD. Could be targeted with its own policy. I can add lots of different conditions. And the users risk the sign in, risk the platform they use in what location they're coming from device state. And then I can have different controls. Hey look, I require multifactor authentication or I require it to be marked as compliant or it has to be Azure Hybrid joined and I can pick. Well do I require all of those things? Or do I just require one of them to be true so I have a lot of control around that. So conditional access is all about, as the name suggests, giving me growing granular control about when a certain application should be available and then what needs to be met to make it available. And that's kind of a key point. We have this Azure AD, this cloud identity provider and the whole point of this is we have all these different cloud applications. That will trust Azure AD for that authentication authorization. Obviously Azure is an obvious one, so it's going to trust a particular Azure AD tenant. I have an instance of Azure ID, it's a tenant for my company, but also so does things like Microsoft 365. So do thousands and thousands of other third party cloud applications can all use Azure AD. And So what that's going to give me is this ability to give a great experience for the end users. Because instead of having a different identity every single cloud application, which could be hundreds, which would be a disaster, I can have one identity. Now most of the time what will happen is a company already probably has an Active Directory. This is an. On premises directory system, Active Directory domain services and they already have users in here and groups in here and maybe other things. So what will happen for most companies is you're actually going to synchronize. Using something called Azure AD Connect. So this is going to take the users and the groups and synchronize them up into Azure ID. So my user here will also has an account up here and it does a number of different things. Once I have that synchronization what I can then turn on is SSO. Seamless sign on. What that means is if I'm authenticated already, if I go and access one of these cloud applications, I'm not going to get prompted to authenticate again. I already have the required authentication in place so we can go and check hey conditional access for the authorization. There's certain requirements I have to meet, but not going to get prompted to re enter my password or maybe MFA again. If I've already got a strong authentication, I'll just seamlessly be able to access those. So I'll syndicate maybe once at the start of the day. And then I'm good. It's not going to keep prompting me over and over again. So this is all of the idea that, hey, Azure AD becomes this central identity provider, not just for Azure, but for thousands and thousands of other applications out there. Now. This is great. This idea the central Azure AD we have identity in place. But there might be other requirements we have when we start creating resources, hey, what regions we're allowed to create in, what types of service we're allowed to create, what types of replication we want. And if I think about year old days, I think about this the on premises days if I was a user. And I wanted something what would we do? Well, there was probably kind of an IT operations person it OPS and they had access to the servers where you could actually create stuff. So what would happen is I would put in a request, hey, I want this thing please. I wanna VM or 10 VMS or a database and the IT operations, well what they would essentially be doing. Would be the checks. OK. You put in this request, does it meet our requirements in terms of governance, in terms of regulatory, in terms of all these other things? And only if this passes would they then go and actually create? So their IT operations person wasn't just the person that created things, they were the ones making sure our requirements for compliance and everything else were being met. So that was great. Well, it doesn't exist in a self-service world if we take this same scenario. But now I think about the cloud. I think about Azure for example. Well. It's self-service. There is no IT operations person in the middle of that interaction, but I had the same requirements that IT operations person would check, hey, we're creating right things. It would then maybe give me the right sets of permissions. It would maybe enforce certain budgets how you're spending too much money. I'm not going to let you create these things. So those controls that used to be in place, those checks I need to do another way. I still need those checks. But now I need Azure to do them. So let's think about, well, exactly what those checks could be. So we talked about, well, maybe they gave certain permissions. So a big one here would be role based. Access control. The idea, remember. So if I think about all these things, this is what I can do. So role based access control in Azure is all about the idea that we have various roles. And a role is just a set of actions. There's all these different resources in Azure that depending on the type of resources, different actions you can perform. So we have roles. So then a role, maybe it's easier to just go and see one of these quick. So if we were to jump over and I just went and looked at, for example, a virtual machine and I'll just pick one. And we can look at access control. And I can look at the roles that exist. That was I can. There's always different roles now. Key ones are kind of owner that zoomed in a long way. Here's owner, contributor, reader. These are generic and available for pretty much everything. As the name suggests, owner is the owner of the resource. They can do anything, including change permissions. A reader can read anything, but can't change anything. A contributor can do pretty much any action except change permissions. So they're like the owner, but they can't change permissions. But there's many other roles that are a subset. For example, here I could have a virtual machine contributor. And I can go and look at. Well, here are all of the actions they can perform. So we can see a list. So all of these different things based on a different types of resource they can perform all these different actions and so role based access control is all about the idea that I have a certain role. That I want to give to a certain identity. That could be a user, it could be a group, it could be a service principle which represents an application. At a certain scope. I'm going to talk about what those scopes are, but management group, subscription, resource group, resources themselves and those things together are a role. Assignment. We can think about role based access control is about giving a certain entity a user or group, a service principle, a certain set of permissions. At a certain scope. So that's hey, this is what you can do. So next thing I care about is policy. So if RBAC is kind of about OK, what I can do and who can do those things, policy is going to control maybe the where and the how I can do these things. So this is all about guardrails. If you think about that IT operations person may be controlled, you could create things in these locations of this type. That's exactly what a policy can do. So actually I might change this. I might make this simpler for you to think about. Maybe this is more about who can perform the action and this is what they can perform. But realize the role also controls kind of what you can do. So if we go and look at a policy for a second. If I look up policy. There's a whole bunch of definitions and you'll see a huge number of these, so many on all different categories of types of service. But we could unselect and only look, for example at storage. And you'll see there's all these different definitions. And I could say, hey, storage accounts should use private links, storage accounts should use customer managed keys. So it's accounts should be limited to allowed SKUs IE control which types of storage accounts I can create. So I'm basically putting in all of these different controls and what this can do is I can use these not only to stop or allow someone doing this, I might put it in an audit mode so they can do it, but it kind of tracks and I can use that for compliance. I might. Even used them to correct something if it was deployed incorrectly. There's different ways I can use policies. And rather than having to deploy each of these one at a time, I can actually create initiatives. O initiatives. I just groups of policies and there are many built in. There are additional ones available for certain compliance requirements, like here you can see hey look NIST SP 800 Rev 4 that's 989 separate policies. And so then I can just assign this initiative at a certain scope. Does that word scope again? But what's really nice is again, I can use it to control. But can you also use it for compliance? I can quickly see for each policy or initiative how am I actually doing in terms of that assignment and how my meeting that in terms of my compliance. So I think about policy is about those guardrails. So yes, it can control. I can stop you, I can correct you, but I can also use it for audit purposes. I can see well what is my compliance. So there's different ways I can assign that, but it's those guardrails to help control and again I apply this at a certain scope. And then I think about budget. And maybe that's how much. I want to control how much of something you can create again at a certain scope. And maybe that's, hey, I want to control how much you're going to spend based on what you've spent so far. Or maybe I'm going to look at trends and say, hey look, if you carry on as you are, you're going to spend this amount. So I want to kind of stop you now or alert you now so we can kind of change track. For all of these different things, they're actually going to get inherited because we're going to be able to apply them at this scope word. So all of these apply at a certain scope. So what are those scopes? So we talked about, we had Azure, that's the cloud and we talked about, well, what actually happens is. That Azure cloud we have trusts a particular Azure AD tenant. So my Azure subscription is going to trust a certain instance of Azure AD. Under my Azure AD we have something called a root management group. So we're now talking about is this idea of management. Groups. And I can create a hierarchy of these so I can create this whole hierarchy of management groups. To fit my needs. This could be based on maybe dev, test and production. Different countries, different business units. They're there for my benefit to. Apply these things to so management groups, RBAC policy and budget at any of these levels can have these applied and I could apply it to all of them. We tend to be more loose and general at the top and get more specific as we get closer and closer to actual resources. But I can have up to 6 levels of management groups, not including the root, but they're designed around. Hey, I want to apply. RBAC policy. And budget and for everything we're going to see here, they are going to get inherited. All the way down to everything we're going to do. So if I assigned a policy, this management group, it will get inherited by this management group and this management group and then everything underneath as well. Same for rbac. Budgets would roll up to wherever I set it. So management groups are there to help me assign RBAC policy and budget and for loose organizations. So if the management group is there to help me kind of structure and control those governance type features when we actually create stuff. So the next construct we have. Is the idea well under a certain management group? I create. A subscription. And I can have lots of subscriptions I might create different subscriptions for, again, for different account teams, different business units, different purposes. Subscriptions do have limits now, they're pretty big, but we can go and look and Azure subscriptions and service limits page goes through all of the different limits that apply. See, some of these numbers are pretty big. So maybe I have to have certain different subscriptions just because? I've maxed it out. I have so many things. I need to have a different subscription just because of that. That's not super common. What's more likely is I have different subscriptions for some kind of structural benefit for how I'm organizing. Or I want certain isolation because the subscription is a base unit of Azure interaction. It's part of the agreement between the customer and Microsoft. It uses a certain billing model, like pay as you go. Maybe it's part of an. Surprise agreement. It's kind of a billing boundary. It's what it's really useful for. Well, all of those things are back policy and budget I could apply into management groups. Yep, I can apply them here as well. So I can apply RBAC policy and budget here as well. Which will also get the ones that were applied to management groups above it. So I have these different subscriptions. Now once we have that and I want to create something. Well, when we create resources, resources get created in a resource group. A resource group exists in a specific subscription. I can have lots and lots of resource groups in a single subscription. I cannot nest them. And what can I do? A resource group? Hey I can apply role based access control policy. And budget. You get the idea. And again these all inherit down South, the resource group would inherit the ones from the subscription and the management groups all the way down. So it just gets more and more granular. So behavior, certain resource group has a certain app that needs a different policy. Saying more specific hey I can do that or a different set of role based access control I can do that there as well. Resource groups are not a boundary of use though. What I mean by that is, for example, I might have in this resource group of virtual machine. That's connected to a network interface card. Maybe this resource group over here has a virtual network. Well, I can still connect the nick to that virtual network. So resource groups are not a boundary of any kind of connectivity. They're there partly for these role based access control policy budget. But I really think about resource groups as things that have a common. Life cycle. What I mean by that is that things are going to get created together, they're going to run together, ultimately they're going to get deleted together. So I put them in a resource group as that boundary really that coupling together. So it makes it very easy for me to understand because most likely all of the components in the same service, well, I probably want to have common role based access control, maybe common budgets. When I deploy and provision things, I'll push it into a resource group. So having that ability to have. These common life cycle, that's really a key reason we would use resource groups. Think about, hey, I finished with a certain project, rather than trying to scour around 50 different places that project was in that resource group, I can just delete that resource group and that's really the key point around there. Now. OK, so we have these key logical constructs. Management groups, subscriptions, resource groups. I can apply those key governance constructs while based access control policy and budget. So understand what those do. Well based access control? Well, who can do? Certain actions policy. What can I do? I can put guard rails and control that stuff. Budget or how much of that can I do? And all of those things can be applied at these scopes to help. Hey, I don't want to have to deploy the same policy in RBAC to 100 different subscriptions. They can all roll up under certain hierarchy management groups and apply it at the management group. So it makes my life easier. Now when I think about this, these are all inherited down. Great. But how do I actually interact with this thing? See if I think about. Well, there's Azure. There's actually. Thank God the Azure. Resource. Manager. Arm. This is how I talk to Azure. So no matter what I'm doing, I'm actually going to talk to the Azure resource manager. Now, Azure itself is actually made-up of. I talked about creating resources of VM and network interface card, all of those things. So Azure is actually made-up of resources. That are defined in resource providers. So that tells me all of the different types of resource I can actually create if we jump over and look. So if I clear this out for a second. If I do a get a. Resource provider. There's a lot of different resource providers in the system. And what we can see. For any of these particular ones, you can start to see hey, look. There's resource types listed. But if we dive into one of them. We have particular provider namespace. Microsoft dot compute. And that means to capitalize that and we can format it as a table and just look at resource types. We'll see. There's just a whole list of different resource types existing in here. This is just compute. Now you see obvious things you'd expect. Virtual machines. That's a particular resource. Virtual machine. Scale sets. Locations. Remember all those different regions? Um, But then we'll see other things. We'll see things like disks. Disks are part of compute. Says all these different types of resources that actually exist within Azure. So the Azure resource manager is really what understands and facilitates that. And everything in Azure is a resource, even a VM. So we talk about a VM as that. It's really simple thing. Well, the reality is even a VM that's simple simple little virtual machine we might have when I go and look at a virtual machine. What I can do is, well, hey, here's a VM. I deployed it to his own resource group, so it's in a certain resource group. If we look at this resource group that contains one VM. It actually contains 5 different resources. O what does it have? Well, it has the VM itself. But the VM connects to a network interface. The VM connects to a disk for its operating system. The network interface connects to a public IP address, and the Nic can use a network security group to control the flow of traffic. And there could be other resources as well. So everything is a distinct resource, but that's good. Because I didn't draw it on the picture, but I can also do RBAC at the resource level. I can go and see all the policies that apply at the resource level because they've all inherited down. And all of those things are available to me here. So the Azure resource Manager provides that management for Azure. So when you hear arm, you can think that the key point of all of this is management. Kind of interactions. And everything is going to use that. So if I think about me as a user. And I'm setting up my machine. I have different ways of talking to Azure. The most common one we are typically going to start with is the portal. Well, the portal. Is talking to Azure and I've kind of shown the portal already. Now the portal is very pleasant, it's very intuitive. The portal is great to quickly look around. I can say, OK, let's look at my resources. I can see my virtual machines. I could go and investigate this virtual machine. Maybe I want to see some basic monitoring information about what's happening. It's great to quickly go and look around. It's good to do little investigations. It is not good to create things to provision. Think about just creating a virtual machine. I have pages and pages of things that I would have to configure so understand the pain point of that. Think about that for a second. If I was going to use the portal to provision resources, I'd have to make sure I did it in a consistent manner. So that's this super detailed document and humans do kind of click the wrong things and important might change, so as I'm screenshot all the buttons slightly different. Try and create 100 of them. I'd be crying so it doesn't scale. It's hard to document, it's hard to compare to a desired end state. There's just so many options, so the portal's great to come and look at things. I would never ever want to go and create things from the portal, but it's good to just kind of look around. Now, there's also something called the cloud shell, which lets me get to things like PowerShell and Bash. If you looked at the portal for a second up here in the corner, you'll see this little icon. So that opens up the cloud shell. So the cloud shell lets me run. So I'm about to show you PowerShell on the Azure CLI. It lets me run both of those so I can pick, but it gives me access without me having to install anything locally on my machine, a bash environment for the Azure CLI, and a PowerShell to run the PowerShell. So that's just natively part of the portal. That can be super convenient. There's also. The mobile. App so this is available for kind of iOS and Android, sadly not Windows Phone. Once again, this talks to the Azure resource manager. The mobile app is great for hey, I'm on the go. I want to quickly look at the state of my resources, maybe look and see if there's certain alerts I could start and stop things. I can access the cloud shell from there as well. So another useful thing. But once again, I'm not going to try and really do any big management from my mobile device. I'm not going to try and provision resources from that. So we get to things. PowerShell Azure module. Now PowerShell is open source. PowerShell is multi platform, Windows, Linux, Mac OS. Which means the AZ module is Windows, Linux, Mac OS. And this is phenomenal for automation. I just want to interact from a command line over here. For example, I've been using this already. You've seen me run certain commands. Hey, I want to go and see what VMS I have super quickly. Ohh get a VM and you can see I've got those commands. And obviously I can use that interactively, but that's also really powerful for automation scripts. I want to automate a set of management actions. These are phenomenal for automation. And likewise, if that's sort of PowerShell based, then there's the AZ CLI that's more kind of from a bash kind of history. I can run it on Windows as well, CMD. And that. Has exactly the same capabilities. So I'm going to jump over to just a regular command prompt now instead. And what we can see here is if I clear this quickly, make this a bit bigger for you, I could do an Azure VM list output table and I see the same information. It's a different syntax because I'm now it's more in the bash world, but I can do the same exact type of things, it's just the syntax is different. So these are super, super powerful for a command line interface scripting. I still don't want to create things with these, although it's easier to create things with this. It's still not the right solution. But again, they go through the Azure resource manager. So so far I've shown you the portal, there's a mobile app, there's PowerShell, there's the acli. We're not creating anything, so keep saying don't create things with this. How we want to create things. There's arm JSON templates. Everything in Azure, the metadata that describes it is stored as JSON JavaScript object notation. And So what I can now do is I can apply a template. To that Azure resource manager and this this is the way we want to do provisioning. And there's a reason for this. This is declarative. And what that means is if I was to create something through PowerShell or Az cli, I have to tell it how to do something. New VM, add disk, what's the script failed halfway through when the change config. I can't just run the script again and change the value, have to use completely different commands. I'm telling it how to do it, it's imperative. This is what I want you to do. With declarative I simply say what is my desired end state. I could say, hey, I wanna storage account. Called A1 and I want it to be a locally redundant storage account. Go and make it so and it will go and look. Does this exist already? Is it LRS? If not, I'll create it. But it's idempotent. I can run this as many times as I want, it has already created it. And it matches, it just won't do anything. Whereas if I run a script to create a storage account an existed it would error. But I could also change my mind. I'll say actually, I now want this to be gears. Make it so and it would ee. The storage account is there, but it's LRS. I'll change it to GRS to match that desired state. So this is kind of where does is so powerful. This is why we want to provision a things with JSON templates. It's declarative. I say what I want, I don't say how to do it. So I can easily go and modify those things and we can actually see so behind the scenes. If we wish to just come and look at really any type of resource, we look at my VM again. And it's going to look honestly, kind of. There's a lot to it. It's not super friendly to actually understand, but you do an export template. And it's actually going to show me. The JSON so here I can see. OK yeah it's a type Microsoft dot compute resource provider of type virtual machine. OK, then there's a name which is a parameter. It's in a certain location, and there's a whole bunch of other. Configurations and properties for that. I can see the VM type. There's a whole bunch of stuff here. But it's declarative. I could run this as many times as I want and it would just make it so. So this is the preferred way to provision things. An arm JSON template, it has massive parallelism. It could create 100 resources, it would create them all in parallel. It wouldn't wait for resource one, then resource two, then resource three. So it's super powerful from that perspective. And what's really useful is it's a file, so I can compare it to what's actually there. But if we think about things like DevOps, I could. Absolutely have some kind of GitHub repo or Azure DevOps repos or whatever. It is something probably git based. I can store that in there. Well, then I get things like version control. I get great collaboration features, so the fact that this is declarative file makes it really good to actually then work with other things. I can have parameter files so I can have different values for different environments, but I can now use this file across many many different types of things. And I can define anything in there well based access control policy. All those can be defined as that Azure JSON template. Now, what you may also hear about is a technology called bicep. So bicep is something new. And it actually transpiles, which means it converts into an armed JSON template. But this is just more human friendly. So I think in the future you're going to see more and more bicep as a friendlier way for us as a human. I want to create this declarative template. Instead of having to try and write JSON, which is really kind of ugly, I could write this really nice bicep file. I've got an example here of a bicep file. So this is create a storage account. And what you can basically just see is how I've got a few parameters. I'm saying I want to create a resource of type storage account and it has a name, location, kind and skew and that's it. So that's me as a human typing that out, which is actually really, really nice compared to the pretty hideous world of trying to actually create an ARM template. So you may hear the term bicep, but it's just going to go and create an arm JSON template. Behind the scenes there were third party solutions like Terraform, Terraforms. Great. Maybe I'm using more than just Azure. I think I've got AWS and Google Cloud. I've got maybe VMware and Kubernetes. I want one declarative technology for all of those. Well, Terraform will let me do that. So total about governance things. There are some other types of governance constructs so I think about this for a second. Rbac is great. Rbac controls what I can do. But maybe sometimes I want an extra check. I want to say look you can't change this or you can't delete it or at least you have to go and perform an extra steps. You don't accidentally do something. So what we can actually do is we can create these things called resource. Locks. And I can then apply that at different levels. So again, I could think about, hey look, I could apply at the subscription, it will get inherited down. I might apply at a certain resource group, I might apply at a certain resource. And what I can do with the resource lock is I can do one of two things. Can not delete, so I can change it. But I can't delete it or I can say I don't even want you to change it. I can say read only so you cannot change or delete it so I can go and create the resource lock. And then what it would do is if I accidentally went and tried to change or delete it depending on which lock I set, it wouldn't let me. It would say, hey you can't do this, I would have to then go and remove the lock. So it has to be the owner basically to be able to do that. And then once I've removed the lock, then I could go and modify, delete or just delete depending on which one I set and it does get inherited. So if I set a resource lock at the subscription level. Whatever that effect was would apply it to everything within there as well. So that's something I can go and do. Another really useful thing is we talked about JSON was kind of the metadata. So we have these arm JSON templates that are fundamentally talking JSON. Well, there's optional metadata we can set because I might want to be able to identify who's the owner, what's the business unit, what's the purpose, what's the criticality? So if I want metadata, one of the things we can add is something called tags. And again, this is basically metadata. It is a key. And the value. And just like pretty much everything else, I can set this kind of subscription. I could set it up the resource group, I could set it at the individual resource. Now. Important thing. Most things we've talked about get inherited. Rbac policy budget rolls up resource locks get, inherited tags do. Not inherit. If I create A tag at the resource group, the resources within it will not have that tag. So just keep that in mind. If I wanted the resources to copy the tag from the resource group, I could do that with policy. I could create a policy that says, hey look if you're missing this tag, go and copy the value from the resource log. But by default. You do not inherit tags, and again, they're just metadata. I'll use them for different things. If I go and look at for example my virtual machine here. I configured a couple of tags. And I had for example over here where I did one for the cost center. I did one for environment, I did one for the operating system, one for the owner. You might see other ones for the type of resource, you might see an exact billing ID. It could be security, like public or confidential. It could have different regulatory tags. It's whatever you want. This is not a fixed schema. I can go ahead and add any value I want, show me ones that I've done already, but I can go and create a completely new one. I could go and create any value I wanted. If I wanted to control, what do you think I would do? I could use policy. So I could use policy to restrict what I could actually do here and these tags are really useful. I can search and find things with a certain tag value when I do billing. Billing I could actually say hey show me the bill and I want to filter it by tags that have this certain value. So tagging that metadata is super super useful for that. Another key construct we have is, well, I've talked about a bunch of different things so far. I talked about our back and resource group and policy and templates. What about if I've got kind of a new subscription and I want to be able to apply maybe a base configuration? I want to be able to stamp down a certain configuration. Well, we can do that. We have a construct called a blueprint. And a blueprint basically enables me to contain a number of different types of artifacts so I can define resource groups. Then within that resource group I can alley an ARM template which again remember creates resources, I can apply role based access control, I can apply policy and I could create a resource group to, etc. So these four types of resources I can define in my blueprint and then I basically assign it. To a subscription. Well, then go and create all those things. Now when I do that assignment, I actually have different options for how it's going to actually assign. If we go and look, let's jump over to my subscription. I have a blueprint. And it's super simple one. All I basically do in this blueprint. Is you can see here at the subscription level. I apply a policy that sets A tag. Then I create a resource group called RG Networking. I set role based access control to give the network admins group the contributor right. Then I deploy an ARM template that creates a core virtual network. But again, I could do lots of other things. So I define the list of artifacts I want and then I assign it, and when I do the assignment I get to pick a lock assignment. So do not lock. I don't lock says we'll put this there, but then they can change, delete, whatever they want to do. Do not delete says. Well, they can change it. But they can't delete the things I create, read only as you would guess. You can't change or delete them. And it does maintain the connection between the blueprint and where I've assigned it. So if I went and created a new version of the blueprint with changes, I can then update that assignment. A really important thing is with these assignments, both blueprints and resource locks, they're applying at the Azure resource manager level, which is kind of the control plane. There's two planes in Azure. There's the control plane, where Azure Resource manager does create resources, delete resources, modify resources. Then there's the resource itself. Has a data plane? Create a row in a table, create a file in a storage account. All of these things apply at the Azure resource manager. Control plane, they do not apply to things that the data plane. So even if a storage account for example was locked or had this do not read only, I could still create blobs and delete blobs. It's not impacting the data plane. It only impacts the control plane either resources that the Azure resource manager controls. Because when I do data plane actions, they're not going through the Azure resource manager. So all of these things apply only to that control plane. One other thing when I think about creating this. Can seem intimidating. There's a lot of different things happening here. So when I'm trying to think, OK, well how do I, how do I get started? What is the right thing to do? There's thing called the cloud adoption framework. So cloud option framework? Is really this set of guidance. And it's all structured around the idea. Well, I want to lay out a strategy. I need to make a plan. About what I'm going to do, I'm going to get my organization ready. Then I'm going to adopt the cloud, my great resources, and then kind of govern manage the environments. There's all these detailed steps for every single part of this. So really my recommendation here would be to walk through this again. The handout for this course has all of these links in it. I'm not putting it in this video. Go and get the handout for the course. But that it's good to have a basic understanding of exactly what this is and what it's doing as part of your preparation. So I understand, hey cloud adoption framework, it's all about things to help me get started and really just get the right ideas so I start off as best practice as possible. OK, so. Talked about a lot, but we've not really talked about types of resource yet. And there's a lot of different types of resource. So what I want to do now is just give us some base understanding of the types of resource and when we would really kind of use them. So let's maybe jump over here. We go above this, so the first type of resource we're typically going to use is going to be a virtual machine, a VM. Now, if you think about a virtual machine, think about a regular machine. I have maybe a certain number of cores or virtual CPUs. I have a certain amount of memory, maybe I have certain amounts of storage IOPS and throughput. I have certain network connectivity, but I have certain characteristics. And that's exactly what a virtual machine is. A VM is just a collection of resources that we're making available to this certain unit of work. Now a key point is, when I create a VM on premises, sometimes I want that VM to have lots of memory. Maybe it's a database. Sometimes I want to have lots of CPU, it's just doing some processing. Maybe I want a balanced mix. So it's exactly the same thing in the cloud. In the cloud we have different SKUs and a big focus of these SKUs is about things like, well, virtual CPU to memory ratios. But also there might be special characteristics. So if we go and look at all of the different SKUs that are available, if we go and look at the virtual machine sizes, what we'll see? Is we could start with the idea of we have these compute optimized. And if I was to look at compute optimized, what we'll see is there's a whole number of different sizes. But you'll see all of the different properties scale the same way. So CPUs, memory, temp storage, Max data, cached, all of these values increase proportionally. And what we're focusing on here is this ratio. So for every two CPUs we get 4 gigabytes of memory. So it's a one to two ratio. If I was to look at general purpose, there's a whole bunch of these again, different generations of processor, different temporary stories, different abilities to do other types of things. We'll now my ratio is 2 to 8, so it's one to four. So there's a bit more memory for each virtual CPU. This is general purpose. Then there's memory optimized. And exactly as you'd guess. This time. It's 2 to 16 or 1 to 8. But also there's going to be differences in the amount of IO side gear I have, ones with GPUs. I have ones that have Fpgas, I have ones that have RDMA network adapters, and then within those they have those different sizes. There's whole sets of different types of virtual machines. Based on exactly what I need it to do so I pick the right skew. And then once I pick the SKU, there's I pick a certain size based on the amount of work it actually needs to do. Now I have full flexibility within that. Member responsibility. I'm responsible for everything inside there. I can pick the OS, Windows or Linux. I can pick the antivirus and the firewall. You're not on your own. There are a whole bunch of extensions in Azure to help you with these things, but fundamentally you get to pick what you want to do. Sounds like the most basic building block virtual machine. But also we're gonna have multiple virtual machines. I have many of them for scale purposes, for resiliency purposes. So in the next type of thing we might build on top of that is something called a virtual machine scale set. Now what this enables me to do is pick kind of a certain template for the disk, pick a certain configuration. But also pick certain scale so I can have a minimum number, a maximum number and even auto scale if you think consumption basis. I want to change the number of saying I have based on the workload. This lets me do that with this auto scale capability and this is going to go and create. VMS. So I create this virtual machine, scale, set that, then behind the scenes will create the virtual machines, but it will create them, delete them based on maybe a schedule, maybe on some trigger. The average CPU is above 70%, going to add some more, average CPU is below 30%. Let's delete a couple. So it's going to go and create those virtual machines for me. Now many other things are going to build on top of, like virtual machines and virtual machine scale sets. But realize again, the cloud is someone else's PC. So there were servers. So most of the time there's going to be these big racks of servers and essentially there's a host. And when I create this thing, hey look, my VM gets created on a certain host, but someone else's VM from another tenant get create on that host as well, and someone from another tenant gets created on that host as well. There's full isolation by the hypervisor, by the software defined networking, through the encryption. That's not a concern for most people. However, there may be scenarios where I do not want to be on a host with another customer. Now by definition the public cloud is multi tenant, but I want to just have my stuff on a certain box. So what I can do is there's something called Azure. Dedicated. Host and what that lets me do is I can buy. Out the entire box. So I'm basically paying for the entire capacity and then I can fill it U. With the ends. Now Azure dedicated host, just like there's different skews of virtual machines that have different ratios the hosts of the same, so I buy a host of a particular skew. And then I can fill it with VMS of that SKU type. Now I can have different sizes, so I can have maybe some little ones or some really big ones, but they're all going to be of the same skew of the host if we go and look for a second. We look at Azure dedicated host pricing. What we see is we buy the host of a certain type. And then that's showing us the type of VM that I can actually run. On that host. So I'm basically buying out. I pay for the host. And then I can run as many VMS as I can cram in of the same type of the host. Now there is another option. Now obviously I can create lots of those. So I could create multiple Azure dedicated hosts. I could put them maybe in. Different fault domains of different racks so I can get resiliency from that type of thing, but also. Some VM's are just really big. So sometimes you'll create a VM. That actually just takes up the entire box. So they're all these isolated. VMS. So I'm not creating an Azure dedicated host. I'm not creating a box just for me, but just by virtue of the VM is so big, there are these isolated VMS. So if I create one of those. And these are listed as well, then I'm going to be on my own box because, well, no one else can fit on the box. I'm taking up the whole box so realize that's another way I can kind of get that isolation as well. So either I'm buying out the whole box or I'm just creating a VM that's so big. No one else can fit on it. So I have VM, so I have virtual machine scale sets. Typically we deploy to a multi tenant set of hosts, but I can do dedicated or I just create really big. There's also Azure batch. So Azure batch is all about the idea of these really large scale workloads. I have this job that I want to run. It's a large scale parallel workload. It's the high performance computing and Azure batch will go and spin up the resources. I need the VMS to execute that job, it will queue it up and run it as required. So if I have that large scale execution, Azure batch is great for that. Now, all of these are based around virtual machines, and virtual machines are based around the idea that we're virtualizing the hardware. We create a virtual machine that's apportion carved out of CPU and memory and storage and networking. We have a lot of things are moving to is the idea of containers and if a virtual machine virtualizes the hardware. A container is more about virtualizing the software. So I could think about, well, there's a container host which could be a VM. Now container host is running a certain operating system. So that's kind of at the kernel. Then there's a container runtime. And that basically creates these little sandboxes. So these isolated environments. In the user mode space, so it's the same operating system, but it's creating these isolated sandboxes and then what we have with containers is the idea that we have a registry. Where we have images, so we have a whole bunch of different images. And we essentially take the image and we run it. In the container instance. And that image itself is probably multiple layers. There's like a base OS layer, then a runtime layer, then an app layer, maybe some customization, and that then runs. But the benefit of containers, if I think about a VM, a VM takes time to start. I have to create the VM, stand up the operating system, and it's fairly heavy. The operating system has memory requirements and storage requirements. One if containers are sharing a container host, container host is there already. So when I create a new container, it spins up near instantly and it's very very low overhead because it's sharing that container runtime. Now it is sharing a container runtime, it's sharing a host, which means typically I want to trust my neighbor. And so that's great if me as a customer, I have multiple containers I can run on the same host. But if I'm multi tenant, I don't trust the person over there. And so there were sometimes different services that will essentially create and managed VM automatically and just run your container image with you on your own. But there's a whole bunch of standby so we can spin up really really quickly. But containers have these nice isolated. They have controlled amount of resource they can use. I have isolated namespaces so they can't see each other's processes, isolated networking, they can't see each other networking it's. Not that great isolation. OK, so I want to use containers. I'm in Azure. What can I do well if I just wanna run a couple of containers? There are Azure container instances and this really is this idea. Hey, I have an image, I want to be able to just run it. I can create a container instance to just run that. If I have multiple ones that want to be able to work together, I can actually create a container group. And with a container group. They will essentially inhabit that same container host, but otherwise. If I create an Azure container instance, it runs on its own host. I'm not going to run it with some other customer because I don't want to share a kernel with some other customer. There's things they maybe can do so as you container instances will isolate automatically to give me that protection. So Azure container instance, I can have a public facing endpoint. Or I can integrate with a virtual network as well, so I have that choice. Virtual Network is a private network for my resources. I have different sizes that I can create, but it's a fairly basic thing. What about if I want a richer set of capabilities? I want to be able to auto scale this out. I want rich networking integration. I want full orchestration. I want balancing, I want policy. Well, the standard in kind of that richer container environment. It's called Kubernetes. And I could stand up Kubernetes myself. I could absolutely create a bunch of VMS and stand up Kubernetes. But why do that? So what we have in Azure is we have the Azure Kubernetes service. Now I'm going to draw it as a cloud because there's two parts to Kubernetes. The first thing is there's basically a management plan, so there's this management plane. The control plane 4 combinators with AKS. This is fully managed for me behind the scenes. There's a whole kind of set, there's a scheduler, there's an API server, there's an ECD database kind of hidden in here. There's a bunch of other things. They're all managed for me. I do not see those things. That's provided as a service. What I see in my environment are the nodes. So I create node pause, which are of a certain type behind the scenes. What do you think this is using? Yep, it's using virtual machine scale sets. So these things will kind of build on each other. And this is where my containers run. So we've AKS. The management plane is just there for me, it's maintained for me. I then push deployment YAML files. It's declarative or there's git OPS where it can pull it from a repo and then it will go and schedule my containers. Now my containers run in things called. What? In the Kubernetes world, but I have great networking capabilities. I can integrate with virtual networks. I can have persistent storage through Azure files or disks, or many many other types of things. I can have different node pools of different types. Maybe some of them are GPUs, some of them are just regular VMS, some of them might be memory centric. But I have all of these flexibility and choice in how I'm going to create these various node pools for the types of resources. That actually want. So if you hear hey, I want to use containers in Azure, I want to run Kubernetes or I want some rich orchestration, what service should I use? It's probably going to be AKS. Now as we carry on thinking about PaaS, then there's Azure app ServiceNow. App service is actually can run containers as well. But typically we think of app services when it's some kind of web focused workload. Now in terms of Web focus workload, that could be a web app. That could be an API service. Maybe it's going to integrate things like Swagger. It's going to host that for me. Maybe it's a mobile kind of application I'm trying to write, in which case it gives me these nice kind of push notification capabilities. But I have these different types of service and again I just focus on the code. I create an instance of a web app. I tell it the runtime. I can be Windows or Linux, and here's my code. I don't worry about anything else. Depending on the SKU, it might have things like autoscale there for me as well. I just don't have to worry about that stuff. So we like these app services. If I was, hey, you want to create a new web application, I want to minimize any maintenance overhead I'm using. Maybe it's net or it could be Java. There's a whole set of different things. App service is probably a great solution for that. Now so far all of these, although these are pas. Underneath there were VMS and what I pay for is really a number of SKU sizes of VM. I don't. Maybe I don't manage them, but they're that's what I'm paying for. What we then move into are the serverless offerings. And the whole point of serverless is I don't pay for. Some unit of virtual machine. I pay for the work it actually does, so that's kind of a real key point of this. Another key point of server is is they are event driven because they're not typically just running all the time. Something has to happen that could be. A BLOB is written to a storage account, a message is written to a queue, someone calls a Restful API, there's a schedule, a timer, but something has to trigger this to actually happen. And then there's different. Well, what am I doing? There's different serverless offerings, but the whole point is I pay for work done. And there's two offerings, so the first is Azure functions. Azure functions is really all about running some code I've written. It supports many different languages. But I'm writing the code. And then it's going to run it. For me it's designed to be short lived. It doesn't have kind of state between executions. There is a way to do that with durable functions, but typically they're not. They're there to do some little piece of work and it goes away. So it spins up, it comes alive to do something, then it disappears and I pay for the work it does. Now I can actually run Azure functions as part of an app Service plan or I can run it in this consumption only mode. But Azure function is. I have some code I want to run it in a serverless. Hi hi Azure function is great for that and the other one is Azure. Logic apps. And I can really think about this as no or low code. This is all about this graphical kind of canvas idea that I can drag these connectors. There's these prebuilt collection of connectors that are wrappers to some API out there. It's about 200 of them and I can just drag it onto this designer. So if we go and look really quickly, if I was to look at functions for a second, if I look at a function app. I can create a function A but the key point of a function app. Is fundamentally. It's code. Now mine here I think is PowerShell based on this particular one. But it's just some code, so I still have to code. I have to understand those constructs to be able to use that. But I wrote the code to do this piece of work, but it's going to run it based on some trigger, whereas if I look at a logic app. We have a logic app. Let's just look at this one. If I look at the designer. I'm not coding, or maybe occasionally I write a little single line of something to do something pretty easy, but for the most part I am not coding. What I'm instead doing is I get this great visual designer if it decides to actually open up and I can just drag and drop different components from these connectors to perform certain actions. Try and refresh this. Come on, wake up. But you're just see basically a bunch of boxes I can drag and drop from connectors. So I'm not writing code and there's a whole bunch of templates built in that I can leverage to actually do this. OK, maybe we'll come back to this later on. But the whole point is a visual designer. I'm not writing code. There's a whole bunch of connectors out there, and I'll just see boxes, hey, do this thing, maybe hey, tweet is received, we'll go and call cognitive services to go and get sentiment. OK, now go and write something to a queue. It's just dragging these different things from connectors that will, hey, make all that work so I don't have to understand coding. It's that idea of a citizen developer. Anyone can really go and do this. So that's kind of the serverless offerings now there's a huge number of different types of service available. Another really popular one right now, if you think about kind of these VMS and all these other things is actually Azure. Virtual. Desktop. And I can really think about this as the idea of publishing a session. I get a complete desktop environment. And or an application. I just want to see the pixels from a particular window and it's obviously very popular with all the pandemic people working from home. Or what Azure Virtual Desktop does is just like kind of AKS. Where's that control and data plane? Well, there's a whole set of components I need for a virtual desktop solution. I need a broker to say where to go to. I need to encapsulate RDP and HTTPS. There's feeds, there's a whole bunch of management. So all of that management side. Which is part of Azure Virtual desktop. What I then get is a bunch of VMS that are actually my hosts. And they can run different images. I can one server, I can run client, I can run a multi session client which is unique to Azure Virtual desktop. But it's going to provide me an environment where I can host that complete virtual desktop solution. So that's really kind of a key service. So hey, I want to be able to stand up a virtual desktop environment in Azure, what should I use? It's probably gonna be Azure virtual desktop. One other key service I want to talk about before we move on to a new type of service. For really anything in Azure, but especially if I'm creating my own services, often we have the idea that I have some sensitive information. Now, maybe that sensitive information is a secret, maybe it's a password or a signature thing and he's able to write and get back. Sometimes I have keys. I want to perform some cryptographic operation against this thing, sometimes I have certificates. And I need to be able to manage the life cycle of those. I need to actually be able to also. Distribute them. How do I store these in a secure manner and then how do I get access to them? So in Azure. We have Azure. Key vault. So Azure Key Vault enables me to host all of these different types of entity. And there's full granularity. So I can either do this using access policies or the new way. Which is better is role based access control policies only, let me say it a vault level. These people could do this to type secrets, but I couldn't do individual secrets or keys or certificates. Rbac, an individual secret level lets me control who can do what and how it can use it. But the whole point is, this provides if necessary, a hardware security module backed service for the storage and use of these. So a secret hey, I can write it, I can read it back out a key, I can generate it or import it and then perform cryptographic operations, but I cannot export it. Certificates. It will help manage the lifecycle and distribute those to other services. But then I can set RBAC to other services, can leverage this. And what super common is you combine this with thing called managed identity. Now that's outside the scope of this, but think about all of these different types of resources, especially VMS or app services or apks. They can have an identity, that's that resource. Nothing else can use it. Why could give that identity permissions to certain sequence and keys so I never have to store sync in my code. Because I'm running as that app service, I'm allowed to read that secret, which then gives me access maybe to something else. So Kivo is really that key service. When I have any kind of consideration for, hey, I need to store a secret or a key or certificate, hey, that can then integrate with everything else. So that's really an important one to understand. I've talked about networking a couple of times. So all these different services, maybe they're just public facing, but often they need to integrate and work with other things. So we have this idea of a virtual network now. We talked about regions. We talked about subscriptions. The virtual network if I think about a certain subscription. Within a subscription I can use lots of different regions. Well. A virtual network exists within a certain subscription. And a certain region I it cannot span regions. It cannot span subscriptions. So I can go ahead and create. A virtual network. Now a virtual network is defined by a group of minimum IPV 4 address ranges, so I'm going to have at least one, or I can have multiple IPV 4. Address ranges. It's very common that you use RFC 1918, so that's just a set of IP addresses that will never route. Over the Internet. You might see kind of 10/8, you might see 172.16/12 and 192.168/16. So those are reserved so I can use. Everyone could use that internally because they can't route over the Internet, they can't mess with other. Companies. Now when I pick the IP range for my virtual network though, I need to make sure I pick an IP range. It doesn't conflict with another virtual network I have or another network I have. For example, if I have on premises. Why might want to connect these? So we need to make sure I pick an IP range. That does not conflict with any other vnet or any other network. Being another cloud or on premises, I may want to ever connect them, so I want to make sure I have this unique IP range. I can optionally add. IPV 6. Ranges as well. That's completely optional. It's always dual stack. If I have IPV 6, it's never just IPV 6, it will be IPV 4 and IPV 6. Now we've in the virtual network. I create virtual subnets. Recommend that one. 2-3 etc. And they will have an IP range assigned to them. And optionally IPV 6. It's going to be a subset of this range, so maybe this is 10.0 dot 0.1 slash zero, 10.0 dot, 2.10 dot, 0.3 dot whatever. So it's a subset of the IP range of the virtual network. So I divide it up. Remember that regions could consist of multiple availability zones. These span availability zones, so if there was, I think about AZ1 AZ2 and AZ3. They all span, so a subnet is not bound to a particular AZ. It spans all the AZ in the region, so there's no worry about that. For any subnet I create, I always lose 5 IP addresses because Jim just the protocol. I always lose kind of the 1st and the last address, all zeros or ones of the host range. But then we lose one for the gateway and then we lose 2 for DNS. So whatever address space size I create, remember we always lose 5. And then I create resources inside here and they will get an I address allocated from the I range of the subnet. If I have multiple virtual networks, so let's have another vnet over here. Could be the same region or a different region. I can peer them so peering will route them over the Azure backbone. But now if we can just talk to each other they cannot overlap. So again make sure the IP ranges are always unique. I can also connect. I drew the idea of an on premises network so I could connect to my on premises network. What we would do is we would actually create. A gateway device. So I could create a VPN gateway device. That would let me then over the Internet create a tunnel. Obviously I would have gateway devices here as well. And then I established that tunnel. So this would be a site to site VPN. It's encrypted. There were two types. There's policy. Policy enables me to have basically one. Connection and we typically don't like it. It's a static route. It's really only if I had a legacy VPN gateway. What we like is route based. So route based is I can have N number. Of connections and it supports point to site VPN, so I can have a particular machine hanging off the just connect a machine to it. And that is actually using separate multiple tunnels and then it has different encryption based on the particular tunnel I have. But this connection is going over the Internet but it is encrypted. The other option is if you think about Microsoft has this huge backbone network. Well, I can actually have a private connection, so I could essentially have a connection which was in goal. That goes. Kind of like this is a different type of gateway, so it's an express route gateway. There's different sizes and skews, but this is now express route. It is not going over the Internet. This is a private. Connection. Now that private connection could be because I'm hosted at a Colo facility, a colocation and they have connectivity and I use theirs. It could be I have an MPLS and any to any IPVPN and now Azure becomes point off of that. So that would be a layer 3. It could be I actually have a new network cable dropped to a certain mean location appearing point, so a layer two connection so there are different types, but express route basically gives me a private connection, so not over the Internet. Between my on premises and that virtual network going through that gateway. And when I have expressed route is actually different types of traffic. Well, I drew here when it was actually going to a network is something called private peering. I'm connecting it to a virtual network. There's also Microsoft peering where I can offer services that don't live in a virtual network. So this is great. We have this virtual network. What about if I want to control the flow of traffic? So if I want to restrict maybe between subnets, maybe between venets, maybe between on premises. To control the flow of traffic I can create saying called a network security group and NSG. So an NSG is built around a series of properties. So I can think about the source and the destination. IP or side arrange? I can think about the sauce and the destination port. I can think about the protocol. I TCP, UDP and then we have things like hey, the name. Description. A priority because I have multiple rules because this is all basically made-up of rules. And then, well, do I allow? Or do I deny? So I create a series of rules based on basically the IP addresses. And then I link them. To subnets, I can link it directly to a VM. It's very hard to manage that way. So typically we create these sets of rules that control the flow of traffic and then link it to a subnet. Now I wrote IP address ranges here. Sometimes when I'm talking about Azure services, that's just a huge range of different IP ranges they may use. So the other thing you can do here is thing called service tags. So a service tag represents a set of IPS used by a particular Azure service, like Azure Storage in South Central US. Another thing I can do is that called an ASG and application Security group. This is really just A tag that I can put on a network adapter. So instead of having to worry about what IP address something is I can say hey look if this Nic is tagged with SQL then treat it as the SQL rules and apply it. But think about NSG's are the way to control the flow of traffic. Now, all of these things I talked about, these are basically layer 4. I it understands TCP and UDP, what about if I want to be add 2 control based on? Fully qualified domain name or a path? The URL I want to understand, SSL I want to do. Floating affinity. So then we get into other types of service. Now one of these is thing called Azure Firewall. So this is an Azure first party network virtual appliance and a big deal about this is it understands yes it has the idea of that. Layer four I can do network rules. But I can also. Do application rules. Which is kind of that layer 7. So that lets me do rules based on the path. Based on the fully qualified domain name, I can have categories based on the IT can understand what it's talking to with the premium offerings, it can even do SSL understanding, getting in the middle of the SSL conversation, decrypt the traffic to know what's happening over the SSL paths. As well, it can do things like dnet so I can have a single IP coming in and then send it to particular VMS or services on the other side. So I can do dnat as well. So Azure firewall would be kind of the answer. Hey I need to do controls based around fully qualified domain names or categories of web traffic or I want to be able to host an IP and send to different VMS based on the port. Hey, Azure file was going to be your answer there. Now to use Azure Firewall we basically have to tell the traffic to go to the Azure firewall as part of its journey. So what typically we would do is hey if I wanted to use Azure firewall we have thing called user defined routes and user defined route just lets me say a next hop. So on your way to this destination hey your next hop. Is for example that virtual appliance. It lets me change how traffic gets routed around. Now there are many types of service that. Actually, don't live inside of virtual networks. Let's come over to this virtual network for a second. So this virtual network, well, we has just like the others a subnet. But imagine now I'm using a storage account over here. Say storage account one, and I want to be able to say that storage account actually has its own kind of firewall and I want to say only things in this subnet, subnet 1. Are allowed to use that storage account, but I can't do that by default it only understands public IP addresses and this is a private IP range. So what we can do is we can enable a subnet. We think all the service endpoint. And it's specific to a certain service, so I would add a service endpoint essay for storage. That does two things. It now gives me a better route. In terms of getting to the service. But it also now on the firewall of that service I can now say hey let's say this vnet one. As part of its rules I can now say Vnet 1, subnet 1. Yeah, you'll have to come in. So the service endpoint now makes this subnet known to that type of service so I can enable it on its firewall. So now that route would actually. Still going through there. And it has an optimal route, but it's going to get checked and will be allowed through. But it's only for things in that subnet. Connected networks, other subnets it would not work. Service endpoint is only for things that exist in that subnet, IPV or an AKA or whatever that might be. What about though, if, well, let's have another storage account. I want to also be able to use it from other networks. So another thing we can do is we can add some called a private. Endpoint and what that does is it's actually an IP address in this subnet. That points to a specific version of a service. And the benefit here is it's just an IP address and there's some associated DNS as well, but it's an IP address and it's now what's actually going to happen is anything. Hey I'm peered. Hey I'm on premises and I'm using transit routing, whatever that might be. It's just an IP and now I could restrict, I could say hey don't allow the public IP at all. I'm only going to allow connectivity coming in through that private endpoints. These are really useful things to help control the traffic. One final thing, when I think about networks, so these will private IP addresses but we can add public IPS maybe to a load balance or something else. As soon as we add any kind of public weigh in. Some public endpoint to something. There are mean people. There are mean people out there who want to do things like a distributed denial of service attack who will kind of try and target that by default for any public IP. Azure has a standard, sorry, a basic distributed denial of service offering that are a huge scale. It will redirect that traffic, but it's at a huge scale now. Maybe my service I want to be more sensitive and a much lower value I want to start working so Azure has both. That basic. But also a standard offering of a DDoS protection service. And what I can get with standard is I create a standard plan. And I can link that plan to multiple virtual networks that will then get that protection for any public IP that's linked to something in that virtual network. And the big differences are if we go and look at the site. Well here I can see. OK, so protection standard overview, I see what I get with the free offering. It's really just the first two. So yes, it's active traffic monitoring and always on detection and automatic attack mitigations, but only like a massive massive scale. But then for the DDoS protection standard, we'll get this availability guarantee cost protection policies tuned to the customer apps that we use machine learning to actually understand normal patterns, which will let it respond even quicker. When there's something outside, I can get reporting of exactly what happened, I can see detailed metrics so when I think really, really large scale. Then that DDoS standard is probably something I would want to look at. So if I see a question, hey I want DDoS protection that's tuned to my application. Hey DDoS standard is probably going to be that right thing. So that's all of the different networking things that we're going to focus on. Now let's think about some of the data side of the house. Because often we want some kind of persistent storage. So great, we've got these various compute services that we're going to build on top of. We have those networking concepts, but hey, I need to store stuff, so how do we think about that? So let's come over here. So the most basic building block we have when we think about storage is a storage. Account. And nearly every other type of storage we see in some way builds on top of that. Now, a storage account has a number of different attributes. It has a name, it lives within a specific region. And one of the big configurations we do is we have a certain redundancy. Remember we talked about so it lives in a certain region. So if it lives in a certain region. Remember, many regions exposed the idea of availability zones to us. So we have that idea within the region of kind of that AZ1, 2 and 3. And then we also talked about paired regions. So there's also the paired region hundreds of miles away, but in the same geopolitical boundary and it has data centers and we really only care about one of them in this case. So when I create a storage account, I pick the type of resiliency I want. So the first option is we have LRS. Now there's always 3 copies of the data, but those 3 copies are within the same. Cluster, so those 3 copies basically live in the same data center. Then we have zone redundant, so that's locally redundant, so there's always three. Then we have a zone redundant where there's three again, but now those 3. Was spread over the three Azure's within the region. Then we have the concept of GRS. So GRS there's three. And then? We have another three in the paired region, so I could have kind of three. And there's A and then three over here as well. Then there's a combination GZRS. So that's three and then three. But this time of GZRS is a combination of ZRS and GRS. So the three are distributed over 3 AZs in the primary, but then you have the three in the same data center over there and whenever it replicates over. That is always asynchronous. So it's because of the latency it would slow down performance. There's always an asynchronous replication. You may also see for some of them there is an RA kind of variant and what the RA like GRS or RA-GZRS does is for certain services you can read from that pair. Not all services support that, but that is available for some of them. Also, the different resiliency options vary depending on the type. The performance of my storage account because we have standard performance, so with standard. All of these options are available. Again, ZRS may not be available if the region doesn't support availability zones, but if I do the premium, the premium options. They never have the Geo redundant and it may not even have the ZRS option. It varies depending on the type. If we want to look to the storage account really really quickly over here, we can actually see that in action. So if I go home, if I look at my storage accounts and I go to create a new storage account. You'll see we have the same things about create inner. We set to resource group. We give it a name, but under performance, hey, it's currently standard, so we've standard. I have all of the options LRS, ZRS and GRS and notice you have that option to make read access to data. Available. So that's that RA option. But if I change this to premium. Notice I only have LRS. That's for page blobs but block blobs. I have LRS and ZRS and files. I have LRS and ZRS as well, but with premium performance I never have a Geo replicated option. So if I'm talking about that premium and standard, So what is that all about? We know it's with premium. I had to pick a certain type of service. So in addition to this idea of region and redundancy, we have different services. Or types that are available so we have BLOB. A binary large object and we have block BLOB that is made-up of blocks. We have page BLOB which is made-up of pages and it's very good for read and write over random areas IE and like an operating system disk. And then there is append very good for logging. I just need to add to the end of that. So with a block BLOB, they kind of are stored in containers. That's the structure, but it's flat. There's no true folders. There's an idea that you have virtual directories by putting a folder as part of the name of the file, but it's not a true directory structure. There is actually on top of block you can add Azure Data Lake Storage Gen 2. That actually adds capabilities like POSIX style ACLs and a hierarchical file system. So I actually gets true like folders. I actually get real folders. As part of that, and there's other features, but that's like a true data lake. Let me think about page blobs. Well, remember in that compute when I list out the compute provider. What? We have disks. So let's try a different color. So disks. Actually, behind the scenes are using a page BLOB sitting on a storage account, but it abstracts it away completely. And disks thought we typically use with virtual machines and virtual machine scale sets and nodes and other types of durable storage. There are different types. You'll see things like standard hard disk drive, which are the cheapest and the slowest performance. Highest latencies you'll see standard SSD. You'll see premium SSD and then you'll see Ultra. Disk. Ultra Disk is unique in that things like the IOPS and the throughput characteristics are independently controllable and can be actually changed while it's being used, whereas with premium and the standards the performance scales linearly with the amount of capacity you add. So that's kind of a big difference between those. To be able to use the premium and the ultra, it must be kind of the S variant of the virtual machine. You'll see often they're saying like AD S and ES and S that S means I can use the premium SSD and the ultra disks, so I have to have that variant to actually be able to use those. The other benefit disk side is higher things like images. I have snapshot capabilities. It makes it a true resource of the Azure rather than just being this page BLOB. Then there's things like files. So files gives me the option to actually have SMB or NFS shares. So I basically create a share of one of those types. Within that share I can then put in my various files using SMB or NFS protocols. There is a solution that what this is basically doing is in Azure I'm creating that file share in my storage account. What you can actually have is if I had file servers on premises running Windows Server. So I had traditional file servers. This thing called Azure file sync. And what Azure file sync does? Is it will actually, as the name suggests, synchronize on premises file servers to that cloud share, the Azure file share. They all sync via the file share, never to each other directly. It can also tier data, so if there's data that is not used very frequently. It will actually remove it from the local copy and it's only stored here, but if someone tried to access it, it would pull it down on demand. So I have files as well capabilities. There's also the ability to have queues. So small messages in our first in first out format. It's normally used to drive maybe some kind of event driven process and then there's also tables. So tables is really about kind of key value schemaless storage and so all of those available as part of a regular standard storage account. But remember if I select premium, well we've premium, then I pick one of them. Remember there was premium block BLOB, premium page BLOB or premium files. Then it's only that type of service is supported. Another key point when I think about block BLOB and actually files has these capabilities as well is sometimes you'll hear about access tiers. Because we have different ways we want to use a service, we have data we're constantly interacting with, data we maybe interact with less commonly, but we need it available instantly. Data we need to keep, but we could wait for getting access to it. So we can always think about, well, there's like kind of that premium offering. We'll do premium in our super gold color often maybe for like BLOB, BLOB, BLOB and folds, I can create premium, but then outside of premium if I just go to kind of my standard type account. Then we have the option of a hot tier. A cool tier. And then we have, I guess we'll do archive tier. And the point is I pay more money for the capacity, the storage with the hot tier, but less for the transactions. And as we go down, we payless for the storage but more for the transactions. An archive is actually offline. I have to actually move it out of archive into hot or cool to be able to interact with the data. I can manually move these between them. Again, premium is a different type of storage account, I can't just move between. That would be an entire copy operation. But one of the things we have is lifecycle management. And what life cycle management will do is based on rules I set. Hey, last time it was accessed, last time it was modified. Hey, move it from hot to cool. Stop being used very much. Move it to call. Hey, it's not being used all. Move it to archive. Hey, it's been seven years. Delete it. So this can help kind of automate those various things. Or even go and put it in the trash can. Dumpster fire, one of those things. So these access tiers available for that. That's block. Files does have a similar concept, but it doesn't have archive. It has transaction optimized hot and cool. There's no offline archive option, but it is a similar kind of concept. Again, I can pay more for the storage because I'm interacting with it locked so I pay less for the transactions. Or hey, I need to keep it online but I don't expect to interact with it much. So I'll pay more for the transactions but less for the actual storage. So that's like really basic, just hey, something to store stuff in. But option often we need kind of a richer capability than that. I don't just want to store some BLOB or something else. So what we typically want our databases. And there are many different database technologies in Azure. Often we talk about a relational database and I want the idea that hey, we have data that is in some way structured in a schema way. I have a defined set of columns I can have with different types of data values. There are keys that specify the uniqueness and how maybe different tables relate to one another. I normalize the data so maybe I have addresses in one table, orders in another table and customers and another table inventory another table avoids. Duplication and is just focused on certain types of data. Now when I think about in Azure, there are many types of database services. Yes, I could run it in a VM. Remember the responsibility. I don't want to be responsible for the OS. Maybe I don't even want to be responsible for the database. So there were solutions that are based on SQL. So SQL is Microsoft solution. So one of the things we have here is we have Azure. SQL database. So this is kind of the most PaaS type solution. Now there's actually, they've all passed solutions really, but this is fully managed offering. There were different SKUs available. There's things like hyperscale which is this massive scale set of capabilities. We've separated page servers that scale out for the storage. There's a serverless offering, there's regular skews, there's standard, there's business critical, but this is a true pas. I'm deploying this service in the cloud. I'm user database. But maybe I'm actually moving and the SQL database from on Prem to the cloud and I need some existing type features that don't work with this Azure SQL database. I'm using the maybe common language runtime. I have cross database queries, I need to use the SQL Server agent, so then what we have is Azure. Sequel, managed instance, MI. So this is all about compatibility. There's a whole bunch of different features that we can quickly kind of look at. And what we'll see is if we compare this against Azure SQL database on the left and Azure SQL managed instance. You'll see a whole lot more yeses on this right hand column. Things like that. Common language runtime? Yes, I can do that with Azure SQL managed instance. Cross database queries, cross database transactions. Database mail, yes. Different types of statements? Yes. Distributed partition views, yes. Just it's. I've got a better compatibility. It actually deploys into. My virtual network in Azure as well. And so if I'm looking for, hey, I'm moving a database from on premises to Azure, I'm using certain features that hey, I don't think are going to be a fit. Azure SQL MI deploys into my vnet and it has great compatibility and there's things like the migration data service. That will help me both ascertain how I'm using things on Prem, what features I'm using to actually then get it into these types of service. Now there's also ones that are built on top of open source. Software so things like Postgres. MySQL. There is Azure database for these, so it's completely managed offerings of these, but it's built on that open source software. So if I'm currently using these solutions on Prem, Hey, I can go to a fully managed version. Actually running in Azure has native backup, native, high availability, different scaling options for monitoring and. Hey I I can just go and leverage these. There's also a Postgres hyperscale offering, so this uses the situs extension. To give me that sharding of the data over multiple servers and get that huge scale, huge performance and then I can think about well OK, I just have this idea of kind of born in the cloud which is Cosmos DB. So Cosmos DB is all about multiple models. And when I talk about multiple models, I'm talking about things like hey, I can have documents, so I could store JSON documents. I'm using SQL or MongoDB APIs. I could have column based data. So Cassandra I have key value, I have graph, I can use a gremlin API. There's multiple models of data that we can have with this and I can pick. The consistency. Often with databases there's a single primary, a read write and anything in another region will be a read replica. With Cosmos DB I get to pick that consistency and although you don't need to really understand the full detail about this. If we just go and look, one of the nice things I can do here is if I go and look at Cosmos DB. You get to pick the consistency. So I could have an instance of a database in every single region. And I get to pick how is it going to handle keeping those different copies In Sync. I could have strong, but they would all have the same data, so that means you have to wait for it to go everywhere before it's acknowledged. But there's hey, I just need to be consistent within a particular session, but I'm guaranteed ordering and consistency between them. Eventual hey, it may get data out of order, but that doesn't matter, it'll get it eventually, and there's kind of ones in between. But that's a very flexible solution depending on what I actually want to do. Now I talked about VMS and actually while I'm in the screen. The same with the Azure marketplace. And as the name suggests, it's a place where I can easily see resources, but not just those from Microsoft third parties. For example, look at networking. There's a whole bunch of networking solutions I could go and see more in the marketplace. And see all the different types of solutions. Now these could be VMS that have certain software pre configured on them and I can just use it. Sometimes they include the licensing as a pay as you go. Sometimes you bring your own license with it. So it totally varies. Maybe it uses another type of Azure resource. But there's all these different types of things available. So if I want to stand sync up in Azure, often we can just head over to that marketplace and there will be something there. And that I can actually leverage. So that kind of sits and makes all these different things available. OK, so let's move on to other types of service. So we drew this idea of these these like core compute things. So this is all about me writing my app and then I can run my app on these things. But sometimes there's kind of. Higher solutions in that there's services that actually do something for me. Internet of Things is kind of this huge popular thing right now. The idea that you have all these little devices and all these little miniature devices have these micro kind of controller units in them and they connect to the network. Now if you have things connecting to the network, there's pros and cons with that. I can now send data, I can send metrics, I can send events to something. I could also now receive updates of firmware update or software update. But also if I'm connected, bad people can try and do things to it. So with this Internet of Things and all these Internet enabled devices, so there's IoT where everything can have a sensor. It thinks about hey, it sends data out. But it also needs to maybe receive instructions. Maybe updates actions it needs to do and so if I think about just that basic interaction with that device, well, there's services to do that. So the first service we think about is Azure. IoT hub. So Azure IoT hub is all about that ability to have devices basically register and be known as devices to this service. It enables me via SDK's that it provides. To then write my app. To talk and receive, file those SDK so it's doing the work to understand the direct communications it has like a digital version of all of those devices. So it has a device twin that represents the device that I can talk to to get information from and send instructions to. It will then pass on the device when it's next online. So this is all about the capability to manage all of those devices and have them registered with something. But I'm going to write the app to actually go and do the work. So yes, I could push firmware updates, I can get telemetry, I can get sensor readings and all of those things, but I just need something to provide the connectivity. I am going to write the work that actually does the solution. Maybe I want sang a bit more so then the next option we actually have over here. Is Azure. IoT central. Now this is essentially sitting on top of Azure IoT hub, but this is adding nice things like dashboards. It has a whole set of industry based sets of solutions and scenarios like retail and government and energy and healthcare. That provides me that complete set of information and simulated devices so I can start getting up and running super, super quickly. I can customize the user interface. I can have rules via a nice graphical wizard based on some kind of telemetry or information I get to do something. I can call a logic app. That's serverless thing we talked about. I could send an e-mail. For example, maybe I'm talking to devices. If a temperature reading goes above XI, maybe it's going to start thawing out. Call this logic app or send an e-mail to someone and I can do it all through these nice graphical interfaces. So IoT hub is about, hey, I want to write something to do the logic and the work, but I need something to deal with the talking to the devices. Azure IoT central is about hey I want saying out-of-the-box that I can then just customize the dashboards and the management. The next solution is Azure Sphere. And Azure sphere. Is really focused around the idea of securing the devices. There's three key components to it this microcontroller unit. Well, there's really this Azure sphere license set of technology. And that's going to run the operating system, it's going to run the sensors. There are various starter kits available. There are Azure Sphere certified microcontroller units and then this runs an operating system. So Azure sphere then gives me the OS. It's a customized Linux kernel. But once again it's saying now that Microsoft responsible for maintaining and updating. And then on top of this, Azure sphere kind of has this A3 service. So this is the Azure sphere Security Service. AS three, so as three I should have said as three Security Service. So that's making sure it's not been compromised by some malicious software. It's using certificate based authentication to also authenticate to Azure because really think about compromise. Compromise could be someone sending bad things to the device, but it could also be someone pretending they're the device sending bad things into my data which could make me do bad decisions. So it enables these secure communication by proving I am who I say I am to make sure there's not bad things coming in the other way either. So this is all about kind of that security. Moving on. So I talked about data. And I had kind of databases, but when I think about data services is actually a lot more than just storing the data. So if I think data service. Think about the flow. There's some kind of source. This could be from the cloud, there could be on premises, all these different types of system, it could be files, it could be database rows, it could be streams of data. And I want to basically get it to some sync. We talk about source to sync, maybe that's a data warehouse and other database, other types of things. So this whole format we talk about where we have to extract the data. We have to transform the data. And we have to load the data. So something has to be able to get the data out of that source system. Now what we will sometimes see is when I talked about Data Lake. Data like are these huge huge stores. So this is the Azure Data Lake storage Gen 2 that sits on top of BLOB. Sometimes we will actually extract. And actually do a load. And then kind of carry on. The reason for this is historical, but it used to be we would transform it quickly because there wasn't much disk space. We had to only keep the data we needed to do our job. Today there's lots of storage. Maybe in the future I have different requirements, so by storing the data in its raw format. Well then later on I could come back to that and transform it in different ways. To do the job I want. Now when we think about all of these different stages, something has to orchestrate that. So all of that orchestration, enabling all these things to talk, calling the different connectors that is Azure data factory. So that is basically the orchestration functionality. For the transformation, there are many different services. Now. The wine you'll commonly hear about is Hdinsight. Which actually hooks into a whole bunch of multiple open source different services. There's things like Hadoop for disk based processing, there's things like storm, for real time processing there's spark. So Spark is a big one, mostly batch jobs, but it's kind of an in memory set of capabilities as cafca for big data streaming, there's hive, llap, there's Hbase, all these different options. This is all about this transforming, getting the data, maybe removing duplicates. It's wrangling the data, it's getting it in some format that I can now do something useful with it. There's also data bricks. So if Hdinsight is all about large numbers of different open source types of framework, this is all built on to Azure. Databricks is using data bricks which is really built on Apache Spark. So it's a fully managed offering that I can use for the transformation of my data. So you may hear a databricks fantastic for that. There's a whole analytics service around there. It uses VMS and blobs behind the scenes. And. It's actually used by other types of service we have as well. Now you may also hear so if that was Azure, Azure there since that was Azure Data factory that full source to sync orchestration, you may also hear about Azure Synapse. Kind of analytics. And that really comprises of this and more so, it has its orchestration as a whole synapse workspace. It used to be Azure SQL data warehouse, so it has a data warehouse in capability, but it also has its own Apache Spark transformation service. The whole point of Azure Synapse Analytics is it brings everything together into one workspace and not worrying about connectors between things and not worrying about roles and permissions between things. It's really just doing everything for me. But it's using some of these other components behind the scenes, but it brings it into one workspace, so it really simplifies that whole thing. So that was data services. Then we get into things like AI services. So we talk about AI, artificial intelligence, we talk about AI and ML. So machine learning, artificial intelligence is more about the deep learning based on the normal network of the mind. Machine learning is about training a model on some existing data. So it can then apply that model to new data to maybe forecast future outcomes or to understand something it's hearing or seeing or many other types of things. And so they're very. The services built around AI. So I can think about. Azure. Machine. Learning. This service is about me as a company. This is a platform. A platform for predictions. And what that means is I I'm doing the work, so I'm going to do the definition of how to kind of get the data. I'm going to kind of create the models. I'm going to do the testing of the models and then I'm going to kind of deploy the algorithm that I've created via an API and this labels me to do that. So Azure machine learning is where I want to basically do the work. I have data scientists that want to work out where the data is coming from create the various models. I want to train the model, evaluate the model, create a pipeline for the experiments, and then make that final model that algorithm usable. Why are some API endpoint so this is I'm creating something? What about if I don't do that? The next thing we have is Azure. Cognitive services. So what we're getting now are prebuilt. Prebuilt models based around a wide range of different types. There are things around language. So it can do things like, hey, I can have natural language coming in and it can actually understand it. It can evaluate sentiment. It's positive. Is it negative? It can understand what users want. I can understand things like speech. So I can convert speech to text. I can translate from one language to another language. I can do various types of verification and validation. There were vision services. There's many different types of this, but I can, hey, I know what you're showing me. So that's a car, that's a bus. That's a person. That's John savill. That's someone else of. There's five of those things in there. So I can analyze pictures, analyze videos or other types of visual content and everything like. Vision services. So these are all prebuilt. So the point of this is, hey, I don't want to build and train models for the most part. I want to be able to just take some prebuilt model and use it. So that's Azure cognitive services. Then we have the idea. Of Azure bot service. And Azure bot service, I'm going to try and draw a bot really quickly. Terrible picture, I know that's a robot, so the Azure bot service it's really about the idea of interacting. With people now, this could be a kind of a chat bot, it could be voice, because remember I can integrate with other types of service so I could understand natural language. So the whole point of the Azure bot service is I want those kind of interactions with an actual human being. I'm going to build an entire knowledge base of things it knows and then it can draw from how it can respond and answer to that person. I can have these nice interactive cars for nice visual interactions, and this single bot I create, I could link into many different types of channels to actually use that. So that was when we think about kind of those AI services now. Come over here for a second. The next basic thing you need to understand is this idea of. DevOps. Now, DevOps is not an Azure technology as such, but remember before we drew this idea of, hey, we had this git repository where I stored a JSON file and we provisioned things to this. So DevOps is all about a process. It's the way people work together, it's the tooling process they may leverage, and there's different ways we enable that. You'll hear things like continuous integration, pipelines, continuous deployment, continuous. Delivery. So we have this idea of DevOps. And there's this whole cycle you kind of see in DevOps around, hey, we get feedback and then we constantly make these small incremental units of business value. Then we gather more feedback and we then enhance it some more. And it's never ending loop. And there are different tooling sets available to us, so there's Azure DevOps. So Azure DevOps has repos, so as you would expect it has repost so it can be git based or it has its own team Foundation version control which really no one is going to use any more. Get really has become the standard in repost. This is how we can do that. Version control. That's all what repos around. It has the idea of boards. So boards is about how we can organize and track projects and Azure DevOps is very very good at this if we jump over for a second. I've kind of got a board that I used to track the videos I work on so I can see, hey, this is my video planning board and we have these Kanban boards which is based on how we organize and move things. I can have these swim lanes and work in progress limits. It's a really great powerful solution, so Azure DevOps is great for that. It also has pipelines. So pipelines are all about that idea of, well, continuous integration, continuous delivery, which is about constantly building our software, maybe continuous deployment actually pushing into production as well. And that that's been a very rich solution for Azure DevOps. It has the idea of I can have gates between different stages which could be different environments, and that's where it was really, really strong. It has artifacts where I can store kind of these built, maybe some library, something else. It has test plans and while this is a very mature solution. It's really not getting a huge amount of investment today because Microsoft bought GitHub. And this is very much the future. And now where GitHub shines is repose. It obviously has repo functionality, but it has fantastic security. It can detect how their secrets in there. It can convert your code to data to run algorithms to detect vulnerabilities in your code. There's a whole set of rich functionality. It is the open source kind of repo for the world. It also has actions. Now it's actions are. Yes, it does C, ICD and else. Well, maybe all because it's not just restricted to CI CD. With GitHub actions I can create an action off really anything. So if I was to come and look at my. Of my GitHub I can create actions. And there's I can trigger off really anything I want. So I've got different workloads here. So one of these, for example. Is. You have a kind of. An on South these ONS. I've got one just set to nothing. So I will manually kind of run this, but I could trigger these on really anything. And what makes that so powerful is I could trigger it. Hey, someone submits a pull request, someone joins a community, someone posts a comment. So these actions are super powerful and it has environments now and I can have kind of gates on the environment so I can still have those really nice controls. Now on GitHub as well, it does have. The idea of projects which would be like kind of the boards, it's not as rich today, but I expect it will catch up. And again, it has the places I can have like artifacts and all of those things as well. This is the future. This is where everything is going to go. It will the places where it's weaker today, like projects. It will catch up and pass, but you had Azure DevOps today. Great, you can carry on using it if I was starting today. I would probably be going GitHub and they can work together. I could have my repo for my code and use Azure Pipelines or Azure boards to actually manage it. Then we have dev test labs. Dave Dev test labs. It's all about the idea that hey, I need to create a bunch of VMS of different configurations so I can test something and then tear them all down. Well, I say VMS. The reality is anything I can define an ARM template, I can define with this. So it's about creating environments for testing, doing the testing, and then tearing it down afterwards. Now tearing it down afterwards is actually really important. That's just consumption based. Remember, we pay for what we use. So let's dive into this a little bit. So let's dive into this idea of, OK, these are all the governance and we talked about budgets and stuff like that. Let's go into what actually costs us money and what can we do to maybe optimize those costs. So how do I think about? Costs in Azure. Remember, fundamentally, we're often creating a resource. So what's going to define the cost? Well, there's a type of resource. Storage account, virtual machine, media service, machine learning. That type of resource will impact the cost, then the type will often have a skew. Is it a standard? Is it a premium? Is it a basic maybe there's a tear? Well, the tear, hot tear, cool tear archive that costs me money. Location. Different things might cost different amounts of money in different places. And then based on that there may actually then be metering in place. Often there is it's consumption based. So I can then think about OK, if that's the basic structure of the unit well. Does it exist? I is it provisioned? Um, is it running like a virtual machine? If it's not provisioned on a host but it exists, I don't pay the compute charges. How many? We think of autoscale. Remember virtual machine scale set can change the number we have. How much work is it doing? Think serverless. I can think about, well, how much is it storing? If it's a database, if it's a storage account, that's going to impact. And that when I think about the storing side, well, there might be OK. So there's capacity. But then I can think about interactions, transactions. And that might go into what's the right tier that I should use. There might be licensing. So there's many, many factors that actually influences the cost of my resources. So I can think about what are the things I can do to help optimize that. OK, well, how many? Also scale. Make sure we're only running the number we need for it to work. Make sure we optimize the skew. Remember those VMS? There were ones that memory optimized, compute optimized, general purpose. Make sure the ratio of resources is matching the workload so I don't have a bunch of wasted resource that I could do something better. Make sure we deallocate. When it's not required. There were ways that you can automatically shut down VMS at night, so if I have like a dev test environment, we'll shut it down at the weekend, shut it down when people aren't using it, and essentially what autoscale does. But also, does it exist? Am I paying for something that doesn't exist anymore? So make sure you use resource groups to organize and then you can actually delete things more easily once a certain project is no longer required. If there are tiers available. Can I use that kind of life cycle management? To move things around. So I'm optimizing capacity costs against those kind of transaction costs and the type. Ideally I want to be moving from IAS. To PAS that includes both compute and database. I don't want to run a database in a VM if ideally I could probably run it as a database. Paas service, Azure managed. Postgres, Azmayesh, MySQL, Azure SQL database, Cosmos DB. That's much better than running those products in a virtual machine. There's probably gonna cost me more. But it's also far much more work for me to actually be managing. Make sure I can always identify the owner. So if all of these remember that the metadata, we'll make sure on these things. I have tags because I want to know who the owner is. So I can always say, well, who's is this? Are you still using it or can I delete this thing so you want to be able to optimize those things? And in general. There's thing called Azure advisor. We're going to talk about this. Azure advisor gives me kind of guidance overall wide range of areas, but it gives me recommendations about cost. So I want to be looking at that frequently, maybe once a week to get ideas if there's something I could be doing. Now, outside of these general cost saving things, there are other things that I can do. One of them is thing called Azure Reservations. If you imagine I pay a certain amount of money based on the SKU or the number I have running. Over a certain amount of time for a certain type of resource, my usage may fluctuate a little bit and I'll talk about maybe over years. There's seasonality. But there's kind of this base level, but I'm always using that amount. Azure reservations let me for kind of one or three-year terms saying hey I'm going to use this type of resource could be storage or cosmos or thickness skewer VM. And if I commit to using it for, let's say three years and this amount, you get a massive discount. So those can really help me save a lot of money if I can commit to using that for a certain amount of time. The other things I can do is remember this licensing. so something called hybrid. Use benefit. And this is all about the idea. Well, I have some licensing already. Maybe it's the OS like Windows or even some of the Linux or things like SQL I've already got the licensing covered by. An enterprise? An EA agreement with software assurance? Hey, I can bring that and use it against resources in Azure and stop paying. For the licensing part, I'll use my existing license, basically bringing my own license to it. I might have workloads where I need to get work done. But it's not time critical and it can be resumed. So it can get stopped and it can start again. Kind of this existing idea. So one of the features we have is Azure. Spot VMS. And what this lets me do is remember we talked about the cloud and it was limitless because there's this massive amount of resource available. Well, obviously they have servers, but they have to have a huge amount spare for when people suddenly create 1000 cores of something. Microsoft don't really want empty servers if they can help it. So what spot VMS let me do is I can say hey look. I want to create some VMS. But you know what I'm reading? I'm OK if you have to stop them, because someone who's willing to pay regular pay as you go needs it more than me. So when I create certain types of resource, what we'll actually see is this idea. Of let me change the SKU. We'll see this idea of Azure spot instance and if I say yes, I can actually go and look and what it's going to do is I can set a price. I'm willing to pay up to a certain amount of money. Or I'm willing to pay up to its regular rate. But I will still get taken off if some regular on demand customer needs it and what it's basically showing me here is what price. I currently pay and what is the chance of me being evicted by regular pay as you go customers. So the rate is going to vary. Obviously you typically if they have so much spare capacity they'll charge you less because they just want to try and get it used. The less spare they have the spot price may go up. I can see over here for example like Canada Central or it's really cheap and viction rate is 5 to 10%. So I can see I can get much much cheaper resource. And this would be a great fit if the particular resource I'm creating is running some workload that. It can be stopped. And then resumed again. So I don't want to lose all my progress. So it's some job I'm running that, you know what, it can be stopped. Because I can just resume from where it got to it some maybe batch process or something else. So it's a way I can use all that huge capacity and get it as cheap as possible. Now, when I think about all of this, when I think about costs, how do I know what my costs are? So there is a pricing. Calculator. And the pricing calculator, this is easy just to understand by looking at it. So if we go and look at the pricing calculator. What this lets me do is I add the type of service so I could add virtual machines. Let's added and then what I'm telling here is, well, how many of this resource do I want? And how many hours? Remember it may not be 24/7 or month, it may run 4 hours a day. So I tell it how much what type. And then it will show me the price. Now notice saying interesting about this. So if I see here, let's change this to one for a second. Notice the price over here $152. Now if I was apply, remember that reserved instances. If I'm willing to commit to a three-year term, look where the price dropped to. $104.00 Now this is a Windows VM. What about if I also have Azure hybrid benefit? I am bringing my own Windows Server license now. It's $37. But I would basically go through and I can workout all my different costs. Remember there's disks as well for a VM. OK, I'm going to add an OS disk of different types. It doesn't show me premium or ultra because. I selected the D series, not the DDS, so if I wanted to be able to use the premiums. I need to use a something S variant, so now I've picked an S variant. Now I get the premium option as well. So I could go through and I could add those to my OS disk. If I wanted to add other data disks, I would add storage account, I would say a managed disk and then pick the type. So the pricing calculator lets me go through Add all my different resources. And then actually understand what my expected prices would be. But it helps me understand hey, where reserved instance may play, a hybrid benefit helps me, etc. But it's more than just the Azure cost. We often think about a total cost of ownership. There's also a total cost of ownership calculator. And what that lets me do is give it information, there's certain assumptions and it will workout OK. This is what we think you're savings will be compared to Azure. Now obviously you have to give it data, and if it's garbage in, it's going to be garbage out. You're going to tell it what you're spending today. So you're telling it the types of resources you have, how many you have, the specification, you can add databases to it. You had all these different types of resource. Then there's certain assumptions. Now it's making assumptions about how much it costs you, what types of resource in Azure, how much you pay for electricity, how much you pay for labor. You can tweak all of those then once you put that in. It will give you an estimation of what it thinks it's going to cost you in Azure. Compared to what it costs you on premises so you can start to workout that total cost of ownership. So this is all about helping me hey plan out from a costing perspective what those various services are going to be. Now, I wrote this line up here before that Azure advisor. Azure Advisor is a service focused on giving me guidance. So this is all about guidance and it's guidance on a range of things related to cost and performance and resiliency that I can basically go and look at and it will help make sure I'm making the right things. So I can think, OK, where's guidance around security? I can think about this guidance around reliability. Am I using availability zones, for example on my protecting operational? Excellence. I can think about performance. And then obviously cost, so these different areas that it's going to guide me on that I can actually go and understand. So if we jump over and justice looks, it's easier to see it. This is something I would recommend at least weekly you would go and look at. But if the question was, hey, you need to get a quick idea of steps you could take as an organization to improve your security or your reliability or cost or performance. There's a whole bunch of different guidance you can give you. Azure advisor is probably it. It has kind of the overview of those different key areas and things you could focus on. It can show me all the different types of recommendations it may give me. So it's about, hey, shut things down, resize different virtual machines to a better SKU or other types of service to a better SKU, use burstable VMS, optimize Azure databases circuits. You're not using whole bunches of different things. They are available in that Azure advisor, so that's kind of a great place to go where I just want some overall guidance on. I don't know where to start, what are some things you're seeing Azure to help me with my environment? Now, beyond that. We have a whole set of resources in our environment and all these different resources we have have maybe different metrics, different logs coming out of them. Things like Azure AD has bits of information coming out of it. How do I kind of stay up to date on what's happening over that entire environment? So we have requirements around monitoring, so we have Azure monitor. So all of those different systems we talk about be it Azure AD. So Azure AD has things like a sign in logs. There's audit logs, there's risk logs, there's different types of logs coming out of that I can think about. Well, my subscription itself. It has an activity log. Things happening at the ARM level related to the subscription I can think about within. There's all different types of resources. Those resources have numeric metrics, well, they just get stored in Azure monitor automatically. But they also have logs. Logs do not get stored anywhere by default. They do further activity log and the Azure ID. But the logs for a particular type of resource do not. If I want to capture these types of logs, what I have to do something? So what we have is we have the idea of diagnostic. Settings and pretty much every type of resource. And note even the ones that are built in like these and this I can apply a diagnostic settings to make it go somewhere else, so even the metrics. All of these things there were diagnostics settings available, so I'm saying what I want to do with this stuff and I can basically send it to different places. So one of them is thing called a log analytics workspace. There's actually kind of part of Azure monitor. But it's a big log ingestion service and a big analysis service, so it's native to Azure. I can store things for up to two years maximum and I pay for the data ingested and then the period of time I keep it. So sending it here is super useful for data that I want to perform some analysis against. I could also. Write it to a storage account. So this is cheap. But it's not that useful to actually interact with. I just got files, but it's very good for long term. Storage. And then the other thing we can do is event hub. So Event Hub is a publish subscribe system and where this is useful is I could have some external tool, it could be like an external SIM and it can actually subscribe. To the event so we would publish. The event and it would subscribe to the event so it then gets them and then can do something. So it's very useful to send it to some external system and I can have any combination of those things. But what's nice is when I think about these systems. So I have things in Azure monitor native that time series database. What Azure monitor also lets me do is. I have these various signals. No no signals could be those metrics. It could be saved from the activity log. It could be something in log analytics workspace. So what I can basically do is I can create alert rules. So based on some criteria. I want to create an alert. Well hey this metric is above this number or this log is found. And it can trigger an alert. Once we have an alert. I can actually have action rules. At different scopes based on the alert that can call an Action Group. Action Group. Hey, I want to send an SMS message. I want to e-mail. I want to call a web hook, I wanna call a logic app. The list kind of goes on, but now I can automate things. I'm not just hey showing an alert that we're showing my mobile app in my portal. I can have rules, and I can actually tie a rule directly to the alert and action to the alert rule as well. But separating them out is actually nicer and I can do a whole bunch of things. Automatically. Now additionally. Think about the services we have. And these alert rules can actually play into here as well. So if I think about OK, that subscription, the activity log, there's also this idea. Of. Service health. Because if you think about it, there's these different sets of telemetry things about the regions, all the different Azure infrastructure, there's the health of the overall service that once again that service health. Can actually be used as I can create rules around this. So if I was to go and look at my subscription. I went down to help and support. I can see service health. So here it's showing me a customized view of any issues that might impact hey the regions I'm using. Um, the services that I'm using, the subscriptions I have, I could see upcoming planned maintenance. I could see a health history of things that have happened. I can see there were some issues. I could see the root cause analysis. Of that, I can see full tracking of what happened within there and I can create health alerts. So I can actually add a service health alert which. Is an Action Group. Hey, I want to add an Action Group. We've got a whole bunch of those which do different types of things. So service health is how can I go and see historically what has happened to my environment? Ohh, service health, how can I see what planned maintenance is coming up? Ohh, service health, all of those things are answered through the service health. So it's super, super useful for that. Now if I think about health for a second. And I've got all these different services all throughout Azure. I have VMS and resources and I'm paying money for things. And we talked about shared responsibility model and the idea that there's a lot of things that I'm not responsible for and maybe I don't even have any control over. I'm trusting my cloud provider to give me a certain quality of service. So what is that? So what we have is for services, we have a service. Level. Agreement. An SLA. And typically you'll hear that in the form of a number of nines. And so we can think about, OK, well, if there was three nines and 99.9% availability, that's basically 10 minutes. Per week it could be down. If we have 99.95, well then that's 5 minutes per week it can be down. If it was four nines, well now we're getting down to it's basically a minute. A week. It can be down 5 nines, it would be 6 seconds. 5 nines is near impossible to do. But you have these different numbers of nines and basically every service has an SLA and all these links. Remember in the handout for the four AZ 900 course. So you can go here and search for a certain type of resource and you can see the SLA. Now it has like a full introduction around, it has general terms. Has talked about service credits or how if there was an issue, if it was breached, how this impacts it. I can see any limitations that may impact that. Now notice it shows me what the SLA's are. But a key point here is some services will vary depending on how I've configured my environment. So remember, availability zones are those blast radiuses. They're separate physical buildings. We've isolated network calling and electricity. So what this is saying the SLA for virtual machines is saying hey look. If I'm in a certain region. And hey, look, let's just focus on the three AZS I see. It's saying if I deploy a service and I've deployed my service such that hey. It's got VMS in at least two AZS that make up that particular service. Well, then I can get a 99.99% SLA because hey, it's independent buildings with independent power calling networking. They have good confidence that even if one building fails, the other one wouldn't be. So if I deploy my service over multiple Azeez and give me that SLA. But if I don't? If they're just in the same one, what it means do that. Go back. Shouldn't try to use hand on that one? But if I go back to the VM. If it's in the same AZ but uses availability sets which are different racks in the same data center, or that I can get a 99.95% SLA. So that's saying, well, you're using the same AZ, but within the AZ there's different racks of servers. And it's saying OK, you created an availability set. So your VMS are separated on different racks, but they're still in the same data center. But then we'll give you a 99.95 because you still got some nice resiliency at the rack level. So that's impacting the SLA I can actually get. But then basically if you start having single instance virtual machines, well then it depends. If it's premium SSD it's 99.9, if it's standard SSD it's 99.5, and if it's using a standard hard disk drive. It's 95% which is obviously generally. If maybe it was a dev environment that's fine, but for any production that that would not be suitable. So then as soon as you get into individual ones, well then it depends on that type of disk. So again the premium is that 99.9 and then it was kind of the standard SSD. Can't remember what it was. 99.5. So basically it changes and then standard hard disk drive. Was 95. So the SLA may vary depending on how I'm actually distributing and you need to go through each independent service to see the details, but that's going to vary. If I want to understand what the service the status is of services overall in Azure, then I can go to the Azure status page and it will show me I can see all the different regions. I can see this shows show me the notice the regions for Azure Gov I can see the regions for Azure China. If you go to America's I can see oh yeah think looks good, so it's a nice way to quickly actually go and see. Obviously if I use multiple resources as a composite SLA and that's really out the scope of an exam cram, but obviously if I need multiple services to work then it increases the chance of failure because if any one of them is out so my SLA will get worse. When we think about features in Azure, there is an overall lifecycle. That the cloud is Evergreen, it's constantly evolving, this is constant innovation. So when I think about services, often what will happen first is it will appear in a private. Preview. That's maybe certain customers who invited or you can apply. That's all like getting feedback from the customer as well as testing. Then it goes to a public preview. That's where everyone can try out. But the whole point of these is it's kind of no SLA. And typically there's no support. And then? It goes to general. Availability. Or GA, that's when it gets an SLA is when it gets support. So that's the general flow of how services are delivered. Actually, in Azure, there's a special preview portal. I can go and check out the Azure Updates blog to see new features. I could actually create a weekly video going through those new things. Now outside of this. Sometimes I talked about SLA and shared responsibilities. You may want to understand a bit more about this. And there's really three key documents this. I'm just going to show these to you. So the first document is the Microsoft privacy statement. This explains personal data Microsoft collects, how it's used, and for what purpose. Then we have the online services terms. This is the legal agreement between Microsoft and the customer. It outlines the obligations around processing security of customer data. And personal data. Then there is the data protection addendum. This further defines the data processing security terms for online services. Things like compliance with laws, disclosure or process data, data security, the encryption, the compliance data transfer, all of that. So you can always go and see all of these different documents just to understand how these documents exist and kind of what their key points are. So their privacy statement, hey, what personal data Microsoft collects, how it's used. And for what? Online services terms what is that legal agreement between Microsoft and the customer? The obligations around processing and security of the customer data and personal data. And then? The OS the data protection addendum. Just further information on that. Now carrying on the, I guess the thread of documentation, often we care about sort of the, well, what compliance offerings does Azure have? And Azure really thinks about these three pillars of security, privacy and compliance. So security. How various defense in depth is provided compliance Azure has a huge number of compliance offerings, so which ones apply and are available on privacy or helping to ensure the privacy of your data? There's also might be reliability, resiliency, intellectual property. So when I think about these three pillars, what we actually get to is the trust center. And there's provides the detailed information about that security, that privacy, that policies, the compliance offerings. And what I would recommend is go and navigate around this, go and look around to understand all these different areas. One of the really useful ones is obviously the compliance offerings. From here you can see, hey look, there's these key ones, GDPR, certain ones about certain service assurance like how the data centers are managed and the security. But if you click compliance offerings in the middle or just give you a massive list of all of the compliance offerings. So that's kind of a great place to quickly go and understand what all of those are. So covered a huge amount, one more section and then we're kind of done. So we talked about security throughout this entire thing. There were security elements when we talk about the networking guardrails, all these different areas, but there are some very specific security things just to think about in general for the cloud. And even outside of the cloud, we can think about the same things on premises as well. So we've security, we always think defense in depth, we think layers, we always want layers, so defense in depth. The idea that we build on these different layers of security because if one failed, well, there's another layer that would protect me. When I think about layers, there's the physical security. So the physical would be the data center get into the hardware. I think about identity. And access. I want to make sure we have strong authentication, password lists, MFA, auditing events, sign in events. Want to capture all of those. I think about the perimeter. We talked about distributed denial of service. I want to make sure I'm protecting against large scale attacks before they get into any kind of environment. Edge firewalls for example. I think about the network. We talk about network security groups. The way to help limit. I should only have the amount of communication needed to do the job. This. Disabled by default deny by default I allow in by exception I want to have private connectivity, site, site VPN, Express route, private peering. I don't really want to use Internet if I can help it. I think about the compute. Ideally I want to offload responsibilities, but if I am responsible my patching the OS, do I have antivirus? Do I have good configuration? Do I have firewall in the OS? I think about the application layer. Applications can have vulnerabilities that my offering things out to the web. I have HTTP, can someone do a SQL injection attack? And there's many types of attacks that can happen. I want to make sure I'm protecting that and then my data. Is it encrypted at rest? Is it encrypted in transit? Am I doing bring your own key? So I always think about all these different layers of making sure I'm thinking of protection all the way through. Now you'll hear about this idea of CIA confidentiality, integrity and availability, so I want to make sure it's the least privileged access, and only when it's required, just in time. I think about my integrity. No unauthorized changes using signatures to validate. Nothing has been changed. Availability protecting against things like denial of service attacks. Now, there are many different services around Azure to help me with this. We've seen some of those. But one of the big ones when I think about just the overall security posture of my environment is Microsoft Defender for cloud. This was called Azure Security Center. You may even see it called that in the exam. But it's been rebranded to Microsoft Defender for cloud, so you might see either one. And really, the Microsoft defender for cloud or Azure Security Center is really a hub for security. So if I go to Microsoft Defender for Cloud, formerly known as Azure Security Center, it has this nice little secure score. It's a great hub for getting an idea of an overview of how secure am I. It can hook into a large number of different compliance offerings. To maybe I need to be compliant against a certain type of regulatory requirement. It has many different enhanced capabilities. There's an enhanced security mode that gives me things like just in time. So hey, I can only RDP or SSH to resource when I make the request. I have adaptive controls based on the commonly used applications, enhanced machine learning, I can extend threat protection for non Azure resources and there's other defender services as well. I can have integrations with other types of solutions from within here. That can all help improve. My overall security posture, so there's Microsoft Defender for the cloud, is really this great starting place. For understanding so I can enable this enhanced Microsoft defender for cloud understanding, exactly what is my security posture? I get specific security recommendations for things to focus on, but again if I turn on those enhanced I then get service specific sets of additional protections. And then? The next service I drew out this idea before of log analytics workspace. Well, there's actually a service called Azure Sentinel. So as a central actually sits on top, it uses log analytics workspace and it's all about getting feeds of information from lots and lots of services. It adds some additional connectors, some of them law had natively. Then it adds things like machine learning on top of that to understand it has a whole bunch of hunting capabilities, detection. So it's all about the idea of being a SIM, a security information and event management understands it will take these huge masses of logs coming in and recognize patterns to say hey look. There's something happening. We need to do something. It has queries that I can run against all the data and log analytics workspace to go and hunt and find problems. But it's also a sore a security orchestration automation response tool so it doesn't just have to say oh let's things happening. It can automate responses that can call a logic app. Hey look I'm having an attack from this IP address. We'll call this logic app to go and disable entry from this IP address on my firewall. For example, go and disable this Azure AD account. It's trying to attack me. So Azure Sentinel provides that SIM and saw. Solution as an Azure service and it's using log analytics to get these massive number of connectors coming in to actually provide that for me. So it's good to kind of understand that as well and that's it. So that's everything I wanted to cover. Now obviously we covered an amazing amount of stuff. What you really need to understand for Azure 900 is understand hey look this solution. This resource exists and what is its primary use case. You're not going to get asked to configure it or do any kind of massive advanced thing. It's just about understanding. This is the requirement, that's the service I would use. That's really the basics of it. When you take the exam, relax. Um. Take note of the amount of time you have. Take note amount of questions. Divide it up pretty evenly. Don't get stuck on one question, loosen your time. You can mark it and come back to it at the end. Don't leave questions empty. It's better to have an educated guess. Eliminate the obvious wrong ones. And then Azure's not there to trick you. Things are named to try and be intuitive to help the customer. Which one sounds like the right thing. You need to protect a resource from being accidentally deleted. Would I use an availability zone, a resource group, a network security group, or resource lock? Well, I know it's not a network security groups that we network specific. I know it's not availability zone. I'm pretty resource group doesn't sound resource lock. Well that sounds like it would lock something, I'll guess that. So just eliminate obvious things and then have an educated guess. If you don't pass the first time, it will tell you at the end where you were weakest. Go back and redouble your efforts. Again, I would make sure you've gone through my full 8 1/2 hour courses now adverts in that it's just there to help you. I would watch this as a quick refresher before taking the exam, but relax, I really wish you all the best. Good luck. This is a huge amount of work. Please please do subscribe and share this with other people. But yeah, good luck in your exam and take care.
