Azure API Management visually explained

<TLDR> Visual overview of Azure API Management service: what it is, how it works and how it can be useful to you. </TLDR>

API Management (APIM for short) is a managed API Gateway service in Azure coming with a rich set of features. If you're not familiar with the concept you can think of an API Gateway as a middleman that operates between clients (web apps, mobile clients, other APIs) and your backend API.

API Management can help protect backend services, improve performance, manage developer and partner subscriptions, enforce usage quotas and throttling. You get analytics, monitoring and alerts out of the box.

3 Components of APIM

Azure Admin Portal

• Manage and configure APIs
• View analytics and logs
• Manage users and subscriptions

Developer Portal

• Automatically generated website with documentation of APIs
• Try API in the interactive console
• Subscribe to Products and get API keys
• Developers can access analytics of their own usage
• Can be customized with content, custom styles and branding (visual in-page editor for admins)

API Gateway

• Accepts API calls and routes them to the backend
• Verifies API keys, JWT tokens, certificates, credentials
• Enforces usage quotas and rate limits
• Transforms APIs on the fly
• Can cache backend responses
• Can be Azure-managed or deployed on-prem / to other clouds
• Supports multi-region deployment (see below)
• Can scale up and out (see below)

API Management use cases

Below are some of the common use cases for the API Management. Note there are many more.

Modify backend requests

Alter headers, add new fields to the request body or change the request format completely.

Modify backend responses

Example: Transform the backend response format from XML to JSON.

Route requests to different backends

With route mapping you can forward requests to different backends. Backend can be a HTTP service or another Azure service (e.g. Storage).

Rate-limit requests

Apply rate limits and quotas per subscription or dynamically computed key (visitor IP address, user ID from incoming JWT).

Cache backend responses

Apply cache policies with dynamic cache keys and configurable expire time.

Verify JWT

Restrict access to the API by validating JWT token in the request.

Authorize requests with external authorizers

You can make requests to external services (managed by you or by a 3rd party) to verify authentication status for the current request.

Black- and whitelist IPs

Protect your API by configuring which IPs can access the resources.

Reduce potential attack surface

Protect you backend services by placing them behind (and securing access to) the APIM instance.

APIs and Operations

As an admin of the API Management instance, you create and expose APIs.

Each APIM API has reference to a backend API.

Each API has one or more Operations.

Operations configure path mapping between APIM and backend API.

You can define Operations manually or you can upload an OpenAPI specification file and they will be created automatically.

API can be public or it can require a subscription (see below).

Products and Subscriptions

Product is a way to logically group multiple APIs and provide access to those APIs for a developer.

You can assign usage quota to a product.

In order to use a product, a developer must have a subscription.

Subscription is a pair of access keys. Key must be sent in the request header to authenticate with API.

Developers can subscribe via Developer Portal or an admin can create a subscription for them.

Product is not available to developers before it's published.

Products can be further organized into Groups.

API Revisions

Create a new revision to introduce non-breaking changes to the existing API.

Multiple revisions can co-exist (they have different URLs).

When new revision is properly tested, make it Current so it's published to the primary URL.

Making revision current creates a change log in Developer Portal.

API Versions

Create a new version to introduce breaking changes to the API.

Each API version must have a unique name, since technically it's another API.

Multiple versions can co-exist (they have different URLs).

You can choose versioning scheme: path (api.com/v1) or header or query.

Policies

Policies are a way to apply custom logic to requests and responses at different stages of their lifecycle.

Policies are defined in XML.

Policy Scopes and Sections

Each policies set contains 4 sections: inbound, backend, outbound, on-error.

Each section can contain multiple policies.

There are many policies available, full list here.

You can apply policies in multiple scopes: Global (all APIs), Product scope, API scope, Operation scope.

There's a special <base /> tag which references parent scope. E.g. policies declaration <backend> <base /> </backend> in the Operation scope will trigger <backend> policies from the API scope.

Order of processing

When request arrives, policies are executed in order.

Rules from <inbound> section run when request is received from a client.

<backend> section is triggered before the request is forwarded to the backend.

<outbound> runs when response is received from the backend and before sending it to the client.

<on-error> is triggered whenever an error occurs.

Pricing tiers

5 pricing tiers are: Consumption, Developer, Basic, Standard, Premium.

A new tier was added recently: Isolated (in preview now). It has the same performance characteristics as Premium but guarantees compute isolation which may be required in highly regulated environments.

Serverless tier has lower SLA and is lacking many features: VNET integration, Developer Portal, internal cache, multi-region, and more.

You can find full comparison of pricing tiers here.

Multi-region deployment

Multi-region deployment is available in Premium and Isolated tiers only.

Improve latency for end users.

Add failover support in case one of the regions becomes unavailable.

Only API Gateways can be deployed to multiple regions. Azure and Development Portals are hosted in the primary region.

Scaling

You can scale your API Management instance vertically (by upgrading to the next tier), horizontally (by adding scaling units), or both at the same time.

Both upgrading instance size and adding new unit take considerable time.

Good metric to use when deciding to scale is Capacity - an abstraction over server resources like CPU, Memory and IO.

There's an Autoscaling feature (Standard and Premium tiers).

Conclusion

API Management can be a good option if you're looking for a managed end-to-end solution to protect and control your APIs. As with many managed solutions it can get costly at scale though.

Hopefully this overview gives you some idea of how the service is organized and whether it can be useful to you. You may want to check the official documentation next.

If you like this type of content you can follow me on Twitter for the latest updates.