Zuplo
Learning Center
API Gateway

API Gateway Architecture Decisions: A 2026 Reference for Engineering Leaders

Nate TottenNate Totten
May 14, 2026
17 min read

A staff-engineer-level decision framework for choosing an API gateway in 2026 — covering edge vs regional deployment, programmability, managed dedicated hosting, compliance, and AI readiness.

Every engineering team building APIs eventually faces the same inflection point: the API surface has grown beyond what a reverse proxy can handle, and someone needs to make a gateway decision. If you’ve reached that point — or you’re re-evaluating a legacy choice — this reference is for you.

This is not a “top 10 gateways” listicle. It’s a decision framework written for staff and principal engineers who need to justify an architecture choice to their CTO, their security team, and their future selves. We’ll walk through five decisions that every team makes (whether they realize it or not), name the trade-offs in each, and show how today’s major gateways — including Zuplo, Kong, AWS API Gateway, Azure API Management, Apigee, Tyk, and Gravitee — handle them.

Contents

The five gateway-architecture decisions every team makes

Most gateway evaluations devolve into feature-comparison spreadsheets. That approach fails because it treats all features as equally important and ignores the architectural constraints that actually determine whether a gateway fits your system.

Instead, we’ve found that every gateway selection reduces to five sequential decisions:

  1. Where does the gateway run? Edge-deployed vs region-pinned topology.
  2. How do you extend it? Declarative config vs programmable handlers.
  3. Who operates the infrastructure? Managed dedicated vs multi-tenant SaaS vs self-hosted.
  4. How does it handle identity and compliance? SSO, audit, and regulatory posture.
  5. Is it ready for AI and agent traffic? AI Gateway and MCP Gateway capabilities.

These decisions are sequential because each one constrains the next. A self-hosted gateway gives you topology control but takes managed compliance off the table. An edge-deployed gateway gives you global latency but may complicate data residency. Work through them in order.

Decision 1: Edge-deployed vs region-pinned

The first question is where your gateway physically runs relative to your users and your backends.

Region-pinned gateways

Most traditional gateways run in a single cloud region (or a handful of regions you manually configure). AWS API Gateway deploys to one AWS region per API. Apigee X runs in a Google Cloud region (you can add additional regions, but each is a separate configuration). Azure API Management provisions a gateway instance in one Azure region, with premium-tier support for multi-region — each requiring a separately billed instance that takes 30+ minutes to provision.

Region-pinned gateways are the right choice when your consumers are concentrated in one geography, your backends are in the same region, and you have strict data residency requirements that mandate all processing happens in a specific jurisdiction.

The downside: every request from a user outside that region pays a latency tax. Authentication, rate limiting, request validation — all of that happens after the request has already traveled across the globe. For a public API with global consumers, that latency compounds into a meaningfully worse developer experience.

Edge-deployed gateways

Edge-deployed gateways run your policies at the network edge, close to wherever the request originates. Zuplo deploys to 300+ edge locations worldwide using a V8 isolate-based runtime — the same execution model as Cloudflare Workers and Deno Deploy, but purpose-built for API gateway workloads. Authentication, rate limiting, and request validation happen at the edge, before the request ever traverses the public internet to your backend.

Kong Gateway is self-hosted, so topology is your choice — you can deploy it at the edge if you operate your own edge infrastructure, but most Kong deployments run in a central cluster. Cloudflare API Gateway runs at the edge but is primarily a routing and protection layer, not a full API management platform.

How to decide: edge vs region

Choose edge-deployed if:

  • Your API serves consumers across multiple continents
  • You need sub-50ms policy enforcement (auth, rate limiting, validation) regardless of consumer location
  • You want to terminate TLS and enforce security policies before traffic reaches your cloud VPC

Choose region-pinned if:

  • All your consumers and backends are in the same region
  • Regulatory requirements mandate that all request processing (not just data storage) happens in a specific jurisdiction
  • You’re building an internal API that only serves co-located services

How Zuplo handles this: Zuplo’s managed edge deployment runs your gateway across 300+ data centers with zero infrastructure for you to manage. Every policy — authentication, rate limiting, request validation, response transformation — executes at the edge. For teams that need regional control, Zuplo also offers managed dedicated deployment pinned to specific cloud regions.

Decision 2: Declarative config vs programmable handlers

The second decision determines your team’s day-to-day experience with the gateway. How do you express routing rules, security policies, and custom logic?

Declarative-only gateways

Some gateways use a purely declarative model: you write YAML or XML configuration, and the gateway interprets it at runtime. Azure API Management uses XML-based policies (verbose, hard to test, and hostile to code review). AWS API Gateway uses JSON/YAML mapping templates for request/response transformation — functional for simple cases, but debugging a VTL mapping template at 2 AM is nobody’s idea of a good time.

