Multi-Cloud and Hybrid API Management with Azure APIM

As organizations strive towards fast-moving, and agile vision to build new capabilities and customer experiences, use of APIs are becoming the bridge to build composability while providing the freedom of choice on tools and languages among development teams. These APIs can come in many different forms, specificiations, and diverse architecture within a large enterprise as business units tend to operate independently, working on different use cases with different objectives. This leads to API sprawls that can create challenges in discovery, management, and protecting all of the organization’s APIs. There rise the need for a single universal control plane to manage, govern, observe, and discover each elements within the ecosystem.

A scalable APIM tool should be implemented as part of the strategy to manage, design, develop, deploy, secure and enforce lifecyle and discovery. Implementing an API Management Service becomes a cruicial step in establishing a mature framework. This capability should enable API Management (publish, discover, document and manage lifecycle), Access Management (secure, audit, authenticate and authorize), Centralized Observability (monitor, analyze, heartbeat, and notify).

Modern organizations have APIs on-prem, and multiple cloud providers that needs to be managed. Some providers who can provide this capabilites would include Kong Konnect, APIGee etc. Each of them have its complexity for initial setup, and maintenance. Azure API Management Service provides a fully-managed service that with self-hosted gateways that connects as a plug-n-play to enable this capability without any complex setup. This blog explores implementing APIM using Azure API Management Service within a private VNET, connecting to AWS through site-to-site VPN to manage APIs deployed in AWS.

High-level diagram of the design

Deploy Azure API Management Service within a private subnet

We will deploy API Management Service within a VNET. This will make the Developer and Management Portal accessible privately.

resource "azurerm_api_management" "apim_service" {
  name                = "<<apim-service>>"
  location            = "<<location>>"
  resource_group_name = "<<rg-name>>"
  publisher_name      = "<<Example Publisher>>"
  publisher_email     = "<<publisher@example.com>>"
  sku_name            = "Developer_1"
  virtual_network_type = "Internal"
  protocols {
    enable_http2 = false
  }
  
  tenant_access {
    enabled = true
    tenant_id = "/tenant/access"
  }
  virtual_network_configuration {
    subnet_id = "<<subnet-id>>"
  }
  policy {
    xml_content = <<XML
      <policies>
        <inbound />
        <backend>
          <forward-request />
        </backend>
        <outbound />
        <on-error />
      </policies>
XML
  }
}

Deploy Self-Hosted Gateways to other clouds

Azure provides a docker container for self-hosted gateway.

To manage APIs in other clouds, we need to deploy self-hosted gateways. Launch containers from the image below behind a load balancer. You can follow the instructions on this — https://docs.microsoft.com/en-us/azure/api-management/how-to-deploy-self-hosted-gateway-docker.

mcr.microsoft.com/azure-api-management/gateway:latest

Traffic flow and administration

Key points to note

• Self-hosted API management gateway doesn’t replace the primary API endpoints. Instead, it augments the API endpoint by providing the essential aspects of API management.
• There’s no difference between managed gateway and self-hosted gateway other than maintenance falls on the customer for self-hosted gateway. All the features available through managed gateway is available on self-hosted gateway as well.
• There’s no round-trip back to Azure for traffic routing. Traffic is kept local to the environment to avoid any latency, or resiliency issue.
• Self-hosted gateway doesn’t need bi-directional traffic. Self-hosted gateway only requires outbound connection to the Azure API Management Service to send heartbeats, get configs, and send logs and metrics back to APIM.

Azure API Service Management and APIM capability mapping

This is a mapping of capabilities we discussed above, and how you’ll be implementing these on Azure.

API Management

• Publish — APIs can be published through portal or CICD with OpenAPI 3.0 swagger.
• Discover & Document—Developer Portal provides the capability to list, mock test APIs for “products” assigned to an AD user or group
• Manage Lifecycle — Revision is a powerful capability that can enable multiple developers to work on different revision without affecting the current API or one another. Once testing is done, then revision can be made Online

Access Management

• Secure — Inbound and outbound policies can be used to secure, as well as throttle, filter by IPs etc. Policies can be applied on a granular level to methods and resources and at a global level affecting all APIs.
• Authenticate — With subscriptions and products, different logical grouping can be created with different resource & path and subscription keys to authenticate to the API. Azure AD connected (Managed Identities) authentication can also be configured through API policies.

Centralized Observability

• Monitor — Gateway continues to send metrics back to Azure Metrics on number of requests, available capacity etc.
• Alert — Alerts can be configured on any metrics reported by the Gateway.