This is a continuation of a previous article on cloud resources, their IaC, shortcomings and resolutions with some more exciting challenges to talk about. When compared with a variety of load balancer options, the Azure Front Door aka AFD we cited in the previous article often evokes misunderstanding about the term global. It is true that an instance of the Azure Front Door and CDN profile is not tied down to a region and in fact, appears with the location property set to the value global. But it is really catering to edge load balancing. When clients connect to it from a variety of different locations, AFD provides the entrypoint based on where the nearest edge location is. As a contrast and for a cross region or global load balancer, that’s always entering Azure from the same endpoint, so the entrypoint is what it decides as what is closest to that endpoint. Based on this entrypoint, clients from two different locations, an Azure cross region or global load balancer  will route in the same exact way. An AFD will determine the edge location and it doesn’t matter where the azure call was made but what is closest to the FD Edge location, and this provides higher control over latency. Having called out the difference, the similarity is that it uses anycast protocol and slip TCP. It is layer 7 technology and is solely internet facing.

One of the challenges from an internet facing resource is its addressability and the best practice to overcome limitations with ip address is to use DNS names always. This brings into consideration DNS caching where the nameserver goes down, but the time-to-live aka TTL helps to keep the routing going albeit to an unhealthy endpoint. A retry or re-resolve would fix this issue and again that falls under the best practices. Some other best practices are about determining whether the client needs a global or a regional solution, where the traffic enters Azure or if it is latency sensitive, what is the type of workload – on-premises or cloud or hybrid.

When the choice for Azure Front Door is determined, the above plays a big role in connecting destination cloud resources as origins in an origin group. Cloud solution architects are surprised when they connect app services with ip access restrictions behind the Front Door. No matter whether they specify one rule or another, or whether they include the ipv4 and ipv6 addresses that the Front Door endpoint resolves to, they will encounter a 403.  AFD leverages 192 edge locations across 109 metro cities – a vast global network of points of presence (POP) to bring the applications closer to the end users. When there are such multiple POP servers involved, all those POP servers must be allowed in the ip access restrictions in the Azure App Services. It is also possible to allowlist based on virtual networks.

Lastly, securing the access restrictions on the app services when it involves IP ACLs, is not complete without setting X-Azure-FDID header check to have the value of the Front Door’s unique identifier in the form of a universal identifier (GUID). This check prevents spoofing.