Declarative config works well for standard patterns: route this path to that backend, require an API key, add a CORS header. It breaks down when you need conditional logic, data aggregation from multiple backends, or anything that looks like actual programming.

Plugin-based extensibility

Kong extends through Lua plugins (with Go and JavaScript plugin support added more recently). Tyk uses JavaScript middleware running in a Go-hosted runtime. Envoy uses C++ filters or WebAssembly. These approaches give you programmability, but the developer experience varies wildly. Writing a Lua plugin for Kong means learning a niche language, packaging it correctly, and testing it against Kong’s specific execution model.

For a detailed comparison of plugin architectures across every major gateway, see our API Gateway Plugin Architectures Compared guide.

Programmable handlers with declarative wiring

The third option — and the one we believe produces the best long-term outcomes — combines TypeScript programmability with declarative configuration.

Zuplo’s approach gives you three extension points, all written in TypeScript:

  • Inbound policies run before the handler and can inspect, modify, or short-circuit requests
  • Request handlers produce the response (proxy to a backend, aggregate multiple services, or generate data directly)
  • Outbound policies run after the handler to transform responses before they reach the client

Each of these is a standard TypeScript function using web-standard Request and Response types via Zuplo’s ZuploRequest and ZuploContext. You wire them together declaratively in JSON configuration:

JSONjson
{
  "policies": [
    {
      "name": "validate-request",
      "policyType": "custom-code-inbound",
      "handler": {
        "export": "default",
        "module": "$import(./modules/validate-request)"
      }
    }
  ]
}

The policy itself is TypeScript you can unit test, code review, and reason about:

TypeScripttypescript
import { ZuploRequest, ZuploContext } from "@zuplo/runtime";

export default async function (
  request: ZuploRequest,
  context: ZuploContext,
  options: { requiredFields: string[] },
  policyName: string,
): Promise<ZuploRequest | Response> {
  const body = await request.json();
  for (const field of options.requiredFields) {
    if (!(field in body)) {
      return new Response(
        JSON.stringify({ error: `Missing required field: ${field}` }),
        { status: 400, headers: { "content-type": "application/json" } },
      );
    }
  }
  return request;
}

This isn’t a toy example. This is the actual pattern Zuplo teams use in production. You get full access to the npm ecosystem, typed options, and a familiar development workflow — git push deploys your gateway, and every branch gets its own preview environment.

How to decide: extensibility model

Choose declarative-only if:

  • Your gateway use cases are entirely standard (routing, basic auth, rate limiting) and you never anticipate needing custom logic
  • Your team lacks TypeScript/JavaScript experience and doesn’t want to invest in it

Choose plugin-based if:

  • You’re already running Kong or Envoy and your team has invested in the plugin ecosystem
  • You need specific plugins from the Kong Hub or Envoy filter ecosystem

Choose programmable handlers with declarative wiring if:

  • Your team writes TypeScript (or JavaScript) and wants gateway logic to live in the same workflow as application code
  • You need custom logic beyond what declarative config supports — aggregation, conditional routing, response shaping, or integration with external services
  • You want every gateway change to go through code review and CI/CD

How Zuplo handles this: Zuplo is built from the ground up as a programmable API gateway. Policies and handlers are TypeScript functions wired together in JSON config. You get dozens of built-in policies for common patterns (rate limiting, authentication, validation, caching) plus the ability to write custom policies that deploy atomically via git push. No Lua, no XML, no VTL templates.

Decision 3: Managed dedicated vs multi-tenant SaaS vs self-hosted

The third decision is about operational responsibility. Who wakes up at 3 AM when the gateway has a problem?

Self-hosted

Kong Gateway (open source or Enterprise) and Tyk are the most prominent self-hosted options. You run the gateway on your own infrastructure — Kubernetes clusters, VMs, or bare metal. Self-hosted deployments require you to manage the Gateway, Dashboard/Admin API, a database (PostgreSQL or Cassandra for Kong; Redis plus MongoDB or PostgreSQL for Tyk), and any supporting infrastructure like load balancers and monitoring.

Self-hosted gives you maximum control. You choose the hardware, the network topology, the upgrade schedule, and the scaling strategy. The cost is operational burden: you need a team that understands how to run, monitor, upgrade, and scale the gateway infrastructure. For a detailed analysis of this trade-off, see Managed vs Self-Hosted API Gateway.

Multi-tenant SaaS

