 Hey, everybody. Scaling global applications can be a challenge for every organization, and that's where Azure Front Door comes in, and we're going to be doing a deep dive into Azure Front Door today with Dong Ao. He's one of my teammates and a senior content developer for Azure Front Door. Check it out in this episode of Wired for Hybrid. Hey, Dong. How's it going today? I'm doing good. How are you? Good, good, good. Awesome. So you're coming in live from your home office. I'm coming in live from my closet, aka my studio. So very cool. So very excited to chat with you today about Azure Front Door. So before we get into that, just tell us a little bit about yourself as far as what you do at Microsoft, besides work on Azure Front Door. Well, I'm one of the content developer on the Azure networking team. Currently, I am working on not only the Azure Front Door content, but also the Azure Express route content as well. Before, I used to also cover the Azure Virtual Network Manager, as well as route server content. Now, mainly focus around the two areas of Front Door and Express route, mainly creating new contents for the new features that are coming out. We've got a couple more features that are coming down in the next couple of months that I'll be releasing. But yeah, looking forward to this session here. We're going to cover Azure Front Door and go a little bit deeper into it and tell you all about it. Very cool. Well, hey, let's go ahead and jump right in and tell us a little bit about Azure Front Door. Well, most people see Azure Front Door as just a global load balancer, but I see it as a lot more and there's a reason why we name it the Front Door, Azure Front Door. It's the entryway to your application, your global entryway actually to your web application. But it's much more than that. There's more to the new generation of Azure Front Door. The new generation of Azure Front Door, the newer tiers of standard and premium combines the features that you see in our old iteration of the Azure CDN for Microsoft and the old Azure Front Door classic. But then now we also bring in the capability of web application firewall that you can use along with it as well to protect your web application from the front end. We see Azure Front Door, think of Azure Front Door as a layer between the Internet and your back-end services. It gives you the ability to control that tier that many of the time you don't actually think about. Azure Front Door, we have, let's see, we have over about 150 edge locations places around the world. These edge locations are entryways where end users can connect to your back-end services. The way that we do that is we allow you to establish connectivity to them by using any CAS, which means that your end users will connect to the closest edge location when they're reaching out to a particular website or a particular web application. Then what would happen is that, we do something called split TCP. Your first initial connection is to the edge location, and then after that, a second TCP connection is established from the Azure Front Door edge location to your back-end services, to grab your content or whatever it is to load that particular website. Very cool. I can see this fitting into people listening that they're a global organization, they've got customers all across the world, and maybe they are located in the US, but they're a multinational company. Front Door fits right in there from not only the ability for them to be able to get their customers closer to the content more quickly, but I love that web application firewall is now part of that. Not only are they getting them quicker to the content or their application, but they're also protecting that experience by using web application firewall, which is really a step up from traditional CDNs, content distribution networks for those that aren't familiar with the CDN that all they do is simply put a copy of it in different locations. I think that's a cool feature of Azure Front Door. Yeah. You should actually also think about it as that Azure Front Door by default, even before you apply web application firewall, is already doing a lot of that protecting for you. At these edge location, there's DDoS protection at infrastructure level already there. By enabling Azure Front Door, you're already protecting your back-end services where requests aren't going directly to your back-end services. It's going to the Azure Front Door. If there's a certain DDoS attack that's already happening, we already catch that edge and we already blocked that and that won't even go or reach to your back-end services. Very cool. That was an awesome foundational explanation for everybody of Azure Front Door and how it fits into an organization's workflow. I hear you got some demos for us. I know a lot of our viewers love to watch the demos so that they can get hands-on. You ready to jump into some Azure Front Door live? Yeah, let's do it. Let's go ahead and hop into the portal here, and let's go ahead and deploy our Azure Front Door profile. Let's go ahead and click Create here, and let's go ahead and start. Here's the landing page for creating Azure Front Door. As you can see, there are multiple offerings that we have under here. The old offerings that you'll see is under the Explore Other offerings. You can choose from our different flavor of Azure Front Doors or the Azure Front Door Classic, and then the other Azure CDN services as well. But today, we are going to be mostly focusing on the newer tier of Azure Front Door. We are going to go through the Create Experience here. Let's go ahead and do a Custom Create. This gives you the most flexibility. We'll go ahead and select a Resource Group here. I had a Front Door demo Resource Group that I created previously. Here, we enter a name for the Azure Front Door profile. This name is just for your own reference to know which Azure Front Door or profile you're currently working with. So I'm just going to name this my Azure Front Door. We have two tiers here that you can select from the standard tier or the pre-named tier. As you can see, the pre-named tier is focused around security optimization. This has a couple extra features where you can enable manage rules within web application firewall, as well as bot protection, and enable private link to your back-end services. We'll cover private link a little bit later on in this demo. For that reason, that's why we're going to go with the premium tier for right now. Let's go ahead and skip over the secret. I want to be able to cover this later on when we upload our own certificate and use that to verify our domain. So we're going to go ahead and create an endpoint here. Your endpoint, think of an endpoint as a collection of domains that service the same application or website. For right now, you can go ahead and enter in this particular domain. We'll just do Confoso Azure here. As you can see in this endpoint host name, this is actually a unique name in order for us to make this a unique name. We actually add a hash right after your name here, and this is actually the URL to your front-door profile. This is the front-end. You go to this particular URL, it will load up your particular website. Of course, we got to enable this endpoint in order for it to work, so we'll leave that check. Go ahead and add it here. This screen right here is going to look very familiar to you. We call this the front-door manager. This is where you configure the routes. Within the routes, there are domains, origin groups, which are the back-end services that are having similar traffic delivered to them. Then on the right side here, we see security policy. Security policy are the web application firewall rules that you'd be applying to a particular endpoint. We will go ahead and add a web application firewall policy here. I'm just going to do my security policy. As of right now, let's just select the domain that we have. We currently don't have any custom domains yet. We'll change this in a little bit once we configure a custom domain later on in the demo. Since I don't have any web application firewall resources currently created, we'll go ahead and create one right now as well. Doing it through here actually saves you some time and also some confusion because when you create a web application firewall resource, there's actually a tier that you have to select or a specific service. There's a specific web application firewall for Azure Front Door Classic, and there's one for the newer tier. Make sure you select the right one if you create the web application firewall beforehand or afterward. Here we'll go ahead and add bot protection to it as well. Then I'm going to select Save, and that is it on creating the Front Door profile. I can actually add a route in here as well at the same time. Actually, let's go ahead and do that. Let's go ahead and add a route. With a route, this is how you configure how traffic is being delivered to the back-end resources that is servicing that particular website or content that the customer is trying to receive. Let's go ahead and add a route here. Before this demo, I actually created a couple, or not created, I set up a couple of web applications that will be servicing this particular demo. I'm going to do registration app two web application, one is for registering a vehicle, and the other one is to renew your license. I'm going to do registration first here, and then I will keep this domain here. We'll go through the steps on how to add a custom domain and then actually change the domain so it actually points to our custom domain there. This pattern to match, so this is how Azure Front Door will read the request that's coming in. This is right after your host name that is being passed. Azure Front Door, the route will match whatever is after the slash. Currently, as you can see right here by default, we have a slash with a star, which is a wildcard, meaning that it will match any part of the path that is being requested by the end user. Pretty much all this would do is it would forward this particular path to the back-end resource. We'll keep it like that for now. Later on, we'll tinker around with it and change the pattern to match and see how we can alter some of the routing with the profile. As you can see here, the particular type of protocols we have that we can select from that the Azure Front Door profile will accept is you can either select HTTP only, HTTPS only or both. As of right now, let's just do both because sometime when you enter into your browser, you type the URL without HTTPS, so this is how you allow that traffic to be accepted at the Azure Front Door edge. And then the neat little thing here. Just a quick question here. So if I were to put just HTTPS here and then I did put HTTP in the browser, it's gonna fail. But if I have this, then if I put HTTP in, is it still gonna flip over to being secure or is it gonna stay on unsecure? Well, that's what the next little checkbox is gonna do for you. It's gonna redirect that traffic over to HTTPS. And actually, I believe our web browser is actually smart enough now. I think Edge has by default setting in there where it makes you go to the HTTPS. But if you do have that unchecked, then yeah, of course it will initiate traffic using HTTPS. Very cool. Let's see here, so yep. So we'll just keep it at that for now, just keep it by default, accepting all the all HTTPS or HTTP and HTTPS check. And then we'll leave this as check. Like I said, it'll redirect that traffic to HTTPS. So let's see here, we got next thing we have here is Origin Group. Origin Group is a logical grouping of backend resources that will service the same type of traffic. So let's go ahead and I don't believe it has one. So let's go ahead and create a new Origin Group here. And let's go ahead and name this, let's see, believe I have a couple of web servers. So let's just call this web server origins here. And we're gonna go ahead and add a couple origins. And then I will go ahead and add my first origin here. So I'm just gonna call this web server one, I have two web servers that's hosting this registration website. So I wanna go ahead and add those. Here we go, we see here the type of origins that we can add. Here's a long list of types of origin that you have. So the type of origin has to have a public IP. So it doesn't actually have to be in Azure, it could be on-premises or hosted in a different cloud provider. The reason why we have this list here is it actually makes it a lot easier for you to select your Azure resources. Say for example, you have a web server and there's a public IP attached to it. You don't wanna have to hop over and find your virtual machine, find that public IP. I can just go ahead and go to public IP here. And it will actually load up the public IP resources that I have that I can use. So as a rent now, I believe this is the one that I want. Yep, web server one. And you can see here it'll pass in, I didn't configure any host headers on the backend. So you're just gonna see the plain old public IP here. And then the configuration here that we have, by default, these are all loaded in for you. So we're just gonna keep everything by default here. Currently, as of right now, those backend web servers are actually accepting only HTTP traffic. So we're gonna see a lot of our traffic on port 80. Let's see here. You can also configure priority and weight on these particular backend services. The priority will give, let me say, if you have multiple origins in the origin group, you can set one to have a higher priority than the other so they service more of the traffic. And then you can also, along with that, you can configure weight on how you wanna distribute the distribution of traffic. Say for example, if we do a weight of one, that's three, and then the other one of seven, out of every 10 requests, the first origin will receive three of the traffic, and the second origin will receive seven of the traffic. And then down here, we have private link. As of right now, I'm not gonna enable private link. We'll do this at a later time, as you can see, the reason why you would want to, is because currently the traffic between the Azure front door edge and this particular origin is done over HTTP. We want that to be secure, but we don't wanna have to change the ports, right? So we'll enable private link later on in order to have that communication between the Azure front door and the backend service. And of course, we want this particular origin to be enabled, so we'll leave that check, and I'll go ahead and add the first origin. Let me go ahead and add that second web server now. And then I'll keep everything the same, and then I'll go ahead and add it. So everything is fine and dandy here. You have the option of enabling session infinity here. The reason for that is you want, say for example, you want a particular type of traffic to end up on the exact same origin server. You want to enable this, and all feature requests is from the end user. To be on that, you wanna enable this. As of right now, I don't have anything on the web server that requires this, so I'll leave that unchecked for now. Next up is configuring the health probe on how Azure front door detects if the origin services are up and running. So as of right now, we'll just keep this as all is default, the root of the web server has a file in there that it will detect and show that the, it will actually get a 200 response, and it will show that the web server is up. One thing to keep in mind though, is that, let's say for example, all of your origin services for some reason is down, or like the health probe is considered down for all of your services. Azure front door actually will see it as healthy, meaning that if all your services are down, it will actually still continue sending traffic. I believe this is a mechanism to make sure that your services are still, what is it, your backend services are still servicing requests that are still coming in. So that's the reason why they set it up this way. And then we got this load balancing configuration that you can do. The reason for, what is it, this option allows you to configure the latency for the load balancing group, meaning that how long between, what is it, in that sample size, what's the range of latency that the health probe should get a response back in order for it to actually continue sending. So as of right now, our default is the 50 millisecond latency. If it goes beyond that, then that particular, what is it, that particular origin won't be receiving that particular traffic. And that is it for origin group. So I'll go ahead and add this particular origin group to it. Our next field here is the origin path. This is where you wanna enter in an additional path. Say for example, your backend service has an additional path in between the webpage. This is where, for example, I have an origin server that has a path of vehicle registration slash then my webpage. Instead of having our customer type in that additional path, what I can do is I can enter that path in here so it looks invisible to our customer. And then that path will actually be forwarded onto our origin. And this next part here is the forwarding protocol. This is, of course, as the name says, it's the type of protocol that will be forwarded to the backend service. So as of right now, whoops, the match coming in. Let's see here, what will actually happen here is that if you make an HTTP request, since we're redirecting it, it will actually just forward it as an HTTPS request to the backend. And then we have this function of enabling caching. As of right now, we're gonna leave this off, but we'll turn it back on because this is a very neat feature of Azure Front Door and it's one of the main feature, actually, of Azure Front Door. And we'll tinker with this a little bit later on to see how that worked in seeing the response time when we make a request to the origin. So we'll go ahead and add this and we will go ahead and create this Azure Front Door profile. There we go. So how long does it usually take to deploy Front Door? It's usually fairly quick. Give it about five minutes at tops. We're gonna see it populate here fairly shortly. It will actually take upward up to about 10 to 15 minutes for your configuration to actually load to all of the edge locations. So depending on how long that would take, right? So 15, well, we have 150 edge locations. So 15 minutes is fairly good to get that out there. Yeah, that seems pretty good. Since you have to send a lot of ones and zeros around the world, we can't expect everything's instantaneous even though we want it to be instantaneous, right? I've had very, was it good response time actually, like I'll purge, so there's a feature that we can do, meaning purge contents that are being cached. Usually we would get, we're told that it would take about 15 minutes, but I've gotten a fairly quick, like usually within a minute or two that contents cached from our purge from our edge location. So depending on what you're trying to do, the response time of beginning down is very quick. Nice. So it's almost done here. Reason why it's taking a little longer because all those configurations that we're doing are configuring around, believe we're setting up a web application firewall as well. As you can see, the resource is deployed right here, and I guess that's even faster in the five minutes that I said. So we'll go ahead and go to our front door profile here. So let's just take a look again on how things are being configured. So as you can see here on the left side, we have a couple of settings that we can take a look at. Our front door manager, let's just hop into here real quick. You'll see it's gonna look very familiar to our create screen. So on here, this is where you can add additional endpoints. So say for example, you have another domain or another set of domains that you want to set up in your Azure front door profile, you can add another endpoint here. Previously, with Azure front door classic, you were only able to create one endpoint per profile. Now with the newer tier of Azure front door, you can create up to 10 endpoints in here. So if you click into add endpoint here, you go through the same configuration process for that when we created the Azure front door profile initially. So we won't be doing that. Let's just go ahead and hop into this one that we have here that we created, in the initial create process. So you can see the screen is very similar to that. In here, you can add additional routes, which we will in a little bit for my other backend service. Let's just take a look and see what we have going on here so far. So as of right now, if I were to go to this URL, I believe my website should load because I didn't do anything fancy with it. Should forward the traffic that we request from the front end and go directly to the origin server. Yeah. If you're seeing that your page isn't loading when you're going to the Azure front door profile, some of the most common mistakes is by leaving the forwarding protocol as default. From what I can see here, my backend services only is accepting HTTP traffic and I had the forwarding protocol set to both or actually what I had it was forwarding based on the incoming requests. Since I had the configuration to redirect all traffic to HTTPS, the forwarding protocol would go to HTTPS in the backend and therefore the webpage would not load. So make sure your forwarding protocol is set correctly to what your origin services would accept. And this is what it would look like once you configure that correctly. As you can see, the backend service is showing my websites and if I were to hit refresh, we should see it bounce back and forth between the two web servers. And as you can see there, I was able to get to web server one by refreshing a few times. Very cool. Yeah, that's awesome. I appreciate you jumping in and just reminding everybody that these things, there's lots of things going on here and making sure you really have an idea of how these things are all connected and making sure you have those settings all lined up. Otherwise, you run into those little things. Yeah, absolutely. So let's go ahead and hop back into the portal again. We're gonna go ahead and add a custom domain to this Azure Front Door profile. As you can see, the URL isn't the most pretty. You wouldn't be giving this to a customer to tell them to go to your website, taking quite some time to type this in. So let's go ahead and configure a custom domain, something a little bit friendlier that people can remember. Okay, so back in the Azure Front Door profile here, let's go ahead and head over to domains which is our second option here under settings. Here, this is where you can add your custom domain. I actually have a custom domain that I own myself called contosoazure.com. So let's go ahead and add that custom domain. So as we walk through here, I have actually have my domain managed by using Azure DNS. So it actually makes the configuration process a whole lot easier to manage it through a third party provider. Although we do have an option that allows you to do that as well. So let's go through some of the options here. So the domain type, we have non-Azure validated domains and then Azure pre-validated domains. What are the differences between these two? Non-Azure validated domains are domains that you bought from a third party, such as GoDaddy, and you're configuring it with your Azure Front Door profile. Azure pre-validated domains is for services that you already configured the domain for. Say, for example, you had a Azure app service that you configure with a particular domain. You can select this option, which would actually reduce the configuration process. I believe you click into this, some of the options go away. Yes, so as you can see, I click into this, the Azure DNS where a lot of the verification that needs to be done goes away and then you can select that particular domain. As of right now, we're starting fresh. So we're gonna go through the validation process and see how things go there. So we see here, the next option here we have is DNS management. We recommend you doing with Azure DNS. It just makes the configuration process a lot easier and I've actually noticed the validation or the verification time a lot faster and quicker than if you were to do it through your third party configuration or settings. So let's just go ahead and do that. I already created a DNS zone with my domain. So we'll take a look at that once I set up the, once I select the DNS zone and figure the domain to add to Azure point door. So I'm gonna go ahead and select my DNS zone here that I created, contosoazure.com. Actually, let's go ahead and create a subdomain here that we can use for the registration website. It can be registration.contosoazure.com that we can use for this configuration. All right. So now that we have this new subdomain here that we're gonna be adding, when you have to configure a few more things here, if you wanna enable HTTPS, you need to configure, once you have to use a certificate or to set this up, you either can use Azure manage, which means Azure will create a certificate for you that you can use, or you can bring your own certificate, your own certificate that you have, either a wild card certificate or an Apex domain certificate. So what I'm gonna do here is I'm actually gonna do the bring your own certificate because that's what most people would do. They already have a certificate that they can use to verify their domain. And in here, you can see, I don't have any secrets. That's a problem, right? That means that my Azure front door hasn't located where my certificate is, where most people would have their certificate is they would store it in Azure Key Vault. So let's actually do that, right? I'm gonna back out of this. We're gonna have to go through this add domain again in a little bit, but let's go ahead and hop over to, let's see here. Let's go ahead and hop over to how we can set this up with Key Vault, right? So one of the configurations that you have to do is you have to actually give Azure front door access to your Key Vault so that it can pull the certificate that you have uploaded there. So you can do that from actually here, where you go to secrets. And you should be able to see, should go add certificates from here. And you can see, you actually see your Key Vault. And we'll see if it actually populates some of my certificate here. So these are the certificates that I have. And actually before, let's see here. Let me see if it actually allows me to, because although you can see their certificate, sometimes you may get an error that says that Azure front door doesn't actually have access to it. So let's go ahead and do this really quick. And the certificate I have here is my wildcard domain certificate. So that's why we're doing the registration.contosoazure.com. So let's go ahead here and see if I get an error of some sort. If I don't, that means I'm most likely, gave it permission already. And it looks like it accepted it. So I already gave it permission. If we didn't have permission, where would we go for that? So what would be- So what would be an Azure Director Directory? Yeah, well, yeah, we would do it through, let me see here. Let's actually, well, that loads. Let me go ahead and hop over to that Key Vault. So you would actually need to give it access, our back access to it. So I would actually go into here, into access policy. And you actually see that I actually created one already. But if this isn't here already, what I would do is I would go ahead and create it. And I would create an access policy that says get and lists secrets. And then what I would do is I would actually search for the service principle, Microsoft.azure leads front door, Yep. So it's this one, Azure front door CDN. If this doesn't populate for you, you most likely need to create the service principle first within our documentation. You'll see either the PowerShell or CLI command to create this particular service principle. Be aware though, there are different service principle IDs. The one that you're seeing here on the screen is specific to CDN and Azure front door standard in premium. The one for Azure front door classic has a different service principle. So make sure you use the right one in order or else you won't be able to see the service principle. All right, sorry. You won't be able to see the certificate show up from the secrets menu from Azure front door. Cool. Thanks for walking through that. Yeah. Once you do that, you should see, let me head back to Azure front door here. Believe that operation is complete. Yep, should be good to go. And we should see that certificate actually load up now. There we go. So here is my wallet card certificate. Let's pop in here real quick and we used to see, let's put it down here. Okay, we won't take a look at the actual content of it. So I always leave it like that. Let's head back to domain and let's go ahead and add that domain again, right? All right, so let's walk through this and then I'm gonna go ahead and add that custom domain, the one that I wanna do for registration. And then I'm gonna select my bring my own certificate and now I should see that in the list. There we go. And I'm just gonna keep my TLS version as 1.2 as the latest one. And then I'll go ahead and add it. It's gonna take a couple of moments here for it to populate into this particular list. There are a couple of things that we need to do in order to actually validate and verify that we own the domain. That's how we make sure that there's no domain takeovers and things like that. Also throw in here while we're waiting here. I'm one of those people that's certificate challenged. I seem to like, every time I have to work with certificates, it's like, I like forgot what a certificate is that this is why you use wildcard certificates because it allows you to be able to do these custom names. Whereas if you just did a non-wildcard certificate, you would have to have a certificate for every one of those names that you created which creates a ton of complexity. Yep, absolutely. Okay, so we, let's see here. So we got to populate here. There's a couple of things that we need to do before we can actually use this domain. So let's take a look here and see what we need to do. I wanna go ahead and first, I wanna go ahead and associate this domain to an endpoint, that particular endpoint that we configured earlier. And then what I'm gonna do is I'm gonna actually select that particular route that we had earlier as well. So now if I were to go to registration.contosoaction.com, you should take me to my backend, to those websites that I had configured earlier. So let's go ahead and associate that. And once you associate, I'm gonna have to do, lead a verification and then after that we'll have to validate the domain. And you do that by creating a, what is it? A couple of records in your Azure DNS. And that's how we verify things. Yeah, I found from stuff that I've worked on that it's much easier to have, I've got a ton of stuff over at Namecheap. And I found it's much easier to have things in Azure DNS when you're going through these processes than it is for our third party, third party domain. Yeah, absolutely. So, okay. So now that we associate to, you can actually see the DNS state change, where it tells me that I need to create a CNAME record to associate a Contoso, was it ContosoAzure, registration.contosoAzure.com to that particular endpoint that we have. So let's go ahead and create that particular CNAME here. The nice thing about Azure DNS here is when you do it here, you don't have to go to the Azure DNS side configure, actually have seen quite a few people talk about having difficulty about this particular process. Cause what they do is they would configure the CNAME record from the Azure DNS side. And then what they would do is that they'll actually try to look up Azure front door. And as of this particular time, there's no way to configure the newer tier Azure front door cause it's not listed in the service. So the way that you work around this is actually by creating the CNAME record through this, what is it? Through this channel, through the domain configuration of the front door profile itself. So let's go ahead and add this. Let's go ahead and add this record really quick. Okay, I believe that is good. So now we can see the DNS state change to traffic is delivered, not quite though. That's just to set up the configure your CNAME. And now we got to make sure we validate that we actually own that domain. And the way we do that is we actually create a TXT record within Azure DNS for that particular domain. And do that, just go ahead and click this little add button and it's gonna go ahead and add that for us there. And we can go take a look. Let's just hop over. I'm gonna go ahead and close this. Let's hop over to Azure DNS real quick and just take a look at those records that were created here under Contoso Azure DNS zone. So you can see right here, these were the two records that were created, one for the registration.contosaujure.com and then the next one is the, what is it, the registration authentication to make sure that we own or that domain is exactly who we said it was. Okay, so all fine and dandy there. Now let's go ahead and test it out. We should, let's see, let's just go back, double check real quick in the domain, make sure everything's all green and fine and dandy. Yep, so we can see here, validation state changed to approve. Once I did that earlier, it was in that pending state. And if I, this right here, it's a little wonky. I think there might be some kind of portal display issue as you can see I just hit refresh and it shows it again. I had this happen to me quite a few times. I couldn't figure out why and I guess I just click the refresh and it shows up correctly again. That's a little weird bug there. Okay, so now that we have that, let's go ahead and go to our registration.contosaujure.com to see if our custom domain has worked correctly. There we go. There, now as you can see, went to the registration.contosaujure.com and we're able to load our page. And if I were to refresh this a few times here, we should see it bounce back and forth between web server one and web server two. And there you go. Now that we have a custom domain, we can share this with our customers and they can use it to access our back-end services or our websites. Let's go ahead and configure a few more, let's say a couple more websites here. Actually, let's not do a website. Let's go ahead and have a media content and let's play around with the caching and see how that helps accelerate what is it, end users and their experience. I'm gonna go ahead and add a new origin here that we're gonna reach out to a test video file that I have located actually in a storage account. So let me go ahead and configure that real quick. Let me see if I can get us back into the Azure portal here so you can see that. Okay, what I'm gonna do here is I'm gonna go ahead and add a new origin group and we're gonna direct that to our, was it storage account where that particular, is it, where that particular test video file is located. So I'm just gonna do a media origin here. I'm gonna go ahead and add that origin here and I'm gonna go ahead and select my storage account and then we'll keep this on the scene here and I'll go ahead and select add. Okay, I'll keep everything else the same in terms of the health probe and the load balance configuration and then we should be able to just redirect our traffic over to our storage account. Give it a couple seconds here for it to create that. Let me go and find that particular path. I'm sure it's taking some time to create that particular origin. So this is good for those instances where you have like, in this case, you're doing like a video, maybe somebody has, you have different sorts of things where you wanna get people connected to this makes it easier for you once you get everything set up to get everybody in there, right? Yeah, absolutely. Yeah, you can share all sorts of contents right here. So one of the most common one is people trying to share video files, right? The thing here that I wanna show is that video files are very, what is it? It can require a lot of bandwidth on your backend services. And in order for us to limit having to, was it reach out to the origin server every single time to get that information, what can happen is that Azure Front Door can actually cache your particular video file or your contents that are frequently being accessed by our end users that they can use. And what would happen is it would limit the amount of traffic that your origin server would receive. And you can set this up that your front door edge can cache this for a certain amount of time. By default, if you don't configure anything Azure Front Door can cache the content from between one and three days. But even by configuring caching for frequently retrieved traffic for just a few seconds, just imagine how is it? You have thousands or millions of users requesting that particular type of traffic that timer actually gets refreshed every single time that that particular content is being retrieved, right? And you should actually think about it as a protection mechanism for your backend services since the content is being cached on the Azure Front Door is not being frequently being retrieved from the origin and limiting attacks and requests that you normally take if the traffic were going directly to your backend services. Okay, so now that I have this particular origin created let's go ahead and see how we can redirect some of the traffic. There's a video file in there that I have called test video that we're gonna try to get to. And how can I do that? We're gonna actually use a feature in here that is a very powerful tool called a rule set. A rule set is how Azure Front Door will actually read through the requests and decide what to do next. So the way that Azure Front Door works is that when you make a request, the host name is matched to an Azure Front Door profile. Then after that, Azure Front Door looks at the path which is in the routing configuration that we did. It reads the path and see which actually which route it should match to. After it does that, it runs through our WAF configuration to make sure that the request is what it's supposed to be. It's not an attack of some sort. It's an actual request that is requesting legitimate information. After that, what happens is the rules engine will kick in. The rules engine is how it will further break down the traffic whether if you want to route it based on if your traffic is coming from a mobile device or a desktop, we can determine that at the front door edge and route your traffic to the very specific backend origin without having, basically you're controlling that there at the front door edge rather than having it go to your origin and then determining, hey, this what service should be servicing mobile traffic and then having to reroute. You're doing that at the very beginning of the request and then therefore limiting the amount of round trip times that we need to request that type of traffic or retrieve that type of traffic. Okay, so let's take a look here. Let's go ahead and do this real quick. Let's go ahead and hop over to the rule set. We're gonna create a new rule set in here. So inside a rule set, you can create a believe up to 10 rules in here that it would diagnose one by one. As you can see in here, there's actually a little checkbox that you can do to stop evaluating. Say you have multiple rules doing certain things, you can stop processing the rest of the rules. I select that particular checkbox. So let's go ahead and create a rule here. So we're gonna go ahead and say we are going to route to media. And then I'm gonna go ahead and, what is it? I'm gonna go ahead and add a condition in here. And what I'm gonna do is I'm actually gonna do it in the request URL and then what I'm gonna do is that we're gonna request that particular file, that media file. The media file is actually named test underscore media or sorry, test underscore video.mp4. So what I'm gonna do here is when I type in our domain, our registration.contosoazure.com and then I'm gonna do a slash, I'm gonna request that particular video file. So I'm gonna configure in here where let's see if I do request URL contains and if it contains a value of video, I'm gonna make sure, I'm gonna configure an action that it would route to that particular origin. So I'm gonna go ahead and do this. I'm not gonna do any string transform. As you can see here, you can do further processing of that particular path. You can do two lower case, double case, you can trim part of the path. I'm not gonna do any of that. I'm just gonna keep it simple here where we're taking a look at if the URL, the request URL contains the word video in there, we're gonna route it to the origin that has the, we're gonna route it to the origin that has the video file, which is the storage camp. So in here, what we can do is we can do a route configuration override. What this does is that it allows me to override what I have configured already in a route. So if I go ahead and select here, we have the option to select a different origin. And what I'm gonna do is I'm gonna go ahead and override the origin group that was selected when we created the route. Go ahead and select yes to override origin group. And now I'm gonna go ahead and select the media. So you actually don't have to have your origin group associated to a route in order for traffic to be routed to it. And this is one way to do that is, or this is the way to do that is to use a route, a rule set in order to configure that. In here in some of the configuration, very similar, you can for the traffic, depending on the protocol that you want, we'll go ahead and match it incoming. And then we will leave cache and disable for the time being. And then we just go ahead and let's see here. Go ahead and save this. Oops, I forgot to put the rule names. This is to media. Once we create this rule, what I will have to do is I need to associate it to that particular route so that when we go to our domain, our ContosoAzure.com domain requesting for that file, it will know how to process or it will use this rule set as part of its route processing. And this is just one of the many ways that you can use a rule set. The rule set is a very powerful tool. It allows you to manipulate the requests that is coming in, right? As you can see, a couple of other options that we had in there when I was pulling down the condition. Actually, let's pull up slide. Yep, so in slide 19 right here, you can see all the specific types of conditions that you can use in here. Allows you to manipulate the, what is it, the particular type of request header, the particular path. And then, let's see here. And even on the client port and server. And then after that, you can apply some types of actions to that, which we'll see in slide 20. Actually, this is where I wanted us to look at where you can modify the requests or response header as well as redirect or rewrite the particular URL into a different path that you want. So now that I, let's see, back to our tutorial here, now that the particular rule set has been created, let's go ahead and associate that to our route here. So heading back to the front door manager, and go ahead and select that particular route that I had created earlier. And let's go ahead and scroll down here where we see rule sets. This is at the very bottom here. And I'm gonna go ahead and select that rule set. It's a little off screen here, but you can see it loading as I can select it. So now I'm gonna go ahead and update this. This will take a couple of minutes for you to distribute was the information to all of our edge location. And we should see this in a couple of moments here. That rule set thing is pretty handy. That seems like kind of the way to go for, you know, doing some of these, you know, just kind of like some granular stuff, whether it be like you did showing, getting to the media, or if there's like specific places you want to make sure people go, that seems like a really good way to be able to manage that for those organizations. Cause a lot of organizations have that, is that they have, you know, multiple places within an application that they want people to go to. So that's super cool. Thanks for walking through that. Really, like this was having the rule set configuration, it allows you to take a lot of that processing that would be normally done on your web server, right? To do the redirect or the URL rewrite or send it to a different server. Now we can do it directly on the Azure front door so that the, was it the amount of time that it would take normally to do that is literally cut in half or even more, depending on the distance of where your origin servers compared to the front door edge location. Pretty cool. So we just take a look at this rule set right here that I have configured. Taking a look at how we have this configured. As of right now, it's looking for the requested URL if it contains the word video. And then what we have next here is the action that will be applied to the path once Azure front door processes. So what we have here is there will be a URL rewrite that's happening and it's looking for a particular source pattern. In this case, it's all source pattern. And then we were gonna rewrite that to include the path of media. This is because the tests video file located in the storage account has a media folder in there. And then what we're gonna do is we're actually gonna preserve unmatched path. So anything that wasn't matched, we're gonna keep it. And then we'll keep this the same here with our route configuration override where originally in the route and then where the origin is located. And we're gonna forward it using the same incoming requests. And for an Azure app. So to see that happening, we're gonna hop over to our test virtual machine here and then we're gonna try to load up that page and request the file for the video. Okay, and before I even do that, what I'm gonna do here is I'm actually gonna bring up the developer tool for us to see here. And then I'm gonna do media and we take a look at this. Okay, so here we go. We're gonna go to that particular. The reason why I'm bringing this up is we're gonna actually take a look at the response time of how long it took for us to request this particular media file. So I'm gonna go to registration.azure.totally and we're gonna go to this video file here. And if I click into this, then actually see how long it took for it actually to get a response back from that server. So as of right now, this particular test VM, I am actually created in the West US region and the origin server that is hosting this particular video clip is actually located in Japan East. So you can actually see that it took us roughly 680 seconds to get a response back. That is quite a long time in networking in order to get a response back. So how can we improve this response time, right? And one way to do that is by enabling caching on Azure Front Door. Azure Front Door, you can enable caching in multiple places. You can enable it initially on the routing configuration that we saw when we were configuring the route. And we can also do it when we're creating a rule set rule where you can enable caching. So I'm gonna hop back into the Azure portal here. I'm gonna go ahead and enable that caching on the rule set there. So let me go ahead and enable caching right here and we're gonna go ahead and enter in some of the information here. I'm gonna use, select use query string and I'm gonna keep a compression off here. And with the caching behavior here, you can select if you're trying to honor the origin. So basically your origin server may have a caching configuration in the response that you wanna enable or we can configure it here directly on the Azure Front Door configuration where we can always override it. Meaning we're setting our own caching time on Azure Front Door. So that's what I'm gonna do here is I'm gonna do an override always and I'm gonna set this to, let's just do, let's go three days. Let's just put it here. We can set this for a shorter period of time. It really depends on how long you want that particular type of information for content that never changes then you wanna have a longer caching period for certain content such as like a homepage where it may change every other week or something like that. You may wanna have a much shorter caching period for that. So I'm gonna go ahead and put that there. I'm gonna go ahead and hit save. And then we should see this reflect on the, when we make a request. So front door caching only gets better when you use it more. So that first initial request, it still needs to reach out to the origin in order to retrieve it. But any following requests from our customer, it doesn't need to reach out to the origin because it already has that information cache and it can be grabbed from. The cache is done at the front door edge. So it actually depends on which front door edge location is currently caching it. So whoever's reaching it, when the end user reach out, they reach out to the closest edge location. So that edge location may not have it. I don't know, first request, but every sequential request after that, it will pull from the cache as long as that content is still cached on the front door edge. So let's take a look here real quick and we're gonna hop back over to our test VM here and we're gonna take a look and see if we can make that request and see if we're getting that particular video clip from the cache or are we getting it from the origin server. So let me go ahead and open up a new in private browser here real quick and I'm gonna bring up this. I'm gonna bring up the developer tool so we can see what's going on within the request. So I'm gonna go ahead and go to registration and then I'm gonna go to that video file again. So let's just take a look here. Now we get a tzp hit for our cache. This means that it actually retrieved the content from our front door edge. Now let's just take a look at the time in here and see what we got for the time. This is what more of what I was expecting on our response time. So we definitely reduce the response time of when you actually reach out to the backend. By quite a bit, 600 milliseconds compared to seven milliseconds here and then where you will be grabbing the content. That's cool. So basically the way the caching works is to break it on for somebody that's familiar with how things work on premises. And it's very similar to the way DNS records work is when you're caching DNS records, right? Because when you click that cache, we're not sending your content everywhere. We're waiting for somebody to hit that edge and then they bring that over to the origin and then that is available for everybody that comes for the next times, right? Yep. And the nice thing about the Azure Front Door caching mechanism is that it's always one step ahead. So it always pulls the information that you would think you would need. So say for example, you got this video file, you're pulling the first, was it segment or so? Azure Front Door thinks ahead and it will pull the next segment in preparation for if you need that next set of information, right? Next set of contents. Very cool, very cool. Well, that was an awesome run through. We got a ton of great stuff there for those people that are looking to roll out front door, where's the best place for them to get started? This video did a great job, but chances are, they wanna dive a little bit deeper. Where's the best place for everybody to get started, dive in deeper into front door? Well, you can get started by looking at our Azure Front Door content, right, our documentation set in there. It'll get you started with getting yourself set up with it, going through the different features that are included in Azure Front Door. And then you can go to our architecture center. There are some great contents that have just been released out recently where it involves multi-tenancy for using with Azure Front Door or how to use our different load balancing services in conjunction with Azure Front Door. So you can put a traffic manager in front of your Azure Front Door profile. And then along with that, you can have application gateway or load balancers in your origins, right? To further distribute the traffic within your virtual network as well. Very cool. And we'll definitely put some links to some of the most common content that'll be helpful for people in the show notes. Anything else that you can think of like, hey, you know, these are the top things that people need to know that we haven't covered. That would be good for people out the door. Do you think we're all ready to go to build some front door? So there are a couple of other features in Azure Front Door that I didn't get a chance to cover, which is the reporting. Azure Front Door has various reporting that you can see live or, sorry, not live. It takes a while to collect it, but you can see it information about the number of cash hits that you're getting or where the traffic is coming from to your Azure Front Door. And then you can export that out to, when is it, your log analytics to take, when is it, to view that. One other thing that I didn't get a chance to cover also is Private Link. It's only available with the premium tier of Azure Front Door, which allows you to establish a private communication between the Azure Front Door Edge with your resources within a virtual network or actually the other service that can be used with Private Link is app services as well. Awesome, awesome, that's a good deal. Well, hey, Don, thanks for taking the time today to really dive deep in Azure Front Door. I learned a ton of stuff today and super excited to find some time to play around with Front Door and appreciate you coming on and all the work that you do for our customers and the great content. So with that, just wanna remind everybody, if there are any things that you'd like to see, maybe you wanna see more about how that reporting works and Don did mention that there are some new things coming with Azure Front Door. Make sure to leave a comment down below. And if there's things you want us to talk about, we take a look at those and maybe we can have Don come back here and talk about some of our Front Door. With that, have a great day, have a great week. Don, thanks again. We'll talk to you soon. All right, you can be having me. Goodbye, guys.