Our industry has seen an evolution in how we run software. Traditionally, platforms were running in on-premises datacenters but started to transition to the cloud. However, not all workloads can move or customers want to have resiliency across clouds and edge which introduced multi-cloud scenarios.

With our self-hosted gateway capabilities, customers can use our existing tooling to extend to their on-premises and multi-cloud APIs with the same role-based access controls, API policies, observability options, and management plane that they are already using for their Azure-based APIs.

New to the self-hosted gateway, how does it work?

When deploying an Azure API Management instance in Azure customers get three main building blocks:

• A developer portal (also called user plane) for allowing internal and external users to find documentation, test APIs, get access to APIs, and see basic usage data among other features.
• An API gateway (also called data plane), which contains the main networking component that exposes API implementations, applies API policies, secures APIs, and captures metrics and logs of usage among other features.
• Finally, a Management Plane, which is used through the Azure Portal, Azure Resource Manager (ARM), Azure Software Development Kits (SDKs), Visual Studio and Code extensions, and command-line interfaces (CLIs) that allow to manage and enforce permissions to the other components. Examples of this are setting up APIs, configuring the infrastructure, and defining policies.

Figure 1: Architecture diagram depicting the components and features of Azure API Management Gateway.

In the case of the self-hosted gateway, we provide customers with a container image that hosts a version of our API Gateway. Customers can run multiple instances of this API Gateway in non-Azure environments and the only requirement is to allow outbound communications to the Management Plane of an Azure API Management instance to fetch configuration and expose APIs running in those non-Azure environments.

Figure 2: Architecture diagram depicting the components of a distributed API Gateway solution using the self-hosted gateway.

Supported Azure API Management tiers

The self-hosted gateway v2 is now generally available and fully supported. However, the following conditions apply:

• You need an active Azure API Management instance; this instance should be on the Developer tier or Premium tier.
  • In the developer tier, in this case the feature is free for testing, with limitations of one active instance.
  • In the Premium tier, you can run as many instances as you want. Learn more about pricing at our pricing table.
• Azure API Management will always provision an API Gateway in Azure, which we typically call our managed API gateway.
  • Be aware that there are differences in features between our various API gateway offerings. Learn more about the differences in our documentation.

Pricing and gateway deployment

In the case of the self-hosted gateway, we can define a self-hosted gateway by assigning a name to our gateway, a location (which is a logical grouping that aligns with your business, not an Azure region), a description, and finally what APIs we want to expose in this gateway. This allows us to do physical isolation of APIs at the gateway level, which is only possible in the self-hosted gateway at this moment. This combination of location, APIs, and hostname is what defines a self-hosted gateway deployment, this “self-hosted gateway deployment” should not be confused with a Kubernetes “deployment” object.

For example, using a single deployment, where the same APIs are configured in all locations:

Figure 3: Architecture diagram describing the pricing model for a single deployment of a self-hosted gateway.

However, you can also create multiple self-hosted gateway deployments to have more granular control over the different APIs that are being exposed:

Figure 4: Architecture diagram describing the pricing model for two deployments of a self-hosted gateway.

Supportability and shared responsibilities

Another important aspect is the support, in the case of the self-hosted gateway, the infrastructure is not necessarily managed by Azure, therefore as a customer you have more responsibilities to ensure the proper functioning of the gateway:

New features and capabilities of v2 and v1 retirement

When using the latest versions of our v2 container image, tag 2.0.0 and or higher, you would be able to use the following features:

• Opentelemetry metrics: the self-hosted gateway can be configured to automatically collect and send metrics to an OpenTelemetry Collector. This allows you to bring your own metrics collection and reporting solution for the self-hosted gateway. Here you can find a list of supported metrics.
• New image tagging: we provide four tagging strategies to meet your needs regarding updates, stability, patching, and production environments.
• Helm chart: a new deployment option with multiple variables for you to configure at deployment time like backups, logs, OpenTelemetry, ingress, probes, and also Distributed Application Runtime (DAPR) configurations. This helm chart together with our sample Yaml files can be used for automated deployments with continuous integration and continuous delivery (CI and CD ) tools or even Gitops tools.
• Artifact registry: you can find all our artifacts in our centralized Microsoft Artifact Registry for all the container images provided by Microsoft.
• New EventGrid events: a new batch of supported EventGrid events related to the self-hosted gateway operations and configurations. The full list of events can be found here.

Please remember that we will be retiring support for the v1 version of our self-hosted gateway, so this is the perfect time to upgrade to v2. We also provide a migration guide and a guide for running the self-hosted gateway in production.