<p>I have set up my application to be served by a Kubernetes NGINX ingress in AKS. Today while experimenting with the Azure API management, I tried to set it up so that all the traffic to the ingress controller would go through the API management. I pointed its backend service to the current public address of the ingress controller but I was wondering when I make the ingress controller private or remove it altogether to rely on the Kubernetes services instead, how API management could access it and how I would define the backend service in API management. By the way, while provisioning the API management instance, I added a new subnet to the existing virtual network of the AKS instance so they are in the same network.</p>

Mar Chal
<p>There are two modes of <a href="https://learn.microsoft.com/en-us/azure/api-management/api-management-using-with-vnet" rel="nofollow noreferrer">deploying API Management into a VNet</a> – External and Internal.</p>
<p>If API consumers do not reside in the cluster VNet, the External mode (Fig below) should be used. In this mode, the API Management gateway is injected into the cluster VNet but accessible from public internet via an external load balancer. It helps to hide the cluster completely while still allowing external clients to consume the microservices. Additionally, you can use Azure networking capabilities such as Network Security Groups (NSG) to restrict network traffic.</p>
<p><a href="https://i.stack.imgur.com/N6Usy.png" rel="nofollow noreferrer"><img src="https://i.stack.imgur.com/N6Usy.png" alt="enter image description here" /></a></p>
<p>If all API consumers reside within the cluster VNet, then the Internal mode (Figure below) could be used. In this mode, the API Management gateway is injected into the cluster VNET and accessible only from within this VNet via an internal load balancer. There is no way to reach the API Management gateway or the AKS cluster from public internet.</p>
<p><a href="https://i.stack.imgur.com/IbA1Q.png" rel="nofollow noreferrer"><img src="https://i.stack.imgur.com/IbA1Q.png" alt="enter image description here" /></a></p>
<p><strong>In both cases, the AKS cluster is not publicly visible</strong>. The Ingress Controller may not be necessary. Depending on your scenario and configuration, authentication might still be required between API Management and your microservices. For instance, if a Service Mesh is adopted, it always requires mutual TLS authentication.</p>
<p>Pros:</p>
<ul>
<li>The most secure option because the AKS cluster has no public endpoint</li>
<li>Simplifies cluster configuration since it has no public endpoint</li>
<li>Ability to hide both API Management and AKS inside the VNet using the Internal mode</li>
<li>Ability to control network traffic using Azure networking capabilities such as Network Security Groups (NSG)</li>
</ul>
<p>Cons:</p>
<ul>
<li>Increases complexity of deploying and configuring API Management to work inside the VNet</li>
</ul>
<p><a href="https://learn.microsoft.com/en-us/azure/api-management/api-management-kubernetes#option-3-deploy-apim-inside-the-cluster-vnet" rel="nofollow noreferrer">Reference</a></p>
<hr />
<p>To restrict access to your applications in Azure Kubernetes Service (AKS), you can create and use an internal load balancer. An internal load balancer makes a Kubernetes service accessible only to applications running in the same virtual network as the Kubernetes cluster.</p>
<p>You can either expose your the backends on the AKS cluster through <a href="https://learn.microsoft.com/en-us/azure/aks/ingress-internal-ip" rel="nofollow noreferrer">internal Ingress</a> or simply using <a href="https://learn.microsoft.com/en-us/azure/aks/internal-lb" rel="nofollow noreferrer">Services of type internal load balancer</a>.</p>
<p>You can then point the API Gateway's backend to the internal Ingress' Private IP address or the internal load balancers Service's EXTERNAL IP (which would also be a private IP address). These private IP addresses are accessible within the Virtual Network and any connected network (i.e. Azure virtual networks connected through peering or Vnet-to-Vnet Gateway, or on-premises networks connected to the AKS Vnet). In your case, if the API Gateway is deployed in the same Virtual Network then, it should be able to access these private IP addresses. If the API Gateway is deployed in a different Virtual Network, please connect it to the AKS virtual network using <a href="https://azure.microsoft.com/en-in/blog/vnet-peering-and-vpn-gateways/" rel="nofollow noreferrer">VNET Peering or Vnet-to-Vnet Gateway</a>, depending on your use-case.</p>
