Anatomy of API Management

When I want to wrap my head around a non-trivial Azure service with a few moving parts, I like to draw a diagram.

That might be from my UML days or it might just be that I reason better with boxes that concepts spread in documentation and APIs. In general, it helps me clear out the parts and how they relate to each other.

I wrote a few anatomy articles. This one is for Azure API Management, a fully managed API Gateway service.

The diagram doesn’t contain every single sub-resources of API management, just the main ones. Each object relates to an Azure Resource (in ARM sense).

API Management Anatomy

API Management Anatomy

We see the API Management Service in the middle, a little darker. This is the actual API Management instance. It has a SKU (e.g. consumption, standard, premium), a list of additional locations (to geo distribute it) and a VNET config (to integrate it to an existing VNET).

The API Management Service has users and groups.

The service can also have subscriptions. Those subscriptions are scoped at the service level and give access to all APIs.

The service also has products. Products can also have subscriptions. With that scope, the subscriptions only give access to the APIs associated to the products.

APIs are associated in a many-to-many fashion to products. API is the level where the versioning happens.

An API can have operations. An operation maps to a back-end API.

Policies can exist at the Product, API or operation level. Hence the base policy: it represents the higher level policies.


That’s it.

I didn’t want to over complicate things. I hope it gives a bit of insights on API Management in the form of a one-pager.

Leave a comment