---
title: "Best API Gateways for Azure Workloads (2026): Evaluative Comparison for Microsoft-First Teams"
description: "Compare the best API gateways for Azure workloads in 2026 — Zuplo, Azure API Management, Kong, Apigee, Tyk, and MuleSoft. Evaluation criteria, Azure integration depth, and a decision framework for Microsoft-first teams."
canonicalUrl: "https://zuplo.com/learning-center/best-api-gateways-for-azure-workloads-2026"
pageType: "learning-center"
authors: "nate"
tags: "API Gateway"
image: "https://zuplo.com/og?text=Best%20API%20Gateways%20for%20Azure%20Workloads%20(2026)"
---
**Our pick: [Zuplo](https://zuplo.com) is the best API gateway for Azure
workloads in 2026.** It deploys as a managed dedicated instance on Azure with
Private Link and VNet peering for secure backend connectivity, integrates
natively with Entra ID, and replaces Azure APIM's XML policies with TypeScript —
all while keeping your option to run the same gateway on AWS, GCP, or at the
edge. [Get started free](https://portal.zuplo.com/signup).

If your backend runs on Azure, choosing the right API gateway is a decision that
shapes your security posture, deployment velocity, and long-term portability.
Azure API Management is the default choice for Microsoft-first teams, but it is
not the only choice — and for many workloads, it is not the best one.

This guide evaluates six API gateways through the lens of Azure workloads
specifically. We cover Entra ID integration, Azure Functions and AKS support,
Private Endpoint connectivity, GitOps workflows, multi-cloud portability, and
total cost of ownership. Whether you are building on App Service, running
containers on AKS, or deploying Azure Functions, you will find the right gateway
for your stack here.

For a broader comparison that is not Azure-specific, see
[Best API Gateways in 2026](/learning-center/best-api-gateways-2026). For a
head-to-head Azure APIM comparison, see
[Azure API Management vs Zuplo](/learning-center/azure-api-management-vs-zuplo).

## How to Choose an API Gateway When Your Backend Runs on Azure

Evaluating API gateways for Azure workloads requires criteria specific to the
Microsoft ecosystem. Here are the eight dimensions that matter most for
Microsoft-first teams.

### Entra ID (Azure AD) Integration

Enterprise Azure environments run on Microsoft identity. Your API gateway must
validate Entra ID JWT tokens on inbound requests, authenticate against Entra ID
for backend service-to-service calls, and support Entra ID SSO for the developer
portal. Gateways that treat Microsoft identity as an afterthought create
friction for every team that relies on Conditional Access Policies, App Roles,
or B2B guest access.

### Azure Functions and App Service Support

Most Azure API backends run on Azure Functions, App Service, or Azure Container
Apps. The gateway needs to route to these services securely — ideally through
Private Endpoints so your backends never need public IP addresses. Native
support for Azure's networking primitives (Private Link, VNet peering) is a
meaningful advantage over gateways that only connect via public URLs.

### AKS and Container Workload Support

For teams running microservices on Azure Kubernetes Service, the gateway should
connect to internal AKS load balancers and private cluster endpoints. This
typically requires VNet peering or a tunnel agent. Gateways that deploy on AKS
as a Kubernetes Ingress Controller offer tight integration but add operational
overhead.

### Private Endpoint and VNet Connectivity

Azure backends behind Private Endpoints or internal VNets need a gateway that
supports Azure Private Link or VNet peering. Without this, you are forced to
expose backends to the public internet — which defeats the purpose of private
networking. Private DNS zone configuration (`privatelink.azurewebsites.net`,
`privatelink.{region}.azurecontainerapps.io`) must also be supported.

### Cost Predictability

Azure API Management's tiered pricing creates cost cliffs — jumping from Basic
v2 at ~\$150/month to Standard v2 at ~\$700/month to Premium v2 at
~\$2,800/month. Evaluate whether each gateway tier aligns with your workload
size, or whether a flat pricing model offers better predictability.

### Multi-Cloud Portability

Not every Azure team wants to stay Azure-only forever. A gateway that runs on
Azure today but can deploy to AWS, GCP, or the edge tomorrow avoids the
single-cloud lock-in that constrains future architectural decisions.

### Developer Portal and GitOps

A developer portal auto-generated from your OpenAPI spec saves weeks of manual
documentation work. GitOps-native deployments — where every configuration change
flows through Git with pull requests and branch previews — bring the same
developer workflow your team uses for application code to your API
infrastructure.

### AI Gateway and MCP Readiness

AI agents are becoming API consumers. An API gateway that supports
[MCP (Model Context Protocol)](/learning-center/what-is-an-mcp-server)
for exposing APIs to AI systems and includes an [AI Gateway](/ai-gateway) for
governing LLM traffic positions your platform for the next generation of API
consumption patterns.

## Zuplo — The Multi-Cloud Managed Gateway That Runs on Azure Without Lock-In

[Zuplo](https://zuplo.com) is a fully managed API gateway that deploys as a
dedicated instance on Azure with native Private Link and VNet peering support.
Unlike Azure API Management, Zuplo gives you the same gateway on Azure, AWS,
GCP, or at the edge — so you get deep Azure integration without single-cloud
lock-in.

For Microsoft-first teams, Zuplo addresses the specific pain points that drive
teams away from Azure APIM: XML policies become TypeScript, 30-minute ARM
deployments become 20-second GitOps pushes, and single-region gateways become
300+ edge locations with zero infrastructure to manage.

### How Zuplo Works on Azure

**Managed dedicated deployment on Azure.** Zuplo provisions a single-tenant
instance on Azure in the region of your choice. Your gateway runs in an isolated
network environment with no shared resources. You get the operational simplicity
of a managed service with the data residency and network isolation of a
self-hosted deployment.

**Azure Private Link and VNet peering.** Zuplo connects to your private Azure
backends through two networking patterns:

- **Private Endpoints (Azure Private Link)** — the preferred approach for Azure
  PaaS services like App Service, Azure Functions, Container Apps, Azure SQL,
  and Key Vault. Private Link scopes access to a specific service without
  exposing your wider VNet.
- **VNet peering** — for backends reachable only on private IPs inside a VNet,
  such as internal AKS load balancers or hub-and-spoke topologies.

Neither pattern requires your backends to have public IP addresses.

**Entra ID integration at every layer.** Zuplo integrates with Entra ID at three
distinct points:

1. **Developer portal authentication** — uses OpenID Connect with PKCE against
   your Entra ID tenant, supporting single-tenant, multi-tenant, and B2B guest
   access patterns
2. **Inbound API authentication** — the
   [OpenID JWT authentication policy](https://zuplo.com/docs/policies/open-id-jwt-auth-inbound)
   validates bearer tokens from Entra ID (or any OpenID provider) by checking
   signatures against the JWKS endpoint, verifying expiration, issuer, and
   audience claims
3. **Outbound backend authentication** — the upstream Azure AD service auth
   policy uses OAuth 2.0 client credentials to mint and cache short-lived tokens
   for calls to your Azure Functions, App Service, or AKS backends — automating
   token management instead of passing long-lived secrets directly

**Sub-20-second global deploys via GitOps.** Every Git push triggers a
deployment that propagates across 300+ edge locations in under 20 seconds.
Branches map 1:1 to environments, so every feature branch gets its own preview
environment with a unique URL. Zuplo integrates natively with GitHub, GitLab,
Bitbucket, and Azure DevOps (via `npx zuplo deploy` in Azure Pipelines).

**TypeScript policies instead of XML.** Zuplo policies are written in TypeScript
using web-standard APIs (`Request`, `Response`, `fetch`). You get full type
safety, IDE autocompletion, and access to the npm ecosystem — a stark contrast
to Azure APIM's XML policy language with embedded C# expressions.

**AI Gateway and MCP Gateway.** Zuplo's
[AI Gateway](https://zuplo.com/docs/ai-gateway/introduction) routes requests to
multiple LLM providers (including OpenAI and OpenAI-compatible services such as
Azure OpenAI) with semantic caching, prompt injection protection, and
hierarchical token budget controls. The
[MCP Gateway](https://zuplo.com/mcp-gateway) provides centralized governance for
MCP servers with SSO credential brokering, per-team RBAC, and audit logging for
every tool call. Azure APIM does not offer a comparable native AI Gateway or MCP
Gateway.

**SOC 2 Type II and EU data residency.** Zuplo is SOC 2 Type II audited
annually, supports GDPR-aligned data processing, and lets you choose specific
Azure regions for data residency via managed dedicated deployment.

**Key strengths for Azure workloads:**

- Managed dedicated deployment on Azure with Private Link and VNet peering
- Entra ID integration for portal auth, inbound JWT validation, and outbound
  backend auth
- Global deploys in under 20 seconds via GitOps (including Azure DevOps)
- TypeScript policies with npm ecosystem access
- AI Gateway with OpenAI-compatible provider support (including Azure OpenAI)
  and MCP Gateway
- SOC 2 Type II, GDPR, and configurable data residency
- Multi-cloud portability — same gateway on Azure, AWS, GCP, or edge

**Tradeoffs:**

- Not Azure-native in the way APIM is — does not integrate with Azure Logic Apps
  or Azure Monitor natively (exports to Datadog, Splunk, and custom SIEMs)
- TypeScript-only for custom policies (not a concern for most modern teams)
- Younger ecosystem compared to decade-old platforms like Kong

**Best for:** Microsoft-first teams that want deep Azure integration without
Azure-only lock-in, teams migrating off Azure APIM's XML policies, and
organizations that need a managed gateway with enterprise compliance. See the
[Azure APIM to Zuplo migration guide](/learning-center/migrating-from-azure-api-management-to-zuplo)
for a step-by-step walkthrough.

## Azure API Management — When the Native Service Is (and Isn't) the Right Answer

[Azure API Management](https://azure.microsoft.com/en-us/products/api-management/)
is Microsoft's native API management service. It provides the deepest
integration with the Azure ecosystem — Entra ID, Functions, Logic Apps,
Application Insights, and Key Vault all work natively. For teams that are fully
committed to Azure and need tight platform integration, APIM is a natural
starting point.

### When Azure APIM Is the Right Choice

Azure APIM makes sense in specific scenarios:

- **You need Azure Logic Apps integration** for workflow orchestration behind
  your APIs
- **Your team already manages ARM/Bicep templates** and wants API infrastructure
  in the same IaC pipeline
- **You need the Consumption tier's pay-per-call pricing** for low-traffic
  internal APIs
- **Your organization mandates Azure-native services** for compliance or
  procurement reasons

### When Azure APIM Becomes a Blocker

For many teams, Azure APIM's limitations become apparent as APIs scale:

**XML policy language.** All policies in Azure APIM are defined in XML with four
processing stages. Expressions mix XML with inline C# expressions, which is
difficult to read, test, and maintain. Microsoft introduced a Policy Toolkit for
C# authoring, but the underlying format remains XML. Compare this to Zuplo's
TypeScript policies with full IDE support and type safety.

**Consumption tier cold starts.** The serverless Consumption tier experiences
cold-start delays of 16–25 seconds when no recent traffic has occurred. This
rules it out for latency-sensitive production APIs.

**Classic tier deployment speed.** Classic (v1) tiers take 30–45 minutes to
provision or apply infrastructure-level changes. The newer v2 tiers improve this
significantly (minutes instead of hours), but there is no in-place migration
path from classic to v2 — you must create a new deployment.

**Tiered pricing cliffs.** Jumping from Basic v2 (~\$150/month) to Standard v2
(~\$700/month) to Premium v2 (~\$2,800/month) creates sharp cost increases. Each
tier unlocks different feature sets (VNet integration requires Standard v2 or
above), making capacity planning tightly coupled to pricing decisions.

**Limited multi-cloud.** Azure APIM's self-hosted gateway component can run on
other clouds, but the control plane always stays in Azure. This is not true
multi-cloud — it is Azure-centric with a multi-cloud escape hatch.

**Key strengths for Azure workloads:**

- Deepest native Azure integration (Entra ID, Functions, Logic Apps, Key Vault,
  Monitor)
- Built-in developer portal with theming
- Infrastructure-as-Code via Bicep, ARM, Terraform
- Self-hosted gateway option for hybrid scenarios
- v2 tiers with faster provisioning

**Tradeoffs:**

- XML policies with C# expressions are verbose and hard to maintain
- Consumption tier cold starts (16–25 seconds)
- No classic-to-v2 migration path
- Premium v2 limited to 6 Azure regions at launch
- Not a multi-cloud gateway

**Best for:** Teams deeply embedded in the Microsoft ecosystem who need Logic
Apps integration, ARM/Bicep IaC, and Azure-native compliance. See
[Azure API Gateway vs API Management](/learning-center/azure-api-gateway-vs-api-management)
to understand the difference between Azure's own gateway services.

## Kong on Azure — Enterprise Kubernetes Gateway for AKS Workloads

[Kong](https://konghq.com/) is the most widely adopted open-source API gateway,
and it runs on Azure through two primary deployment patterns: self-hosted on AKS
using the Kong Ingress Controller, or as a managed service via Kong Konnect
Dedicated Cloud Gateways.

### How Kong Deploys on Azure

**Self-hosted on AKS.** Kong Gateway (open-source or Enterprise) deploys to
Azure Kubernetes Service via Helm charts or the Kong Kubernetes Ingress
Controller. This gives full operational control but requires managing Redis (for
shared rate limiting state) and optionally PostgreSQL for the control plane.

**Kong Konnect Dedicated Cloud Gateways.** Kong's managed SaaS platform launched
with Azure support across five initial regions (Frankfurt, Ireland, UK,
US-Virginia, US-Washington) and has been expanding regional coverage. Konnect
provides a cloud-hosted control plane with single-tenant data planes on Azure,
Azure VNet peering support, and managed Redis.

**Entra ID support.** Kong supports Microsoft Entra ID authentication via its
OIDC plugin for token validation. The Konnect developer portal supports Azure
IdP configuration for SSO.

**Key strengths for Azure workloads:**

- Extensive plugin ecosystem (70+ production-ready plugins)
- Kubernetes-native via Kong Ingress Controller on AKS
- True multi-cloud: single Konnect control plane managing gateways on AWS,
  Azure, and GCP
- Managed Redis on Azure for stateful rate limiting
- AI proxy plugins for LLM traffic routing

**Tradeoffs:**

- Self-hosted on AKS requires managing Redis, database, and gateway
  infrastructure
- Enterprise features (portal, RBAC, OIDC plugin, analytics) require paid
  Konnect licensing
- Konnect Dedicated Cloud on Azure launched with 5 regions (expanding)
- Pricing complexity: ~\$105/month per gateway service plus ~\$34/million API
  requests, with enterprise contracts starting at \$30,000–\$50,000/year

**Best for:** Enterprise platform teams with Kubernetes expertise who need
extensive plugin customization and are already running AKS clusters. See
[Kong vs Zuplo](/learning-center/kong-vs-zuplo) for a head-to-head comparison.

## Apigee on Azure — Google's Gateway in Front of Azure Backends

[Apigee](https://cloud.google.com/apigee) is Google Cloud's enterprise API
management platform. Apigee X runs exclusively on Google Cloud, but Apigee
Hybrid allows the runtime to run on AKS while the control plane stays on GCP.

### How Apigee Deploys on Azure

Apigee Hybrid splits the architecture: the control plane (management APIs,
analytics, policy configuration) is always hosted by Google on GCP, while the
runtime plane runs on your AKS cluster. This means API traffic stays on Azure
infrastructure, but all management operations and analytics flow through Google
Cloud.

Google publishes Terraform blueprints for automating multi-cloud Apigee Hybrid
deployments across GKE, EKS, and AKS.

**Key strengths for Azure workloads:**

- Mature API lifecycle management with deep analytics
- Apigee Hybrid runtime runs on AKS for data locality
- Built-in monetization with multiple billing models
- Strong governance and API product management

**Tradeoffs:**

- Control plane is always GCP-resident — management operations, analytics, and
  configuration flow through Google Cloud regardless of where the runtime runs
- Requires a GCP account and billing alongside Azure infrastructure
- Apigee Hybrid installation and management on AKS is operationally complex
  (Kubernetes, Cassandra, connectivity back to GCP)
- XML-based policies with Java callouts for custom logic
- Standard tier starts at ~\$500/month; enterprise pricing typically
  \$8,000–\$25,000/month plus AKS infrastructure costs
- No native Entra ID integration beyond standard OIDC/OAuth2

**Best for:** Large enterprises already invested in Apigee that need runtime
data locality on Azure while accepting GCP control plane dependency. See
[Apigee vs Zuplo](/learning-center/apigee-vs-zuplo) for a detailed comparison.

## Tyk on Azure — Self-Hosted Multi-Cloud Gateway

[Tyk](https://tyk.io/) is an open-source API gateway written in Go that supports
self-hosted, cloud, and hybrid deployments on Azure.

### How Tyk Deploys on Azure

**Self-managed on AKS or VMs.** Tyk Gateway, Dashboard, Pump, Redis, and
PostgreSQL deploy on Azure infrastructure. This gives full data sovereignty but
requires operating a multi-component stack.

**Tyk Cloud on Azure.** Tyk's managed SaaS platform supports dedicated
single-tenant deployment on Azure. The Starter tier begins at \$600/month for up
to 5 APIs and 10 million calls.

**Hybrid.** Control plane on Tyk Cloud, data plane (gateway) self-hosted on AKS.
API traffic stays on Azure while Tyk manages the control plane.

**Key strengths for Azure workloads:**

- Open-source core (Apache 2.0) with no feature lockout on the gateway
- High-performance Go-based runtime
- Flexible deployment: self-hosted, cloud, or hybrid on Azure
- Cloud-agnostic design with multi-cloud and on-premises support
- GraphQL, REST, TCP, and gRPC protocol support

**Tradeoffs:**

- Self-managed stack requires Redis plus PostgreSQL/MongoDB and multiple
  components — significant Kubernetes expertise needed
- Tyk Operator for Kubernetes became closed-source (October 2024) and now
  requires a paid license
- Smaller plugin ecosystem and community compared to Kong or APIM
- No native Azure service integrations (Azure Monitor, Key Vault, etc.)
- Cloud pricing beyond the \$600/month Starter tier requires direct sales
  engagement

**Best for:** Teams that want genuine open-source flexibility with self-hosted
data sovereignty on Azure, and have the platform engineering resources to manage
the operational stack. See [Tyk vs Zuplo](/learning-center/tyk-vs-zuplo) for a
detailed comparison.

## MuleSoft Anypoint on Azure — Enterprise Integration Platform as Gateway

[MuleSoft Anypoint](https://www.mulesoft.com/) is Salesforce's enterprise
integration platform that includes API management capabilities. It is the
broadest tool in this comparison — an iPaaS (integration Platform as a Service)
that also manages APIs, rather than a purpose-built API gateway.

### How MuleSoft Works on Azure

**Anypoint Runtime Fabric on AKS.** MuleSoft's Runtime Fabric deploys Mule
runtime engines on Azure Kubernetes Service. Organizations bring their own AKS
cluster and MuleSoft manages the runtime layer. Licensing is based on vCores
allocated to Mule application replicas.

**CloudHub 2.0.** MuleSoft's managed SaaS runtime runs on Salesforce's
Hyperforce infrastructure, not on Azure directly.

**Entra ID integration.** MuleSoft supports Entra ID as an identity provider for
platform SSO, with documented limitations: only Entra ID v2.0 tokens are
supported, custom scopes are not available, and the introspection endpoint
requires MuleSoft-specific configuration.

**Key strengths for Azure workloads:**

- Broadest integration platform — API management plus iPaaS with 1,000+
  pre-built connectors
- Pre-built connectors for Azure Service Bus, Blob Storage, and Data Lake
- Runtime Fabric on AKS for data plane control on Azure
- Salesforce ecosystem integration

**Tradeoffs:**

- Among the most expensive options: enterprise deployments with 20–50+ vCores
  typically run \$300,000–\$500,000/year, with first-year total cost often 2–3×
  the subscription
- Significant overkill if you only need API gateway capabilities
- CloudHub control plane runs on Salesforce infrastructure, not Azure
- High complexity and learning curve for teams that do not need full iPaaS
  capabilities
- Entra ID integration has scope limitations

**Best for:** Enterprises that need MuleSoft's integration capabilities (not
just API gateway) and are already invested in the Salesforce ecosystem. For
teams that only need an API gateway, Zuplo, Azure APIM, or Kong offer
purpose-built solutions at a fraction of the cost.

## Decision Framework: Native Azure APIM vs. Portable Multi-Cloud

The gateway choice for Azure workloads often comes down to a fundamental
architectural question: do you want the deepest native Azure integration, or do
you want portability?

### Choose Azure API Management When

- Your organization mandates Azure-native services for compliance or procurement
- You depend on Azure Logic Apps integration for API workflow orchestration
- Your team already manages ARM/Bicep templates and wants APIs in the same IaC
  pipeline
- Budget allows for Premium v2 tier and its regional limitations are acceptable

### Choose Zuplo When

- You want managed Azure deployment (Private Link, VNet peering, Entra ID) but
  need multi-cloud portability
- Your team prefers TypeScript over XML for gateway policies
- You need global sub-20-second deploys via GitOps, including Azure DevOps
  integration
- You want AI Gateway and MCP Gateway capabilities that Azure APIM does not
  offer
- You need a developer portal with self-serve API key management and
  monetization out of the box

### Choose Kong When

- Your platform team has deep Kubernetes expertise and wants AKS-native
  deployment
- You need an extensive plugin ecosystem for custom gateway behaviors
- You want a single control plane managing gateways across Azure, AWS, and GCP

### Choose Apigee or Tyk When

- **Apigee** — You are already invested in Google's API management ecosystem and
  need runtime on AKS while accepting a GCP-resident control plane
- **Tyk** — You need a genuinely open-source gateway with self-hosted data
  sovereignty on Azure and have the team to operate the stack

### Choose MuleSoft When

- You need a full enterprise integration platform (iPaaS), not just an API
  gateway, and are already in the Salesforce ecosystem

## Migration Patterns for Teams Moving Off Azure APIM

If your team has outgrown Azure API Management — whether because of XML policy
friction, deployment speed, or multi-cloud requirements — Zuplo provides a clear
migration path.

The
[Migrating from Azure API Management to Zuplo](/learning-center/migrating-from-azure-api-management-to-zuplo)
guide covers:

- **Architecture translation** — mapping APIM's products, subscriptions, and
  named values to Zuplo's routes, API keys, and environment variables
- **Policy mapping** — converting XML policies to TypeScript equivalents
  (authentication, rate limiting, IP filtering, request transformation, CORS)
- **Developer portal migration** — moving from APIM's built-in portal to Zuplo's
  OpenAPI-driven developer portal with self-serve key management
- **Phased rollout** — a four-phase approach (discovery, pilot, migration,
  cutover) that most teams complete in two to four weeks

For a direct feature comparison, see
[Azure API Management vs Zuplo](/learning-center/azure-api-management-vs-zuplo).
For the comparison page, see
[Zuplo vs Azure API Management](/api-gateways/azure-api-management-alternative-zuplo).

## Getting Started with Zuplo on Azure

If you are evaluating API gateways for Azure workloads, here is a practical path
forward:

1. **Try the free tier** — [Sign up for Zuplo](https://portal.zuplo.com/signup)
   and deploy your first API with authentication, rate limiting, and a developer
   portal in minutes. No credit card required.

2. **Import your OpenAPI spec** — Zuplo auto-generates routes and documentation
   from your existing OpenAPI definition, so you can see how your current APIs
   look on Zuplo immediately.

3. **Test Entra ID integration** — Configure
   [OpenID JWT authentication](https://zuplo.com/docs/policies/open-id-jwt-auth-inbound)
   against your Entra ID tenant to validate that your existing Microsoft
   identity setup works with Zuplo.

4. **Evaluate managed dedicated** — For production Azure workloads that need
   Private Link or VNet peering, talk to the Zuplo team about
   [managed dedicated deployment](https://zuplo.com/docs/dedicated/overview) on
   Azure in your preferred region.

Ready to evaluate Zuplo for your Azure workloads?
[Sign up free](https://portal.zuplo.com/signup) and deploy your first API with
authentication, rate limiting, and a developer portal in minutes — no credit
card required.

## Related Guides

- [Best API Gateways in 2026](/learning-center/best-api-gateways-2026) — A
  broader comparison of 10 API gateways not scoped to Azure
- [Azure API Management vs Zuplo](/learning-center/azure-api-management-vs-zuplo)
  — Direct head-to-head feature comparison
- [Azure API Gateway vs API Management](/learning-center/azure-api-gateway-vs-api-management)
  — Understanding the difference between Azure's own gateway services
- [Migrating from Azure API Management to Zuplo](/learning-center/migrating-from-azure-api-management-to-zuplo)
  — Step-by-step migration guide with policy mapping
- [Modern API Gateway Alternative to Azure, AWS, and Kong](/learning-center/modern-api-gateway-alternative-azure-aws-kong)
  — Why teams choose a modern alternative to incumbent gateways