Using Azure Application Gateway with API Management service
An application developed using a microservices architecture might expose multiple front-end services to clients. Each of these front-end services should handle multiple cross-cutting concerns such as authentication, SSL termination, load-balancing and so on. It will be easier to abstract these concerns into a single API gateway that handles all client requests, and forward the requests to the respective services. In this article, we will discuss 2 solutions that Azure offers — the Application Gateway and the API Management service.
Azure Application Gateway
The Azure Application Gateway is a load-balancing service that handles layer 7 routing and SSL termination. There is also a web application firewall (WAF) integrated in it. It can act as the reverse proxy for the backend infrastructure.
API Management service
The API Management (APIM) service is a turnkey solution for publishing APIs to internal and external consumers. There are policies that can be applied for inbound, backend, and outbound traffic, such as IP whitelisting, JWT validation, request manipulation and the such. In addition, it also supports useful features for managing public-facing APIs such as authentication through Azure Active Directory, and rate limiting. However, it does not support load-balancing, which is a void the Azure Application Gateway can fill.
Pre-requisites
We will be setting up the infrastructure using a mix of Terraform scripts and Az CLI commands. As such, the pre-requisites are:
- Terraform
- Az CLI
- Bash (or its equivalent such as zsh)
Azure Application Gateway + APIM service
Here is an overview of the setup.
In this setup, there are 3 main components — the backend service, the APIM service, and the Azure Application Gateway.
The backend service is a simple virtual machine (VM) running several services to mimic an application that consists of multiple front-end, and backend services. For simplicity, a VM was chosen for this layer instead of setting up a full-fledged Azure Kubernetes Services cluster. The idea is that the VM represents the multitude of endpoints that the application supports; It can be easily replaced by a Istio+K8s cluster as well.
The APIM service serves as a gateway to the AKS cluster. It will handle security concerns such as IP whitelisting, JWT validation.
The Azure Application Gateway serves as the reverse proxy for the various domains of the application. It will also handle SSL termination so that consumers of the application only have to deal with a single SSL certificate.
The networking elements in the diagram, such as the Private DNS zone, and the Network Security Groups, will be discussed later in the following sections.
The image below depicts a high level view of the end-to-end flow. Consumers of the application make requests to the Application Gateway. The Application Gateway then performs SSL termination, and forwards valid requests to the downstream APIM service. Invalid routes are immediately dealt with at the Application Gateway. The APIM service performs its security checks, and forwards valid requests to the downstream services in the AKS cluster.
Setting up the APIM service
In our example, the APIM service has to be set up before the Azure Application Gateway. This is because we are setting up APIM service in internal mode, which means that the APIM instance will only be reached from the internal network(s).
The APIM service is configured to:
- Use a custom domain that is only reachable within the virtual network
- Run on internal mode, so the APIM service cannot be reachable from the internet
- Route inbound traffic on the /api/v1/players endpoint to the backend service hosted on the VM
- Perform JWT validation on inbound traffic using the Azure Active Directory
Therefore, there are several pre-requisites to fulfill before we start setting up the APIM service:
- An SSL certificate for the domain name of the APIM service. In our example, we will be using a certificate signed by a self-signed CA trusted root certificate
- A dedicated subnet for the APIM service. This allows us to configure the Network Security Group for the APIM service
- A backend service that is up and running. The APIM service will route traffic to this backend service
- An application registration on the Azure AD for the backend service
- An application registration on the Azure AD for the client service
As of the time of writing, the APIM service is set up using both Terraform and Az CLI, with Az CLI commands being used to supplement actions that are not handled by Terraform yet.
The following Terraform script shows the creation of the APIM service with the configuration of a custom domain, and the creation of the various APIs that routes traffic to the backend service.
The following Terraform script shows the creation of the various network infrastructure dependencies of the APIM service.
The AZ CLI commands are used to configure the APIM service for internal mode. We need to use the Az CLI commands to:
- Create a private DNS zone A record set for the APIM service
2. Set the APIM service to internal mode
3. (Optionally) set the demo API to not require subscription
Setting up the Application Gateway
In our example, the Application Gateway is configured to:
- Reroute incoming traffic on a particular path to the APIM service,
- Perform custom health checks on the APIM service,
- Handle only HTTPS traffic.
Unlike the APIM service, the Application Gateway can be fully setup using only Terraform scripts.
And, along with the supporting network infrastructure.
Wiring them up
Why do we need a Private DNS Zone?
The Private DNS Zone is required because the domain name configured for the APIM service is no longer valid in internal mode. In addition, the APIM service does not service requests made with its IP address as the host name. Thus, we will need to create a custom domain name for the APIM service, and create an A record in the Private DNS Zone to map the new domain name to the private IP address.
In addition, we will need to set up the APIM service with a self-signed certificate using the custom domain name as the Common Name. This certificate is needed as we will be setting up the Application Gateway to perform a custom health probe of the APIM service using HTTPS.
What is a custom health probe?
The Application Gateway performs health probes on its backend to ensure that these backends are healthy, and ready to receive forwarded requests. Once the health probe fails, any requests that was to be routed to the unhealthy backend is immediately responded by the Application Gateway with a 502.
The APIM service has a pre-defined health check endpoint https://apim.demo.com/status-0123456789abcdef.
This is then used in the configuration of a custom health probe for the APIM service backend configured in our Application Gateway.
In a nutshell
In a microservice architecture, having these gateways helped to centralise cross-cutting concerns such as authentication, SSL termination, and load balancing. These help keep the microservices lean and focused. Nonetheless, these gateways are not “free lunches” — some amount of time is still needed to plan, configure, and set up.
Check out my list of the common gotchas while using Application Gateway with APIM service.
A full working example of the setup scripts will also be uploaded to github soon.
Happy coding! (:
