Considering AI Gateway alternatives?
Move beyond AI experimentation and confidently deliver AI solutions into production with Kong.
The market for AI gateways is rapidly expanding, with a growing number of offerings that focus on managing and securing LLM traffic, adding guardrails, and providing visibility into AI usage. Many of these solutions, however, are narrowly scoped point products — designed for basic AI proxying or single-vendor ecosystems — and lack the maturity, flexibility, and governance capabilities required by enterprises.
As organizations move beyond experimentation into production-scale AI adoption, the need for a comprehensive API + AI platform becomes clear. Enterprises don’t just need an AI proxy; they need a platform that unifies API and AI governance, supports hybrid and multi-cloud environments, and enforces policies across both human and machine consumers. This is where Kong delivers a major advantage: by extending a proven API platform into the AI era, Kong combines best-in-class runtime performance with enterprise-grade governance, cost control, and extensibility.
To help enterprises evaluate their options, we’ve organized this analysis into three major product areas:
Core AI Functionality
AI gateways are critical infrastructural components for exposing LLMs to developers, applications, and AI agents in a secure, reliable, and cost-effective manner.
When your AI Gateway limits the number of models you can use, you limit your business’ AI potential.
- Kong: Multi-LLM support across thousands of models with a unified abstraction layer, integrated into the same Kong Gateway runtime layer.
- LiteLLM: Supports a broad catalog across multiple providers.
- Portkey: Supports a broad catalog across multiple providers.
- Databricks Mosaic: Primarily tied to models hosted in the Databricks/MosaicML ecosystem; limited cross-vendor flexibility. Even when connecting to external providers, workloads remain tied to Databricks’ control plane.
- Solo Gloo: Extends Kubernetes Gateway API to AI traffic; supports external LLMs but optimized for K8s-native deployments.
- Google Apigee: Treats each LLM as an API proxy, with the ability to route to Gemini, Vertex-hosted models, as well as external providers like OpenAI or Anthropic. It offers broad connectivity, but lacks a unified multi-model abstraction layer. All orchestration assumes Apigee + Vertex AI, introducing partial Google lock-in.
- AWS Bedrock: Aggregates a broad set of models under the AWS umbrella. However, all models are delivered only through AWS services, limiting portability and usage across environments.
- Azure: Connects to Azure OpenAI, Foundry, and popular external providers, but orchestration is Azure-first and endpoint-by-endpoint. In many deployments, non-OpenAI models are integrated through passthrough, which forwards requests with limited governance, visibility, and cost control.
Traffic control automates routing of requests to different models, applies rate limiting, and ensures the fastest and most cost-efficient model is used. Semantic caching further reduces spend by avoiding unnecessary calls.
- Kong: Advanced traffic control via AI Proxy Advanced plugin. Cost/latency routing, semantic routing, semantic caching, and token-aware rate limiting for granular cost control.
- LiteLLM: Cost and latency-based routing, semantic routing (via AutoRouter + semantic-router), and semantic caching supported.
- Portkey: Cost and latency-based routing, conditional/task-based routing, semantic caching. Smart routing documented, but no explicit semantic-similarity routing capability.
- Databricks Mosaic: Rate limiting per user/endpoint, but lacks advanced routing (no semantic routing, semantic caching, or token-aware rate limiting).
- Solo Gloo: Can route and secure AI traffic across providers with support for rate limiting, retries, and load balancing. However, it does not provide semantic routing, semantic caching, or token-aware rate limiting; functionality is limited to Envoy’s standard traffic management capabilities.
- Google Apigee: Reuses standard API policies for LLMs. Token-budget enforcement and semantic caching are available, but these are tied to Apigee X + Vertex AI. Advanced controls like token-aware rate limiting, semantic routing, and cross-cloud orchestration remain DIY workflows.
- AWS Bedrock: Routing is limited to a single model family. Only one can be active at a time, restricting fallback and cross-provider orchestration.
- Azure: Provides token quotas, semantic caching, and load balancing. However, advanced orchestration patterns like semantic routing and intelligent fallback aren’t documented as first-class features.
As more organizations adopt MCP as the integration layer between agents, LLMs, APIs, and tools, organizations must prioritize secure, reliable exposure of MCP servers — just like they do for traditional APIs.
- Kong: Enterprise-grade MCP gateway with auto-generation of MCP servers from any API, centralized OAuth enforcement, real-time observability, and Konnect portals that double as MCP entry points, making APIs instantly discoverable for AI agents.
- LiteLLM: Provides a fixed-endpoint MCP gateway for accessing all MCP tools, but lacks advanced security and observability controls.
- Portkey: Supports “Remote MCP Servers” via its Responses API, offering flexibility but no centralized auth or governance.
- Databricks Mosaic: Supports hosting custom, managed, and external MCP servers via Databricks Apps (currently in Beta), but all must route through the Unity Catalog, lack centralized auth, have delayed (hour-plus) observability metrics, and offer no dedicated MCP portal or catalog.
- Solo Gloo: Provides Kagent, an MCP gateway with support for both MCP and A2A protocols, primarily optimized for Kubernetes-native teams.
- Google Apigee: Enables MCP servers to be proxied with standard API policies. Authentication and observability rely on manual setup or Cloud Logging. No centralized OAuth enforcement, catalog, or integrated MCP analytics dashboards.
- AWS AgentCore: Allows developers to expose APIs or Lambdas as MCP tools, but configuration for Lambda is manual and tied to AWS services.
- Azure: Exposes REST APIs as MCP servers, secures them with Entra ID, and registers them in the Azure API Center. However, OAuth enforcement is configured per server, and MCP observability relies on manually built Azure Application Insights dashboards.
LLM governance enforces consistent best practices for security, reliability, and compliance across the full AI lifecycle.
- Kong: Comprehensive governance with policy-as-code, automation, and IaC to enforce federated guardrails org-wide across APIs and LLMs.
- LiteLLM: RBAC is available, but other basic governance features are in beta.
- Portkey: RBAC is available, org/workspace isolation, team management, workspace-level rules.
- Databricks Mosaic: Governance is limited to the Databricks environment. No API productization, developer/consumer management, or federated policies. Discovery of MCP endpoints is manual through notebooks/UI.
- Solo Gloo: Namespace/workspace isolation via Kubernetes, but lacks multi-org federated governance.
- Google Apigee: Offers LLM governance through its existing API framework: quotas, product-level access, and discovery in API Hub. Cost tracking via token budgets is supported, but federated governance and enterprise-wide AI guardrails require custom integrations with Vertex AI or Model Armor.
- AWS Bedrock: Supports guardrails for PII sanitization and blocking harmful content. However, policies are AWS-defined, and there is no unified management plane to enforce consistent policies across multiple gateways.
- Azure: Enforces quotas, subscriptions, and access rules via XML-based policies. However, governance remains endpoint-centric, without federated guardrails or consistent policy-as-code across hybrid and multi-cloud AI environments.
Guardrails and sanitization capabilities are critical as direct access to models can expose organizations to PII leaks, prompt injection, and compliance risks.
- Kong: Easily sanitize and protect personal data, passwords, and 20+ more categories of PII across 12 different languages and most major AI providers. Inherits 100+ enterprise-grade plugins from the Kong Gateway for AuthN/AuthZ, ACLs, mTLS, OAuth2, and advanced rate limiting, enabling unified enforcement of security and compliance policies across both APIs and AI traffic.
- LiteLLM: Security guardrails (PII masking, prompt injection, etc.) are currently labeled as “Beta.” These include guardrail integrations like Presidio and prompt validation, available in preview but still under ongoing development.
- Portkey: Built-in PII detection and redaction capabilities are documented.
- Databricks Mosaic: Built-in PII detection optimized for U.S. use cases, but detection-only with no masking or removal. Lack of masking limits enterprise readiness outside U.S. regions.
- Solo Gloo: Provides security through Envoy filters and OPA policy enforcement within Kubernetes. Can apply mTLS, JWT validation, and namespace isolation for controlling access. However, it lacks AI-specific guardrails like semantic prompt filtering or multi-language PII sanitization.
- Google Apigee: Does not provide built-in LLM security. Apigee relies on Model Armor for AI-specific protections like prompt injection filtering, PII sanitization, and data loss prevention.
- AWS AgentCore: Integrates with IAM, Cognito, and OAuth providers for authentication. However, AgentCore only secures APIs and Lambdas—it cannot proxy existing MCP servers in passthrough mode, limiting reuse of external MCP endpoints.
- Azure: Offers Content Safety and Language APIs for PII detection alongside gateway-level token validation. However, enforcement is app-level, and real-time guardrails like prompt injection or streaming response filtering aren’t centralized at the gateway.
Sensitive credentials (keys, tokens, passwords) must be stored securely, auditable, and integrated with enterprise vaults.
- Kong: Enterprise-grade integrations with major secret managers (e.g., HashiCorp Vault, Azure Key Vault, AWS Secrets Manager, GCP Secret Manager, CyberArk). Provides consistent key handling across APIs and AI traffic, with built-in support for automated rotation and policy-driven access enforcement.
- LiteLLM: Provides enterprise-grade secrets management with support for third-party vaults (e.g., HashiCorp Vault).
- Portkey: Supports a native secrets vault (“Virtual Keys”) where provider keys are stored using envelope encryption. For enterprise or self-managed deployments (Hybrid or Air-gapped), Portkey supports BYOK integration with Azure Key Vault, AWS KMS, and GCP KMS, but it does not support other notable enterprise vaults like HashiCorp Vault or similar providers.
- Databricks Mosaic: Provides only basic key handling tied to Mosaic endpoints. No documented integration with external vaults, lifecycle management, or automated rotation controls.
- Solo Gloo: Relies on Kubernetes secrets and CRD-based configuration. While suitable for K8s-native teams, it does not offer direct integration with enterprise secret managers like HashiCorp Vault, Azure Key Vault, or AWS KMS.
- Google Apigee: Integrates with Google Secret Manager and IAM to handle credentials. Integrating with external vaults like HashiCorp or CyberArk is possible, but it requires custom workflows or connectors, making multi-cloud secrets management more complex.
- AWS AgentCore: Secrets are handled via AWS-native services, but there is no native integration available for third-party vaults.
- Azure: Integrates with Azure Key Vault and Managed Identity for credential storage. Integrating with external vaults like HashiCorp or CyberArk is possible, but it requires custom workflows or connectors, making multi-cloud secrets management more complex.
RAG reduces hallucinations, however the implementation process can be developer-intensive and create security risks if VectorDBs are directly exposed.
- Kong: Standardizes RAG enforcement across the organization. Kong improves AI response accuracy and reduces hallucinations with RAG implemented at the gateway layer by default.
- LiteLLM: RAG integrations with AWS Bedrock knowledge bases, Vertex AI RAG Engine, PGVector, and OpenAI Vector Stores.
- Portkey: No automated RAG capability documented.
- Databricks Mosaic: No automated RAG at the gateway layer. Any RAG workflows must be built manually in notebooks or ML pipelines.
- Solo Gloo: Supports RAG by enabling devs to manually configure vector datastores and augment prompts with retrieved data, however RAG is currently not supported for Gemini and Vertex AI providers.
- Google Apigee: Does not provide a turnkey RAG engine at the gateway level. Instead, customers can implement RAG via Vertex AI or external vector stores, with Apigee acting as the policy enforcement layer around those pipelines.
- AWS Bedrock: Provides managed Knowledge Bases for RAG: automating ingestion, embedding, and retrieval. However, retrieval flows are AWS-native only.
- Azure: Supports RAG through Cognitive Search and Prompt Flow integrations. However, RAG pipelines are app-level, with no centralized governance at the gateway layer for consistency across deployments.
No-code request/response transforms accelerate rollout and reduce risk by centralizing enforcement outside of application code.
- Kong: Enables customers to integrate legacy (or modern) technology into LLMs without having to write application code through the use of AI request & response transformer plugins.
- LiteLLM: No equivalent gateway-level transformers documented; requires app-level code.
- Portkey: No equivalent gateway-level transformers documented; relies on configuration-driven controls (routing, caching, budgets, RBAC).
- Databricks Mosaic: Configuration handled via UI or Python client, with many controls remaining UI-bound. No Terraform or GitOps pipeline support for declarative or no-code transformations.
- Solo Gloo: Policies and routing configured through Kubernetes CRDs; while powerful for K8s-native teams, there are no dedicated no-code request/response transformers for AI-specific use cases.
- Google Apigee: Reuses API policy framework for low-code AI integrations. Templates exist for caching and security, but most AI orchestration still requires GCP add-ons like Vertex AI or Model Armor.
- AWS Bedrock: Provides “playgrounds” for prompts, guardrails, and model comparison. However, these no-code tools stop at prototyping, and publishing full workflows still requires developer orchestration.
- Azure: Low-code setup accelerates onboarding of OpenAI or Foundry endpoints. However, advanced no-code orchestration and AI-native transformations remain developer-driven, limiting accessibility for non-technical teams.
API runtime infrastructure and the API producer experience
To be successful with LLM initiatives, organizations will need more than just an AI gateway. Customers will need a comprehensive control plane that provides the ability to automatically onboard new teams and their infrastructure, instantly deploy new LLMs with plugins that go beyond just the AI use cases, and also have traditional API management controls for access tiers, authorization, authentication and more. Additionally, they will need a way to document which AI providers and models are available for developers to use, with RBAC in place to restrict which developers access.
In addition to the Kong AI Gateway, the Kong Konnect API platform is optimized for managing AI traffic at scale by:
- Enabling centralized access, security, federated governance and visibility.
- Implementing usage tracking, cost allocation, and budgeting controls per team or project
- Supporting scalability & self-service enablement
- Providing deployment flexibility across any environment
Enterprises need a unified platform that manages both APIs and AI services with consistent policies, rather than siloed tools.
- Kong: Provides full API + AI management in one control plane, with policies, governance, and visibility spanning all APIs and LLMs — reducing silos and simplifying platform operations.
- LiteLLM: Focused narrowly on proxying AI calls; lacks full API management lifecycle features such as tiered plans, developer onboarding, or consumer analytics.
- Portkey: Strong AI routing and analytics, but does not cover broader API lifecycle management (APIs, products, versioning).
- Databricks Mosaic: Primarily manages Databricks-hosted models; no API productization or API consumer management.
- Solo Gloo: Kubernetes-native gateway; can manage APIs and AI endpoints inside of K8s, but lacks multi-cloud or non-K8s API lifecycle breadth.
- Google Apigee: Extends mature API management to AI, applying the same governance, quotas, and analytics to LLMs. AI-specific features are accessed through Vertex AI and Model Armor rather than within Apigee itself.
- AWS Bedrock: Provides a single entry point for AWS-hosted models and third-party providers. However, it lacks a broader control plane for APIs, policy federation, and multi-team governance.
- Azure: Extends existing API management with GenAI-specific policies like token limits, semantic caching, and telemetry. However, AI-specific governance is fragmented across Azure API management, Foundry, and Cognitive Services.
AI adoption at scale requires deep visibility into usage and spend. Without built-in observability, teams risk runaway costs, compliance gaps, and lack of accountability. AI Gateways should provide metrics (tokens, latency, cost) broken down by model, provider, team, or endpoint — and make them easy to act on.
- Kong: Provides native AI analytics in Kong Konnect: per-model/provider/team token usage, latency, and cost — all alongside API traffic in a single pane. Integrates with OTel for export, and includes advanced tool-call analytics, budget alerts, and cost controls to prevent overruns.
- LiteLLM: Exposes basic metrics (token counts, latency, cost) via OpenTelemetry; enterprises often need to plug into their own observability stack (Grafana, Datadog, etc.) for deeper cost tracking. Governance around per-team cost allocation is limited.
- Portkey: Offers a dedicated analytics suite with filters by model, cost, tokens, latency, metadata, and time range. Includes developer feedback loops, but lacks a unified single-pane view across both AI and traditional APIs.
- Databricks Mosaic: Includes inference tables and usage tracking, but logs can take up to an hour to appear, limiting real-time visibility. Cost attribution tied to Databricks billing makes fine-grained team allocation difficult. Usage tracking, logging, and guardrails are add-on paid features.
- Solo Gloo: Provides token and usage visibility through Envoy/Kubernetes metrics. Can track consumption by model, provider, or namespace, but requires custom dashboards via Prometheus/Grafana to visualize per-team or per-endpoint spend.
- Google Apigee: Provides token usage, latency, and error metrics in Apigee analytics, plus budget enforcement and semantic cache reports. However, native analytics can typically lag by ~10 minutes, and fine-grained AI observability across models or teams requires external services like Looker Studio.
- AWS AgentCore: Surfaces observability through CloudWatch dashboards and logging. However, monitoring is AWS-siloed, with no unified MCP analytics or cross-vendor cost governance for multi-cloud AI workloads.
- Azure: Integrates with Application Insights, Azure Monitor, and Event Hub to track token usage, latency, and budgets. Foundry provides developer-level dashboards on model usage and token consumption, but cloud-cost attribution is not built-in. On-premises deployments require the local equivalents of these observability tools.
As LLM adoption grows, organizations will need to process millions of requests reliably, with minimal latency and predictable throughput. A performant gateway not only reduces costs by optimizing traffic and caching responses, but also ensures customer-facing applications are responsive, with accurate results. Poor performance at the gateway layer can amplify downstream costs, increase latency for end-users, and ultimately limit the scalability of AI initiatives.
- Kong: Benchmark-proven leader: 859% faster vs LiteLLM, 228% faster vs Portkey, with semantic caching + token-aware rate limiting (source).
- LiteLLM: Proxy-only; benchmarks show Kong is 859% faster throughput and 86% lower latency (source).
- Portkey: Provides caching/routing, but Kong outperformed it by 228% throughput and 65% lower latency (source).
- Databricks Mosaic: No external benchmarks published. Monitoring is delayed, with inference table logs taking up to an hour to appear.
- Solo Gloo: Envoy-based; strong in K8s but no AI-specific performance features published.
- Google Apigee: Apigee X and Hybrid are Envoy-based, while legacy Apigee Edge is Java-based with higher latency. No AI-specific performance benchmarks are published; performance depends on applied policies, routing complexity, and GCP integrations.
- AWS AgentCore: AgentCore enables long-running, large-payload agents (~8h/100MB). Meanwhile, AWS API Gateway times out at 30s and 10MB, making it unsuitable for AI-scale APIs.
- Azure: Supports autoscaling and caching to handle load. However, it is documented that scale-out changes can often take 15+ minutes, and published resource limits (v2 tiers) constrain throughput headroom.
For a self-serve platform to succeed, runtime provisioning needs to be simple, consistent, and adaptable to different enterprise environments. Provisioning should support multiple deployment models — self-hosted, hybrid, or cloud-native — while giving teams the ability to roll out infrastructure quickly across monolithic, microservices, and multi-cloud environments.
- Kong: Kong provides flexible deployment options with a setup script generated directly in the Konnect control plane, tailored for the chosen runtime environment. Connections between control and data planes are secured with mTLS. Cloud deployments are fully configurable and can be provisioned across multiple regions and providers, enabling self-service onboarding for a variety of teams. This flexibility ensures consistent and secure provisioning across hybrid, multi-cloud, Kubernetes, VM, and bare-metal environments.
- LiteLLM: Provisioning is entirely manual and configuration-driven. Teams must set up LiteLLM as a proxy, configure environment variables, and maintain the routing logic themselves. There is no control-plane integration, automation workflow, or self-service provisioning experience for new teams. As a result, it can be challenging to implement consistency and repeatability across environments.
- Portkey: Provisioning is limited to AI routing rules and integrations defined through its dashboard or APIs. While this makes it relatively straightforward to onboard an AI provider, it does not extend to broader gateway provisioning or automated rollout of policies across environments. Enterprises that want to enforce standardized runtime deployments must rely on external automation or manual configuration, making Portkey more of a point solution than a platform.
- Databricks Mosaic: Gateways cannot be deployed independently outside Databricks workspaces. Limited to managed deployments in AWS, Azure, or GCP — with no on-premises or private data center option. All workloads are tied to Databricks infrastructure, restricting hybrid and multi-cloud flexibility.
- Solo Gloo: Provisioning is handled entirely through Kubernetes CRDs. While this provides strong declarative control for Kubernetes-native teams, it is YAML-heavy and requires significant Kubernetes expertise. For teams outside Kubernetes, the process is more complex. There are no turnkey setup scripts or multi-cloud runtime provisioning workflows, and consistency is limited to what Kubernetes itself enforces.
- Google Apigee: Provisioned as a managed service (Apigee X) or via Hybrid (control plane in GCP, runtimes in Kubernetes). Deployment is tied to Google Cloud, with no turnkey air-gapped provisioning.
- AWS AgentCore: Provides a simple launch flow for deploying agents within AWS. However, deployments are AWS-only, and extending to hybrid or multi-cloud environments requires extra tooling and manual setup.
- Azure: Supports SaaS, hybrid, and containerized gateways. However, there is no turnkey deployment for on-prem or multi-cloud provisioning.
IaC ensures consistency across environments, while APIOps shifts governance left into CI/CD pipelines. Automation is crucial to enforce governance across the AI and API lifecycle. Without various and in-depth automation offerings, teams will be left to slow, error-prone manual work.
Many organizations eventually make the decision to move from a “click ops” approach to an infrastructure-as-code approach. This approach requires platform and infrastructure teams to be able to automate the various actions typically done within the GUI and ensure that certain guardrails are in place so that every step of the API lifecycle is compliant with their organizations’ various policies and procedures.
For example, the team taking an IaC approach to API deployment and publishing might set up a series of automated steps that result in every API always being deployed with:
- A gateway in front of them
- Gateway policies configured (i.e., rate limiting, authorization, etc.)
- Publishing to a developer portal with documentation
The application of these kinds of practices within your larger API strategy is often referred to as APIOps, and this is one area where Kong has an advantage over every other API management solution in the space.
- Kong: Built from the ground up for declarative configuration and automation. Kong offers support for declarative config via our Gateway operator (Kubernetes Operator) for Kube-native teams or our decK CLI and/or Terraform provider for non Kube-native teams. Kong's Admin API works for all supported versions of Kong control planes and data planes, is well-documented, and easy to start with.
- LiteLLM: Offers some API endpoints, but automation and IaC offerings are limited. Because they don’t offer API Platform functionality, they have no automation and IaC tooling for the entirety of the AI API lifecycle. The API also forces imperative config, which might not be suitable for many organizations–especially those that are Kubernetes-native and prefer declarative config.
- Portkey: Offers some API endpoints, but automation and IaC offerings are limited. Because they don’t offer API Platform functionality, they have no automation and IaC tooling for the entirety of the AI API lifecycle. The API also forces imperative config, which might not be suitable for many organizations–especially those that are Kubernetes-native and prefer declarative config.
- Databricks Mosaic: No declarative IaC. Configuration is handled via UI or Python client, with limited automation support. Many policies remain UI-only, and there is no GitOps alignment.
- Solo Gloo: CRD-driven and GitOps-friendly, but only for K8s. For organizations operating in hybrid or multi-cloud environments that include VMs, serverless, or non-K8s workloads, this model becomes restrictive.
- Google Apigee: Supports IaC via Admin APIs, Terraform, Maven plugins, and Kubernetes manifests, with CI/CD through Cloud Build. Automation is viable but fragmented, relying on XML/JSON-heavy policies and manual setup for AI-specific workflows.
- AWS AgentCore: Provides SDK/CLI support for automation. However, there’s no turnkey Terraform or cross-cloud IaC support.
- Azure: Supports IaC through ARM, Bicep, and Terraform. However, with management APIs deprecated, automation is tied to ARM’s resource-centric RBAC model, which can add operational complexity.
A modern gateway must be extensible — allowing organizations to add features, integrate systems, and enforce policies without rewriting infrastructure.
- Kong: Delivers extensibility with a proven plugin framework, supporting 100+ policies and integrations spanning security, observability, traffic control, and AI.
- LiteLLM: Minimal extensibility beyond Python code; lacks plugin ecosystem.
- Portkey: Closed system; enterprises are limited to what Portkey builds.
- Databricks Mosaic: Extensibility confined to Databricks services and Python SDK.
- Solo Gloo: Good extensibility within Kubernetes using CRDs and Envoy filters; limited outside K8s.
- Google Apigee: Extends API management functionality through policies (e.g., ServiceCallout) and AI-focused policies such as semantic caching. For advanced security, Apigee integrates with external services like Model Armor, keeping extensibility tied to GCP.
- AWS Bedrock: Extensibility comes through managed features like guardrails, model routing, and RAG knowledge bases, however, enterprises can’t add custom extensions at the gateway layer.
- Azure: Enables extensibility with custom XML policies and Azure-native integrations like Monitor and Key Vault. While effective in Azure environments, this framework lacks the portability enabled by plugin-driven frameworks.
Protocol mediation in an event gateway enables HTTP-based applications to still garner the benefit of access to real-time data, even if that real-time data is locked down inside of an event broker that does not communicate over HTTP.
- Kong: Kong Gateway can be used as an event gateway that exposes event broker resources (i.e., Kafka broker) as HTTP-based event APIs, such as REST APIs and server-sent event APIs. You can also use Kong Gateway to enforce policies to shape event-based API traffic.
- LiteLLM: No native support in LiteLLM.
- Portkey: No native support in Portkey.
- Databricks Mosaic: No native support in Databricks.
- Solo Gloo: Gloo Gateway can be extended to act as an Event Gateway, such as exposing Kafka brokers over HTTP via an event-driven proxy pattern. However, this requires using Gloo in combination with a Kafka HTTP bridge or REST proxy.
- Google Apigee: Does not provide a native Event Gateway. Apigee can front event APIs over HTTP and apply standard API policies, but lacks dedicated event mediation or event-native abstractions.
- AWS AgentCore: Relies on AWS API Gateway and EventBridge for event routing. These services may work well within AWS, but they don’t provide unified governance across non-AWS platforms.
- Azure: The API Management offering can expose event APIs (HTTP/SSE) and apply policies, but it lacks a dedicated Event Gateway. Real-time streaming requires integration with Event Hub, Event Grid, or Service Bus, adding complexity for unified governance.
Service meshes are key infrastructural components for organizations that want to govern and implement zero-trust security across microservices-based, service-to-service communication.
- Kong: Yes, Kong provides Kong Mesh (based on Kuma and Envoy). It enables organizations to deploy a service mesh that is multi-cloud, multi-cluster, and supports both Kubernetes and VM-based workloads. Kong Mesh delivers zero-trust security, advanced traffic routing, observability, and policy enforcement with a simpler operational model compared to Istio — giving enterprises a more flexible and scalable service mesh solution.
- LiteLLM: No, LiteLLM does not provide a service mesh.
- Portkey: No, Portkey does not provide a service mesh.
- Databricks Mosaic: No, Databricks does not provide a service mesh.
- Solo Gloo: Yes, Solo offers Gloo Mesh, an Istio-based service mesh. It provides mTLS, traffic routing, observability, and policy enforcement across Kubernetes clusters. While powerful for K8s-native teams, it inherits Istio’s operational complexity and is less accessible for non-Kubernetes environments.
- Google Apigee: No native service mesh, but Google will likely recommend Anthos Service Mesh (Istio-based) for service-to-service connectivity.
- AWS AgentCore: No built-in service mesh, but AWS will likely recommend ECS Service Connect.
- Azure: No native service mesh integrated with the API management offering. However, Azure offers an Istio-based service mesh add-on for AKS.
Developer portals accelerate onboarding, self-service, and internal/external adoption of APIs and AI models.
- Kong: Offers multi-portal flexibility with support for distinct identity providers, enabling tailored experiences across business units. It combines highly customizable, branded content using markdown components with fine-grained visibility controls powered by RBAC and IdP integrations. Developers benefit from modern, auto-generated OpenAPI and AsyncAPI docs with built-in “try it” functionality, while integrated analytics provide actionable insights across APIs, versions, developers, and applications.
- LiteLLM: No developer portal; onboarding is manual.
- Portkey: Offers dashboards, but no API/AI developer portal.
- Databricks Mosaic: No dedicated portal; developers interact via UI or Databricks notebooks.
- Solo Gloo: Basic YAML-driven portal; optional Backstage integration but not enterprise-grade.
- Google Apigee: Provides an integrated developer portal for API products with documentation, quotas, and monetization. AI model endpoints can also be published as products.
- AWS Bedrock: No vendor-managed developer portal solution.
- Azure: Provides a built-in portal for API onboarding and AI endpoints. However, enterprises that need more than one portal must self-host and manage it as a standalone app. Its coupling to Azure identity also limits multi-tenant and external developer scenarios.
A catalog provides visibility into available APIs, models, and tools, with ownership, versioning, and access policies.
- Kong: Full API/AI service catalog with ownership, dependencies, compliance scoring. The Kong Service Catalog offers an automated solution for generating a comprehensive catalog of all services running in your organization. By integrating with both Konnect-internal applications, like Gateway Manager and Mesh Manager, as well as external applications like GitHub and PagerDuty, Service Catalog provides you with a 360 overview into each of your organization’s services. It presents you with information that includes who the service’s owner is, its upstream and downstream dependencies, its code repositories, its CI/CD pipelines, and whether it is fronted by an API gateway or is part of a service mesh.
- LiteLLM: No support for service catalog.
- Portkey: Provides a Model Catalog for AI models, but not for APIs.
- Databricks Mosaic: Unity Catalog for data, but no API/AI service catalog.
- Solo Gloo: No built-in catalog, but can integrate with Backstage.
- Google Apigee: Apigee has no direct equivalent to Kong’s service catalog. They have tangentially related services like the API hub that acts as a repository and governance tool for all APIs within an organization, but fails to integrate with 3rd party services—limiting how much context and governance can be provided.
- AWS AgentCore: Tool discovery is supported, but there’s no unified catalog spanning APIs, models, and services.
- Azure: The Azure API Center and API management offerings can catalog APIs for discovery and subscriptions, and MCP servers can also be registered. However, AI models and MCP tools are managed separately, without a unified cross-cloud catalog for enterprise-wide visibility.
Enterprise-readiness
Beyond feature comparisons, it’s important to recognize a broader challenge in the market. Many vendors are either early-stage with small teams, or mature in traditional API offerings but only beginning to build out their AI capabilities. While they may bring useful features, enterprises require a partner with the proven scale, enterprise support, and engineering experience to keep up with fast-changing AI needs. This is where mature platforms with a unified API + AI approach stand apart—offering both innovation and the stability required for long-term enterprise adoption.
An organization needs to know and trust the vendors they rely on. Enterprises should evaluate not just features, but also vendor maturity, global support presence, compliance posture, and proven ability to sustain mission-critical deployments over time.
- Kong: 24/7/365 globally distributed support team along with professional services (architects + field engineers) and local customer success & account managers.
- LiteLLM: Operates with a very small team and community-driven support model (e.g., Slack/Discord). Enterprises may find this level of support and compliance maturity insufficient for mission-critical deployments. Past security missteps, such as exposed user information, further underscore concerns around enterprise readiness (source).
- Portkey: Enterprise support offered, however, Portkey is still a company with less than 20 employees, and is unproven.
- Databricks Mosaic: Missing enterprise features such as advanced secret management, unified security policies, and automated governance. Requires additional charges for usage tracking, guardrails, and logging. Monitoring/logging latency (up to an hour) and mandatory Unity Catalog control plane increase vendor lock-in risk.
- Solo Gloo: Venture-backed company with Kubernetes-native expertise and a portfolio of Envoy/Istio-based products. Gloo AI Gateway is relatively new and tightly tied to Kubernetes expertise; lacks the global scale, breadth of deployment models, and federated enterprise support of larger platforms.
- Google Apigee: Enterprise maturity proven for API management, but AI-specific governance, guardrails, and observability still rely on adjacent GCP services like Model Armor and Vertex AI.
- AWS AgentCore: Benefits from AWS operational maturity, but expect some constraints while AgentCore is still in preview.
- Azure: The AI offering is backed by Microsoft’s global support infrastructure and SLAs, however, API/AI support issues may escalate through general Azure support paths rather than domain experts.
All comparative statements are based on our best interpretation of public-facing collateral, research, and word-of-mouth information. If you notice any inaccuracies and want to submit a correction request, please reach out to hello@konghq.com.
Kong Konnect: The API platform that powers your AI innovation
Many AI gateways only focus on proxying requests, leaving enterprises without the governance or scale they need. Kong takes it a step further by extending its proven API platform into the AI domain. By choosing Kong, organizations every day are able to securely scale multi-model adoption, enforce cost and compliance policies, and accelerate the rollout of AI-powered products.