Azure Front Door [FULL COURSE IN 2.5 HOURS]

hi everyone my name is hassain awad and i would like to welcome you to my azure front door course in the next few hours we are going to dive deep into azure front door before i get into the details of my course i want to give you a heads up that this course is completely hands-on there is no powerpoint slides at all all the time you are gonna see me demonstrating stuff on azure portal or showing your diagrams on azure documentation this is to ensure that you are going to get the best value out of this course so we are going to apply everything we teach practically not just theoretically so we are going to know what is actually as your front door is doing and where it sets in terms of the related load balancers that are available in angel then we are going to go ahead and create an azure front door and we are going to see how you can add a custom domain name for your azure front door and how can you secure it using https and how we can use the apex domain or road domains in the front door and how you can do redirection whether it's a protocol redirection from http to https or url redirection then we are going to talk about the back ends and the back in the pools and then talk about caching and how azure front to door caches your content in different edge locations around the world then we are going to move to the rules engine and understand its architecture and talk about when it's going to get executed when the incoming request hits your front door then you are going to talk about the different conditions you can specify and the different actions you can trigger then we are going to move into the routing architecture to understand how front door makes routing decisions and tries to match the incoming request with a specific routing rule that you have configured in your azure front door also how azure front door routes incoming requests to the healthy backend instances and what are the different routing methods that azure frontal door is using to achieve this even though frontal door standard premium tier is still in public preview we are going to cover it through this video as well so you are going to see how can you create a standard or premium tier and what is the main feature comparisons between the two tiers then we are going to get to the pricing difference between the front door classic standard and premium tiers then we are going to move to the web application firewall or some people prefer to call it wealth and we will understand how it works and when the waf rules gets executed when azure front door receives a request from the clients and then we are going to see how can you create our policy and associate it to your azure front door and what is the difference between wealth managed rules and wealth custom rules then we are going to be moving to the monitoring where we will be covering how you can create diagnostic settings for your azure front door what are the key metrics that you need to keep an eye on on your production environment and how can you set up some alerts that are going to notify you when the usage exceeds a specific threshold and finally we are going to cover how azure front door is using the healthy probes to know the healthy status of the backend instances i think that's enough to give you an overview what this course is going to cover let's get started and let's dive deep into azure front door hi everyone in this video we are going to talk about what is age or front door so azure front door is a global scalable entry point for your application that is deployed globally across microsoft edge network and this is one of the key things about azure front door it is a global service which you will be able to interpret and orchestrate the traffic globally across multiple regions now let's have a look at this diagram here to help us understand how azure front door works and what is the key benefit of using azure front door let's assume that we have deployed our workloads on azure on three different regions region one region two and region three each of these regions have its own sql database vms cosmos db and app service and let's assume that we have a local load balancer in this case i would go for application gateway to orchestrate or distribute the traffic evenly within the region and also will cover some failover scenarios if some backing the targets become unhealthy for any reason all of this are gonna be managed within the region so we are going to have a three separate load balancers regional load balancers for all of these regions so are going to deploy three different application gateways here now the question here is how the client is going to get directed to the right region and when i say the right region i mean the closer region that has the lowest latency and maybe the healthy region that has the healthy instances so how are we going to direct these traffic or these client requests to the right region we will have to have some service in between that will be able to take the client requests and based on the different routing rules we are going to configure then it will be able to route the traffic to the right region or to be more specific to the right application gateway which is then going to distribute the traffic to the other back in the targets within the region this is exactly what azure front door is doing it is a global scalable single entry point for your application so your global customers will have to interact with just one entry point and then based on the routing rules we are going to configure in the azure front door it will be able to route the traffic to the right region another key feature of azure front door is it operates at layer 7 so it will be able to intercept http and https traffic and it will be able to make routing decisions based on the url values or request headers that has been submitted in the http request also it worth to know that azure front door is resilient to failures even failures that affect an entire region azure front door is resilient for those kind of failures because it sets globally it will direct the traffic to the other healthy regions this is one of the key benefits of using azure front door and as we are here talking about the different azure load balancing services i am sure that some of you are asking why there are so many load balancing services in azure it is so confusing for me like we have load balancer we have front door we have application gateway we have traffic manager and every time i have to use a load balancer i keep scratching my head what would be the right azure load balancing service that i should be using in this situation although it might seem a little bit confusing when you look at it at the first time but when you pay a closer look you will see that there is no confusion at all and each of these load balancing services has a specific use case and a specific purpose so if we are going to compare all of the azure load balancing services across two dimensions the coverage whether it's a global coverage or regional coverage and then the recommended traffic whether it's http or non-http traffic so let's go for http first in this case we are going to have two load balancing services azure front door and the application gateway both of these are the only two that supports http traffic out of the four services so far it's great we have narrowed it down from four services to two services but again which one should i go for when i have http traffic that i need to handle this is when the second dimension comes really handy which is the coverage if you have a global coverage then the azure front door is going to be the right service for you to use however if you have original coverage then you should go for application gateway similarly for the non-http traffic we have two azure load balancing services that are recommended for non-http traffic and we are traffic manager and load balancer and similar as before traffic manager supports global coverage while azure load balancer supports regional coverage only so having these two dimensions next to the azure load balancing services when you make your decision about which azure load balancing service you should choose it's going to help you to pick up or choose the right azure load balancing service that fits your requirement and use case cable is very useful and is going to help you to choose the right load balancing service now i have done a course for the application gateway before and currently i'm doing the front door which you are already watching and i'm planning in the near future to cover the other two services traffic manager and azure load balancer that's all i have for you in this video it was a quick introduction about what is azure front door thanks for watching and i'll see you in the next video hi everyone before we get started i want to give you a quick heads up as you already know this course is completely hands-on so we are going to spend a lot of time working on azure portal and create a lot of resources and i really encourage you to follow along with me and create the resources that i am creating on your own so after this course you will have enough understanding of azure front door having said that bear in mind that if you are going to follow along with me you will be expected to pay some money to azure at the end of the month because we are going to create some resources on azure portal as i said before however in my case when i prepared this video it costs me around 50 australian dollars five zero you could just check what would be the equivalent for other azure regions if you are not happy paying some money to azure by the end of this course so please don't create any resources on your azure portal and just watch what i am doing and it will give you enough information about azure front door let's get started and let's learn frontador together hi everyone in this video we are going to dive deep into the core features of azure front door firstly we are going to see how can we create azure front door and then how you can set up a custom domain name for the azure front door and how can you secure it and what are the different redirections you can use in azure front door whether traffic redirection from http to https or url redirection then you are going to talk about the back ends and the backend pools also are gonna cover the caching and how you can purge the cache at all edge locations that as your front door might be caged your content let's dive straight into it thanks for watching and i will see you in the next video hi everyone in this video we are going to create an azure front door and as you can see here this is a brand new azure subscription doesn't have any resources at all so let's get started by creating a resource group i'm gonna call it australia east resource group i'm gonna put it in australia east region and let's go ahead and create our resource group now let's create some app services to be the backend for my front door i'm gonna create a new app service i'm gonna put it in australia's resource group i'm gonna call it front door web app one and then i'm gonna make the platform or runtime stack dot net core 3.1 and in australia east region and i don't have any app service plan so let's go ahead with the one that azure portal suggested me to create then going to the next step deployment continuous deployment is going to be disabled as default let's go to monitoring i'm going to disable the application in sites and let's go ahead and create the app service and while it's been created let's go ahead and create another app service because i'm planning to have two app services as a back in the targets for my azure front door so let's create another app service let's put it in australia east resource group i'm going to call it front door web app 2 and then the runtime stack will be dotnet core 3.1 i'm gonna put it in australia east everything else before and this time i'm going to use the app service plan i have created in the first app service that i just created now let's go to deployment i am going to disable continuous deployment as it's already disabled then going to monitoring i'm going to disable application insights and let's go ahead and create the second web app or second app service and while it's been created let's go back and create an azure front door so let's browse to front doors and let's go ahead and create a new front door let's put it in australia east resource group and then going to the configuration where we are going to configure the front-end domains and the back in the targets and then the routing rules and the host name is going to be my front door the name is already used i'm gonna put my name okay my front door has sign um this is my front-end domain for my azure front door and let's keep everything to the default values let's go ahead and add the front end now moving to the back in the pools let's go ahead and add back and pull and then we are gonna have two targets my first target is going to be an app service and i'm going to choose front door with app1 and leave everything to the default values and then i'm going to add another backend target i'm going to choose app service again but this time i'm going to choose web app 22 and then let's go ahead and add the backend target let's leave everything to the default values and let's add the backend pool for my azure front door then the last step i have here is to create or configure a routing rule so i'm going to call it routing rule again it's going to accept http and https traffic and the front end domain is going to be the front end that we've just configured in the azure front door and then it's going to forward the traffic to the back in the pool that has two app service as a back-end targets and let's leave everything to the default values and add our routing rule now let's go ahead and create our azure front door now my azure front door has been deployed for me so let's go and test it so this is my azure front door i'm gonna copy the front end host and as you can see here my front-end domain i have configured for my front door directed the traffic to the back-end app services i have created before now let's go ahead and stop these two app services just to show you that my front door is actually directing the traffic to those two app services so what's gonna happen when i stop these two app services that nothing is gonna get displayed when i refresh this page but this is not the case because of the browser cache so i'm going to copy the domain name i'm gonna put it in incognito address bar and as you can see here the web app is stopped this is all i have for you in this video we have just created an azure front door and linked it to a tool back in the targets and how we directed the traffic from the front-end domain name to the back in the targets thanks for watching and i'll see you in the next video hi everyone in this video we are going to see how can you add a custom domain name for your front door as you can see our front end endpoint is not really nice it has an azure fd.net at the end it's not good to be used in a production workload and for your branding purposes so now we are going to see how you can use a custom domain name and use it in your azure front door first thing you need to go to your domain provider where you have registered your custom domain name and because i don't have any registration with any domain provider i'm going to show you the steps in azure dns zones and you should be able to apply the same steps in your domain providers so i'm going to go ahead and search for dns zones and i'm going to create a new zone i'm going to put it in australia east resource group i'm going to call the zone assign award dot com and let's go ahead and create this zone and let's go to our dns zone and now i'm going to create a record set and for the name i'm going to specify it front door for example and in here i'm going to choose a c name and i'm going to link it to the dns record for my front door so i'm going to browse to the front door and copy the front end domain name for my front door and let's put it in the alias of my cname record let's take out the https and let's add this record our record set has now created so let's go back to our front door and see how can we apply these changes so i'm gonna go to the front door designer and then i'm gonna go ahead and add a custom host name and in this case i'm gonna add the front door dot assign award dot com and definitely it's not going to work because this is not an actual domain name but if you are using an actual domain name that you have already registered with a domain provider it should work and you will be able to make your users use the custom host name that you entered in here to access your website through front door now there is an interesting point you need to be aware of if your custom domain has already some production workloads because you might experience a little bit of a downtime until this domain changes took place and to avoid this you need to map your custom domain to the default front end host for the front door which is going to be afd verify subdomain and it's going to be the exactly same steps i've just showed you before however you are going to do it temporary to ensure that your users will be able to access your domain until the dns mapping took place this is only required if your custom domain has a production workload however if you are going to have a brand new custom domain name that doesn't have any production workloads then you shouldn't worry about this temporary step at all now let's go back and clean things up and i'm going to go to my dns zone and delete my dna zone that's all i have for you in this video thanks for watching and i will see you in the next video hi everyone in this video we are going to talk about how can we secure our custom domain name using https generally speaking the default endpoint for azure front door is secured by https as you can see in front of us here but this is not the case when we define a custom domain name for our front door you have to define or you have to configure the https for the custom domain names you add to your front door so i'm gonna go ahead and put a custom domain name here i'm gonna put my name and according to the last video it's not going to work because you will need to add a cname record to your domain provider anyway if we scroll down a little bit you will see that we have an option here to define a custom domain https so let's go ahead and enable it then you are going to choose what is the minimum tls version that you want to select for your custom domain name i'm gonna go with the latest version 1.2 then when it comes to the certificate management you have two options whether you make azure front door to manage the certificates for you or you can create your own certificate in key vault and there are many benefits to make azure manage the certificates for you first of all it's free like you are not going to pay any post for certificate acquisition or renewal also it's a very simple and easy just one click and you are going to enable a certificate for a custom domain finally and more importantly you wouldn't need to worry about certificate management at all because azure front door is doing it for you so you wouldn't need to worry about any risk of service interruption in case of your certificate has been expired however in some cases you cannot use azure front door to manage certificates on your behalf for example when you have an epics or root domains you can't use azure front door managed certificates in this case you will have to use an azure key vault and use your own certificate for the epics and root domains and if you don't know what root domain or apex domain means we are going to talk about it in more details in the next video so for the first option to make azure manage your certificates on your behalf this is all the configurations you have to do however if you want to use a key vault and use your own certificate for epics or road domains you will have to do some more steps as you can see in here the azure portal suggests us to run some commands to create a service principle and give it an access to the key vault where my certificate is stored however i would rather to show it from the azure portal how this work and what are the exact steps that we will need to do so i'm going to go ahead to azure active directory and i'm going to browse to app registrations and i'm going to create a new app registration i'm going to call it front door app and let's go ahead and register it and i will need to go to my subscription to create a service principle to the front door app i just created so i'll go into my subscription browse to access controls and add a role assignments and in here i'm gonna specify a contributor rule to the front door app i've just created and in here i'm going to select the member which is going to be front door app and then i'm going to select it and let's go ahead and assign this rule to my subscription then i'm going to browse to key vault to go ahead and create a key vault and create a self-assigned certificate and show you how i can assign it from the front door configuration now let's go ahead and create a key vault i'm gonna put it in australia east resource group gonna call it key vault front door certificates and i'm going to put it in australia east region standard tier i'm gonna change the days to retain deleted volts to seven days which is the minimum number of days you can go for like if i try to make it two it won't work now let's go to the next steps and define the access policy so since i am the creator of this key vault i have already an access to the key vault but i still need to create an access to the front door app i just created so firstly let me select get for the secret permissions and also for the certificate permissions and when it comes to the principle here i'm going to choose my front door app i just created let's select this one and let's add this access policy then moving to the networking i am not going to choose or specify any networking restrictions however you shouldn't do this in a production environment you should restrict the access to the secrets in your key vaults at all times now i'm going to go ahead and create my key vault all right my key vault now is created so i'm going to browse to my key vault and let's go to certificates and i'm going to create or generate a new certificate self-assigned certificate i'm going to make the cn name to be my name for example and then let's leave everything to the default values i'm gonna go ahead and create this certificate now i'm gonna go back to my front door and i'm gonna show you how i'm going to assign the certificate i just created in the key vault to my custom domain name so again i'm gonna put the custom host in here in the https and now i am going to choose using my own certificates and in here i can choose my key vault and the secret which is certificate and then the certificate version usually it's recommended to go for the latest one and these are all the changes you will have to do to choose your own certificates to secure or provide an https security for a custom domain name that you create in your edge or front door that's all i have for you in this video now i am going to clean things up so i'm gonna delete the key vault and then i'm gonna remove the role assignment for the front door app and then i'm going to go back to the active directory and delete frontal door app i've created so this was all i have for you in this video we have seen how can we secure our custom domain names using https either using azure front door managed certificates or using your own certificates that are stored in key volts thanks for watching and i'll see you in the next video hi everyone in this video we are going to see how can we create an apex domain name for our azure front door but firstly let's understand what apex domain name means so if i'm going to open a new browser tab and type in husseinawad.com this is an example of epic's domain name or a root domain name however if i'm going to put any prefix like front door dot hussein award dot com or dev.hussein award.com then in this case it won't be an apex domain name so what's the difference for us if you remember in a previous video when you have created a custom domain name for our azure front door we created a cname record for our domain provider and linked it to the front end of our azure front door however there is a limitation of linking or creating a cnm record for the apex domain name so if you want to have your custom domain name to be your apex domain name for the azure front door it won't work by using the cname record for your domain provider so i'm gonna go ahead now and show you how can we do it in vdn zone so firstly i'm gonna create a dna zone i'm gonna put it in australia east resource group and i'm gonna call it hassanawad.com and let's go ahead and create the dns zone let's go to the our dna zone and let's create a cnm record which what we have done before when we tried to create a custom domain name we called it front door.hussainawad.com and we linked it we created the cnn record and we linked it to the front end of our azure front door let's take the https out however i want you to notice something in the cnn record this is going to be what the client need to use in order to be able to access your custom domain name as you can see here it's not the apex domain name and sometimes you want to allow your customers to be able to access your custom domain name by just hitting the apex domain name and in this case by just typing in husseinawad.com however as i said before there is a limitation for creating a cname record for the apex domain name so let's go ahead and see what does this mean so if i try to create a c name record for the apex domain name it won't work it will ask me to provide some prefix for the custom domain name as you can see here it's not allowed by dns protocol to create a cname record for the apex domain name but what we can do in this case is to create an ales record and in this case it will allow me to create a custom domain name for the apex domain name and in this case i'm gonna create a record set and i'm gonna route it to my azure front door and then let's go ahead with that now my a les record has been created and then when the client wants to access my custom domain name they would be able to access it straight by typing in the epics domain name of my domain so let's go back to my azure front door and see how can we add this epic's domain name as a custom domain name for my azure front door so i'm going to go ahead and put the apex domain name in the custom host name in here so i'm going to put my name in here and if you want to have https protocol for your custom domain name then you go ahead and enable it and if you remember from a previous video that you cannot use a front door managed certificates for the epics domain names and in this case you will have to use your own certificate that's stored in a key vault and i'm going to refer you to the previous video to see how can we use a key vault to create a certificate and then to be used for the azure front door in case you are using the epics domain name as a custom domain name for your azure front door so this is the key difference between the c name record and the a alias record cname records cannot be used for the apex domain name and if this is what you want you need to create an alias record and always remember if you are going to go ahead and create some custom domain name for an apex domain name then you will have to use your own certificate that's stored in key vault because front door managed certificates cannot be applied for an epic's domain names that's all i have for you in this video so i'm gonna go ahead now and clean things up so i'm going to delete the dns zone i've just created thanks for watching and i'll see you in the next video hi everyone in this video we are going to see how can we do redirection from http traffic to https through our azure front door to understand what this mean let's copy the front end of our azure front door and put it in incognito window you can notice here it's https traffic and when we hit it we get a secured traffic through our backend pool but let's try to change the https to http only and see what we will get in result we had been redirected to our backend pool but in this case our traffic is not secure because it's over http protocol and what we are going to see in this video is how to redirect the http traffic to https now let's get started let's go to our front door designer and then let's edit our routing rules i'm going to change the name of our routing rule and make it http redirection and then for the accepted protocol i'm going to choose http only and the front end is already selected the front end of our azure front door now i'm going to choose the route type to be redirect and i'm going to make it for http so for every incoming http traffic through the azure front door it's going to be redirected to https and i'm going to go ahead and update this rule actually i need to go ahead and create another routing rule i'm gonna call it back-end routing and this rule it's going to accept only https traffic the front end is the same front end of our azure front door and then i'm gonna forward it to our back in the pool through https only and then i'm gonna go ahead and add this routing rule then let's save our changes all right now my changes has been saved let's get back to incognito to test our changes and as you can notice here when we try to hit the front end of our azure front door we have got not secure traffic because we try to access our front door using http protocol and now after we have created this routing rule we are going to be able to redirect the http traffic to https so we are going to end up having a secure connection to our backend pool so let's go ahead and refresh this page and as you can see here it's now secured traffic and if we had a closer look at the protocol it's https even though if we try to change it to http again it always end up with https this is according to the redirection we have configured in our routing rule to redirect http traffic to https that's all i have for you in this video thanks for watching and i'll see you in the next video hi everyone in this video we are going to see how can we do url redirection in our azure front door we have already seen how can we do a traffic redirection like how can we redirect http traffic to https in the last video now in this video let's go ahead and go to our front door designer and then let's click on the back end routing and what i'm going to change here is the route type instead of forwarding the traffic to our back in the pool i'm going to redirect it permanently to another host and in this case i'm going to use google and i can change the destination path as well so i'm going to make a search query to a specific query string parameter like for word test and then let's go ahead and update our routing rule and let's go ahead and save our changes all right now my changes has been saved so let's go ahead and open incognito window and let's copy the front end of my azure front door as we have configured our routing rule the traffic has been redirected to google and performed a search for word test this is just to show you how can we do or configure url redirection in the routing rules in your azure front door so let's go back and revert our changes so i'm going to go for the back end routing and bring it back to forward the traffic to our back in the pool and let's go ahead and update our routing rule and then save our changes that's all i have for you in this video thanks for watching and i'll see you in the next video hi everyone in this video we are going to talk about the back in the targets and the back the pool in the azure front door so let's go to the front door designer and we are able to see here the list of the back end pools we have configured in our azure front door so let's dive deeper into this so this is our back in the pool and as you can see here we have created two back end targets for our back in the pool and these two targets could be hosted in azure or on-prem or any other cloud provider as long as it's reachable through the public internet and it has a public ip address then you could configure it as an endpoint or a target for your back in the pool let's go ahead and add a new back end and as you can see here these are the different host types that you can add as a back in the target for your back in the pool and we have already added two app services as a back in the target for our pool and you are able to add all of these services and if you want to add something else that hasn't specified in this list you can go for the custom hosts and then you specify the public ip address or fully qualified domain name and then you will be ready to go so let me change it back to the app service but before we get into that i want you to notice here the application gateway could be a target for azure front door which is quite interesting like both of the front door and application gateway are considered to be one of the azure load balancing services so we are going to direct the traffic from one load balancer to another load balancer which is interesting but the main difference here as i said at the beginning of this video or this course that the azure front door considered to be a global service so you are going to have the front door to accept the traffic globally coming from your customers and then after you are going to direct the traffic to a different regions you can place a regional load balancer which is in this case could be application gateway to route the traffic to different instances within the same region anyway so let's get back to the backend targets so if we select an app service for example you will get to choose a subscription where the backend instance is gonna be hosted and this is one of the interesting things about azure front door because it's a global service so it's not tied to a specific subscription you can specify any instance in the sim subscription or in a different subscription maybe in the same region or in a different region and then you get to specify the backend host name which is in this case the host name of my app service and then the host header is going to be filled automatically and then you get to specify the http port https and then we will have the priority and weights which are two interesting configurations and let's dive a little bit more into these so for the priority one there is something called priority traffic routing which allows you to configure what would be the primary instance and what would be the first backup second backup and so on so it's a way to allow you to configure active active configuration or active passive configuration which are very common terms in disaster recovery scenarios so what does it mean so let's get back to the back end pools as you can see here both of my back in the targets has priority one which means both of them are going to accept the traffic at the same time which makes both of them an active active configuration for my azure front door however if i'm gonna go ahead for the second app service and change its priority to be two what does this mean that all my traffic now is going to be directed to app service one which has priority one and app service two will never get any traffic as long as app service 1 is up and running this is what we mean by active passive configuration and this is very common in disaster recovery scenarios you can configure the priority to be any number from let's first bring the priority back to b1 for app service two the priority here can be any number between one to five like if i try to put six in here it won't work and the lower the priority the lower the number the higher the priority which means like one in here will be the highest priority in this configuration now let's come to the weights which is another interesting configuration you can do for the azure front door and it's called weighted traffic routing where you can assign the weight for each backend in the front door configuration and it can be any number between 1 to 1 thousands and the default is 50. as you can see here could be any number between 1 2 and thousands we are going to come back to the weighted traffic routing in more details probably in the routing section and it's important to mention that the host header should be exactly the same as the host name if you are using any of the app service or blob storage or cloud service now let's get back to the back in the pool and see what other configurations we can do for the back in the pool itself but firstly let's talk about what the back in the pool means it's a logical grouping of your application instances could be in the same region or in a different region but all of these instances has to do the same job and you could have them in an active active deployment or you could have them in an active passive configuration as i've talked about in the priority traffic routing before and in order for azure front door to know the healthiest tedious of the back in the targets azure front door is going to use health probes to know the healthy status of those backend targets so you can specify the path of your healthy probes and which protocol is going to operate on whether it's http or https and when it comes to the probe method you could choose either of head or get verbs however for lower load and cost you should go for the head yeah it's already mentioned in here and also you get to specify the interval how often as your front door is going to check for the healthy status of the back and the targets and the default here is 30 seconds then finally here we are coming to the load balancing which is a way to help as your front door to decide how it's going to evaluate the healthy status of the back and the targets so let's say that we set our sample size to be 4 and our interval here is 30 seconds and we have configured that the successful sample required are going to be two so over the last two minutes which is the time required to send the four samples we configure the azure front door to receive at least two successful samples from the back in the target in order to mark that back in the target as a healthy back in the target finally here we have the latency sensitivity this is what you are going to define if you want to make your azure front door send the requests to beckons within a specific latency range or you just forward the request to the closest back end to the azure front door and again we are gonna come again to the latency traffic routing more details in the routing section that's all i have for you in this video we have talked about the back in the pools and the backend targets thanks for watching and i'll see you in the next video hi everyone in this video we are going to see how can we play around with the rules engine and add the security headers to our front door so let's get started by going to the azure front door and go to rules engine configuration and let's go ahead and add a new rule i'm going to call it my rules engine and the rule name here it's going to be my rule and in this case i'm not going to specify any condition because i want to apply this security header to all requests coming through my azure front door so let's go straight for the action and add a response header and let's append content security policy and for the header value here let's put script src self and then putting the https api.net or any other url you would like it's not actually going to work now after we have added the rules engine we need to get back to the front door designer and attach the rule engine we have created to the routing rules so as you can see here in our routing rule there is no rules engine is configured now let's go ahead and select my roles engine i've just created and let's go ahead and save my changes now my front door has been updated so let's go and test it so i'm gonna browse to my front door dns as you can see the web app is stopped so i need to start my app services so let's select all of them and start my app services they are now ready now as you can see our front door has directed the traffic again to our app services now how can we tell that the rules engine that we have created actually took place let's say press on f12 to see the console and as you can see here the content security policy directive that we have is specified violates some requirements because actually the endpoint i have entered is not actually working i just put it to show you how can we add a new security header to the http responses that are coming out of the front door and how we can put a specific values on those headers this is just to show you how can we play around with the rules engine and create some actions or add a security headers to the http responses coming out of the front door now let's go ahead and clean things up because we are going to get back to the rules engine in more details later this is just to give you an overview about what rules engine is about so i'm gonna go ahead and delete this rule engine but it's already associated to the routing rule so what i need to do is to de-associate my rule engine from the routing rule and then i will be able to delete my rules engine from front to door configuration now let's get back to the rules engine configuration and delete the role engine i have created that's all i have for you in this video thanks for watching and i'll see you in the next video hi everyone in this video we are going to go ahead and create a web application firewall policy and associated with our front door so let's get started and see how can we do this let's search for web application firewall policies and let's go ahead and create a new policy so when i create the laugh policy i have to choose what service this policy is for and in this case it's going to be for my front door and i'm going to put it in australia east resource group and i'm going to call it wealth front door policy and leave it as a detection mode as a default now moving to the managed rules i'm going to choose rule set 1.1 and as you can see here i can enable or disable specific rules according to my requirements and as you can see here all of these rules are already enabled by defaults if you have some specific requirements to exclude some rule you can just go ahead and disable this rule however i'm not gonna go ahead and do that also you can add additional rule set like bot prediction rule set and similar as before you are able to see the enabled rules and you can go ahead and disable any rule that doesn't work for your requirements now let's go to the policy settings and i'm going to leave everything to the default values and for the custom rules i'm going to create a new custom rule so i'm going to call it my custom rule and i'm gonna give it a priority one and i'm gonna make it for the jail location if it's not australia then i'm going to deny traffic so i'm creating a geolocation filtering here to block any traffic that's not coming from australia let's go ahead and add this custom rule and in here i can go ahead and add the front door for this policy as you can see here however i'm not gonna do it from here i will do it from the front door after this policy is created so let's go ahead and create this wealth policy all right the left policy is now deployed let's get back to the front door and see how can we associate the wealth policy with our front door and as you can see here we have a menu item for web application firewall and if i'm going to select the front-end domain for my azure front door and then i will be able to apply a policy for this domain and now i'm going to specify the off policy i've just created and i'm going to go ahead and add it to my azure front door and then let's save my changes all right now the left policy has been associated with my front end domain i have configured for my front door this is just to show you how can we attach wav policy with our front door and we are going to come back to the web application firewall port in the front door in more details later i was just showing you how can you configure or ask a site of policy with an azure front door now let's go ahead and clean things up so i'm going to select the front in the domain of my azure front door and i'm going to remove this policy and save my changes and now let's go back to the web policies and remove our policy let's select our wealth policy and go ahead and delete it that's all i have for you in this video thanks for watching and i'll see you in the next video hi everyone in this video we are going to talk about the caching behavior in azure front door you remember when i mentioned that azure frontal door is a global service and also considered to be a cdn because it has an ability to cache certain contents at different age locations around the world so let's go ahead and see from where can we configure the cache in azure front door so it is in the routing rules where you can enable and configure the caching behavior for your edge or front door and as you can see here once you enable cache you will be able to select the cache behavior whether to ignore a query strings or cache every unique url or ignore specific web strings or include specific query strings these are the different caching behaviors that you are asking front door to implement when they cache your content at different edge locations and then you are coming to the dynamic compression you can enable it or disable it as you like then coming to the cache duration or default cache duration so in any caching system there is a term called cache expiry this is a duration of time that the azure front door is going to keep your cached content at the edge location and it's not going to bring it from the back in the target this is to speed up the response that's been sent to the end user so if you are going to enable the default cache duration for azure front door then azure front door is going to keep your content at the different edge locations until the default cache duration expires however if you wish to specify your own cash expiration policy you can go ahead and specify the minimum cash duration you want as your front door to use when they case your content so why cash expiration exists it actually exists to ensure that the end user is going to get up-to-date or latest content from your back-ends and you need to maintain a good balance here for your cage duration because if it's too little probably it might be useless because every few seconds as your front door might need to get the fresh content from the back and the targets at that point your caching wouldn't achieve much benefits however if you have made the cache duration too big then the in the client might get all the content that you have already updated some time now let's assume that you have configured your caching behavior in a certain way and for some reason you want to clear all the case in all edge locations around the world maybe you have made a big update and you want to make sure that the end users are going to start fresh receiving your latest or recent content there is a way to do this by purging your cache so you can go ahead here and purge all content in all edge locations around the world or if you are more specific you can specify what exactly you want to cache maybe you can go for the road domain or maybe you go for a specific file like pictures and then welcome dot png for example or you can go for a wild card domain maybe going for docs and then all of the documents under docs these are the different ways you can instruct azure front door to purge certain caged content at different edge locations and of course you can purge all if you analyze your front door to get rid of all caged content in all edge locations around the world caching is going to improve the performance of your solutions a lot and you should be consider using cache whenever it is applicable for your architecture that's all i have for you in this video thanks for watching and i will see you in the next video hi everyone in this section we are going to dive deep into the rules engine configuration firstly we will understand what is the rules engine architecture and when exactly takes a place in terms of the incoming request that's hitting our azure front door then we are going to talk about the different conditions you can specify for the rules engine and the different actions you can trigger let's get straight into it thanks for watching and i'll see you in the next video hi everyone in this video we are going to talk about the rules engine in the azure front door and we have already created a rules engine and associated it with a routing rule in a previous video if you remember and now we are going to dive deeper into the rules engine configurations so simply speaking the rules engine allows you to change or customize the http requests that are coming or handled by azure front door so you can apply a certain behaviors on the incoming requests based on specific conditions and there are some scenarios you want to consider using the rules engine for your age or front door maybe when you want to enforce https connection with the end customer to ensure that they are always have a secure connection with your application or maybe when you want to implement some security headers to prevent common browser vulnerabilities like http restricted transport security or cross-site scripting or content security policy or exit frame options or access control allow origin headers for cross-origin resource sharing this kind of security-based attributes that can be defined in the roles engine configurations or maybe when you want to route a request to a mobile or desktop versions of your application based on some information in the content or cookies or query string or http headers or if you want to make some redirection maybe internally or externally based on the incoming protocol or incoming request path and we have seen the url redirection in a previous video and you should be able to achieve the same using the roles engine as well also if you want to modify the caching configurations based on the incoming request and if you want to change or rewrite the request url and forward it to a specific back in the target based on the incoming request parameters so those are the different things you can do in the rules engine configurations now let's look at some diagrams and try to understand how the rules engine work and when actually it's going to be executed so firstly when the client sends the request to azure front door the first thing it's going to get evaluated is the wealth policies to ensure that the request is fine secure doesn't have any security vulnerabilities to our applications and once the dev policies are executed and nothing wrong with the incoming request then the rules engine is going to take place usually the rules engine has a condition and an action when the condition is met when the condition is true the action is going to take place when the conditions falls the action is not going to be applied and in this scenario here we have configured our action to extend the lifetime of the cache to be the maximum age this only going to be executed when the condition is true which is the request the file extension is gpg however when the condition is false then the request is going to be routed to the routing rule and then the back end is going to respond with the default cache control we have configured in our back in the targets so in the incoming request match the condition we have is specified in our rules engine then in this case the cache control is going to be changed in our response header to the customer and if the condition doesn't met in the incoming request then the request is going to be routed to the routing rule and then we are going to respond with the default cache control to the customer now let's look at another example to help us understand it better let's say that we have created the rules engine with a condition to check for the device type the client is using to connect to our application and based on our role's engine condition here if the device is mobile then we are going to direct the customer to a mobile version of our app however when the condition is false and the customer is connecting from a desktop then we are going to direct it to the routing rule which we are going to respond with the desktop version of our application so according to our rules engine configuration if we have a client trying to connect to our application from their mobile device then we are going to respond with the mobile version of our application and if we have another customer connecting to our application using their desktop then we are going to respond with the desktop version of our application this is just to give you a quick overview of what is the rules engine and where it sets in terms of the wealth evaluation and rules engine configuration and when exactly it gets executed and in the next few videos we are going to dive deep into the roots engine and its conditions and actions so you will be able to tell what are the different conditions you could set in the rules engine and what are the different actions you could apply as well that's all i have for you in this video thanks for watching and i will see you in the next video hi everyone in this video we are going to see the different conditions we can specify in our rules engine so let's get started by creating a rules i'm engine to call it my rules engine then my rule name here it's going to be roll one now let's go ahead and add different conditions let's start with the device type and this allows us to identify requests that are coming from a specific device whether it's mobile or desktop also we can add a condition based on the post arguments and this will help us to identify requests based on arguments sent in the post request body let's say that we want to identify the customer name in the post arguments if it begins with some values like x and also i can do some transformation for these arguments however i'm not gonna do any at the moment also we can create a condition on query string and this will help us to identify requests based on a specific query string maybe for example it's going to contain language equal english us also i can specify a condition based on the remote address and i can specify a jail match at selecting few countries or all countries that i would like to identify in my request or i can specify ip address range could be a single ip address or could be assider range also i can add a condition based on the request body to identify requests based on a certain information or certain text that's been sent in the request body so let's make a condition if it contains some words like error for example also i can make a condition based on the request file name to identify requests that include a specified file name in the url if it's equals secure dot xml for example also i can make a condition based on the file extension so i can identify requests that include the specified file extensions in the request url so if it's equal maybe pdf or xml or doc i can include multi values in the values here also i can add a condition that are going to identify requests based on a specific request header and let's put my header name to be my header and then it's going to equal certain value like 10. also i can add a condition based on the request method so i will be able to identify the incoming requests based on a specific http verbs maybe i have incoming request for a delete verb or a trace verb i am able to identify these verbs for my incoming requests also i can add a condition based on the request path to identify some requests based on the pass or the incoming request path maybe if it contains some api the domain in the request path as you can see here after i have created 10 conditions i'm not able to create or add any more conditions because this is the maximum number of conditions i can create for my rules engine so what i'm going to do now is just delete the last one so i can add extra conditions i can add another condition based on the request the protocol whether it's http or https so i can identify the incoming traffic or incoming requests whether they are http or https also i can add another condition for the request url so if the request url contains a specific text i will be able to identify them in this condition for example if it contains some values like api for example i will be able to detect it and it's going to trigger my condition now we have seen the different conditions we could configure in our rule now let's see what are different actions we can trigger we can create an action for the request header and we can append overwrite or delete maybe i'm going to append it and add content security policy as a header then the header value for example is going to be hundred also i can add an action for the response header that is going to be returned to my clients i can add some action or maybe delete some of the headers sensitive headers that i don't want to be sent back to my clients maybe in this case could be the asp.net version also i can add an action to override the routing configuration i have specified in the routing rule so i can either forward or redirect the traffic so if i'm gonna forward it i can forward it to a different back-end pool we're choosing the forwarding protocol whether it's http or https whether i'm gonna do any url rewriting or any caching would be enabled for this rule and if i enable the caching in here you will see that i can play around with the caching configuration or i can route the traffic or redirect the traffic to another destination based on the configurations in here and you have already seen the url redirection in the routing rules configuration and you should be able to get or achieve the same results using the redirection or forwarding configuration in the rules engine configuration this is all i have for you in this video this is to show you how can we create different rules engines and specify some conditions and also trigger some actions based on those conditions thanks for watching and i will see you in the next video hi everyone in this video we are going to dive deep into the routing architecture and understand how the routing works in azure front door and we are going to dive deep into the different routing rules and how azure front door is matching the incoming request to a specific matching rule and then we are going to talk about the different routing methods that azure front door is using to route the traffic to a particular backend instance so we are going to talk about the latency based routing weighted based routing priority based routing and session affinity based routing that's all i have for you in this video thanks for watching and i will see you in the next video hi everyone in this video we are going to talk about the routing architecture of the azure front door like when the client sends a request to azure front door what's again happen and how azure front door handles the client requests so in this video we are going to dive deep into all of these layers and faces inside azure front door to see and understand how azure front door can process the incoming client requests the first step we have here is when the client decided to send the request to azure front door edge location as we have said before azure front door is a global service and also it can be used as a cdn content delivery network and it has edge locations around the world and based on the client location the client request is going to be directed to the closest edge location to the customer or to the client location and this is going to be the first step then after that azure front door is going to try to match the incoming http request to a front door instance that you have configured to your environment and front door will be able to do this by using the host header if the incoming request and if you are using a custom domain name as i said before you have to register your custom domain name in the azure front door as well as in your domain provider then after azure front door finds the right azure front door instance that the customer wants to hit then what's going to happen is establishing the tls connection through tls handshake between the client and the server using the tls certificate that you have provided for your custom domain or in case you are using the default endpoint of front door then the front door certificate is going to be used in this case then moving to the next step which is evaluating the waf rules this is definitely going to take place only if you have enabled the web application firewall for your azure front door and if you didn't enable wf inside your front door then there is no waf rules is going to be executed and in this phase if there is any violation has been detected then azure front door is going to stop the processing of the incoming request and is going to respond to the client with an error however if the incoming request with genuine doesn't have any security issues it's going to be processed or forwarded to the next step where front door is going to match the routing rule to the incoming request and we are going to dive deeper into this in a separate video and as we said before there are rules engine can get associated with the routing rules and if you have already a society some rules engine with your routing rules then they are going to be evaluated and see if they are meeting the conditions or not keeping in mind that the rules engine actions can override the routing rules you have already defined for your edge or front door then if you have configured caching for the azure front door then if the response has been already caged in one of the azure front door edge locations then in this case the response is going to be returned from the edge location sketch assuming that the cache was enabled then the process it's going to be terminated at that point and the client is going to get a response from the front door edge location cache however if the cache was disabled then the execution is going to move on to the next step where azure front door is going to select a back in the target from the back in the pool as we said before the back in the pool it's a logical grouping of many resources to be in the same pool and front door is going to make this selection based on three factors the healthy status of the back and innocence whether it is healthy or not and frontal door is able to know this by using the health probes as we said before the second factor is the routing method for the back in the pool and also if you have enabled session affinity in azure front door these are the three main factors that azure front door is using to determine what would be the back end instance that are going to be selected to send the incoming request to this back in the targets finally frontal door is going to go ahead and send the incoming request to the selected back in the target in order to be executed and then returning the response to the client so these are the different phases and processes and layers that are going through inside azure front door in order to process the incoming request and return a response to the client it's very important to know where these layers set within azure front door and when they are getting executed and what layers can override the actions of a previous layer so you understand how it works internally so when you configure azure front door you can configure it correctly that's all i have for you in this video thanks for watching and i'll see you in the next video hi everyone in this video we are going to talk about the routing rule matching in azure front door in a production environment you are not going to end up having two or three routing rules as we see in front of us here you are going to end up having hundreds of routing rules in your production workloads so it's very very important to understand how the routing rule matching works and you should be able to tell which routing rule is going to be triggered based on an incoming request that is hitting your azure front door and in this video we are going to dive deep into the routing role matching in azure front door so let's get started and dive into one of our routing rules we have configured before so when it comes to the routing role matching i want you to imagine two sides the left hand side and the right hand side and what we are trying to do here is to do some matching between the left hand side and the right hand side the left hand side is going to be the incoming match and it's going to be determined by three factors the incoming protocol whether it's http or https or both protocols second factor is going to be the front end whether it's a default endpoint of azure front door or a custom domain name you have it specified for your front door this is the second factor and the third factor is the path you have specified in the incoming requests so these three factors together are considered to be the left-hand side of the picture and what we call it the incoming match and what sets on the right hand side is the route route so based on the three factors i just talked about we wanna route the traffic coming through the three factors into a specific route that sits on the right hand side and we are going to dive deeper into the matching process for the front end domains and for the paths as well so let's go to the azure documentation and see some examples of the front end matching the matching rule is very easy and straightforward the first thing as your front door is trying to do is to find an exact match to the incoming request if azure front door didn't find any exact match then it's going to respond with 400 bad request error so let's say that we have defined three routing rules in azure front door routing rule a b and c and these are the different front end hosts for the different routing rules and it are the different paths as well now let's try to work out which routing rule is going to be matched based on the incoming front-end host if the request was full.contoso.com we have it already defined in routing rule a and routing rule b and in this case rules a and b are going to be matched for these requests however if we have a request for fabricam.com again we have an exact match in rule c then our matching rule it's going to be routing rule c and if we try to hit images.fabrikam.com which we don't have an exact match in our front end hosts then we are going to get 400 response code bad request and if we try to hit foo.adventurework.com again we have an exact match in routing rule c so we are going to respond with routing rule c however if we tried these three routing rules that we haven't defined before like contoso.com adventureworks.com or northwindtraders.com for all these three requests we are going to get 400 response code bad requests because there is no exact match to any of these requests in the front end hosts in our routing rules hopefully it now make more sense now let's have a closer look at the path matching so we have already talked about the front end matching and understand how it works now we are going to talk about the path matching and it's very similar to the front end matching rules so firstly azure front door will try to find an exact match to the path if you didn't find an exact match to the incoming path then azure front door is going to try to find a routing rule with a wild card path if azure front to door didn't find it then it's gonna respond with 400 response code or bad request so let's try to work it out again as we have done before so let's say these are the different routing rules we have configured for our azure front door and this is the front end host configuration all of them are the same and the path here is different and what we are going to work out here on the right hand side of the screen is to try to work out what would be the matched routing rule based on the incoming request so when we get a request for contoso.com again it's an exact match to our routing rule a so in this case it's gonna be routing rule a and if our incoming request contoso.com backslash a so it's going to be an exact match to routing rule b we have is specified and our matched rule here it's going to be b and if we have got an incoming request for contoso.com a b again we have an exact match for routing rule c and our matched rule it's going to be rule c and if we get an incoming request contoso.com backslash a b c again we have an exact match with the rule d and this is going to be our matched rule however if we have got an incoming request with something random like backslash a b treble z that we don't have any exact match in our path here in this case we are gonna go to the next step which azure front door will try to match it with a wild card path and in this case we have it already defined in routing rule b and b here is going to be our matched rule and if we get some incoming request contoso.com backslash abc backslash we have an exact match to this incoming request which is routing rule e so our matching rule it's going to be e and if we are get an incoming request backslash abc backslash d as you can see here we don't have an exact match so we are going to move to the next step where we are going to look for wild card path and in this case we have routing rule f meets our condition and rule f it's going to be our matched rule and if you have got an incoming request a b c backslash d e f we have an exact match in routing rule g and g here it's going to be our matched route and if we have got an incoming request abc backslash def treble z as you can see we don't have an exact match so we'll try to match it with a wild card path and we have already one here for routing rule f and in here and i'm gonna put routing rule f it's gonna be matched for this incoming request and if we have got incoming request e abc backslash g h i again we don't have any exact match so we are gonna go for the closer wild card and as you can see here routing rule f is going to be matched to this incoming request and if we try to put contoso.com backslash path again we don't have any exact match don't confuse it with routing rule h it's a little bit different so we don't have an exact match to backslash path and in this case we're gonna look for a wild card and we are going to go for routing rule b if we have got an incoming request contoso.com backslash path backslash we have an exact match which is routing rule h and in this case it's gonna be our matched route and finally if we have an incoming request backslash path backslash z again we don't have an exact match in our rules configuration so we are going to go for the wildcard path and we are going to select routing rule b these are just a few examples to show you what would be the routing rule that is going to be selected for the incoming requests based on the configurations we have configured in our azure front door however we haven't seen a scenario here like what if we had an incoming request that doesn't have an exact match and it doesn't match with the wild card path and in this case we are going to look at this example here we have a route rule a with a host profile dot contoso.com with this path and if the incoming request is something completely different that we don't have any exact match and we don't have a wild card that matches the incoming request then in this case azure front door is going to respond with 400 response code bad request as i said before it's very important to understand how azure front door makes it a matching decision for the different routing rules because in production environments you are going to end up having many routing rules and you need to be able to tell which rule is going to be triggered for different incoming requests that's all i have for you in this video thanks for watching and i'll see you in the next video hi everyone in this video we are going to talk about the different routing methods that azure front door is using to route incoming traffic requests to a selected backend instance an azure front door actually is using four routing methods in order to do this first one let's dive first into the back end pool first routing methods that azure frontal door is using is latency based routing this is when azure front door is going to send the client requests to the instance that has the lowest latency and also within the acceptable latency sensitivity that we have configured in our back in the pool generally speaking the user requests are going to be sent to the closest instance to the user location so when i say the closest instance i don't mean geographical location i mean from a networking latency perspective then the second routing method that azure front door is using is the priority routing methods this is when you define some set of primary backend instances and some set of secondary back-end instances and then when the primary instances are not available for any reason then the traffic is going to be directed to the secondary back in the instance we call this like active active deployment or active passive deployment to ensure high availability architecture for the backend services and the third routing method we have in here is the weighted routing method and you can configure it in a way to ensure that you distribute the traffic evenly across your backend instances only if the latency is within the acceptable latency sensitivity range that you have specified for your backend pool finally and it's not in the back in the pool it's in the front end configuration this session affinity this is when you wanna enable session affinity in the front door then azure front door is going to send subsequent user requests to the same server where the user had already initially sent their first request it's kind of a maintaining the same session for that particular user now out of all of these four different methods how azure front door is going to determine which instance or which routing method is going to take place so let's look at this example here in azure documentation so these are the different phases or stages that azure front door is going to go through in order to determine what is the selected instance that azure front door is going to send the traffic to it so in this scenario we assume that we have six instances a b c d e and f and in our first phase azure frontal door is trying to determine out of these six instances which instances are the healthy ones and we ended up having only four instances that are considered to be the healthy instances for azure front-to-door so we are walking away from the first step with four healthy instances now we are coming to the second evaluation or second step which is priority based routing assuming that we have configured our backend pool in a way to make a b and d has priority one while instance f will have priority two so according to this configuration we will walk away from the second phase having only three instances valid which are a b and d and moving to the latency step and let's assume that the latency for instance a is 15 millisecond the latency for instance b is 30 millisecond and the latency for instance d is 60 milliseconds and we have configured our acceptable latency or latency sensitivity in our pool to be 30 milliseconds for example so according to this we will walk away from the latency step having two healthy instances a and b because as we see in front of us here d doesn't sit in the acceptable latency range that we have specified so currently we're coming to the last step with two healthy instances a and b that are healthy up and running has a theme priority and within the same latency sensitivity range we have specified in our back in the pool then let's say that we have configured our weights to be 5 for instance a and 8 for instance b then the traffic is going to be distributed in a ratio of five to eight among a and b so for every five requests that are going to be routed to instance a in instance we are going to get eight requests so this is just to show you how azure front door is using different routing methods to make a decision about what would be the selected instance to send the traffic to it now let's dive a little bit deeper into the priority traffic routing and we have talked about it before in a previous video so priority traffic routing allows you to configure high availability architecture for your services so you can have an active active deployment similar to what we have in front of us here when all backend instances has the same priority number or you can configure it to be in an active passive way this is when you have some backend instances has a higher priority than the others so maybe if i'm gonna go ahead and change the priority of the other back-end instance in this configuration i have configured my back in the pool to work as an active passive model priority one is gonna receive the traffic all the time and as long as it is up and running priority 2 will never get any traffic from azure front door priority 2 instances are only going to get traffic from azure front door when priority 1 instances becomes unhealthy or unable to accept traffic from front door for any reason and when we define the priority number it has to be a number between 1 to 5 and the lower the number the higher the priority you are going to specify for your backend instance now coming to the weight traffic routing of our backend pool as we said before it's a way to till or to distribute the traffic evenly across the backend instances and we can configure it to be any number between one to one thousands and the default value is 50. so what's going to happen if the traffic is going to be routed to the backend instance based on the weights we have configured in our back end pool and as long as the latency for the backend instances are within the latency sensitivity we have specified in our back in the pool as we have seen in this example latency routing method takes a place before weighted routing method this is to ensure that all backend instances that are going to get into the weighted traffic routing fits within the latency sensitivity for our backend pool that we have configured in our azure front door and there are many scenarios you want to implement the weighted traffic routing when you wanna have a gradual application upgrade so you are gonna create a new set of instances in the backend pool and then gradually you want to increase the traffic to the new instances until you shift all the traffic to the new backend instances also when you want to migrate an application to azure as well and the final routing method we are going to talk about sets in the front-end host which is the session affinity so by default having session affinity disabled for azure front door azure front door is going to send the requests coming from the same client to the front back and servers and in some situations this might not be the best practice because sometimes you want to implement some session management for your users using the backend servers and if the initial user request has been sent to a particular backend instance you want to maintain the subsequent user requests will be sent to the same backend instance this is what the session affinity will allow us to do will allow azure front door to have or maintain a session for all incoming requests coming from the same user and then allow azure front door to send all these requests to the same server so in this video we have talked about the different routing methods that azure front door is using to route the incoming requests to a selected backend instance and this table is really helpful to summarize what are the different steps and which one takes a place first and how it contributes to the incoming inputs to the second phase that's all i have for you in this video thanks for watching and i will see you in the next video hi everyone in this video we are going to talk about the front door standard and premium tiers although it's still in public preview but i rather to cover it in my video as well so i are going to dive deep and show you how can you create a front door whether it's a standard or premium tier and what are the feature comparisons between standard and premium and then at the end we are going to cover the pricing between the front door classic standard and premium versions that's all i have for you in this video thanks for watching and i'll see you in the next video hi everyone in this video we are going to talk about azure front door standard and premium tier it's not very different from front door classic that we have already seen throughout the video but i wanted to give you a chance to see both tiers so you can see what are the improvements and what are the differences between the classic version of azure front door and standard and premium tier so if i'm gonna browse to the premium tier or front door standard the premium tier you will be able to see the classic frontal door that i've already created before so i'm going to go ahead and create a front door standard premium which is still in public preview at the beginning i have two options whether i want to use an azure front door or use other offerings which is primarily around using a cdn for different providers now let's stick to azure front door and i'm gonna go with the custom create to give you more chance to have a look at the detailed steps of building up our azure front door let's go ahead with that now i'm gonna put it in australia east region and i'm gonna go for the premium tier because some features are only available in the premium tier and i want to give you a chance to have a look at it now let's go to the secrets and here you are going to specify or add different certificates you want to add your azure front door you remember when i mentioned that when you create a custom domain name for your azure front door you need to provide a certificate for the custom domain name and in this screen you will be able to add your own certificate onto the endpoint screen and let's go ahead and add an endpoint i'm going to call the endpoint name to be front door premium then let's put some numbers and let's go ahead and add the end points now you are going to see the different steps i need to do to configure my end point properly so i'm going to start adding the origin group which is exactly the same at the back and the targets that we used to do for the front end the classic so i'm going to call this back end and then in here i'm gonna add an origin so let's go ahead and call this origin one and for my origin type i'm gonna go for upservice and selecting app service one and this is one of the key features that's supported in the premium tier enabling a private link service for your backend targets or for your origins so what is the private link service let's say that you are having some vms in a private v-net or maybe you are using a pass environment like azure app service like what you are using or you want to access blob storage without having these services enabled or accessible to the public internet so having a private link service it's going to allow the front door to be able to access the past environments or internal v-nets securely without exposing those back in the targets to the public internet and when you are going to establish or enable the private link service on a particular origin you are going to receive an email and you will have to approve it before the traffic will start to flow to your backend origin moment private link service is not available in some regions including australia so i'm not going to enable the private link service for my app service let's go ahead and add it and let's add another back in the target or another origin let's call it origin 2 and i'm going to select the other web application i've created before and let's leave everything to the default values nothing new in here all of these things we have talked about it in the azure front door classic so let's go ahead and add our origin group which is our backend then after creating or adding a backend we need to specify a routing rule so i'm gonna call it routing rule and then i'm gonna select the front in the domain and the origin group it's going to be my back end and i'm gonna add the routing rule also i can specify the wave policies and bot protection and vedos attacks while i'm creating the front door premium tier and as you can see although i have a wealth policy already created before it's not applicable to be associated to the azure front door standard or premium tier so i'm going to go ahead and create a new wife policy new wef i'm going to call it front door premium and i need to get rid of the underscore and then add bot protection and i'm gonna associate it to the front end point of my front door these are the main things i need to specify before being able to create my azure front door but probably i have missed some information so let's get back to the name okay i'm gonna call it front door premium and then let's put some random numbers now let's go ahead and create my azure front door so the deployment has failed for some reason and as you can see here because it failed to attach or create the security policies so even though even though that specific step has failed my azure front door has been created and my web policy has been created probably i need to do this step manually at some point anyways so i'm gonna go to my front door premium and see what are the main differences between the classic and premium versions probably it's around the interface in the pointer manager here it's going to be the new interface to organize your back ends routing rules and also enabling your security and wave policies on specific endpoints and here are the domains that you are going to specify in your azure front door whether they are default endpoints or they are custom domain names that you are going to create and the origin groups here are going to be the backing the targets to route the traffic through azure front door to land to the backend targets and the new name that azure front door premium tier is using is origin group instead of backend targets and the rules set similarly as the front door classic you can create certain rules and conditions and use them to override certain actions that have been specified in the routing rules now the security we have it in a separate menu item by itself so i'm gonna go ahead and attach the left policy because it hasn't been attached for some reason i'm gonna associate it to the front end of my front door and then going to the optimization here which is one of the new features in the front door premium so in the optimization it tells me what improvements i could do in my current front door configurations and as you can see i haven't enabled caching or compression on my routing rule in my azure front door and this could be one of the improvements that i could apply straight away now the wealth policy has been associated so let's go back to security and see what are the differences between the front door classic and the premium so here we can see the association with the wealth policy that we have created with our domain and we can dive deeper into the wealth rule here and see what is the difference and the main thing here in the managed rules if we are going to have a look you will notice that azure front door premium could be associated to a higher level of managed rule set offered by microsoft it's still in preview but we didn't had the same chance to associate rule set two to as your front door classic tier if you remember also you have a chance to associate it to a bot protection rule sets and this is the same as we had it in azure front door on all of the actions you can do in the web policy we have talked about in the front door classic there is no much difference although there is much more rules that are associated or created in set two in rule set two now let's go back to the azure front door and in secrets here you can manage your different certificates that are coming from key vault as we have seen before now one of the other key improvements or key features in azure front door premium tier is built in real time reports it allows you to see the data in real time as they come through to your azure front door so you can see the different traffic coming to your azure front door according to different domains also you can see different usage metrics data transferred in and out protocols used how many requests the bandwidth and latency all of this information it's going to be available to you one of the key metrics or key information that i like is the traffic by location and it's been already used in apim which is key for me to tell me if i'm getting an attack from a particular location around the wallet i find it really useful to have a view of where the traffic is coming from that is hitting my services and this has been already available in apim two years ago or something i'm really glad that microsoft added it to the azure front door since it's such a global service now and you have some graphs telling you the cash hit ratio and the cash hit and cash mis percentage so you know what you need to do differently for your cache and then you are going to be able to see the top url top referrer and top user agents all of these are new kind of reports that will be available in the azure front door standard and premium tiers and then if you are using a premium tier you are going to have an access to additional set of reports comes under security here which is primarily focused on the wav web application firewall and you will have more detailed information about how many allow traffic blocked logged or redirected so in the classic version of front door we didn't get to see that level of detail also you will be able to see much detailed information about your security and wealth policies so these are the main things i want you to be aware of when it comes to the azure front door standard premium tiers as i said before they are still in public preview and i'm not sure if azure is going to get rid of the classic front door all together and keep it strict to standard premium tier or probably they are gonna keep both working next to each other i haven't found a clear communication about that but either way we know how both works and what are the differences and what are the new features that you could be using for standard and premium tiers that's all i have for you in this video probably i need to go back and clean things up so i'm gonna go back to my azure front door and and before i delete it i want to de-associate the firewall policy from my front door so i'm gonna go to my wealth policy and the associated from my front door until this happened i'm gonna go back to my front door and i'm gonna delete it now i'm gonna get back to my wife policy and i'm gonna delete it as well that's all i have for you in this video thanks for watching and i will see you in the next video hi everyone in this video we are going to look at a feature comparison between front door standard and premium tiers and as i mentioned before it's around the private origin as you can see here it's not supported in the standard tier and it's only offered in the premium tier and for the left policy you can only apply custom rules for the standard tier and you're not going to have the default rule set for the left policies unless you are going to go for the premium tier also the bot protection it's not offered in the standard tier and finally the security report it's not going to be provided for the standard tier so this is a feature comparison between the key features between the azure front door standard and premium so you can know upfront which tier you should go for based on your requirement and based on what you're trying to achieve however i didn't found any comparison between azure front door classic and standard or premium so if i want to try to put front door classic features i couldn't put it under either of standard or premium because it's kind of mixing of both but it's very useful to keep in mind what are the key differences between the different tiers that's all i have for you in this video thanks for watching and i'll see you in the next video hi everyone in this video we are going to talk about the pricing for azure front door classic standard and premium tiers let's start with the classic tier pricing so for the classic tier pricing it's around four main dimensions data transfer out from the edge locations to the clients data transfer in from the client to the edge locations and then the number of routing rules you have configured for your azure front door and then the bandwidth which is how much data transferred between front door and azure websites and you will be able to see the breakdown of each of these dimensions in the tables below however if you decided to go with azure web application firewall it's gonna have an additional cost that you need to be aware of as well but when it comes to azure front door standard or pricing tier the dimensions are a little bit different so you're going to get a charged based on five dimensions for standard or premium tier the first one you are going to pay base fee based on the tier you are using then you are gonna pay for outbound data transfer from the edge location to your clients and also an outbound the data transfer from the edge locations to the origins which are the back and the targets also you are gonna pay for the number of requests coming from your clients to the azure front door edge locations however you're going to have a free data transfer from the origins which is your back in the target that are hosted in azure data centers and to your edge or front door edge locations and when it comes to the base fee that you will have to pay this is gonna be the monthly price you are expected to pay for standard tier and premium tier and as you can see the premium tier is much more expensive than the standard tier and then you're going to see the breakdown of different cost estimates for different dimensions for the standard or premium tier it's very important to keep an eye on the pricing for the services you are going to use for azure and especially when you are going to have a variable cost that's depending on how much data transfer in and out are going through your service because it's going to change the monthly bill for your usage a lot that's all i have for you in this video thanks for watching and i'll see you in the next video hi everyone in this video we are going to dive deep into the web application firewall or some people prefer to call it wealth and we are going to understand how the web works and when it takes place in terms of the incoming requests to your azure front door then we are gonna dive more into configuring the left policy and what is the difference between managed rules and custom rules and how you can specify both for your environments then we are going to touch on the different wav modes whether it's detection or prevention and also the different policy settings you can specify for your wav policy that's all i have for you in this video thanks for watching and i'll see you in the next video hi everyone in this video we are gonna talk about how the web application firewall works in the previous video we have created a wealth policy and we associated it with our azure front door and by having waff in our architecture it's gonna defend our web application and our web services against common attacks but someone might be asking where the wave lives where the wav is deployed we already know that azure frontal door is a global service and we are going to end up having azure front door instances in all edge locations for microsoft azure networks where exactly the wav is going to be deployed exactly at the edge location so we are trying to add additional layer of security which is our wealth here and we are placing it closer to the attack source closer to the attacker to prevent the incoming attacks before it reaches to your network or to your systems which is going to ensure you have a secure solution scalable at scale and also it's not going to compromise performance because it happens at the edge location and this actually reminds me with one of the cloud design patterns we have talked about it before like the gatekeeper pattern which is simply adding additional layer of security to protect your systems against potential attacks and probably i'm gonna put a link for the gatekeeper video for you to review if you are interested now let's get back to the wealth policy as you can see here it has set of rules managed rules and custom rules managed rules as the name suggests it's managed completely by microsoft azure and for the custom rules you can go ahead and create custom rules by yourself and in case if you had both rules in place like you had already managed rules and you have created some custom rules in this case the custom rules are going to be processed and evaluated before the managed rules because usually when you create a custom rule it means you want to create some sort of exception for something that's been already implemented in the managed rule and we are going to talk about these managed rules and custom rules in more details in a separate video now switching the firewall mode from detection to prevention it used to be in the policy settings but somehow azure moved it to the overview here so from here you should be able to switch your firewall mode from prevention to detection or the other way around so what's the difference when you set your firewall mode to be a detection your firewall will not block any traffic but it's going to log it to the log analytics workspace that we have specified before it's going to be a really good practice to set your firewall in a detection mode in a development environment so you'll be able to see how the firewall deals with different requests coming through your firewall however for a production or testing environment it's really recommended to set your firewall up in prevention mode now let's go and have a quick look at the managed rules and as you can see here we can select the default rule set for our firewall and in this case we have selected rule set 1.0 and also you can add additional rule sets i'm gonna go ahead and add bot rule set which is going to add a managed bot protection rule set to protect my firewall from potential bot attacks all right now my bot rule sets has been added so let's scroll all the way down and have a quick look so we have three categories of bots bad bots good bots or unknown bots the bad bots are the bots coming from a malicious ip addresses and they are identified from microsoft threat intelligent feed and it gets updated every hour you don't really need to worry about it because microsoft manages it for us also we have a good bots like verified search engines or search crawlers and we have set of unknown bots as well this is all i have for you in this video it was a quick walkthrough inside our web application firewall and in the next few videos we are going to dive deep into the managed rules and the custom rules and how they work together also we are gonna have a look at the log analytics workspace logs thanks for watching and i'll see you in the next video hi everyone in this video we are gonna go ahead and create a web application firewall policy and associated to our azure front door also we are gonna enable the log and monitoring on our azure front door so we'll be able to see the different firewall logs in the log analytics so let's get started by creating a web application firewall policy and we have done it before let's go ahead and create one let's select policy for my front door and i'm gonna put it in australia east resource group and i'm gonna call it waf for front door earlier is region and i'm going to leave it as a detection mode probably i'm gonna leave everything to the default values as of now the only thing i'm gonna do in the association i'm gonna associate it to my front door now let's go ahead and create my wife policy and while it's been created i'm gonna go back to my azure front door and enable the diagnostic settings or create a new diagnostic settings so you'll be able to see the different logs that are coming through my azure front door so let's add a diagnostic settings i'm going to select all logs if you can notice here there is two types of logs front door access logs or web application firewall access logs and as you can imagine the web application firewall logs are related to the wealth policy that we have just associated to our azure front door and i'm going to select all metrics as well and i'm going to send all of the data to a log analytics workspace but i don't have any so i'm gonna go ahead and create a log analytics workspace so i'm gonna call it i'm gonna put it in australia east resource group i'm gonna call it log analytics front door i'm gonna host it in australia east region i'm gonna go ahead and create my log analytics workspace all right now my look analytics workspace has been created i'm gonna go back to my azure front door and probably i need to refresh this page adding a new diagnostic settings selecting all logs and metrics and sending all of them to my log analytics workspace that i just created i'm gonna call my diagnostic settings name to be my settings and then i'm gonna go ahead and save my changes all right so my changes has been saved looking at the off policy has been already deployed and the log analytics workspace as well that's all i have for you in this video it was a quick one to show you how can we set up the web application firewall for the azure front door and also how we set up the monitoring and logs for the web application firewall thanks for watching and i will see you in the next video hi everyone in this video we are going to dive deep into the managed rules of our web application firewall as we said before the web application firewall has a set of managed rule sets that are managed already for you by azure and they are compliant with the os best practices so these rule sets covering the protocol attacks local file inclusions remote file inclusions remote command executions php injection attacks cross-site scripting sequel injection attacks which is very common and session fixation and java attacks in addition to the other bot attacks that we have added in the previous videos i'm not going to jump into the details of each of these rules it's not going to be the purpose of this course and i don't want to go sideways from our focus which is front door and the web application firewall so what we can do with these different rule sets you can select a specific rule set and if it doesn't work for your situation then you can go ahead and disable it which means that the firewall is not going to apply this rule for the incoming traffic if you are going to do this if you are going to disable a certain rule from being executed at your firewall you need to have a very good reason for doing this like you should be able to explain why you had to disable this specific rule and how this affects the incoming traffic to getting through the firewall anyways as you can see here the action for this rule is block however you are able to change the action for this rule maybe you want to allow a specific rule to get through the firewall instead of just disabling it or maybe you just want to log that event or maybe redirect it to another url but keep in mind if you are going to allow a specific rule set to be able to get through your firewall this is going to be applied to all incoming requests that the firewall identifies under this rule sets so you need to be very careful about that however as i said before if you are going to disable or change the action of a specific role you need to be very clear why are you doing this now i'm going to show you a different way to manage the exceptions through your default rule set like what if you wanna keep this rule enabled and you'd wanna change its action so you wanna keep this role at your firewall to block any potential attacks at the same time you wanna allow some exceptions to allow the genuine traffic coming from a genuine sources to get through the firewall how you are able to do this you should be able to do this by using the managed exclusions so let's go ahead and see how can we do this by managing exclusions you can go ahead and add a new exception and in here you get to specify the rule set and the rule group and in this case i'm going to specify the sql injection and in here for the rule let's go ahead with the injection attack and then in here i'm going to specify the match criteria maybe a request header name it's going to start with sql equal resql and let's go ahead and save it all right now we have created an exception for our managed rule and what this is going to do is going to tell my firewall to allow incoming requests that has this criteria that we have created to get through the firewall even though the firewall could identify it as a potential attack but because we have created an exception in here and the incoming request matches the exception the firewall is going to allow the request to get through we have done this by keeping our role enabled so our role it's going to be effective to block other potential attacks and while we are here let's see the different rule sets you can assign to your firewall like you can choose from different rule sets or you can go for none and i couldn't think for any reason why do you want to go with no rule sets anyways also for the additional rule set you can specify an additional rule set for bot protections this is all i have for you in the managed rule sets for the web application firewall thanks for watching and i'll see you in the next video hi everyone in this video we are going to talk about the custom rules we can define in our web application firewall so let's go ahead and create a new custom rule and i'm going to call it location rule it's going to be enabled matching a condition and the priority here is key because the custom rules are going to be executed in order and the lowest the number the higher the priority and the custom rules are going to take place before the default rules or managed rules if you remember so i'm going to specify my role based on a jail location if the traffic is coming from australia then my wife is going to block it also i'm able to add another rule location two for example i'm gonna specify priority two let's try to specify the same priority to see if it's possible now as you can see it's not possible each custom role priority has to be unique in your firewall so i'm gonna go with priority two but this time i'm going to specify a slider range maybe you started to receive a malicious attack from a specific ip address and you want to block receiving any more requests from the eyepiece coming from this range so you can do this by specifying the cider range to block these attacks at the firewall and let's go ahead and add that also we can add another role based on the size of the query string parameter or maybe on a request uri or other request header or any of these attributes if the size is greater than 100 characters then we are gonna deny the traffic and block it at the firewall and for this role i'm gonna call it size roll and let's go ahead and add it also i need to specify a priority so i'm going to go for three now let's add one more roll or the string it could be applied to any of these parameters again maybe when the request header equals customer and it contains x y z then i'm gonna block it i'm gonna specify priority four for the header role now i'm gonna go ahead and add it so i'm gonna add one more role for the rate limit roll and for this role i'm gonna go by specifying a rate limit instead of match and let's go with priority five so the limit duration is gonna be over one minute and the threshold i'm gonna specify it one thousands and if i started to get more than one thousand requests over one minute and these requests are coming from austria for example then i'm gonna deny and block this traffic also you can go ahead and enable or disable a specific role for your web application firewall i think that's all i have for you for the custom roles also it's very important to remember that the custom roles take place before the managed rules for your web application firewall and for the custom roles they are going to be processed according to the priority you have specified for your custom rules the lower the number the higher the priority that's all i have for you in this video thanks for watching and i'll see you in the next video hi everyone in this video we are going to talk about the web application firewall settings and we have talked about it briefly in a previous videos so for your wealth you can go ahead and disable it and enable it back again also there are two wav modes detection mode and you will be able to switch it to prevention mode from here and also i said the difference between detection mode and prevention mode detection mode it will not block any traffic however it's gonna log it in the log analytics workspace but the prevention mode it's going to block that traffic if there is any potential attack in the incoming requests now let's go to the policy settings and have a look as you can see here you will be able to redirect all blocked traffic to a specific url also we can respond with a specific response code so let's go ahead and see what are the options so these are the available response codes that you can use in your web application file war response when your wealth blocks a specific request also you can specify a custom message as well to be sent in the response body now let's go ahead and bring this back to 403 which was the default while you are here let's go to the associations and if you remember you can associate a single wealth policy to multiple azure front doors however for the azure front door it can be only associated to one wealth policy at a time and if you remember i have mentioned that when you set your firewall in a detection mode then the firewall is not going to block any traffic however it's gonna log it in the log analytics workspace so now i'm gonna show you how can you see it so let's go back to my azure front door and browse to the logs and in here you will be able to see the firewall audit queries that you can go ahead and run them so let's go ahead and run this query of course it won't return us any data back because i didn't have any blocked traffic as you can see here if i run this query over the last seven days i wouldn't get any data back but the main thing i want you to notice here that we have configured our query to look for the logs that are coming for category front door web application firewall log this is where my web application firewall is going to place all the logs relative to the firewall for my azure front door this is all i have for you in this video thanks for watching and i'll see you in the next video hi everyone in this video we are going to dive deep into the monitoring part of our azure front door and we are going to see in details the different metrics you can use for your azure front door in addition to the web application firewall also i'm going to show you how can you set up some alerts that are going to notify you if the usage exceeds a specific threshold that you can specify then we are going to have a look at the predefined queries that you can check in the log analytics workspace to see the behavior of your front door and your web application firewall and finally you are gonna cover the health probes and how azure frontal door is using it to ensure or check the healthy status of the back in the targets that's all i have for you in this video thanks for watching and i'll see you in the next video hi everyone in this video we are going to talk about front door metrics and there are many metrics you can get a lot of information about the azure front door and the healthy status of your back in the targets so the first metric we have here is the backend health percentage and this shows you the health percentage of your back and the targets and if i'm gonna expand the time range to be over the last 30 days we're gonna see the health percentage of my back in the targets you can see that they are not hundred percent all the time because i am stopping my web apps or app services when i am not using them now the other metric we have here is the backend request count and as you can see we got 400 requests to the back-ends over the last 30 days however if i'm gonna look at another metric which is the request count we will see that's 800s which is interesting so my azure front door received 800 requests over the last 30 days but the back end request count was only four hundreds and this happened when the app services has been stopped or the configurations wasn't routing the requests properly to the backend targets also other metric i wanted you to be aware of is the backend request latency so this is how much time took from the back end to get a response through to the front door and then to the client and as you can see here if i made it to the maximum you will be able to see it talk around four seconds to get a response this is the maximum all right and if i'm gonna put it next to another metric which is the total latency so this is going to help me to understand where the latency is coming from whether the latency is coming from the back and the targets or the latency is coming from the front door and the web application firewall and as you can see in this graph here the latency is coming from the backend targets now the other metric i want you to look at is the available response size this shows you that you are going to pay for your responses and if you look at the description here it will make more sense also it's a good if you look at the request size response size to understand how much data your front door is receiving or responding to your clients and finally here you will be able to see the wealth request counts over a certain period however i'm not getting any because i didn't send any more requests after i have configured my wife on my azure front door these are the key metrics probably all metrics you could play around for your or front door thanks for watching and i'll see you in the next video hi everyone in this video we are gonna talk about the alerts you can set up on your edge or front door so i'm gonna go ahead and create a new alert rule and you can signal or specify the alert rule on either a metric or log or log activity or activity log so i'm gonna go ahead with the matrix i'm going to select the backend health percentage and i'm going to select all the back in the pool current and futures and if it dropped below 90 then it's gonna trigger my alert and send the notifications to the action group as you can see here i can specify the action group or create an action group that are going to react or receive a notification when this alert is triggered and you can apply the same concept and creating other rules or other alert rules that are going to notify you about the healthy tedious of your azure front door and the number of requests you're receiving or maybe the number of requests that your wife has blocked because it will be a very good indicator to tell you that you might be under attack that's all i have for you in this video thanks for watching and i'll see you in the next video hi everyone in this video we are going to talk about the log analytics in azure front door and we have configured it already in the diagnostic settings if you remember when we asked azure front door to send all logs including front door access logs in addition to the web application firewall logs plus all metrics to the log analytics workspace that we have created before so let's go back and see what are different sort of queries we can use and get some information about azure front door on the left hand side here you can see the different categories of the queries and in here you are able to see different predefined queries that you can use for different categories and i'm interested to show you the firewall queries which is going to show you how many requests had been blocked by the firewall and because i didn't have any i didn't get any data back but the most important thing i want you to notice here that we are filtering our query and make the category field equals front door web application firewall log by doing this filter we will be able to see all logs that our web application firewall has been blocked or allowed or does whatever action it does to these kind of requests and this is not the only category because we said we are already using azure front door so you are also able to use another category which is front door access log to get access to more sort of information about the incoming requests through your edge or front door that's all i have for you in this video thanks for watching and i'll see you in the next video hi everyone in this video we are going to talk about the health probes of azure front door as we said before the healthy props is a way that azure front door is using to know the healthy status of the back-ends as you can see here it's already configured for us and it's enabled by default and we can configure here what http verb that azure front door is going to use when checking for the healthy status of the backend targets head http verb is going to be more efficient than get http verb and then you are going to specify the interval like how often you want to configure your azure front door to paying your back in the targets to check for their health status an azure front door is going to use this configuration to check for the healthy status for your back in the targets and is going to use this information to decide what is the healthy instances that the azure front door should direct the traffic to the healthy backend instances this is all i have for you for this video thanks for watching and i'll see you in the next video hi everyone in this video we are going to clean up all resources we have used in this course so let's go to the resource groups and let's dig into the australia east resource group and you will be able to see here the different app services we have created on our azure front door and the laugh policy and the log analytics workspace so let's go ahead and delete the resource group which is going to delete all of the resources inside this resource group that's all i have for you in this video by the end of the course i hope that you have enjoyed it if you have any question please feel free to put it in the description box below thanks for watching and i will see you in the next video

Channel: Hussein Awad

Views: 23,310

Keywords:

Id: gcnoH0CiWw0

Length: 153min 30sec (9210 seconds)

Published: Wed Mar 02 2022