| title | description | services | documentationcenter | author | ms.service | ms.topic | ms.date | ms.author |
|---|---|---|---|---|---|---|---|---|
Self-hosted gateway overview | Azure API Management |
Learn how self-hosted gateway feature of Azure API Management helps organizations manage APIs in hybrid and multicloud environments. |
api-management |
dlepow |
api-management |
article |
03/18/2022 |
danlep |
This article explains how the self-hosted gateway feature of Azure API Management enables hybrid and multi-cloud API management, presents its high-level architecture, and highlights its capabilities.
The self-hosted gateway feature expands API Management support for hybrid and multi-cloud environments and enables organizations to efficiently and securely manage APIs hosted on-premises and across clouds from a single API Management service in Azure.
With the self-hosted gateway, customers have the flexibility to deploy a containerized version of the API Management gateway component to the same environments where they host their APIs. All self-hosted gateways are managed from the API Management service they are federated with, thus providing customers with the visibility and unified management experience across all internal and external APIs. Placing the gateways close to the APIs allows customers to optimize API traffic flows and address security and compliance requirements.
Each API Management service is composed of the following key components:
- Management plane, exposed as an API, used to configure the service via the Azure portal, PowerShell, and other supported mechanisms.
- Gateway (or data plane), which is responsible for proxying API requests, applying policies, and collecting telemetry
- Developer portal used by developers to discover, learn, and onboard to use the APIs
By default, all these components are deployed in Azure, causing all API traffic (shown as solid black arrows on the following picture) to flow through Azure regardless of where backends implementing the APIs are hosted. The operational simplicity of this model comes at the cost of increased latency, compliance issues, and in some cases, extra data transfer fees.
:::image type="content" source="media/self-hosted-gateway-overview/without-gateways.png" alt-text="API traffic flow without self-hosted gateways":::
Deploying self-hosted gateways into the same environments where the backend API implementations are hosted allows API traffic to flow directly to the backend APIs, which reduces latency, optimizes data transfer costs, and enables compliance while retaining the benefits of having a single point of management, observability, and discovery of all APIs within the organization regardless of where their implementations are hosted.
:::image type="content" source="media/self-hosted-gateway-overview/with-gateways.png" alt-text="API traffic flow with self-hosted gateways":::
The self-hosted gateway is a containerized, functionally equivalent version of the managed gateway deployed to Azure as part of every API Management service. The self-hosted gateway is available as a Linux-based Docker container image from the Microsoft Container Registry. It can be deployed to Docker, Kubernetes, or any other container orchestration solution running on a server cluster on premises, cloud infrastructure, or for evaluation and development purposes, on a personal computer. You can also deploy the self-hosted gateway as a cluster extension to an Azure Arc-enabled Kubernetes cluster.
The following functionality found in the managed gateways is not available in the self-hosted gateways:
- Sending resource logs (diagnostic logs) to Azure Monitor. However, you can send metrics to Azure Monitor, or configure and persist logs locally where the self-hosted gateway is deployed.
- Upstream (backend side) TLS version and cipher management
- Validation of server and client certificates using CA root certificates uploaded to API Management service. You can configure custom certificate authorities for your self-hosted gateways and client certificate validation policies to enforce them.
- Integration with Service Fabric
- TLS session resumption
- Client certificate renegotiation. This means that for client certificate authentication to work, API consumers must present their certificates as part of the initial TLS handshake. To ensure this behavior, enable the Negotiate Client Certificate setting when configuring a self-hosted gateway custom hostname.
- Built-in cache. Learn about using an external Redis-compatible cache in self-hosted gateways.
We provide a variety of container images for self-hosted gateways to meet your needs:
| Tag convention | Recommendation | Example | Rolling tag | Recommended for production |
|---|---|---|---|---|
{major}.{minor}.{patch} |
Use this tag to always to run the same version of the gateway | 2.0.0 |
❌ | ✔️ |
v{major} |
Use this tag to always run a major version of the gateway with every new feature and patch. | v2 |
✔️ | ❌ |
v{major}-preview |
Use this tag if you always want to run our latest preview container image. | v2-preview |
✔️ | ❌ |
latest |
Use this tag if you want to evaluate the self-hosted gateway. | latest |
✔️ | ❌ |
You can find a full list of available tags here.
Our deployment options in the Azure portal use the v2 tag which allows customers to use the most recent version of the self-hosted gateway v2 container image with all feature updates and patches.
Note
We provide the command and YAML snippets as reference, feel free to use a more specific tag if you wish to.
When installing with our Helm chart, image tagging is optimized for you. The Helm chart's application version pins the gateway to a given version and does not rely on latest.
Learn more on how to install an API Management self-hosted gateway on Kubernetes with Helm.
Rolling tags are tags that are potentially updated when a new version of the container image is released. This allows container users to receive updates to the container image without having to update their deployments.
This means that you can potentially run different versions in parallel without noticing it, for example when you perform scaling actions once v2 tag was updated.
Example - v2 tag was released with 2.0.0 container image, but when 2.1.0 will be released, the v2 tag will be linked to the 2.1.0 image.
Important
Consider using a specific version tag in production to avoid unintentional upgrade to a newer version.
Self-hosted gateways require outbound TCP/IP connectivity to Azure on port 443. Each self-hosted gateway must be associated with a single API Management service and is configured via its management plane. A self-hosted gateway uses connectivity to Azure for:
- Reporting its status by sending heartbeat messages every minute
- Regularly checking for (every 10 seconds) and applying configuration updates whenever they are available
- Sending metrics to Azure Monitor, if configured to do so
- Sending events to Application Insights, if set to do so
To operate properly, each self-hosted gateway needs outbound connectivity on port 443 to the following endpoints associated with its cloud-based API Management instance:
Important
- DNS hostnames must be resolvable to IP addresses and the corresponding IP addresses must be reachable.
- The associated storage account names are listed in the service's Network connectivity status page in the Azure portal.
- Public IP addresses underlying the associated storage accounts are dynamic and can change without notice.
If integrated with your API Management instance, also enable outbound connectivity to the associated public IP addresses, ports, and hostnames for:
The self-hosted gateway v2 requires the following:
- The public IP address of the API Management instance in its primary location
- The hostname of the instance's configuration endpoint:
<apim-service-name>.configuration.azure-api.net
Additionally,customers that use API inspector or quotas in their policies have to ensure that the following additional dependencies are accessible:
- The hostname of the instance's associated blob storage account:
<blob-storage-account-name>.blob.core.windows.net - The hostname of the instance's associated table storage account:
<table-storage-account-name>.table.core.windows.net - Public IP addresses from the Storage service tag corresponding to the primary location of the API Management instance
The self-hosted gateway v1 requires the following:
- The public IP address of the API Management instance in its primary location
- The hostname of the instance's management endpoint:
<apim-service-name>.management.azure-api.net - The hostname of the instance's associated blob storage account:
<blob-storage-account-name>.blob.core.windows.net - The hostname of the instance's associated table storage account:
<table-storage-account-name>.table.core.windows.net - Public IP addresses from the Storage service tag corresponding to the primary location of the API Management instance
When connectivity to Azure is lost, the self-hosted gateway is unable to receive configuration updates, report its status, or upload telemetry.
The self-hosted gateway is designed to "fail static" and can survive temporary loss of connectivity to Azure. It can be deployed with or without local configuration backup. With configuration backup, self-hosted gateways regularly save a backup copy of the latest downloaded configuration on a persistent volume attached to their container or pod.
When configuration backup is turned off and connectivity to Azure is interrupted:
- Running self-hosted gateways will continue to function using an in-memory copy of the configuration
- Stopped self-hosted gateways will not be able to start
When configuration backup is turned on and connectivity to Azure is interrupted:
- Running self-hosted gateways will continue to function using an in-memory copy of the configuration
- Stopped self-hosted gateways will be able to start using a backup copy of the configuration
When connectivity is restored, each self-hosted gateway affected by the outage will automatically reconnect with its associated API Management service and download all configuration updates that occurred while the gateway was "offline".
- Learn more about API Management in a Hybrid and Multi-Cloud World
- Learn more about guidance for running the self-hosted gateway on Kubernetes in production
- Deploy self-hosted gateway to Docker
- Deploy self-hosted gateway to Kubernetes
- Deploy self-hosted gateway to Azure Arc-enabled Kubernetes cluster
- Learn about observability capabilities in API Management