AWS API Gateway and Apigee X are fully managed, multi-tenant services. You don’t operate any infrastructure — the cloud provider handles scaling, availability, and upgrades. The trade-offs are vendor lock-in (your gateway configuration is deeply coupled to one cloud provider), limited customization (you get the features the provider ships, on their timeline), and noisy-neighbor risk (you share infrastructure with every other customer on the platform).

Azure API Management sits in an awkward middle ground: it’s a managed service, but each instance is dedicated to your subscription. Provisioning a new instance takes 30+ minutes, and every environment (dev, staging, production) requires a separately billed APIM instance.

Managed dedicated

Managed dedicated is the third option, and it resolves the tension between “I don’t want to operate infrastructure” and “I need single-tenant isolation.”

Zuplo’s managed dedicated deployment runs dedicated gateway instances on your chosen cloud provider — AWS, Azure, GCP, Akamai, Equinix, or TerraSwitch — without you managing any of the underlying infrastructure. You get single-tenant security boundaries, data residency in the regions you specify, and Zuplo handles provisioning, scaling, upgrades, and incident response.

Kong Konnect offers a hybrid model: the control plane is SaaS, and the data plane (the actual gateway) runs on your infrastructure. This gives you more control than pure SaaS but still requires you to operate the data plane nodes.

How to decide: operational model

Choose self-hosted if:

  • You have strict requirements that mandate running all components on infrastructure you physically control
  • You have an experienced platform team that wants fine-grained control over every aspect of the gateway
  • You’re running in an air-gapped or classified environment

Choose multi-tenant SaaS if:

  • You’re a small team that needs a gateway quickly and your API traffic is entirely within one cloud provider
  • You’re building a prototype or MVP where operational simplicity trumps everything else

Choose managed dedicated if:

  • You need single-tenant isolation for compliance or security but don’t want to operate the infrastructure
  • You run workloads across multiple cloud providers and need a gateway that isn’t tied to one
  • You want predictable performance without noisy-neighbor risk

How Zuplo handles this: Zuplo gives you both options — managed edge for global, multi-tenant deployment across 300+ locations, and managed dedicated for single-tenant isolation on your cloud. You can mix both models: use managed edge for public-facing APIs that need global reach and managed dedicated for internal or regulated APIs that need data residency. The developer experience is identical across both deployment models.

Decision 4: Identity, SSO, and audit posture for regulated workloads

The fourth decision matters most to teams in regulated industries — fintech, healthcare, government — but every growing API program eventually runs into it.

What regulated workloads require

At minimum, a gateway serving regulated workloads needs:

  • SSO integration for the gateway’s control plane (not just for API consumers — for the engineers who configure the gateway)
  • Role-based access control so that a developer can deploy to staging but not production, and a security engineer can modify policies but not routes
  • Immutable audit logs that record every configuration change, every deployment, and every access event
  • Compliance certifications (SOC 2 Type II at minimum, with HIPAA, PCI DSS, or FedRAMP depending on your industry)

How the major gateways compare on compliance

Zuplo provides SOC 2 Type II certification (audited annually), SAML SSO and SCIM provisioning for enterprise identity management, role-based access control across organizations, projects, and environments, and immutable audit logs across the control plane. For data plane audit logging, Zuplo offers a dedicated Audit Log policy with an API to retrieve logs programmatically.

Kong Enterprise offers SOC 2 compliance, RBAC through Kong Manager, and audit logging as an add-on feature in the Enterprise tier. The audit log capability covers Admin API actions but requires additional configuration for data plane request logging.

Azure API Management inherits Microsoft’s compliance stack — SOC 2, HIPAA, FedRAMP, and dozens of other certifications. Azure Active Directory provides SSO. The compliance story is strong if you’re already in the Microsoft ecosystem, but APIM-specific audit logging requires Azure Monitor integration and the data flows through Microsoft’s observability stack.

AWS API Gateway relies on IAM for access control and CloudTrail for audit logging. There’s no built-in SSO for the gateway-specific control plane — it’s all IAM policies. This works if your team lives in AWS, but it means your gateway access control is coupled to your cloud provider’s identity model.

Apigee X inherits Google Cloud’s compliance certifications. Access control uses Google Cloud IAM. Audit logging goes through Cloud Audit Logs. Similar to AWS, the compliance story is strong but tightly coupled to the cloud provider.

How to decide: compliance posture

If your team operates in a regulated industry, prioritize gateways that provide native compliance capabilities rather than relying entirely on the underlying cloud provider’s controls. The distinction matters because cloud-native compliance tools (IAM, CloudTrail, Azure Monitor) cover the infrastructure layer but may not provide gateway-specific audit trails — like who changed a rate limit policy, who deployed a new route, or who modified an authentication scheme.

