Azure Master Class v2 - Module 6 - Networking

Hey everyone, welcome to the networking part of the Azure Master class V2. We have a little new logo for this week. So the goal of this part is to explore all things networking in Azure. So you think about the virtual network construct, how we leverage the virtual network, how we might have connectivity between virtual networks, connectivity outside of Azure, maybe to on premises, controlling the flow of traffic, offering services, everything. Around the network. So that's our goal. So if we think about the basics of a virtual network, well, a virtual network exists within a certain subscription, so that's a boundary. Within a certain specific region. So within a subscription within a region, obviously subscription can use many regions. And it cannot span those subscriptions or regions, so it's always bound within those. And we think about defining what is a virtual network by one or more IP ranges. When I say IP here, we always think IPV 4, but as we'll see later on, it could be IPV 6 as well. It always has to be IPV 4, but it may also add some IPV 6. Now typically we're going to use RFC 1918 for that. So those are IP addresses that are set aside that we can use in our internal networks. You probably have it at home. You'll maybe see your IP addresses tender or 192168 dot. And the point of these IP addresses, they won't route over the Internet. If they get to anything that's on the Internet, just going to drop those packets. So every company could use the same addresses because they won't route or clash when they actually get to the Internet. Now this address space is then broken up into subnets. Just what we would have. Regular network. I have a physical network. Then maybe we have floors of a building, parts of a data center. They'll get a portion of that IP space. Now in Azure, a certain number of IP addresses from every subnet are reserved. The regular ones just for IP, the all zeros and all ones we're always set aside for the network address and the broadcast address. Then Azure will also take an additional. Three, which we'll see when we draw this out. And subnets are regional, they span availability zones. So while in some clouds, hey, a subnet has to be bound to a particular availability zone, which remember is that particular group of data centers with independent power calling networking. That's not the case in Azure. I can have services really all over the place and it doesn't impact anything. So if we think about these constructs for a second, so remember we said OK, well I have a subscription. Remember I can create many things within a subscription so we have this boundary. It is the subscription. Now within the subscription I can create things in many many different regions. But here are pick a specific region, maybe it's South Central us, it could be E US two, it doesn't matter. But within a particular region I'm using within those two boundaries I can create a virtual network. So I can think about OK. I've created my and the quality of vnet 1. Now the whole point is that virtual network will defining by at least one IPV 4 cider range. So as cider is a way to write down a particular network and how many bits make up that network. So I might think about, well I have to have one IPV 4 cider range. For example, I might say hey say EG 192.168 slash 16. So those that's an RFC 1918 range. Now another RFC 19 range is 172.16. And remember this slash 16 is a number of bits that make up the network mask. So it's 32 bits in IPV 4 range. Send the dot something something hey, I can use whatever I want within there. There's also 172.1612 so it's only using half, so this could actually go up to something beyond the 16. And then as 10 slash 8. So I might hate 10.0 dot 1.0 could be a particular subnet that I use within here, but this is this RFC 1918 ranges. You don't have to use these. If I own some great big range on the Internet that I've purchased as a company, it's actually Internet routable. I could absolutely bring a portion of that to the virtual network. But just because it's routable on the Internet, these will not be routable. They'll still be private IP addresses used only within the virtual network, so it would really be a waste of the IP space to bother assigning them right here. And there was some really, really good reason. So we have at least one, but I can have additional. So I can change the side arranges. For Virtual Network I can add. I can even remove providing it's empty. I've managed to empty everything out of using that particular block of the addresses. Now within that virtual network. Hey I create subnets. Now let's say in my example. Just when we think about the IP ranges I might use, let's say what I actually used in my virtual network was. This is 10. 0. Slash 16 so I'm using a portion of that 10 space I'm using hey the 10.0. That I could then break up into subnets. So if this first subnet so this is my subnet 1. I have to use a portion of that space, so maybe I'm going to make subnet one. Well, it has to start with 10.0 because that's virtual networks address space. So the slash 16 is saying this is the network. Then I use a portion of that, so maybe I'll do 10 dot 0.0. Slash 24 so now everything within this subnet would be those. I might create a second subnet so I can have another subnet. Subnet 2. Well, it's IP range. It has to come from this range. It can't be the same. I can't overlap. Maybe this is 10.0 dot 1.0 slash 24 so you can see it's just moving along and I'm using whole 8 bits per subnet just to make it simple for me. Now when I create these subnets, remember the whole point is we lose a set of IP addresses, so whatever this range is. So say that was a slash 24, I always lose. Five IP addresses. Now the all zeros. So for example if this was a slash 24. So I'm making assumption just to it looks easy when I write this down, but the zero, well that's the network address. The .1 is always used for the gateway, so Azure is providing the gateway service. Even if resources are in different subnets, they can automatically just talk to each other because Azure is providing that gateway for us. The .2 and the .3 are reserved for DNS purposes. And then the all ones that make up the host address. So for example 255 in my example or that's used for broadcast so those are reserved so I always lose 5 IPS from any virtual network, so no matter what that size is. So if I create the 29, there's only be 3 usable IP addresses, so 29 would give me 8 addresses, but I lose 5 so it could be 3 usable, so a slash 20. Nine therefore becomes the smallest possible. In Azure, because anything less than that there won't be enough even to give it the reserved IP addresses it wants. So that's always going to be the way for those. So I think about these constructs and remember, as I mentioned already. We have those availability zones in most regions AZ2AZ3. AZ1 subnet span them. There's no alignment of a subnet to a particular availability zone. They do not care, they can just crossover those and then I would create resources. So OK, great, I'll create a VM and what I say I create a VM in the subnet, it's not really the VM. What really happens is that VM has a virtual Nic. And it's the nick. That connects and is bound to a particular subnet in a particular virtual network. So now you would say that VM is in this subnet. But again, we know really it's not the VM, it's network interface card that's connected to the VM, it's connected to a particular subnet. So this is this is all virtual network. It's bound to a particular region, cannot span regions, cannot span subscriptions, and this is built on unused by nearly everything in Azure. Most things inhibit inhabit a particular virtual network. That's just the way these resources are constructed. OK, so. Then we get. Of virtual Machine Network interface card. So I drew that on the picture. The idea of hey, there's this nick. The IP address from a virtual machine always comes from the Azure fabric. This will be thought of within the guest operating system as DHCP. Now I can reserve a particular IP address from the subnet. The VM is connected to four articular virtual machines. If I was domain controller a SQL Server I can absolutely configure it so it always gets the same IP, but the guest operating system it thinks it's using DHCP. Now the exception to this would be well. I have multiple NICs, so I can have multiple NICs connected to it. But then if I had multiple IP configurations, well then I'll have to do some configuration inside. Now you can have multiple NICs. But they have to be connected to the same virtual network. So they could be connected to different subnets, absolutely. But if I go back to the picture and we think about this, so this VM, remember the Nic is just connected into a subnet. It could absolutely have another Nic connected to this subnet, but it could not have a Nic connected to a subnet in a different virtual network. Every subnet it connects to has to be in the same virtual network. And if you think about the use of multiple network cards, that's useful in a physical world. In a physical world, there's pieces of wire attached that connect to physical hubs that connect to physical other pieces of wire, copper, fiber, whatever it is. So it actually separates up my connectivity. This is all software defined networking. The use of multiple NICs becomes a lot less useful in a software defined networking world. It's better to use network security groups and rules to control traffic. I can use routing to control things. Now that may absolutely be scenarios where I have rules assigned. Maybe this is a DMZ, this is some back end. This is some particular workload and I want a network virtual appliance, so a virtual machine with special software. In which case sure I want it to have Nic so it can connect to the different subnets. Which all do different things. Maybe it's routing in between them, but the point is it's a lot less common to need multiple NICs than it is in the real world because this is all software defined networking that's actually achieving this. So now if I think about. Going back to this. Many VM types also support accelerated networking. So what is accelerated networking? So if I think about the regular. The way this works. So I just said software defined networking, and when I talk about a virtual machine, so the whole point of a virtual machine is there's some bare metal. So there's some bare metal hardware I could think about, and then we're running a hypervisor. So there's some hypervisor and a hyper V world. The hypervisors really concerned with CPU and memory. And then there's this parent partition. And the parent partition because of the flexibility of acquiring different types of driver and I don't want those in the hypervisor directly, this parent partition runs. And connects to other types of hardware. So if I think about the network interface card, the Nic, the physical Nic on this bare metal piece of hardware, when it's actually the parent partition that is bound to that Nic and it has sync called a hyper V switch that enables all of the connectivity. So the hyper V switch actually connects to the Nic and then when I create my virtual machine. And it has that virtual Nic. Well, the Nic connects to the virtual switch. Great. The virtual switch is where we have all these virtual filtering platform components that do the various bits of routing and checking and all that magical. Great stuff, but it adds a certain amount of latency. Well, what we can also do is there's technologies like SRIO V that exist in Hyper V and in the hardware when he's network cards also expose things called virtual functions. So it might have multiple virtual functions on it. Just schedule three of them. They're really can expose themselves like their actual physical adapters. So why accelerated networking does is instead of it going via the hyper V switch? It gets bound to a particular virtual function use my color. So it goes this way. So this is when I turn on. Accelerated. Network. It bypasses the Hyper V switch. It basically just reduces latency, improves performance. Not every VM SKU supports it, but many of them do. So if I see the option there for accelerated networking, go ahead and turn it on inside the operating system and inside, what's really happening is there's actually still a regular virtual NIC as well. They bind them together because there were certain times everything's being moved, something happens. There has to break away from the virtual function. Goes back via the virtualized the synthetic Nic, but other times it will then switch back as best it can. So if you see accelerated networking turning on, all it does is give you goodness there's not a downside to it if it's available and you really just want to leverage it. OK, so. Many of them do supports accelerated networking. I can have multiple IP configurations per Nick as I was talking to. So if you think about an IP configuration, this is the idea of hey, certain IP address. It's always a private IP I from the range of that subnet. But maybe I also want a public IP and if we jump over for a second. If I was to just look at. A nick. So it's gonna look at this demo, Nick, right here. We noticed we have so notice. Firstly, I guess the important thing here is the nick is its own resource in Azure. It is an actual resource. It's an Azure resource manager resource. It is connected to a certain VM, it's bound. To a particular virtual network and subnet. They're notice one does not have accelerated networking, but I could change that. And enable it. Then it has its private IP address. This one also has a public IP address, so it has to have a private I. Optionally, I can also bind a public I and then I can see it's attached to a particular VM. It does not have IPV 6. We'll come back to that. If I go to my IP configurations down here in my settings on a single Nic, just like you could on a physical Nic, I can actually have more than one IP configuration. I have more than one IP address on the. In go neck. So I could do add and then I can say, well do I want to add an IPV 4 or an IPV 6? I can only have one primary which I already have, so it has to be secondary. And I can say do I want this to be a dynamic or static allocation and do I want a public I with this I configuration. So the whole point of this remember I can actually go and edit the existing one if I wanted to. Look at this IP configuration. See it's signed by default with dynamic. It's going to take the next available usable IP address and use it for this Nic. But this was something like a domain controller or a SQL box where I always want to have the same IP. I can change this to static, configure the IP address. Now remember the virtual machine is still using DHCP. Hey starts up. Hey, I need an IP address please. But the Azure fabric which acts as that the HTTP server will always reply with that IP address. It's not going to vary each time. Whereas if I have this as dynamic then. Hi, depending on maybe what started before it. It may get a slightly different IP address. Normally we don't care. Even if something needs to talk to it, normally it will go to DNS and DNS will say, oh, this is its current IP address because it will get registered as part of that IP address allocation and other processes. But this is where I can control that if I wanted to. But I can absolutely give multiple IP configurations to a particular Nic, and if I do multiple IP configurations we'll then I have to manually. Inside the guest. Do configuration for those because obviously there's no way for DHCP to give out multiple IP configurations to a single Nic. It just doesn't work that way. So if I do want to do multiple IP configurations, realize hey I can, but then that's the one time that I am going to have to actually do something the guest OS to leverage those additional configurations. So I can have that. I always have a private IP. I can optionally add a public IP and we're going to talk more about public IP's and how they flow just in a few slides time. The number of NICs does vary depending on the actual type of VM, so if we look at some of the limits. This talks about, well, how many IP addresses can I have to notice private IP addresses per VM. There's a lot of them, so per interface I can actually have 256. Private IPs and 256 public IPS per Nic. So I could have a lot of different IPS, but NIC, if I wanted to. Now these are really focused around IPV 4. IPV 6 today has some very different limitations from that. It's nowhere close to those numbers. I think it's one today. I think you have one IPV 6 today, but I'm sure over time that will change. So supported types of traffic that I can have being used on that virtual network and it really boils down to its. Most things that sit on top of IP. So IP is a layer three. So then if it sits on top of IP. It will probably work. Now things like TCP and UDP, which layer four they sit on, IP they work, they're tested and by working. The important thing is they work with other components of the virtual network. So if I had network security groups and rules, those rules understand TCP and UDP load balancers well, they have rules that can be defined in terms of TCP and UDP. May other layer four things work, sure, but those? Components within Azure may not understand them and so you won't be able to operate those with things like the load balancer or NSGS. Also ICMP. So ICMP we typically use for ping. Hey, I want to check if things there I send out an ECHO request to something and then if it's there it will send back that response to me a reply. So that's how I can go and check something. So those things are supported within my virtual network. So if we go and look at our picture, when I think about the types of traffic I can use, I'm thinking about what the layer three and by say layer this is OSI the old open systems interconnect I think it stands for this is IP. At the layer four, well, it's TCP and UDP and then ICMP is also supported. Now I'm drawing that kind of in the middle. There's sometimes debates about is ICMP layer three or layer four. Obviously it works with IP, but it kind of sits next to it. And so I'm joining in the middle so I can avoid that whole argument. But those are primarily what I'm going to think about using in my virtual network now. I cannot use multicast. Multicast is why I can target multiple IPS from a packet. I cannot use broadcast. I can't say hey everyone. I cannot use encapsulation, so I and I packets. I cannot use generic routing and capsulation GRE. Azure is using this for its own software defined networking, so there are limits on some of the functionalities that I can do within a virtual network. I can't ping the Azure gateway. If I try and ping the .1 it's not going to respond to me because again, this is software defined networking. If I think about what is a ping, a ping is actually sending out to that end device. Hey. Ping request please. EE, request this packet back to me. I'm sending you a packet, send it back to me. There is nothing at one to actually be able to send it back, so I can't ping the gateway. Also tools like traceroute are not going to work with the gateway also. I can't use things like Vlans. There is no layer 2 here that I'm going to be able to leverage as part of this. Um, I can't sniff in a promiscuous mode. So promiscuous mode network sniffer is. Hey, I put a device on network and it looks at all of the packets that are going over the network wire. There is no network wire. For the neck. It's being sent packets targeted to its customer address on this software defined network. I can't look at packets that are going over the wire to other people. They'll never get to my nick. I can look at packets that are for me or from me locally in my VM, but that's all I can do now. Azure has some tracing and packet capture capabilities as part of network watcher for example, but within the guest I can't look at packets for other people. I can't deploy my own DHCP server, it's not going to work. Those packets will never get received. Azure grabs them and it replies so it can give out IP addresses. So there are definitely limitations to certain things that I might be able to do. What about IPV 6? IPV 6 has become very popular and I have a whole separate video on IPV 6. I actually talked about what is IPV 6. And then how it relates to Azure. But the whole point is I can absolutely enable IPV 6 for a virtual network. So I drew this idea here that a vnet is one or more IPV 4 cider ranges I can absolutely also. Optionally add on IPV six side arranges. And the whole point of IPV 6 is it's much, much bigger. If a regular IPV 4 is 32 bits, an IPV 6 is 128 bits, and the idea really is, and I can't remember what the the actual number is, but there's is it thousands or millions of IP addresses for every square foot on the planet? You're not going to run out. IPV 4 basically ran out. We've done clever things with network address translation to make it keep working, but P V6 is so big we're not going to run out. So this was the idea that no matter how many wearables. Have and have any microwaves or toasters have an IP address? IPV 6 laughs and says, hey, I've still got plenty of space for that. It's not going to be an issue. So the idea is I can enable for particular subnet an IPV. V6 address once the vnet so then a subnet level I can say hey I want a portion of whatever IPV 6 that I might want to use. Now, typically. You're going to use the idea of there's different types. But there's things like there's link local. So I can have something that I generate myself. But I can also have certain unique addresses that like RFC 1918 won't actually route on the Internet. So if you see FD, FD is basically starting off the address that it won't route on the Internet and I can use whatever I want within my own virtual network. So there are once again IP address ranges that are reserved that I can use internally and if we went and looked at my network quickly. If I jump back over here. For a second. And what we can see if I go and Scroll down? Let's go and look at my vnet for a second. And I think it's my dev connect and look at my address space O it's on my address space. What I can see? Over here. Is it called an IPV 4 IPV 6 address space as well? So we can see it's an IPV 6 range. Now notice it starts with FD. OFD is that local range of IP addresses, so it won't actually route on the Internet. And it says slash 56 because, well, it saves another. Set of bits that I can actually use as part of the subnet. So if this is the range I'm using here, I'm using a portion of it. My actual subnet would always be a 64. So here. Can see basically my subnet is 1. But that is my subnet and now it's available IPS. It's just saying more than 10,000. It's always a slash 64 for IPV 6. Because the address space is so big, I don't ever have to worry about trying to make subnet some weird slash 27 or 20. We just make it slash 64. It guarantees it's going to work all different types of routers and devices and there's such a big IP space. I don't worry about it. It guarantees future compatibility. So it's always going to be this slash 64 for the subnet. It won't let you do anything else. And there's just so many IP addresses. And now the VM inside it. If I was created for example in that infra, it would also get an IP address from that range O. If I was to think about for a second, let's just jump over really quickly. So if I go and look at my. VM. Let me just go over here for a second. So if I get my VM. Come on, show the VM. Why is it not showing? Get that in a second, I promise. There we go. There's my VM, so if I didn't IP config. Notice my IP address is. Well, I've got that IPV 6 address. And it's from that FD. And notice it's the colon 1. Which was my subnet, and it's IP address is 4, so that's the sum of its. The 64 bits for the actual host address is 4. That's all it needs. It's the first usable IP again, I always lose 5, so the first four are taken 0123, so it uses 4. You'll see it also has this 80, which is a link local address that's also generated. It's like the old address we got if we use DHCP in a server. Couldn't be found, was it? 169 or something that's the equivalent of there, but we can see that my VM running in Azure therefore has. This IPV 6. So I have my regular IPV 6, I have my link. I always get a link local. I can't turn off the link local and IPV 6. I'm always going to have it, but those are available for me. OI can absolutely add IPV 6 as well if I'm ready to use it now. Things like network security groups. We're going to talk about user defined routes for load balancers, peerings, all support IPV 6. But it's always dual stack. I cannot do just IPV 6. I have to have an IPV 4 issues for some of the management traffic it's used for other things. I can add an IPV 6 to my config, I cannot be IPV 6 only. So think about today, it's always dual stack if I want IPV 6. Dual stack means in the networking stack it has an IPV 4 and IPV 6 as part of that. VM support IPV 6 virtual machine scale set support so IPV 6 AKS. Has support for I PV six in the cube net scenario where it has its own IP address range for the container networking. It does not support IPV 6 for CNI today, so the exact configuration is going to vary today based on exactly what is the workloads you're doing, but peering works if I create a public IP address such as. Jump back over to that for a second. So if I was to try and create a public IP. It actually gives you a choice. It will say, well hey, do you want this to be IPV 4, IPV 6? Or maybe you want it to be both? So I hit create and it gives me that choice. So many many things I can now use if I want to. IPV 6 things like Express route. Private peering, so connectivity from Azure to my on premises network. It can use IPV 6 that's available for me as well. I can enable it for existing resources, so I could go and add an IPV 6. I could then add it to the subnet depending on the OS. Maybe have to restart, maybe not. It does depend on the exact operating system and as I said Express route can support it as well. And I already talked about the public IPS. External access. All these IP addresses have been talking to so far have been within the virtual network. They're a private IP space. There is no special DMZ or Internet facing subnet in Azure. Some clouds have. The concept of a subnet has been marked as external facing and is not the case in Azure. There is no subnet where everything just gets a public IP. By default, Azure provides an outbound. Snap, so. Aesthetic network address translation based on ports support address translation, enabling resources to access the Internet receive responses. So before I go on to the next part, So what this means is. Let's redraw little virtual network for a second. So if I think about OK, I have a virtual network. So I have a vnet. And then we're in the VM. Now I have a certain subnet. Within that subnet I have some resource. Could be many resources whatever it is, but I've got resource with VM. Whatever got a group of them. And then floating out in wherever. Is the Internet. Then then, then other stuff. Things inside a virtual network just by default. Can talk to the Internet and they'll get a stateful response back. It won't let anything in, but let we will let the response come back in. Now this is gonna work, so this is going to be a layout. So it's using Snat now. This is that whole idea. Remember that the Internet is just a whole set of networks that are connected and can route. They know how to get to something, or at least what's a hint for the next hop to go to to be able to get to something. The Internet is just a bunch of connecting networks. Well, because they're connected they have to better route, which means they have to be valid IP address ranges. But we already said our virtual network is probably not, it's this RFC 1918. It's non routable. So what has to happen is I need something at the edge that is a valid. Public IP and what snack does is. Well hey I have this valid IP. You have a bunch of non public valid IPS. When you private IP address make a request I can specify a source port. And if you think about the port number, I think it's about 64,000 usable ports for anyone IP address. So I'm going to map Port 4000 to this particular request from VM1, Port 4001 I'm going to map to this request from VM2 and etc. So one IP address can handle a huge number of contiguous requests from different clients. So there's that is provided. Well, in different ways there's an implicit. So an implicit is just there's some public IP created that you don't really see or know about. If I just have a VM I try and talk to the Internet, it will do this implicit method. It will go and allocate a public IP and it will use it to provide this snap service when you go out to the Internet and let the responses come back. Well, I can do explicit. This is where I'm actually defining something now. One way is I actually have an instance level. The public. IP. This is saying hey VM, in your IP configuration you also have a public IP. Now the guest OS still doesn't really know what public IP it has nothing to do with it. It's the Azure fabric. When response comes into this public IP, it will just send it to the Nic of the virtual machine. The VM doesn't know it has that public IP. But in this case, if I have an instance level public IP, I'll use that to do my outbound Internet. Another option is I'm using a standard load balancer. I'm saying standard. It would also work with basic. Basic is really on the way out, which is why I'm not emphasizing that actually. One of the nice things about basic is even if it was an internal load balancer, this external stuff would still work. If I have a standard load balancer and it's internal, it will actually break the ability for workloads behind it to talk to the Internet. So if I have workloads behind a standard load balancer. And it's internal. I have to also put it behind either a public standard load balancer or I can use something called a Nat gateway. So this is a specific service designed to provide outbound and for all of these I give them a public IP or a public IP prefix. So prefix is a set of contiguous continuous IP addresses. Maybe I need multiple addresses? I need them to be one after each other so I can use a prefix. The benefit here of intent like Nat Gateway, it's designed purely to do nap outbound. I can define the IP addresses, it will dynamically use as many public IP's as it needed. As it fills up those 64,000 ports per IP, it will go and grab another one depending on the amount of workload coming in. The standard load balancer outbound rules can also use an IP prefix, but I have to think about it more in advance and plan it out more in advance. So this is designed for that outbound type access. But hey, I can also do it with outbound rules with a standard load balancer. But realize the key thing is if I'm behind an internal standard load balancer, I don't do anything. Those workloads won't be able to get to the Internet. I have to do something else, add a public standard load balancer that they're behind as well, or give it an instance level public IP. We almost never want to do this, by the way. Almost never do I want an instance level public IP. In fact, I'm going to draw my famous. :( like there's very few scenarios I ever want to do an instance level public I. And we'll talk more about that later on. But that's just not a great thing to do, really. I want to use one of these to control it. And of course the benefit here, this implicit one, I have no idea what this public IP address is going to be. It's just something. Whereas with both the standard load balancer and a Nat gateway I'm defining the public IPS so that when if there were things behind these services that try and access some other thing on the cloud, well I know what IP the request is going to be coming from. So I could actually whitelist out that particular IP on that target service if I wanted to. There's a lot of benefits with using those services there. OK. So what about if I want to offer something to the Internet? I actually maybe I'm running a web server well. I could give you an instance level public IP. We know that sucks. We don't wanna do that. More likely I'm going to put it behind a load balancer or an app gateway. Maybe in Azure firewall, but Azure file was really not designed for that type of balancing and that type of offering resources. Maybe there's some other network virtual appliance maybe? I don't want to use the Azure native functionality. Maybe I'm using an NGINX or something. There are other solutions to do that but saying it's gonna offer a service on the public IP and then distribute it to multiple backends. Be careful about what ports you exposed to the Internet. We're going to come back to that. So if this was about getting outbound to the Internet, well now what I want is from the Internet to be able to talk to my service and so I have to have a public IP. It can't talk to my private IP from my vnet. Again, I could do instance level. I do not want to do. We'll draw it in. So this could be instance. But I don't want it, it's horrible. So what's the problem with doing an instance level? It goes directly to a particular resource, so firstly, I've got no opportunity to add any kind of protection in front of it. The only protection is going to blindly send everything now. Things like distributed denial of service, there's native protection at the vnet to stop huge scale distributed denial of service types attacks. There's also a standard distributed denial of service service I can add now there would be more specific, it would be more tuned, I could do more reporting on it, but outside of that. Everything just gets passed straight through. It would be nicer to have something to be more specific about what it's going to pass through and when and maybe even add like web application firewalls to do some checking. Hey am I trying to do a SQL injection attack? Am I doing saying bad? But also it's going to one resource, it's that resource is down for maintenance. I've only got the scale of 1 resource. I probably want to have multiple back end resources so that I can distribute the workload and So what I really want to think about owning this public IP. Is some kind? Of load balancer. Now remember that load balancer might be providing the outbound as well. There's a standard external load balancer and then what I do is I have a back end set that would have all these members in it when it gets to request because the public IP is bound to the front end configuration. Of the load balancer and this is the back end configuration. It's doing health probing to say, hey, are you there? Only if you're healthy, we'll actually send you stuff. And requests, but it could do checking now. There were different types of load balancer, so remember those layers again. So layer four would be just the regular load balancer. Understand TCP, UDP. I have a certain amount of stickiness. Stickiness is well, if a request comes in, do I always send it to the same back end member? So there's five tuple by default, source IP, destination IP, source port, destination port, protocol. If all five of those things match, I'll go to the same instance. Maybe the port changes? Maybe the protocol might change. Um, I can do things like 3 tuple. So in three tuple it doesn't care about the ports, it just cares about the IPS and the protocol. I can do 2 tuple doesn't care about even the protocol. If I do 2 tuple, the ports can change, the protocol can change, but as long as the source IP and destination IP at the same, it would go to the same back end instance. But it doesn't understand a higher level things like HTTP or HTTPS, it can't inspect the traffic. Cookie based affinity. Well that's what at Gateway does. So the other option is App Gateway. It understands layer seven, it can provide those additional features and if we actually jump over and look at the portal for a second. So we'll just go over to here. If you just search for load balancers. There's many different types, but if you go to this overview tab. Right here. It will help you decide. Has a little set of questions. And it's telling me the different types now ignore front door and ignore traffic manager. These services, we're not actually gonna talk about this. We talk about that more in the resiliency. When we talked about resiliency, I talked about front door and traffic manager, but they are Global Services. Front door and traffic manager will distribute between instances. Of some regional service I want to focus on a gateway. And the load balancer. And it's telling you hey layer four, layer 7. But instead of looking at this questionnaire I can just do a service comparison where it's telling me. And it tells me what app Gateway. Hey look it's HTTP HTTP. S HTTP2 whereas load balancer is TCP and UDP. It tells me how it can distribute what can be supported so load balancer can only point to Azure services. Whereas what we can see is. If I go and look at my. At Gateway my app Gateway can actually point to Azure and non Azure and even on Prem things so it has more flexibility. And then there's some other capabilities. But notice because App Gateway is layer seven, it can do nice things like TLS offloading. So it's got some nifty things it can do. Web application firewall, whereas a regular load balancer can only do NSG. So there's different benefits I get, but I can go through this but realize the real big difference between these is. What is it? Understand. So that's the whole point. And so just to make it super clear, so the whole point of then those these are regional. So these solutions here are regional. They're providing and they've got to be careful when I say that. The service itself is in a region now as we saw at Gateway could technically point to things anyway it wanted to. But the App Gateway instance lives within a particular Azure region. So if that Azure region was there on that App Gateway would not be reachable. But then there are global solutions. And at the layer seven, that would be front door Azure, front door layer four. Well, there's actually the global load balancer now. But then there's also DNS, so there's traffic manager which is DNS based so really would work across any type of service you wanted to. And the whole point is you'd have these global solutions. So maybe I've got an Azure front door for example. So this is my global. And then what it would actually point to are regional solutions. So since Azure front door is layer 7, so HTTP, HTTPS at the regional level I would have at Gateway instances. To then go and talk to some web service, could be containers, it could be Azure app service, it could be VMS, but that would be how I would make that distribution so a global service regional. If instead these were not at gateways, if they were just standard load balancers, I probably wouldn't use Azure front door. Maybe I'd use traffic manager and it's DNS based to distribute between them. Or I could use the global load balancer which is also layer 4 so we have different architectures depending on what are the services we're actually using. So that's how I can talk to the Internet, offer things to the Internet, that that's how those things work. OK. Do not enable RDP or SSH or winrm. To the Internet. It's a great way to test how good your passwords are, because they're going to get hacked near instantly. If I have to offer it out to the Internet. At minimum, use things like defender just in time. What it will do is it will lock down the rules that enable communication to it so that it can only come from your IP address for maybe 2 hours. Or I could use things like Azure Bastion. Azure Bastion is a managed jump box. And it can do authentication using like Azure Active Directory, so would actually go and talk to them managed jump box service which then I would go and talk to the resource within the virtual network and I could use those together. There's different ways I can do it, but don't just go and open up to the Internet and that's a super common pattern. So if I do want to ask you about RDP to my services, where those resources there in an ideal world, remember I'm sitting at some office somewhere. So let's say this is my office. And in my office I'm sitting there on my machine. The best case scenario is I've got a link between my network and Azure. Because then I can just RDP or SSH to the private IP. But it still has of the resource. Great, I don't have to go via the Internet at all. But if I don't have this link, if I have to go via the Internet. Then. Right, there's different things I could do. This is where Azure firewall can do dnat. So Azure Firewall has an IP address that different ports can go to different internal resources. Or if it does have an instance level, I go into defender, I do a just in time. I say, hey I want to connect from my IP for four hours. It would open up a role to allow this instance to work just from my IP just for four hours. Azure Bastion lives in a certain subnet, but it can work for peered networks as well where I through the portal or. With the native tools now connect via the bastion which has a public IP and then it acts as that managed jump box service. I don't have to do it and then I go and connect to my resource. A jump box I'm assuming is a familiar concept. The idea would be if I manually did it, I would create a VM. So I would create a VM. And I'll call it jump box. And that jump box VM would have a public IP. So what I would do is I would first RDP to the jump box I'm now sitting on this machine and then I could RDP to the private IP address. So I'm jumping. Via that box to my target resource, but I have to be super careful about locking this down and protecting it. So Azure bastion. Is a managed version. But it's much, much better. So that's available. To you as well, so that's a useful thing to know about. OK. For the public IP addresses, normally you're taking them from Azure. Azure has a huge range of public IP addresses, it makes them available to you. And you could not bring your own. They have now made it available. So yes, you normally would use theirs. But you could bring your own out if you really wanted to. Now the minimum size I can bring is a 24. That may seem really small. But public IP V4 addresses are pretty scarce, so I have to bring an entire slash 24 to Azure. And the reason is remember what is the Internet again, the Internet are connected routable networks, so anytime I add some address space now the entire Internet. Really that works, but they need to know how to get to it. So I don't want to do onesie 2Z IP addresses. The route tables would get hideous. So instead I want to be able to summarize so Azure will now start offering out say hey if you're trying to get to this range. I'm the target. And again, there's different hops along the way. They aggregate tables. So I don't wanna offer a slash 30 to one IP address, so the minimum is a slash 24 so I can bring my own set. There's a series of steps to do this. It's a multi stage process. Firstly we validate, then we provision and then we Commission. So the validation is checking you actually own that range of public IP addresses so it has to be registered with some standard routing Internet registry, ARIN or ripe you're bringing it, then you provision it. So this is now going to be a prefix. We've been Azure and IP prefix. You then take IP addresses from that and give them to resources. It will anything that supports the standard skew public IP will be able to now use this IP from this prefix you've brought. Once you've done that and you're ready, you're going to Commission it. When you Commission it, what you're doing is now saying Azure. I want you to start advertising that you have this range out to the Internet. It's going to take a while. Azure has to say, hey, this region has it and then the Azure backbone, the Wan has to say to the Internet, hey, we have it. So there's going to be some time it takes to propagate out. But now those services are now being offered from you. So you bought your own IP, arranged to Azure, and it's offering those services. So if you really want to, for some reason DNS isn't good enough. I want to bring something to Azure and it has to be within this particular IP range for some reason. Well, you can now do that if you have to so I can bring my own IP range. OK. Connecting virtual networks, remember? If I have multiple subscriptions, if I'm using multiple regions, I'm using multiple subscriptions and multiple regions. Those two things are the boundary of a virtual network. It cannot span those things. So I may end up with multiple virtual networks. In the past there were ways to connect virtual networks, but those ways. They were ugly, so let's look at what those ways were super quickly, just so we can see how bad they were. So we're going to start drawing under here. I have got two virtual networks. So I've got vnet 1. And I got vnet too. Let's say they were actually in the same region, so let's say they were both. They don't have to be. This doesn't have to be the case for this, but it helps show why this is bad. Let's say this was in South Central US, which remember means they're in San Antonio. OK. And let's say in our example we want to use our express rail, now express route as a private connection. We're going to talk about this, but the way you express route actually works is there's a Microsoft backbone network. Which these basically get connected to because they're going to have a gateway. In each of them. And then what happens is they're saying called meet me. Appearing point. And normally this is where I would then connect my network to it, which would then connect to here. Well, the Microsoft backbones connects. So I might say, hey, I want to connect MY2V Nets together by connecting them to the same express route circuit. That sounds fantastic. They're in the same data center. Is bound to be super quick. The path the traffic will flow is. To the meet me. This meet me might be in Dallas. So even though these the servers that being spoken to each other might be sitting across the data center, they can see each other, they can wave. If I connect them to the same circuit to connect the V Nets together. It's going to route hairpin via the meet Me location, which could be hundreds of miles away. The latency will be horrible. I don't want to do that. So we're going to do our big red pen. This is a :( scenario because latency I mean other regions as well. Latency. I'm wasting the throughput of the circuit. This is just a horrible thing. OK, we said express route, that's not a good fit. What about a site to site VPN? I have the exactly the same scenario. I have exactly the same. I've gateways but this time they're site to site VPN gateways and I'm going to establish. A site to site VPN. To connect them together. Well, remember how does VPN work? Encrypt the traffic expecting it to go over the Internet. Now these wouldn't go over the Internet because they're both in Azure. Even though it might be a public IP, it would stay on the backbone network, but it's still using Ipsec. Ipsec is expensive in terms of computational resources to do the encryption and decryption. So what here is throughput. It's going to be bad, so this is not that great either. So my throughput, the amount of bandwidth is going to be limited. By whatever the skew is of the gateway, because that's how big it's CPUs are, that's how much traffic it can do. So I don't want to do express route to connect V Nets together. I don't want to do site site VPN to connect virtual networks together. So what do I do? What is my answer? Vnet peering. So Vnet peering enables me to, on the Microsoft backbone, just connect virtual networks together. They cannot have overlapping IP ranges, but they can be in the same or different regions, it does not care. There is a small today ingress egress charge, so I pay for the data going out, I pay for the data coming in so that there is a fee that I'm going to pay for that. And again, the IP address space cannot overlap. So what this now would look like in our picture? Is OK. Withdraw the same. Idea of here. So I want to use this picture for some other stuff as well, so we'll say this is being that one. This is V Net 2. And. I'm just going to pair them. And again, there's global vnet peering. There's just regular which would be in the same region. It doesn't really matter. But now this is just going to work, so we'll give this a :) this is the best option to connect things together. But again, when I'm doing this peering, what I cannot have is no I overlap. They cannot use the same IP addresses. I cannot overlap them. But I could obviously connect multiple V Nets together. So we have this vnet over here as well. So we'll call this vnet 3. These compare. Great. Can these talk? This is a very common model hub and spoke. Here's the hub. These are spokes. Can the spokes talk? No, they can't. It's not transitive. So if I wanted these to be able to talk, I would have to explicitly add. Appearing relationship between them. That's how I could make them actually be able to communicate with each other now. It can span subscriptions, it can span Azure AD tenants, but it's not transitive. But they can be. What does that mean? By default. They they have no way of talking via the hub. This is the hub. Well, they're both connected to the hub. There's nothing in the hub that will take a packet from here. And send it to the here for them. This vnet has no reason to think, oh, I should send it to the hub vnet one to be able to get to that. Why would it possibly think that's the thing to do well? What I can do is let's take out this peer I could add in this hub network. I'm going to say I'm going to call this a hub because this gets it's a very common pattern to want to do this I could add maybe Azure firewall. Or just a network virtual appliance that does forwarding. That can accept the packet and send it somewhere else. Personally, so this vnet, hey, if you want to get to Vnet 2 now this, whether it's a network virtual appliance or Azure firewall, it's going to have an IP. So let's say this is IP1. I need to tell this, hey, if you're trying to get to vnet 2. Your next hop. So the place to send your packet is IP1, and likewise this one needs to say hey, if you're trying to get to vnet 3, your next hop is IP1 as well. Notice ain't nice about this. The next hop doesn't have to be in. The same subnet, even within the same virtual network, there's really nice things that we can do because it's software defined network. Normally I could never do that. The next hop would have to be in the same subnet. Doesn't have to be the case here. Hey, next top. Is this appliance over here now? How am I doing this? How am I defining to say, hey, when you're trying to talk to this IP space which is the side of range of bring that too? This is your next hop. Well, the solution is then called user defined routing. So what we're doing is we're creating route tables. So this enables me to override. Or just add to the default system routes. I can go ahead and say hey, when you're trying to get to this thing, actually go this way instead. So if we were to jump back over here. And if I go and look at route tables, so the point is I would create a route table. And so I could add rounds so it might say OK to NVA and it's anything from a set of IP ranges or a certain service tag. And then what is the type of hop? Is it a network gateway? Is it just a virtual network? Is it the Internet? Is it some virtual appliance? Are there NVA or whatever and I would just put in the address of that next top in here. And then once I define that. I would then link it. 51 association. Two particular subnets. So subnets would then use that route table and node to go that path. So this is how we can achieve making them transitive. I have to have something in a network they both connect to that's capable of forwarding packets. And then tell. The virtual network and the subnets hey to actually get to this place. Go to this next hop and it will then tell you where to go. Essentially, is what we're doing here. So this is a a really powerful capability that now I don't have to add this whole spider web. Of peering relationships, I can just use that now there are things like Azure Virtual network manager. And it enables you to do this without using peering, but it has its own back end mechanisms to enable that connectivity. So there are other things and ways I can achieve this and I did a whole separate video on Azure Virtual Network manager, but it's a cool thing. But it does a special type of grouping on the back end that the software defined networking now can help them talk directly. But it doesn't have to actually use those user defined routes, doesn't have to use those sorts of appliances, it does its own. Kind of magic in the middle. But those are definitely things to know about. OK. So I think about connecting to on premises. We have our own locations as well. Maybe we've moved everything to Azure, but likely we have data centers. So many Azure services have external Internet facing endpoints that I could use. Yes, I could go and connect to instance level public IP of a VM. Yes, I could go and connect to my storage account with its public IP addresses. But often I don't want to do that. I'd rather talk to some private connectivity. There are different ways I can achieve that. So the the first ways of doing that is I could think about this a point to site VPN. So it's going to connect to specific device to a virtual network. There's also site to site VPN where it's connecting a network to another virtual network. And there were different types of gateway sizes that have a different number of support for how many networks can connect to it. If it can learn dynamically the IP ranges, there's different sets of functionality around that. So before I go on, let's talk about this. So. We had this actual picture here. Great. But now we also have. I'm gonna forget about those higher networks for a second. Now I also have my on Prem, so if I think all the way down here. I've got my. Location 1. Now it's different to things I could do. Now certainly within here I'm going to have a gateway. This is my hub, so I'm going to use this to talk to other stuff. Now, the first type of other stuff that I might want to use. Would be the VPN. So let's say we're going to deal with the VPN scenario. So on premises I also have to have some kind of N VPN device. And what we're going over, remember, is the Internet. There's no special private wires between them. It's the Internet and what we're basically establishing is a tunnel. So we have this IP SEC. Tunnel. Over the Internet. Now this is a site to site VPN a point to site VPN. So this is site to site. A point to site would just be hey my machine. And only my machine. So if I had individual contractors at home hey they could do a point to site so I can also do a point to site VPN connection here. And this works. I mean it works fine. There's different SKU's have different amounts of bandwidth they support. I think it's 2.3 gigabits per second is the highest per tunnel. A single gateway can support multiple tunnels to it. Now the aggregate it might be 10 gigabits per second for the high end skews. But a particular IP SEC can only be serviced by particular core virtual CPU. So any one tunnel is restricted based on. The capabilities of the processor. Now it does actually open up a few different architectures. If I think about high availability now, I drew one location. So let's say, OK, I've got my VPN. And then we've got the Azure side, so we've got the Azure Gateway. And it could absolutely be just this. It could be. This now Azure actually always deploys 2. But this one might be standby. So this is always active. This might be active or it might be standby. You can control that, but maybe it's that configuration. Or maybe I want it to be active? So my next option I could do is from on Prem I'll connect to this one as well. So over redundant connection. If there was some problem on this, these are VMS behind the scenes saying it happened to this one, it could fail over to this one. Fantastic. Maybe I have multiple VPN devices on my side? Could it be different locations technically? And maybe my path here is. Well, actually I'll connect to this one. From both my locations. Well, maybe I connect to all of them. I can have a little bow tie, so there's different levels of resiliency I could do. I could make the Azure site and I can do the active, active on everything except, I think, basic and standard on the Azure side of the VPN gateways. And it's my choice if I want to add multiple VPN gateways on Prem. But now this is very resilient. This resilient against the failure on one of the Azure side, it's resilient against the failure on my side. So I can bring those in to have a more resilient connection no matter what might happen to those. But it's coming over the Internet. And going over the Internet means, well, the latency between these connections. It could vary. Because it's the Internet. It's not going to be a set standard latency, it's just there's going to be some variation. So next thing we can do is express route. So express route there's different locations and I've got the links in the description below of the video. There's a big Microsoft backbone network, and what Express route does is there's different types of peering. So there's Microsoft peering. Microsoft peering lets me via particular route tables. I can say, hey, I want to offer. Microsoft 365. That's a bad example typically, but I want to be able to offer these other Microsoft services that typically accessed via the Internet through my express route connection. But more typically what I'm going to do is private peering. So private peering, it's connecting an IP space I define for my on Prem or even maybe another cloud. To the IP space of my virtual network. Now the way this works is I'm leveraging that backbone network, so let's just carry on. Most enterprises will use express route if I'm a major user of Azure. What I really want to think about is Azure just becomes an extension of my IP space. I don't want to think of it as these different thing, I want them to just have this free flowing IP space. And yes site site VPN does that but companies a don't like the fact that goes over the Internet even though it's encrypted, it is safe. Companies don't like it. And also this variable latency. So what we have is this idea that there is this great big. Microsoft one. It's backbone network. And every Azure region is connected to it, redundant connections to it, so I can also think about hey. Um. Region 2 that was in Region 1, so I've also got Region 2 for example. That's got redundant connections to this Microsoft backbone network as well, and they extend this backbone network to other locations. So one of the things you'll actually see is this idea. Of these carrier neutral facilities called peering points. Might also hear them called meet Mees. Meet me here. Remember you had your network. Well one of the things I can do is I can have a connection. To the meet me. Which now connects your network. To the Azure backbone. Maybe it's not this, maybe I actually have an MPLS. And all my locations hang off the MPLS. Well now the MPLS connects to this meet me and in the middle here there's magic that does a cross connect between them. So now again my network is connected and then what I do through express route is from this gateway. So here. I have express route. Private. Appearing. This IP space. Is now. Connected to this IP space. That's what private peering does. Have this private connection. I've connected this space together. Now this gateway here is now an express route type gateway. I can have site, site, VPN and express route in the same virtual network. Express route would get used first. And then maybe VPN is a a failover expressed route went down, it could fail over to the site to site VPN. I can even run site site VPN over the express route which you might think why? Well remember site site VPN is encrypted. Express right as a private connection. It is not an encrypted connection, it's private wire. Generally we don't worry about that stuff, but if you really were worried I could run the site site VPN over my private express route private peering to then encrypt the traffic inside there is called Express Route macsec which encrypts but it only encrypts at the meet me. So it's that. Space of air at the meet me between your router and the Microsoft Enterprise Edge routers that then go and connect. It's that because what's actually happening in here is there's two Microsoft Edge routers that you get 2 connections. They run in active, active. Normally there's maintenance, there's a failure and reduced to one. But normally I'm connected to two different Microsoft Enterprise Edge routers at this meet me that connect to my edge. Ordinarily, this connection is provided by some provider, AT&T. Whoever that is. Microsoft don't provide the last mile. I the connection from the meet me to your location. You work with some provider there is called Express route direct. So we've express route direct. I'm a really big company. And instead of relying on the provider to provide that last mile, I'm doing it myself. I'm dropping my own fiber, I'm dealing with levels of light. I get let with authorization from Microsoft. So at the meet me they connect my router into the Microsoft Enterprise Edge. And then on top of that I create circuits of various sizes. So there are ways that I can do that, but generally that's really big companies. I could buy a 10 or 100 Gigabit per second. Ports and then fill it up with circuits on top of that. So I can absolutely do this as well. Now realize from a resiliency perspective I might have multiple locations, so maybe this is, I don't know, E US. Maybe this is Europe. So I might have another location over here. When it might have a connection. So this meet me, which primarily uses this region. But absolutely I could still have the ability to have connections so a single gateway can connect to multiple circuits. So I might have a different circuit over here, but this gateway could have a connection to both of them and maybe I've got some connection between them so I can still get to this location. My network here could get connected to both of those gateways because maybe they're needs vinets appeared. Because I remember I don't want to use the express route to talk between my virtual networks, so I would probably have peering. Between my ultimate vnet that I end up having over here with its gateway and all of that stuff. So I could add certain resiliency by hey, this gateway actually connects to a circuit here and a circuit that lives there. So it's got different paths. And likewise, this would connect to both of them. So it has resiliency. So that same bow tie we saw here. I would have here, hey, this connects, this connects, that connects, that connects. And there's things I could do with preference. There's things I can do with proper path length. There's a whole set of hops that go on here to make it use the preferred one where it can. But there's some problem how you it can fail over. The exact number of connections does vary depending on my standard or my premium. Premium add certain functionalities. For example, standard I can connect to regions within the same geopolitical boundary. But if I do premium, I could have a circuit in the US but go and connect OA region in Europe for example. Premium also lets me do Microsoft peering, so there's other services. It also lets me advertise more routes over the network. It's more than standard. You never ever pay for Ingress. So network traffic going into a region, so that could be coming from express route, it could be coming from the Internet, you never pay for Ingress. So if I think about all of the scenarios we talk about wherever I am on all this picture. So one thing I should point out here so ingress. To Azure. So if this is the Internet, if I draw Azure for a second. Ingress. Is free. That could be ingress from the Internet, it could be ingress from on premises. Doesn't matter, you don't pay for ingress. Egress so data leaving Azure. You, absolutely. Pay for it's going out to the Internet, it's going out to express route, it's going out to site VPN. You pay for data leaving. Azure they don't charge you for it's coming in because it's going to get stored somewhere, you're going to pay for it. For services, you just pay for it going out. The exception to that is on this express route there's actually sent called Express route local. Now if we went back for a second and looked at locations. Come on, open up. So these are all the points where they're appearing points. And there's different this one, so there's different locations all around the world. We can see here lots and lots of them. And. They operate by different partners. Different partners can see that second column of the partners to operate that last mile and provide that connectivity. But you'll also see there's this 4th column local Azure region. So if you buy a local. Skewed so at the top here expressed route local. I don't pay egress. But. I can only. Talk to its local region for that meet me location. So that's the whole point. If I use express route local. Whatever region is the local region for that meet me location has the only region I can talk to now don't pay egress, so when the date is coming back to my on Prem I don't have to pay for that. But I can't. Talk to this other region over here, region 1. So I have a choice express outstanding, hey, so if I think about the different, I guess the the boundaries of this, I can think of local. Well, if you think here's the meat me. So we've local it's only. That local region. So that's my boundary. For local. Then I could think about. There's the standard express route. So then it's the other regions. In the same geopolitical. Boundary. Eg kind of North America. So that's what express route standard would let me do. But the whole point of remember again if this one. Is it's free egress? And then finally, we have premium. Which? Is global. Any region all throughout the world. So there's different sets of boundaries I can think about. And obviously I pay more, I pay more for premium than I pay for standard, also get those additional routes plus it's it's more routes. I can also do Microsoft peering. But there's additional capabilities. There's different types of express route depending on exactly what I need. Now even for regular express route, there's metered and unmetered. Our meeting means I pay based on the amount of egress I do, which is what most people want. There is also an. Unmetered one. So the unmetered. I don't even know if I have that here. I don't think I do. Let's see if I can get to it from here. They there is an unmetered. Um, but it it's really expensive like so these are the types of gateway you can do and they talked about. Remember the number of circuits that I can connect to from the gateway to depending on the gateway SKU and there are availability zone redundant ones available to me. I can bypass that. But let me just see if I can. It's just through pricing super quick. If we look at express route pricing now, it says the metered plan. So it's charging me. Notice there's no. Outbound data included. So I'm going to pay for the amount of data or there's an unlimited. Data plan. Where it's unlimited. Outbound. It's always inbound. Inbound is always unlimited, even on the metered 1. Inbound was unlimited. I don't pay for the inbound. But notice the pricing. SO50 megabits per second was $55 for the unmetered. Doesn't even exist. So one Gigabit per second, sorry, standard, it's $300.00, so it's $300. Instead of $55. Because it's not gonna bill me for the egress. And then we have these local options as well. So different things available and again that Express route direct is there as well. Have all these different capabilities that we can leverage depending on exactly what it is I need to actually do. There's also like called global Reach. I'll just, I'll touch on that quickly. I have two locations, not one of that one. And normally they might have their own network, they can talk to each other, but maybe they don't. Maybe that networks down, but they both have connections to meet meets and they both have this Microsoft backbone. So one of the things I can do, I'm running out of colors. I think we'll do, we'll do yellow. Is I can actually set up? Over the Microsoft backbone via the meet me is. Global reach? So what global REACH is doing is connecting my on premises locations. By the Microsoft backbone via the meekness. It's not bouncing via region. Hey, I'm now connecting my networks together via express route. That's what that does. OK, now there's anchored express route fast path. Ordinarily with private peering, you have that gateway, and that gateway does a number of different things. A big job is BGP. I've not talked a lot about this because really it's it's a more complicated concept to do. But if you really think about the way all of this works, especially in these scenarios, it's about learning routes. It's about learning, hey. Well, this location, that location is really defined as a certain cider range. Side of five, it's a set of IP ranges. Well, this network has to learn. Oh OK well if I want to get to this set of IP ranges, my next hop is this gateway. So this network has to be able to tell the Azure vnet what its IP addresses are and the paths to get there. And there are things I can do with peering. That can leverage this. So in this peered scenario, these spokes can actually use this to get to the on Prem networks. I can configure. On this side of the pier. Allow Gateway transit. On this side I can say use remote. Gateway. Listen now what happens is. This has to exchange tell this network about this IP space all the way down here. How does it do that? BGP borderless gateway protocol? It's about sharing IP ranges and details about how to get there and so the whole point is that. This gateway, when it talks to express route, it's acting as part of that BTP. Now again, it's redundant. There's active, active, there's two BGP sessions to exchange the various routes to do that, but it's gateway is critical as part of that BGP, it's also called route server. I didn't talk about it. But these route tables I have to do this if I have network virtual appliances that talks to some IP range. When I have to use UDR to say, hey, this IP range that this network virtual appliance talks to, it's the next hop for it. What's it called? Azure route server? Azure Route Server runs the service, it acts as a BGP target. So my NVA can now talk to route server and say hey I'm talking to this other IP range, make the vnet know about it done. I don't have to do udrs anymore and again I've got different videos. On route server. So there's tons of amazing, clever, cool stuff. There's just so much it becomes impossible to try and cover all of it in the one video. But the point is. It does that the gateways responsible for BGP. But it's also part of the data path. Hmm OK, so as part of the data path. The traffic, actually. Goes via the gateway to then go and get to whatever the target VM is. Or maybe it's over some peered connection. It's really not ideal, but it's a little bit required because if you think about the networking and the software defined network that's going on. There's these physical addresses, provider addresses of the physical hosts that are in the Azure data center. Then have this software defined networking set of customer addresses that are completely abstracted away. Well, that Microsoft Enterprise Edge router has no way of knowing how to possibly get to some VM IP3 on a customer's virtual network. So the. The gateway and the V net does that, so it's part of the data path. Well, there's a feature called fastpath. Fastpath actually removes this bit. I still need gateways. I still need gateways because I still have to do this bigger stuff, but the gateway gets removed as part of the data path now. Those instructions, those how do I get to this VM actually gets pushed down as part of the Microsoft Enterprise Edge, which is why there's a limit of how number because these are physical pieces of equipment. Now there are some features that are limited. There were some that in preview as part of this if we go and look at the documentation about it. It tells us, well, hey look vnet peering is in preview IE I can bypass the gateway to talk to things in a peered virtual network like those smokes user defined routes. OK, that's in preview. Private link connectivity to 10 Gigabit per second Express route direct will that's in preview as well and it's only for certain services we're going to talk about private link. So the point is here, not everything is supported for it. But. I mean, a lot of the things are. There's a lot of capabilities that I can actually do with this thing. So we're fast. Part of the whole point is it's going to improve the performance. Now it says ever a problem with fast path, it will fall back to using the gateway and then as soon as it can it would adjust and start using the fast path route again. So it may disappear. You wouldn't know anything about it, you would just see a slight drop in performance. Now it's only going to actually be available for the higher skews of the gateway. So it's the ultra performance or the ER Gateway 3. So I have to have a top tier gateway to be able to do fast path because again, it's having to do a lot more work now on that enterprise edge. So it's trading one thing or another. Things like the basic load balancer that's been deprecated anyway, but. I don't think that works with fast path either, but again, if it can't work with fast path, it will just fall back to use the gateway. As part of the data path. Controlling the traffic flows. So as we talked about already, by default within a virtual network, traffic can really just flow by default. I can just go and talk outbound to the Internet and I'll only get a stateful response back. Doesn't let anything else in. Bit of a response to saying I've sent out will come back. But I want that maybe I actually want to control the type of traffic and there's different approaches to this. He was asked a firewall. So Azure Firewall is a managed network virtual appliance provided by Azure. It's VM scale set based. It will auto scale and it can go and inspect the traffic. In fact, let's have a quick think about that. So let's go back over to here for a second. I'm going to draw a virtual network a lot of times, so if I have a virtual network. And remember, we break it into subnets. This isn't my vnet, this is my subnet 1. Subnet 2 wouldn't be called Subnet 2, which is a different discussion. One of the things I could do is I could deploy Azure firewall. I said it won't be called subnet 2 because it actually has to be called Azure Firewall subnet if I remember correctly. So we'll actually be called Azure. Firewall. Subnet. This is a managed appliance or I could just have some sort of network virtual appliance. But the whole point is Azure Firewall does a whole set of different things. It has rules. So I define rules and they can be either application rules, application remember means it understands layer 7, HTTP, understands URL, understands fully qualified domain name, or it could be a network rule. It's layer 4. But it also has rules, for example for that did net incoming. I'm going to send this port to this particular target. It has things like intrusion detection, it can crack open HTTPS packets for the premium SKU by injecting itself in the middle of the conversation and it will give out a certificate to the client because the client has been configure the trust it so it can crack open and actually look inside the TLS traffic. It can do filtering. The basic can do it based on fully qualified domain name. The premium can actually do it based on the full URL. It can look at the path and then use that as part of categories as well, it says. Core sets of stuff and there's even more I can do with the Azure firewall and the whole point. The way I would use this is how could I make remember this has an IP address. How can I make traffic go via the Azure firewall? What's the solution to that right? So route table? I'd have route tables, UDR, user defined routing in all of these. That basically says you might just say everything. If it's going on the Internet, it's going to this network. You might say pretty much everything, everything goes to IP1, and I'd repeat that. So all traffic would go by the Azure firewall. And then it can control that flow of the traffic. So that's how I could restrict and control the flow. Azure Firewall, that's an option. And there are those different skews. Actually go and look super quickly come open up. If we look at the documentation, it talks about standard and premium and there's this basic skew. So standard is really focused around, Yep, I understand fully qualified domain name. I could look at server name indication that's in the flag to understand even if it's HTTPS. But then premium add with other stuff TLS inspection. Intrusion detection prevention. URL filtering. So actually look at the path at the end of the fully qualified domain name. I have categories based on also that URL. It's not just based on the fully qualified domain name. So a certain site may have gambling and news. Or I could say you can look at the news bit, but you can't look at the gambling bit. So I have different sets of functionality and then basically just defined to be for a small medium businesses that just need some very basics of functionality and obviously a reduced price. So that's the goal of those solutions. But my other option is using network security groups. And then there's an add-on called application security groups, and then there's these things called service tags. And the whole point is. I'm going to link this to a subnet. Now I can link an SSD to a Nic as well. Don't do it. It gets horrible to manage. It's not really buying me any benefit because they're all enforced at that virtual filtering platform on the hyper V switch or it's been sent down to the Nic. If I'm using accelerated networking. Doesn't buy me any extra security to apply an NSG at subnet and a Nic. It's not doing too levels of protection. It's in the software defined networking, so just do it the subnet. It's going to be much easier to manage and they're made-up of rules based on IP ports actions. And then application security groups that we build on this by. Maybe IP is too rigid, maybe what I actually have is things that are in different subnets, but I want to classify this as a domain controller. Or this is an IIS server. This is a SQL box and control it based on some tag on the network interface instead, so I want to be able to do that. So here. What I'm going to define. Is the network security group, so I'm going to create an NSG. And again, my NSG is made-up of sauce. And destination. Protocol. Pooped and then action allow, deny and when I think about this source and destination, they could be cider ranges, so sets of IP addresses. It could be a service tag. Now what's a service tag? There were many services in Azure that are obviously lots of IP addresses. So Microsoft know which IP addresses are used for storage, which are used for SQL, which are used for Postgres. I have no way of really knowing or keeping that maintained. That would be hideous for me. So Microsoft do is it maintains service tags which represent the IP addresses used for a certain service whatever and I can use those. And if we go and look super quickly. If I was to just go and look at. NSGS. So here, I'll just pick one. And I can see there's inbound. Now there were default rules and if I look at the inbound rules. If I hide the default rules, three of them disappear. So by default it allows all communication between things in the virtual network to the load balancer, but then it denies everything else. So we can see these actions allow and deny outbound. Hey, anything can talk to the virtual network, anything can talk outbound to the Internet, everything else is denied. Then I can add my own rules and when I add my rule. I have my sauce so it can be IP addresses, a service tag. And again, there were service tags for all these different types of services, and it can be just the IPS in a certain region for that service. So there's a lot of different breakdowns I can do for that. And then hey, what's the destination? And again, what particular service it might be? Is it I? Is it a service tag? And I just add those rules and then once I define those rules, once I've created the rules. What I would then do. Is I would associate it. To a subnet. Which would then enforce those rules. Now you saw the idea of an application security group. So what's an application security group? Well, an application security group. It's really just A tag. That's all it is. It's a tank, so I might call it SQL, I might call it IIS. I might say quarantine because that's an interesting one of the things I might want to do is, hey, if I detect some issue, tag the network interface card because I apply the ASG. To the nick. And then I could have rules in the network security group. Hey look, if the tag on this is quarantine, don't let it talk to anything except these certain resources that can heal it. But then I can use the application security group as you saw in the rules. So I just create these tags. If we go and look. So you already saw what I could use them, but I just defined them. So application Security Group, it's has to be in the same region as the NSG, but I've got one here called SQL VM, I could create another one. So here I would just put in whatever the name is and it has to be in a region. And then once I've created that application Security group I can just assign it to a particular Nic. So if I went in here not to the networking, you'll see I have this concept of an application security group tab on the Nic of the VM. Well, I could just go and add. Any of those application security groups that I have defined, then it would be used by, hey, any of those network security groups. So that's another way I can think about actually controlling. The traffic. So, and this is really powerful and it doesn't have to be either or. I would absolutely use this with Azure file or Azure file members. Got those richer sets of inspection? It can do more flexibility, but maybe some core sets of control, hey, I'll use network security groups for that. I don't have to just use one or the other. Azure virtual Wan. So if I think about, I drew some pictures and my pictures were actually maybe a little bit scary. If we go back to our whiteboard for a second and we'll zoom out as you this hub with spokes, with gateways and maybe transit and maybe virtual appliances in there, it's like, ooh, that looks pretty horrible. I would never ever want to do that thing. Well, sometimes you want all of the control, you want all the responsibility, you want all the flexibility of what you can actually define. But if you don't, if I just want the service provided to me. As Azure virtual web. So if Azure virtual Wan, what's going to happen is it provides managed hubs per region. So I create an Azure virtual Wan in each region I want it, it creates a virtual hub. And then? It's different skews. There's a basic and a standard and really basic only support site to site VPN coming into that hub and then I connect V Nets to it. That's it. With the standard it supports yes site site VPN, but also express route private peering. It enables the transit between the V Nets, enables into hub connectivity. It has a whole bunch more stuff. So if we go and look at our picture, what I now would think about creating is I just create. And Azure Virtual Wan instance. I'm just going to create one of them. But then remember, hey, maybe I'm using multiple regions to region 1, region 2, region 3. For each region it's going to create a hub. Now when I draw the word hub, this is a managed virtual network, so this is a vnet with stuff in it. But I don't have access to this directly. These are managed hub virtual networks. And remember again in the basic SKU all I have is that site to site VPN. So if I think about my options for this. Basic. I can do a site to site VPN. That's all I can do. So they're not even really, there's not into hub routing between them. And then what I do remember is I then hey, I have my V Nets that I create. Etc etc. And I'm going to peer them. I create a peered connection to them, but then I also can add the idea of point to site VPN, Express route private peering. I get that, inter hub, I get transitive. Or with the premium? So it's not premium, I get my native terms, it's standard, standard. There we go. So with the standard now. Hey, there's connections between these, there's into hub, these could now talk and obviously other things and offices can connect in as well. So I have all of those different capabilities with the different skews, so. Virtual Juan, Super powerful takes away the emphasis on me for having to manage and deal with those things. OK, service endpoint, service endpoint policies. We already talk about network security groups. Network security groups can control from the vnet what I can talk to what types of service with the service tags remember would let me say, hey I can't talk to storage in this region and what I can accept from, but what about on the service itself? Maybe on the service on the storage account or the MySQL database? I only want to be able to talk to a particular things in a particular subnet and as she don't let me do that. So NSG is a great, they're focused on the traffic into and out of the Vnet, it's focused on the vnet side. Most of the Azure Paas services have their own firewall. I can do rules in terms of IP addresses and many other things to lock down. And I might want to only be able to talk to that storage account from things in this particular subnet. So service endpoints let me make a certain subnet known to a certain type of service so they can allow it on their firewall configuration. They can then have also an optimal path to actually serve it up. And then service endpoint policies, let me then restrict on the subnet. You're only allowed to talk to these instances of the service. If I think about data exfiltration, hey, I can go and connect OA good storage account with important data and I'm a bad person, I want to go and copy it to another storage account. Service endpoint policies let me control. Which I'm allowed to talk to from this subnet, so I couldn't connect to the production storage account and my nefarious storage account so I could try it and copy the data. So let's let's think through what this looks like, and again, we'll draw another. Another virtual network. So many virtual networks. So. It was slightly smaller one, so we have my vnet. Mean that one? And what we have now is we have some service. It's just storage account. It doesn't matter, these are very similar so storage account one and the whole point. Remember is most of these services have. A native firewall. And it can lock down and it can restrict things, so it could restrict things based on IP addresses and other things. But what I want. I want to be able to say hey, I've got this subnet. Subnet one. And what I want is to only be able to things that live in this subnet. To be allowed to talk to this storage account. So on this firewall I want to say only let this subnet. I can't do it based on the IP range because remember this is all private IPS. It has no clue what some internal IP range is. I have to be able to identify the subnet. So what I'm going to do is I can add a service endpoint. So I'm going to add a service endpoint for storage. It now makes this subnet known. To storage services and it's going to be an slightly faster route. Then what I can say is on the firewall configuration, I'm going to say yes, allow in. Vnet 1, subnet 1. But not other things, and we can see that. So if we jump over. Firstly, if I looked at my virtual network now, I don't actually have to do this in advance. If I was just to. Go and create one of these. Rules it will say, hey, this subnet doesn't have the service endpoint, should I create it? But let's say we're ahead of ourselves. We can see service endpoints. And we can see I have added it for storage. That's super easy. We have the drop down. I could select other services that I want to enable service endpoints 4. Then on an instance of that particular service it has to be. The same region. So now we pick this one. And I'll go to its networking. I want to enable it from selected virtual networks and I ranges and here I'm going to say add an existing virtual network. I select the virtual network. And notice there's my subnet. And it doesn't say service endpoint required. These other ones do, so didn't add it, it would go and add it for me. But I could now just check that box. And now the firewall on this storage account would only allow things in that particular subnet to talk to it. So that's a really nice capability. That I can do there. But the challenge still. Is that that virtual network? Could still talk to others towards council, could still do data exfiltration so the other thing I can create. Is a service endpoint policy, and the service endpoint policy will basically say, hey, you're allowed to talk to storage account one, you're allowed to storage account two, and then I associate it. With a subnet. So now this this subnet. Things in the subnet can only talk to storage account one and only storage account two they couldn't talk to storage account three. So what this does is this stops data. Exfiltration. That's the whole point. I'm limiting. I can't bring it from storage account one and then copy the storage account 10, my evil storage account. I can't do that anymore by adding in that service endpoint policy. And we have private link. Thus far, all of these services. Actually have a public IP address, so it's really when I'm drawing this connection. This connection is actually going via some Internet based public IP. So this is actually got this firewall is fronting a public IP. Now when I'm on an Azure resource, it doesn't actually bounce out to the Internet and come back, but it's still a public facing IP. It's still there on that resource and maybe I don't want that. So what private link does is. I want to lock it down so now I get a privacy endpoint in my virtual network. In my particular subnet it's just an I address that represents that service. I could also have my own services sitting behind a standard load balancer and we'll show this. Anything can interact with that IP address. So I could be on a connected network like on premises. As it has a path like Express route private peering or site site VPN, it could use that IP address. Because it is instance level it also helps with date Rex Filtration because now I could say hey, I only have private endpoints to these two storage accounts and my network security group could block. The service tag for storage. Because maybe the private endpoint is not in the IP range of that, so then I can still go and get to them. This also can solve the problem. If I want to use a service from a different virtual network, I don't have to peer them anymore. So let's look at this. It's a great this was service endpoints and I can use service endpoints and I can use private endpoints in the same subnet if I wanted to. But now the scenario is. What color should we use? For private endpoints we use light blue. I'm now going to add. Private endpoint it's just an IP address. But it now represents a specific instance of storage, it's storage account one. Because this now exists, if I wanted to, I could actually. Turn off the public IP. I don't want it. No one can use the public IP. I can only use the private endpoint. That is some other things that have to happen here. There's some changes to DNS. So DNS basically. Now hey, if I want to talk to storage account one, actually you need to talk to this private endpoint IP address. Now that's simplifying it massively. What actually happens is when I talk to BLOB, there's a storageaccount1.blob.core.windows.net. So let's say it's normally storage account one dot BLOB. When I turn on private link. It now becomes an alias to storage account one private link. Dot BLOB. Dot core.windows.net which then that resolves to private endpoint one. So that's the magic that actually makes all of these things really work together. So that's a private endpoint, and I've got one of these in the environment so we can see it right here. I've created a private endpoint for BLOB. On this particular storage account. So my private endpoint, if we look at it. Is the target resource is BLOB? Now it's gone and done. All the DNS configuration for me is integrated with my standard zones and we can even see it's created this private link. Dot blob.core.windows.net so ordinarily on this storage account. Just come and look. We look at the end points. Let's look. Get away from there. If we don't talk BLOB, it would be this. Storage account name. Dot blob.co.windows.net now if we looked at that VM I have so this is in the vnet that's using that if I didn't nslookup. On that storage account name. Another thing interesting, you can see it's now alias to a private link version of the zone and it resolves not to a public I to that private IP address. Of the record. So now when anyone talked to BLOB, it's going to go talk to ten 2.5 which is the IP address. If we look at private link, so there's different ways I can actually interact with this, but if you look at private link it's a nice view. And my endpoints there. 10.10 dot 2.5. And that's just a regular I. If I was to go and look at my virtual network. And I looked at connected devices. It's just a nick. It's just a nick. So anything connected to that could actually use now could be on premises, could go and use that private endpoint. So that's fantastic for Microsoft. Paas services, storage accounts, Postgres, Cosmos. What about if I had my own virtual network? And I have my own resources, could be VMS or AKS node pools. They're sitting behind a load balancer. And I want to be able to use it from this vnet. Now I could peer them. But what about if maybe they got this overlapping IP ranges? I can't peer them, I just don't wanna peer them. I'm a SAS provider. I want to be able to provide this. I don't want to peer my vnet with the customer. Well, I can add. A private link service. And then? I can just add a private endpoint that goes to my private link service, and what private link does is network address translation anyway, so it abstracts my IP range to whatever this actually is so I can do my own services as well. Ohh, this is really powerful. This is replacing service endpoint most of the time in all honesty. People tend to use this now. There's a cost, there's a cost for creating a private endpoint, there's a cost for the traffic over it. But it gives me a lot richer set of functionality when I compare it to for example the service endpoints. OK. One thing. Was this the DNS? I was like ohh as DNS record that there's zone that's set up for private link that points to this IP. Where? Where is this mystical DNS? Now? Technically I could host this myself. But the better solution, and what we would normally do is we would create an Azure private DNS zone. Now again, it's just a record. I could absolutely just create this on my own DNS server and manually add the records, but it's just a little bit. Of a pain to do, I'd rather use this private DNS zone. So we get the DNS in Azure. A virtual network is configured to use certain DNS servers. Now there is a built in Azure. DNS. That just fingers by default will use. So it's this special IP address within the network that will just get leveraged by it. It's 169, no sorry, 168.63.129.16 and that will provide IP resolution or. I can define my own. So if I think back to this picture for a second, if I'm just going to come over here. Space do I have OK? So come over here. So we'll draw another virtual network again. I'm going to get Lazier and lazier drawing these vignettes. So for the DNS I have a choice, there's Azure DNS or I can configure custom my own DNS servers. If I use the Azure DNS, what it's really pointing to is this special IP 168.63.129.16. Or I just have my own ones? And then what that does is obviously looking at records. Now there's certain just built in records. That I always register and I might want to create my own one. That is really two types of DNS I can think about. Well, there's public DNS. This is where I go online and I look up youtube.com. Well those zones have to be available to the Internet and I can create Azure DNS zones so this will can go and look up against public zones so I can create those in Azure. I great Azure Public DNS zone so I can host it. Obviously it has to be authoritative for that zone. But I can create IPV 4 and IPV 6 host records. I can also create alias so Cname records. But those are the records I create that's really limited to those types of records. They are global resources. So when I think about these, these can be used in any region anywhere. So that would be public facing. Then we also have the concept of private. I have some zone that's going to have records in it that I don't want to resolve from the Internet. I just want them to be resolvable from one or more virtual networks. And So what I can do is I can create these private zones and then what I do is I link it. To a virtual network. Now when I link it, it's actually two different types of things I can do. So when I create resources I talked before about, it gets an IP address dynamically and maybe I want its host name to get registered. So there's something when I do this link I can configure the link to be auto registration. Now from a vnet it can have one private DNS zone they will auto register with. So when these names. It will go and create a record. So if this was saddle Technet and this was called Bob. It would create a record called Bob Savilltech net with its IP address it got. It can also be linked for resolving up to 1000 private DNS zones. So savilltech.net, savilltech.com all these internal things. BLOB private link dot core windows net. That could be a private DNS zone as well, so we drew that picture of that private DNS zone. That's a great use for actually using a private DNS, and each private DNS zone can be linked to up to 1000. Venus. So I can use this by many things so I can have one zone, but I could also link it. To my vnet 2. It could get linked to the same so they have the same resolution for example. For whatever the content is within there. So if we jumped over to the portal for a second. And one of the really nice things actually look at the public DNS first. So if we looked at just regular DNS zones, one of the challenges you can get with DNS. Is. You can get this idea where it becomes dangling. And what dangling would be actually talk about Super Super quickly is normally when I create a service in Azure. It has a name, but the name is not very pleasant. It might be I'm just going to click name Azure service. It's going to vary.windows.net, whatever that might be. So that's the Azure name. I don't want to give that to my customers so I would probably on my DNS I might create ohh. App dot savill tech. .net and I would point that so I could create like a cname record in my DNS to this Azure service name. So far so good. Time passes and I retire this service. I delete it. But I forget to delete the alias, so right now there's alias resolves the same that doesn't exist. Not a problem until Mr. Bad Guy comes along. And because this is just an Azure name. Bad guy creates a service called the same name as I did dot Azure. Also. Now my cname points to their service because they just took over the name because I forgot this was a dangling DNS. That's a risk. There were some things being built in to Azure to help resolve this, but that's a real problem. There were bad actors out there that are going looking for dangling DNS and they'll try and create the name. That this used to point to and then try and get people to use this because you're gonna trust it and it's not trustworthy anymore. So my whole point here is one of the nice things that I can do with the Azure public DNS. It's rather than being an alias to a name. If you look at these bottom records, what they actually point to? Ohh Azure services. So it automatically points. If I deleted the Azure service, the alias would just stop working. It's not dangling, it can't be taken over by someone else. Now if I jump over to my private DNS zones. So remember these would not resolve over the Internet. The whole point of private DNS zone is I would link them. But notice what I have here is I have 1/4 that private link privatelink.blob.core.windows.net and the records it added it for me so I didn't have to manually create this, it just resolved it. So this is a really nice really powerful feature. That private link and the Azure private and sons working together just provide this for me. So that's that's a real nice capability. So we get all these different capabilities, I link them to different V Nets and I covered all of that. There is also a private DNS resolver service available and just to talk about that at a high level. This is great. Azure provides this DNS server for me OK, but I still have maybe my on premises network, so give yourself a bit more space. So I've got my on Prem network. It would like to be able to use this private DNS zone, but it can't because it's only available via this 168.6312916. So the only thing I could do is I could add a VM with a DNS forwarder in here and point to that, which is an option. I can definitely do that, but my other option now is there's this service. The private. DNS resolver and it does two different things. So I create it. When I create it, it links to a specific vnet. Now in that specific vnet, there's two things it can do inbound. And it can do outbound. I don't have to use both, but if I do, I need a subnet for each into which you can create endpoints and inbound endpoint and then outbound endpoint. So I create this private iness was over and I create an inbound and outbound endpoint. I could have all. I could have both. The inbound endpoint is just an IP address. It's an IP. And why this is Nice is that now other networks could point to that IP address. So from on Prem, my DNS servers could conditionally forward for blob.privatelink.core.windows.net. So I don't have to manually create records, I can just point to the private DNS resolvers in bound endpoint. So from my DNS on Prem. Just got an IPO of four. It could have a conditional forwarder that now says hey for BLOB dot private go to IP1. I've got site, site VPN or private link private peering. There's an IP path, it would now use it. Fantastic. Let's solve my problem. There's also a second challenge that sometimes from Azure DNS I want to conditionally forward to a zone that's hosted on a custom DNS server, and I can't do that. Well, now I can. In private DNS I can create forwarding. Rule sets. Which I can say hey to get to zone. A. You have to talk to DNS servers IP4. Now it has to use an outbound endpoint. Why? Private DNS was over. Is this floating service out there in Azure? It has no actual network. It needs to go and look up these IP addresses for you. It's not just going to tell you go and talk to IP4, it will go and talk to IP4, resolve the record and return you the response. So it needs a network path to get to IP4. That's what the outbound endpoint does. It uses this to go and IP talk to this DNS server to do the lookup to return you the response. Now once I've set this up I could use this. The same vnet 5. I can link this. This rule set can be linked. To other virtual networks this bring. It doesn't need an IP path to this planet or this server, but it could now say hey nslookupname.zonea.com. Azure DNS. Because it's got the forwarding rule set, says OK, I know that. I'll go find my outbound endpoint, talk to it, look that up and I'll give you the answer. So that's what a private DNS was overdue. So it's two things. One. It's a target to my DNS. Can now query against records in private DNS zones. But also, hey, I've got other DNS zones on custom DNS so servers. I can now tell Azure DNS go and talk to this DNS server to be able to look up records for me. So that's the private DNS resolver. So we covered a huge amount. I didn't even get into things like network monitoring because there are phenomenal network monitoring. Network Watcher provides functionality to hey, can this packet get here, capture these packets, do an actual connectivity test, do traffic analytics, show me a nice map of all the traffic flowing? There's there's just so many different things, but just because the time I had to limit it. But that was our networking module. And as always, I hope that was useful and I'll see you on the next video.

Channel: John Savill's Technical Training

Views: 37,043

Keywords: azure, azure cloud, microsoft azure, microsoft, cloud

Id: 9DuTWSvsLXM

Length: 135min 52sec (8152 seconds)

Published: Tue Jan 17 2023