Azure Architecture Close Up: API Management External and Internal Traffic

The APIM Service in Azure gives us an opportunity to organise our APIs in a centralised manner (not to be confused with API Center, separate topic). While it known as an organising service for APIs, it can be easy to misconfigure or mismanage when attempting to use the service for both internal facing APIs and external public facing APIs.

The following architecture diagram can help visualise how this can be done properly:

External API Traffic

For any externally facing traffic that comes into the instance, it is considered ideal to have public IP addresses be assigned to an Application Gateway. Then within the subnet that this Application Gateway is deployed in, it come with it an endpoint address that can be used to send the traffic it receives through to API Management. To separate the APIM instance from direct public access we set the APIM instance to be in Internal Mode.

By design, this then means that we are assuming that the APIM instance itself is only accessible by systems that can reach it NOT through the public internet, which is what the Application Gateway is meant to do. Fundamentally the Application Gateway reaches the subnet of the APIM instance within the same VNet that they both live under and communicates with it that way. The public traffic only ever sees the IP address attached to Application Gateway (note, this can also be Azure Front Door). Finally, the APIM instance is selected to be on the Premium tier because it allows for features that will scale the implementation such as Workspaces for different API teams as the number of APIs grow, and most critically Virtual Network Injection which is needed for this kind of implementation to work.

Internal API Traffic

In exactly the same VNet that we have the Application Gateway and APIM subnets, we would then have Private Endpoint subnet that is dedicated JUST for backend services. We can connect Key Vaults, Azure Functions, App Services, Services Buses, Blob Storage etc to our APIM instance through these Private endpoints meaning their connections and IP addresses are never visible to the public.

This is a different mental model of setting up the APIM instance in Azure whereby in past practices that spring from Developer pilot program, it would have been an easier but less ideal scenario to simply give direct access to the APIM FQDN to end users/clients which are effectively part of the public internet. Proper ingress layers like Azure Front Door and Application Gateway gives us additional protection of the APIM instance itself from the public rather than just needing to protect the API services themselves that we think of centrally in this conversation.

Architectural Considerations

Security - It is important to remember that the ingress layer in the form of an Application Gateway from this guidance has WAF policies applied. With WAF, it becomes possible to monitor and scrutinise the incoming traffic well before it arrives at the APIM instance. It is important for us as a team to make sure that these security practices are achieving the system defence we anticipate to improve our security posture

Cost Optimisation - In addition, we must also consider that using a Premium plan for our APIM instance means that costs will be relatively high on this resource in the name of pursuing scalability and other operational features such as Workspaces as discussed before.

Reliability - On the other hand, by selecting a premium plan for APIM, we also ensure that we can operationalise virtual network injection capabilities. With that we can reliably separate the concerns of public versus internal traffic in the most informed way at scale.

Performance Efficiency - When thinking about performance, we can see an architecture like this allowing Private endpoints into one singular subnet in our VNet. That design means that when we talk about the backend services that want to connect to this particular APIM instance, we talk about them as coming from the Private Endpoint subnet, assisted by the our DNS Zone to resolve to custom names.

Operational Excellence - Through the use of logging and monitoring tools such Log Analytics and Application insights, we can be more observant of the system as a whole. The choice of Internal mode for the APIM instance gives us room to connect a Devops agent that has access to the VNet. From that, the Devops agent can help apply policies, updates to API versions and additions of other resources