How Zuplo handles this: Zuplo treats compliance as a first-class feature, not an add-on. SOC 2 Type II, SAML SSO, SCIM provisioning, RBAC, and audit logs are available on the Enterprise plan. The governance features provide visibility into every configuration change and deployment across your entire API program — independent of which cloud provider hosts your gateway infrastructure.

Decision 5: AI and MCP readiness

The fifth decision is the newest, and it’s moving from “nice to have” to “blocking requirement” faster than most teams expect. If your organization uses LLMs, AI agents, or MCP-connected tools, your API gateway needs to govern that traffic.

What AI readiness means for an API gateway

AI readiness isn’t a single feature — it’s three capabilities:

  1. AI Gateway — a control plane for outbound LLM calls. Route requests across multiple AI providers, enforce token budgets, cache semantically similar prompts, detect prompt injection, and mask secrets before they reach third-party models.
  2. MCP Gateway — governance for the Model Context Protocol. As AI agents connect to internal tools and APIs via MCP, you need a way to catalog approved MCP servers, enforce per-team access control, and audit every tool invocation.
  3. API-as-MCP-tool exposure — the ability to make your existing REST APIs discoverable and callable by AI agents without rewriting them.

For a deep dive on how these three capabilities relate, see The Three Gates of AI Infrastructure.

How the major gateways compare on AI readiness

Zuplo offers all three capabilities on a single platform. The AI Gateway provides multi-provider LLM routing, semantic caching, prompt injection protection, secret masking, and per-team budget controls. The MCP Gateway provides a centralized catalog of approved MCP servers, per-role access control, virtual MCP servers (exposing only selected tools per team), SSO-brokered authentication, and full audit logging for every MCP interaction. Security policies — PII detection, prompt injection blocking — apply across API, AI, and MCP traffic from one policy engine.

Kong launched Kong AI Gateway as a separate product, offering LLM routing and AI-specific plugins. MCP support has matured from an initial proxy plugin into an Enterprise MCP Gateway with OAuth 2.1 authentication, observability, and governance features. In early 2026, Kong also launched an Agent Gateway extending AI Gateway to cover A2A traffic alongside LLM and MCP. Kong’s AI capabilities and API gateway capabilities remain separate products on the Kong Konnect platform.

Gravitee added AI gateway features in late 2025 and was recognized in the Gartner Market Guide for AI Gateways. Gravitee supports converting existing APIs to MCP tools and offers unified policies across API and AI traffic. MCP analytics and an enterprise MCP Resource Server were introduced in Gravitee 4.11.

Tyk launched Tyk AI Studio with multi-model routing, cost metering, and MCP support — available as a separate product from Tyk Gateway.

Apigee added the ability to auto-generate MCP servers from existing API specs — a strong feature for teams with large API portfolios. Apigee provides LLM governance capabilities through Google’s Model Armor (prompt validation, output filtering) and token-based policies integrated into its existing platform, but does not offer a separately branded AI Gateway product.

AWS API Gateway and Azure API Management have no native AI Gateway or MCP Gateway features. You’d need to build custom Lambda functions or Azure Functions to achieve LLM routing and MCP governance, or add a separate AI gateway product in front of or behind your API gateway.

For a detailed feature-by-feature comparison, see our AI Gateway Comparison 2026 guide.

How to decide: AI readiness

If your organization is already using LLMs or AI agents, AI readiness is a current requirement, not a future one. Prioritize gateways that offer AI governance natively rather than bolting it on later.

If AI adoption is on your roadmap but not yet in production, favor gateways that have shipped AI capabilities today over those that promise them on a future roadmap. The difference between “shipped” and “planned” is the difference between evaluating a product and evaluating a press release.

How Zuplo handles this: Zuplo’s AI Gateway, MCP Gateway, and API Gateway compose on a single policy engine. You don’t need three separate products or three separate vendor relationships. One platform governs REST API traffic, LLM calls, and MCP tool invocations with consistent authentication, rate limiting, and audit logging across all three traffic patterns.

Putting it together: three reference architectures

Abstract frameworks are useful, but architects need concrete examples. Here are three reference architectures for common scenarios, with named gateway recommendations.

Scenario 1: Regulated fintech with EU data residency

Requirements:

  • EU data residency for all API traffic processing
  • SOC 2 Type II compliance, immutable audit logs
  • SAML SSO with an existing identity provider
  • Public-facing APIs for partners plus internal APIs for microservices
  • Growing AI agent integration for fraud detection workflows

Recommendation: Zuplo managed dedicated on EU-region infrastructure.

