My Azure Front Door experience

I share my experiences setting up Azure Front Door (AFD). This blog covers things that are not in Quickstart: Create an Azure Front Door profile – Azure portal | Microsoft Learn. I found this Quickstart really good.

Use case for Azure Front Door

If you read my previous blog, you would have seen that we use AFD to load balance HTTP requests. In the first place, the prime driver of this was our desire to move from two active-passive regional set up to an active-active one. A secondary driver is that AFD controls the SSL certificate rotation. What is more, if you choose AFD managed certificates instead of self-managed certificates you might get a cost saving. AFD pricing includes managed certificates, but you must be careful you do not exceed the composite route limit.

There are Basic APIM, Consumption APIM and Azure function app origin endpoints.

Implementation

Following the Microsoft documentation AFD was easy to set up. I was a novice and had never set up a CDN before but with the help of the Quickstart I could work out what to do. To begin with we choose to create Standard tier AFD profile because we did not need the advanced features immediately. Furthermore, upgrading to a standard tier to premium tier to get features such as Web Application Firewall managed rules and Private links is easy.

You must be aware of the quota and limits on a AFD profile. Creating all the endpoints in our Basic tier worked well but what we did not realise that you can only configure 10 endpoints. We have 10 endpoints. Thus, if we want to add another endpoint we will need to upgrade to the Standard tier to get 25 endpoints.

APIM Gotchas

The first issue was that all of our Consumption APIM health probes fail. The Basic APIM probe did not fail. Eventually we will move all our consumption APIM’s to the basic tier but for now we cannot. The Microsoft documentation tell you to configure a hidden path of /status-0123456789abcdef in all Health Probes. This is shown below.

Running this query against the AFD Log analytics

AzureDiagnostics
| where ResourceProvider == "MICROSOFT.CDN" and Category == "FrontDoorHealthProbeLog"
//| where toint(httpStatusCode_s) >= 400

we see errors like this for all consumption APIM endpoints.

What Harris, one of my colleagues did was, configure a mock endpoint as a health probe for our consumption APIM’s. these errors then disappear. Thus, we conclude that consumption APIM’s do not have the hidden health probe.

Secondly, once load balancing was set, we observe this error from the second APIM endpoint.

{
    "statusCode": 401,
    "message": "Access denied due to invalid subscription key. Make sure to provide a valid key for an active subscription."
}

Subscription Keys are generated whenever a new subscription is created, or the key is regenerated. Thus, if you load balance two APIM’s you must have a way of synchronising the keys between each APIM. Harris wrote a powershell script to synchronize the keys between the load balanced consumption APIMs.

      $sourceApimContext = New-AzApiManagementContext -ResourceGroupName ${{ parameters.sourceApimRg }} -ServiceName ${{ parameters.sourceApim }}
      $destinationApimContext = New-AzApiManagementContext -ResourceGroupName ${{ parameters.destinationApimRg }} -ServiceName ${{ parameters.destinationApim }}

      $subscriptionsSource = Get-AzApiManagementSubscription -Context $sourceApimContext
      $subscriptionsDestination = Get-AzApiManagementSubscription -Context $destinationApimContext

      # Iterate over subscriptions from the source APIM
      foreach ($subscriptionSource in $subscriptionsSource) {
          # Check if the subscription exists in the destination APIM
          $subscriptionDestination = $subscriptionsDestination | Where-Object { $_.Name -eq $subscriptionSource.Name }
          if ($subscriptionDestination -ne $null) {
              # Get primary key from the source APIM
              $subscriptionKey = Get-AzApiManagementSubscriptionKey -Context $sourceApimContext -SubscriptionId $subscriptionSource.SubscriptionId

              # Update primary and secondary keys in the destination APIM
              Set-AzApiManagementSubscription -Context $destinationApimContext -SubscriptionId $subscriptionDestination.SubscriptionId -PrimaryKey $subscriptionKey.PrimaryKey -SecondaryKey $subscriptionKey.SecondaryKey

              Write-Output "Successfully synchronized keys for subscription $($subscriptionSource.Name)"
          }
          else {
              Write-Output "Subscription $($subscriptionSource.Name) does not exist in $($destinationApim)"
          }
      }

      Write-Output "Subscription key sync completed."

Once done this error went away.

Moving from BYO to AFD managed SSL certificates

All of our APIM’s and Function App endpoint were bound to domains certificates. One of the goals of moving these to AFD was that the users would not notice any disruption. Secondly, we would start using AFD managed certificates instead of “bring your certificates”. This process was seamless in my hands. Firstly, selecting the defaults on the screen below we could browse to the DNS zone and the custom domain we require. Because it already exists in the DNS Zone for our Azure subscription. Selecting the Add button starts the process to add a new domain.

It takes 5-10 minutes for the new certificate request to complete.

In the meantime, you can associate the certificate the domain certificate with your origin group by clicking on the Unassociated link. At this point you can link the TEXT record by clicking on the Pending link. Eventually the certificate request is complete, and the final step is to link the CNAME record.

Conclusion

I had no difficulties setting up Azure Front Door following the Microsoft documentation. Furthermore, switching to AFD managed domains happens seamlessly. Consumption APIM endpoints have require a custom health endpoint. All APIM endpoints must use shared subscription keys.