---
title: "API Gateway Architecture Decisions: A 2026 Reference for Engineering Leaders"
description: "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."
canonicalUrl: "https://zuplo.com/learning-center/api-gateway-architecture-decisions-2026"
pageType: "learning-center"
authors: "nate"
tags: "API Gateway"
image: "https://zuplo.com/og?text=API%20Gateway%20Architecture%20Decisions%3A%20A%202026%20Reference"
---
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](https://zuplo.com), Kong, AWS API Gateway, Azure API Management, Apigee,
Tyk, and Gravitee — handle them.

## Contents

- [The five gateway-architecture decisions every team makes](#the-five-gateway-architecture-decisions-every-team-makes)
- [Decision 1: Edge-deployed vs region-pinned](#decision-1-edge-deployed-vs-region-pinned)
- [Decision 2: Declarative config vs programmable handlers](#decision-2-declarative-config-vs-programmable-handlers)
- [Decision 3: Managed dedicated vs multi-tenant SaaS vs self-hosted](#decision-3-managed-dedicated-vs-multi-tenant-saas-vs-self-hosted)
- [Decision 4: Identity, SSO, and audit posture for regulated workloads](#decision-4-identity-sso-and-audit-posture-for-regulated-workloads)
- [Decision 5: AI and MCP readiness](#decision-5-ai-and-mcp-readiness)
- [Putting it together: three reference architectures](#putting-it-together-three-reference-architectures)
- [What we'd choose, and why](#what-wed-choose-and-why)
- [Further reading](#further-reading)

## 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](https://zuplo.com/docs/managed-edge/overview)
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](https://zuplo.com/docs/managed-edge/overview) 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](https://zuplo.com/docs/dedicated/overview) 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](https://zuplo.com/learning-center/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](https://zuplo.com/docs/articles/custom-code-patterns) 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:

```json
{
  "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:

```typescript
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](https://zuplo.com/features/programmable). 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](https://zuplo.com/learning-center/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](https://zuplo.com/docs/dedicated/overview)
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](https://zuplo.com/docs/articles/security) (audited
annually), SAML SSO and SCIM provisioning for enterprise identity management,
role-based access control across organizations, projects, and environments, and
[immutable audit logs](https://zuplo.com/features/api-governance) across the
control plane. For data plane audit logging, Zuplo offers a dedicated
[Audit Log policy](https://zuplo.com/docs/policies/audit-log-inbound) 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](https://zuplo.com/features/api-governance) 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](https://zuplo.com/learning-center/three-gates-ai-infrastructure-api-ai-mcp-gateway).

### How the major gateways compare on AI readiness

**Zuplo** offers all three capabilities on a single platform. The
[AI Gateway](https://zuplo.com/ai) provides multi-provider LLM routing, semantic
caching, prompt injection protection, secret masking, and per-team budget
controls. The [MCP Gateway](https://zuplo.com/blog/zuplo-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](https://zuplo.com/learning-center/ai-gateway-comparison-mcp-a2a-agent-governance)
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](https://zuplo.com/learning-center/what-is-a-developer-portal)
and [API key management](https://zuplo.com/docs/articles/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](https://zuplo.com/migrate/apigee-edge) that maps Apigee
concepts to Zuplo equivalents. For teams on Azure APIM, the
[Azure to Zuplo migration path](https://zuplo.com/learning-center/migrating-from-azure-api-management-to-zuplo)
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](https://zuplo.com/api-gateways/kong-alternative-zuplo) is
a legitimate choice. For teams that are 100% on AWS and building serverless with
Lambda,
[AWS API Gateway](https://zuplo.com/api-gateways/aws-api-gateway-alternative-zuplo)
is the path of least resistance. For teams locked into the Microsoft ecosystem,
[Azure APIM](https://zuplo.com/api-gateways/azure-api-management-alternative-zuplo)
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](https://portal.zuplo.com) and see how it handles
your specific requirements.

## Further reading

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

- [Best API Gateways in 2026](https://zuplo.com/learning-center/best-api-gateways-2026)
  — A comprehensive comparison of every major gateway
- [API Gateway Plugin Architectures Compared](https://zuplo.com/learning-center/api-gateway-plugin-architectures-compared)
  — Deep dive on Lua, Go, WASM, and TypeScript extensibility
- [Managed vs Self-Hosted API Gateway](https://zuplo.com/learning-center/managed-vs-self-hosted-api-gateway)
  — Full cost and operations analysis
- [AI Gateway Comparison 2026](https://zuplo.com/learning-center/ai-gateway-comparison-mcp-a2a-agent-governance)
  — Feature-by-feature MCP and AI gateway comparison
- [The Three Gates of AI Infrastructure](https://zuplo.com/learning-center/three-gates-ai-infrastructure-api-ai-mcp-gateway)
  — API, AI, and MCP gateway architecture patterns
- [API Management Maturity Model](https://zuplo.com/learning-center/api-management-maturity-model)
  — Assess where your API program stands today