Deploy Zuplo’s managed dedicated gateway on a European cloud region (AWS eu-west-1, Azure West Europe, or GCP europe-west1). All API traffic processing — authentication, rate limiting, validation, logging — stays within the EU. SAML SSO integrates with your existing IdP. Audit logs capture every configuration change and deployment. As AI agent traffic grows, Zuplo’s MCP Gateway governs tool access without adding a second vendor.

Why not the alternatives? AWS API Gateway meets the regional requirement but lacks native SSO for the gateway control plane and has no AI/MCP governance. Azure APIM works if you’re already on Azure, but per-environment billing and 30-minute provisioning times slow down development workflows. Kong Enterprise could work self-hosted, but you’d need a platform team to operate it, and AI governance would require a separate Kong AI Gateway deployment.

Scenario 2: High-volume public API with global consumers

Requirements:

  • Sub-50ms authentication and rate limiting for consumers worldwide
  • API key management and a developer portal for external developers
  • Monetization — usage-based billing for API consumers
  • TypeScript-based customization for request/response transformation
  • 50,000+ requests per second at peak

Recommendation: Zuplo managed edge.

Zuplo’s edge deployment across 300+ locations ensures that every API request hits a nearby gateway node. Authentication and rate limiting happen at the edge before the request reaches your backend. Zuplo’s built-in developer portal and API key management serve your external developer community. Monetization is handled through Zuplo’s built-in capabilities. TypeScript handlers let you implement custom transformation logic without learning Lua or XML.

Why not the alternatives? Kong can handle the volume but doesn’t deploy at the edge unless you operate your own edge infrastructure — most Kong deployments run in a central cluster with CDN-level caching in front. Apigee offers a developer portal and monetization but runs region-pinned and charges enterprise pricing. AWS API Gateway lacks a developer portal, API key management, and monetization.

Scenario 3: Multi-cloud enterprise migrating off legacy APIM

Requirements:

  • Currently running Apigee Edge (end of life) or Azure APIM
  • Workloads spread across AWS, Azure, and GCP
  • Needs a single gateway vendor across all three clouds
  • 200+ APIs managed by 15+ teams
  • GitOps workflow for gateway configuration

Recommendation: Zuplo managed dedicated on each cloud, unified control plane.

Deploy Zuplo managed dedicated instances on each cloud where you have workloads. Each instance runs on the respective cloud provider (AWS, Azure, GCP), but all instances share the same Zuplo control plane — same policies, same developer portal, same audit logs. Gateway configuration lives in Git, and every change deploys through CI/CD.

For teams migrating from Apigee, Zuplo provides a migration guide that maps Apigee concepts to Zuplo equivalents. For teams on Azure APIM, the Azure to Zuplo migration path covers the transition from XML policies to TypeScript handlers.

Why not the alternatives? Kong Konnect offers multi-cloud support but requires you to operate the data plane on each cloud. AWS API Gateway and Azure APIM are locked to their respective clouds. Apigee X runs on Google Cloud only (Apigee Hybrid can run on other clouds, but the control plane stays on GCP).

What we’d choose, and why

We’re not going to pretend to be neutral here — Zuplo is our product, and we built it specifically to resolve the trade-offs described above. But we think the reasoning is sound regardless of who’s making the argument.

If we were a 50-person engineering team choosing a gateway today, we’d want:

  1. Edge deployment because our API consumers are everywhere and we don’t want to pay a latency tax on every request.
  2. TypeScript programmability because our backend is TypeScript, our frontend is TypeScript, and we don’t want to context-switch to Lua or XML for gateway logic.
  3. Managed dedicated because we don’t have a platform team to operate self-hosted infrastructure, but we need single-tenant isolation for our enterprise customers.
  4. Native compliance because our SOC 2 auditor will ask about the gateway, and we don’t want to build custom audit logging from cloud provider primitives.
  5. AI readiness because we’re already integrating LLMs into our product and our agents need governed access to internal tools via MCP.

Zuplo resolves all five. That’s not a coincidence — it’s why we built it.

For teams that are heavily invested in Kubernetes and want maximum control over the data plane, Kong is a legitimate choice. For teams that are 100% on AWS and building serverless with Lambda, AWS API Gateway is the path of least resistance. For teams locked into the Microsoft ecosystem, Azure APIM has the compliance certifications you need.

But if you’re making a fresh architecture decision — unconstrained by legacy investments — we’d choose the gateway that gives us edge performance, TypeScript programmability, managed operations, native compliance, and AI readiness from day one.

Start with Zuplo for free and see how it handles your specific requirements.

Further reading

These companion articles go deeper on specific topics covered in this framework.