In this article I present an architecture to expose services behind an API Management solution and with a Front Door CDN.
Azure API Management is a great solution to organize your APIs in one place, giving the opportunity for your/external developers to consume them from a single hub. It’s also used to enforce authentication at a central level leveraging on Policies which allow JWT token check, instead of forcing you to evaluate JWT signature in each of your APIs.
Azure Front Door is a CDN Service used to terminate client connections at the edge, therefore giving better network perceived performance from a user perspective. It can also be used to apply Firewall rules at OSI Level 7 to early detect hacks attempts before they reach your internal network and to cache API responses to enhance your workload performance. In this architecture, Front Door connects to the API Management using a Private Link service.
From a security perspective, the following architecture makes sure that your cluster is not exposed to the public Internet thanks to rules applied to the API layer of AKS allowing only connections coming from the Azure Firewall CIDR. Moreover, the nodes and the PODs are given only an internal IP address from the subnet in which the node-pool resides, making it possible to leverage Network Security Groups or AKS Traffic Policies to govern both North-South and East-West traffic.
In this architecture, the networks are implemented in a Hub & Spoke model, which gives you enough elasticity to adapt as your entire application portfolio evolves.
The AKS networking model used is the Azure CNI which gives any POD its own IP address. Using this approach, its advisable that you plan in advance the CIDR of you vNET as growing your workloads inside the cluster may lead to IP exhaustion. In case of IP exhaustion at subnet level, you can decide to create a new node-pool inside a different subnet so that PODs spun up in that pool will receive IPs from the new subnet.