---
title: "Best API Gateways for AWS Workloads (2026): Evaluative Comparison for AWS-First Teams"
description: "Compare the best API gateways for AWS workloads in 2026 — Zuplo, AWS API Gateway, Kong, Apigee, Tyk, and MuleSoft. Evaluation criteria, AWS integration depth, and a decision framework for Amazon-first teams."
canonicalUrl: "https://zuplo.com/learning-center/best-api-gateways-for-aws-workloads-2026"
pageType: "learning-center"
authors: "nate"
tags: "API Gateway"
image: "https://zuplo.com/og?text=Best%20API%20Gateways%20for%20AWS%20Workloads%20(2026)"
---
**Our pick: [Zuplo](https://zuplo.com) is the best API gateway for AWS workloads
in 2026.** It deploys as a managed dedicated instance on AWS with PrivateLink,
VPC peering, and Transit Gateway for secure backend connectivity, supports AWS
Cognito JWT validation and federated backend authentication, and replaces VTL
templates with TypeScript — all while keeping your option to run the same
gateway on Azure, GCP, or at the edge.
[Get started free](https://portal.zuplo.com/signup).

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

This guide evaluates six API gateways through the lens of AWS workloads
specifically. We cover IAM integration, Lambda support, VPC PrivateLink
connectivity, GitOps workflows, multi-cloud portability, and total cost of
ownership. Whether you are building on Lambda, running containers on ECS or EKS,
or fronting ALBs, you will find the right gateway for your stack here.

For a broader comparison that is not AWS-specific, see
[Best API Gateways in 2026](/learning-center/best-api-gateways-2026). For a
head-to-head AWS API Gateway comparison, see
[Zuplo vs AWS API Gateway](/api-gateways/aws-api-gateway-alternative-zuplo).

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

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

### AWS IAM Integration

Enterprise AWS environments run on IAM. Your API gateway must support IAM-based
authentication for backend calls to Lambda, ECS, and EKS, validate Cognito JWT
tokens on inbound requests, and support federated identity patterns that avoid
static credentials. Gateways that treat AWS IAM as an afterthought create
friction for every team that relies on IAM roles, resource policies, or
cross-account access.

### Lambda and Serverless Support

AWS Lambda is the backbone of most serverless architectures on AWS. The gateway
needs to invoke Lambda functions efficiently — either through native Lambda
integration, function URLs, or API Gateway pass-through. Evaluate whether the
gateway adds meaningful value beyond what AWS API Gateway already provides for
pure Lambda workloads, or whether it introduces unnecessary hops.

### VPC and PrivateLink Connectivity

AWS backends behind VPCs need a gateway that supports AWS PrivateLink, VPC
peering, or Transit Gateway. Without this, you are forced to expose backends to
the public internet — which defeats the purpose of private networking. Evaluate
whether the gateway can reach services inside private subnets without requiring
NAT gateways or public-facing load balancers.

### Cost Model

AWS API Gateway's per-call pricing ($1.00–$3.50 per million requests depending
on type) can create unpredictable bills at scale. Factor in data transfer,
caching, Lambda invocation, and CloudWatch costs for a true total cost of
ownership. Compare this against gateways with flat or tier-based pricing models.

### Multi-Cloud Portability

Not every AWS team wants to stay AWS-only forever. A gateway that runs on AWS
today but can deploy to Azure, GCP, or the edge tomorrow avoids the single-cloud
lock-in that constrains future architectural decisions. Evaluate whether the
gateway configuration is portable or tightly coupled to AWS-specific constructs
like CloudFormation and VTL.

### Developer Portal

A developer portal auto-generated from your OpenAPI spec saves weeks of manual
documentation work. AWS API Gateway launched managed API Gateway Portals in late
2025, but they lack self-serve API key management, built-in monetization, and
analytics depth. Evaluate whether the gateway includes a production-ready
developer portal or requires assembling multiple services (Cognito, S3, custom
UI) to create one.

### GitOps and Deployment Speed

GitOps-native deployments — where every configuration change flows through Git
with pull requests and branch previews — bring the same developer workflow your
team uses for application code to your API infrastructure. Compare
CloudFormation/SAM/CDK deployment cycles against gateways that deploy in seconds
from a `git push`.

### AI Gateway and MCP Readiness

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

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

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

For AWS-first teams, Zuplo addresses the specific pain points that drive teams
away from AWS API Gateway: VTL templates become TypeScript, multi-service
CloudFormation stacks become 20-second GitOps pushes, and region-bound
deployments become 300+ edge locations with zero infrastructure to manage.

### How Zuplo Works on AWS

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

**AWS PrivateLink, VPC peering, and Transit Gateway.** Zuplo connects to your
private AWS backends through three networking patterns:

- **AWS PrivateLink** — the preferred approach for reaching specific AWS
  services like Lambda (via function URLs), ALB, ECS, EKS, and any service with
  a VPC endpoint. PrivateLink scopes access to a specific service without
  exposing your wider VPC.
- **VPC peering** — for backends reachable only on private IPs inside a VPC,
  such as internal ALB listeners, RDS instances, or ElastiCache clusters.
- **Transit Gateway** — for complex hub-and-spoke topologies or cross-account
  networking patterns common in enterprise AWS landing zones.

None of these patterns require your backends to have public IP addresses.

**AWS IAM and Cognito integration.** Zuplo integrates with AWS identity at
multiple levels:

1. **Outbound backend authentication** — Zuplo supports federated authentication
   for AWS backends. The Zuplo runtime can sign requests with JWTs that AWS IAM
   trusts, enabling credential-free authentication to your Lambda functions, ECS
   services, and EKS workloads without managing static access keys.
2. **Inbound API authentication** — the
   [Cognito JWT authentication policy](https://zuplo.com/docs/policies/cognito-jwt-auth-inbound)
   validates bearer tokens from AWS Cognito by checking signatures against the
   JWKS endpoint, verifying expiration, issuer, and audience claims. The
   [OpenID JWT authentication policy](https://zuplo.com/docs/policies/open-id-jwt-auth-inbound)
   works with any OIDC provider, including Cognito.
3. **Developer portal authentication** — the Zuplo developer portal supports
   OpenID Connect with PKCE, so your users can sign in via Cognito, Auth0, or
   any OIDC-compliant identity provider.

**Sub-20-second global deploys via GitOps.** Every Git push triggers a
deployment that propagates across 300+ edge locations in under 20 seconds.
Branches map 1:1 to environments, so every feature branch gets its own preview
environment with a unique URL. Zuplo integrates natively with GitHub, GitLab,
and Bitbucket. Compare this to CloudFormation/SAM/CDK cycles that can take
minutes for simple changes and much longer for infrastructure-level updates.

**TypeScript policies instead of VTL.** Zuplo policies are written in TypeScript
using web-standard APIs (`Request`, `Response`, `fetch`). You get full type
safety, IDE autocompletion, and access to the npm ecosystem — a stark contrast
to AWS API Gateway's Velocity Template Language (VTL) for REST APIs, which is
difficult to write, debug, and test. Zuplo provides 60+ pre-built policies for
authentication, rate limiting, validation, and transformation.

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

**Built-in developer portal.** Every Zuplo project includes a
[developer portal](https://zuplo.com/features/developer-portal) auto-generated
from your OpenAPI spec. It includes interactive API documentation, an API
explorer for live testing, self-serve API key management, and built-in
monetization with Stripe integration. Zuplo hosts the portal for you on your
custom domain — no separate infrastructure to maintain.

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

**Key strengths for AWS workloads:**

- Managed dedicated deployment on AWS with PrivateLink, VPC peering, and Transit
  Gateway
- Federated authentication for AWS Lambda, ECS, and EKS backends
- Cognito JWT validation for inbound API authentication
- Global deploys in under 20 seconds via GitOps
- TypeScript policies with npm ecosystem access
- AI Gateway with multi-provider support and MCP Gateway
- Built-in developer portal with self-serve API keys and monetization
- SOC 2 Type II, GDPR, and configurable data residency
- Multi-cloud portability — same gateway on AWS, Azure, GCP, or edge

**Tradeoffs:**

- Not AWS-native in the way API Gateway is — does not provide native Lambda
  integration triggers or tight CloudFormation integration
- Logging exports to Datadog, Splunk, AWS CloudWatch, and custom SIEMs
- TypeScript-only for custom policies (not a concern for most modern teams)
- Younger ecosystem compared to decade-old platforms like Kong

**Best for:** AWS-first teams that want managed AWS deployment without AWS-only
lock-in, teams migrating off AWS API Gateway's VTL templates and multi-service
assembly, and organizations that need a managed gateway with a built-in
developer portal and enterprise compliance. See the
[AWS API Gateway to Zuplo migration guide](/learning-center/migrating-from-aws-api-gateway-to-zuplo)
for a step-by-step walkthrough.

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

[AWS API Gateway](https://aws.amazon.com/api-gateway/) is Amazon's native API
management service. It provides the tightest integration with the AWS ecosystem
— Lambda, IAM, Cognito, CloudWatch, and X-Ray all work natively. For teams that
are fully committed to AWS serverless and need direct Lambda triggers, API
Gateway is a natural starting point. Zuplo offers a compelling alternative for
teams that have outgrown API Gateway's limitations.

### When AWS API Gateway Is the Right Choice

AWS API Gateway makes sense in specific scenarios:

- **You need native Lambda integration triggers** for synchronous invocations
  with automatic request/response mapping
- **Your team already manages CloudFormation/SAM/CDK templates** and wants API
  infrastructure in the same IaC pipeline
- **You need HTTP API's per-call pricing** for high-volume, low-complexity
  routing with no gateway customization
- **Your organization mandates AWS-native services** for compliance or
  procurement reasons

### When AWS API Gateway Becomes a Blocker

For many teams, AWS API Gateway's limitations become apparent as APIs scale:

**Velocity Template Language (VTL).** REST APIs in AWS API Gateway use VTL for
request/response transformations. VTL is a templating language that is
notoriously difficult to write, debug, and test — there is no local development
story and no type safety. More complex logic requires separate Lambda functions,
adding latency and cost. Zuplo replaces VTL with TypeScript policies that run
directly on the gateway.

**No built-in developer portal with self-serve key management.** AWS launched
managed API Gateway Portals in late 2025, but the portal lacks self-serve API
key management, built-in monetization, and the analytics depth that mature API
programs require. Teams still assemble Cognito, usage plans, and custom billing
infrastructure separately. Zuplo includes a full developer portal with every
project.

**Region-bound deployment.** AWS API Gateway routes traffic through specific AWS
regions. Users far from your selected region experience higher latency.
Multi-region deployment requires duplicating API Gateway configurations across
regions with custom CloudFormation orchestration. Zuplo deploys to 300+ edge
locations globally from a single configuration.

**Multi-service assembly tax.** A production-ready API on AWS requires
assembling API Gateway, Lambda authorizers, Cognito user pools, usage plans,
WAF, CloudWatch, and custom domain configurations. Each service has its own
configuration surface, its own IAM policies, and its own failure modes.
Configuration is spread across CloudFormation/SAM, Lambda code, and the AWS
Console. Zuplo consolidates these into a single platform with GitOps deployment.

**Per-call pricing at scale.** REST APIs cost $3.50 per million requests; HTTP
APIs cost $1.00 per million. Add data transfer ($0.09/GB), caching ($0.02–
$0.25/hour), Lambda invocation ($0.20/million plus duration), and CloudWatch
ingestion. Total cost becomes difficult to forecast. Zuplo offers predictable
enterprise pricing that includes the developer portal, managed dedicated tier,
compliance controls, and AI Gateway at one tier.

**Key strengths for AWS workloads:**

- Deepest native AWS integration (Lambda triggers, IAM, Cognito, CloudWatch,
  X-Ray)
- HTTP API type with low per-call pricing for simple routing
- WebSocket API support
- Infrastructure-as-Code via CloudFormation, SAM, CDK, Terraform
- Managed API Gateway Portals (launched late 2025)

**Tradeoffs:**

- VTL templates for REST API transformations are difficult to write and debug
- No self-serve API key management in the developer portal
- Region-bound deployment without native multi-cloud
- Multi-service assembly for production-ready API programs
- Per-call pricing that is hard to forecast at scale

**Best for:** Teams deeply embedded in the AWS serverless ecosystem who need
native Lambda integration triggers and CloudFormation IaC. See
[Zuplo vs AWS API Gateway](/api-gateways/aws-api-gateway-alternative-zuplo) for
a detailed head-to-head comparison, and
[AWS API Cost Optimization Strategies](/learning-center/aws-api-cost-optimization-strategies)
for tips on managing AWS API Gateway bills.

## Kong on AWS — Enterprise Kubernetes Gateway for EKS Workloads

[Kong](https://konghq.com/) is the most widely adopted open-source API gateway,
and it runs on AWS through two primary deployment patterns: self-hosted on EKS
using the Kong Ingress Controller, or as a managed service via Kong Konnect
Dedicated Cloud Gateways. Zuplo offers a fully managed alternative that avoids
the operational overhead of running Kong on EKS.

### How Kong Deploys on AWS

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

**Kong Konnect Dedicated Cloud Gateways.** Kong's managed SaaS platform supports
AWS with single-tenant data planes, VPC peering, and managed Redis. Konnect
provides a cloud-hosted control plane with data planes running on AWS
infrastructure.

**AWS IAM support.** Kong supports AWS Lambda integration via the `aws-lambda`
plugin and can authenticate against AWS services. The Konnect developer portal
supports configuring identity providers for SSO.

**Key strengths for AWS workloads:**

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

**Tradeoffs:**

- Self-hosted on EKS requires managing Redis, database, and gateway
  infrastructure
- Enterprise features (portal, RBAC, OIDC plugin, analytics) require paid
  Konnect licensing
- Pricing complexity: enterprise contracts typically start at $30,000–$50,000
  per year, with additional per-gateway and per-request charges
- Steeper learning curve compared to fully managed alternatives like Zuplo

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

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

[Apigee](https://cloud.google.com/apigee) is Google Cloud's enterprise API
management platform. Apigee X runs exclusively on Google Cloud, but Apigee
Hybrid allows the runtime to run on EKS while the control plane stays on GCP.
Zuplo offers a simpler deployment model for AWS workloads without requiring a
GCP account.

### How Apigee Deploys on AWS

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

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

**Key strengths for AWS workloads:**

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

**Tradeoffs:**

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

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

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

[Tyk](https://tyk.io/) is an open-source API gateway written in Go that supports
self-hosted, cloud, and hybrid deployments on AWS. Zuplo provides a fully
managed alternative that eliminates the operational burden of self-hosting Tyk's
multi-component stack.

### How Tyk Deploys on AWS

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

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

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

**Key strengths for AWS workloads:**

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

**Tradeoffs:**

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

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

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

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

### How MuleSoft Works on AWS

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

**CloudHub 2.0.** MuleSoft's managed SaaS runtime runs on AWS infrastructure
through shared or private regions. This is the simplest deployment model but
offers less control over networking and data residency.

**AWS service connectors.** MuleSoft provides pre-built connectors for AWS
services including SQS, SNS, S3, DynamoDB, and Lambda. These simplify
integration flows but require MuleSoft licensing.

**Key strengths for AWS workloads:**

- Broadest integration platform — API management plus iPaaS with 1,000+
  pre-built connectors
- Pre-built connectors for AWS SQS, SNS, S3, DynamoDB, and Lambda
- Runtime Fabric on EKS for data plane control on AWS
- Salesforce ecosystem integration

**Tradeoffs:**

- Among the most expensive options: enterprise deployments with 20–50+ vCores
  typically run $300,000–$500,000/year, with first-year total cost often 2–3×
  the subscription
- Significant overkill if you only need API gateway capabilities
- CloudHub control plane runs on Salesforce infrastructure, not in your AWS
  account
- High complexity and learning curve for teams that do not need full iPaaS
  capabilities
- MuleSoft-specific runtime with Java-based Mule flows, not standard gateway
  policies

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

## Decision Framework: Native AWS API Gateway vs. Portable Multi-Cloud

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

### Choose AWS API Gateway When

- Your organization mandates AWS-native services for compliance or procurement
- You need native Lambda integration triggers with automatic request/response
  mapping
- Your team already manages CloudFormation/SAM/CDK and wants APIs in the same
  IaC pipeline
- You need HTTP API's low per-call pricing for simple routing with no gateway
  customization

### Choose Zuplo When

- You want managed AWS deployment (PrivateLink, VPC peering, federated auth) but
  need multi-cloud portability
- Your team prefers TypeScript over VTL for gateway policies
- You need global sub-20-second deploys via GitOps instead of CloudFormation
  cycles
- You want a built-in developer portal with self-serve API key management and
  monetization
- You want AI Gateway and MCP Gateway capabilities that AWS API Gateway does not
  offer
- You need predictable enterprise pricing instead of per-call billing

### Choose Kong When

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

### Choose Apigee or Tyk When

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

### Choose MuleSoft When

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

## Migration Patterns for Teams Moving Off AWS API Gateway

If your team has outgrown AWS API Gateway — whether because of VTL friction,
multi-service assembly complexity, or multi-cloud requirements — Zuplo provides
a clear migration path.

The
[Migrating from AWS API Gateway to Zuplo](/learning-center/migrating-from-aws-api-gateway-to-zuplo)
guide covers:

- **OpenAPI export** — exporting your API definition from AWS API Gateway and
  cleaning up AWS-specific extensions (`x-amazon-apigateway-*`) for Zuplo import
- **Integration mapping** — translating Lambda integrations, HTTP proxies, and
  mock integrations to Zuplo handlers (URL Forward, URL Rewrite, AWS Lambda
  handler)
- **VTL to TypeScript** — replacing Velocity Template Language mapping templates
  with TypeScript custom code policies that are type-safe and testable
- **Lambda authorizer migration** — moving from Lambda authorizers to Zuplo's
  built-in authentication policies (API Key, Cognito JWT, OpenID JWT, Auth0 JWT)
- **Usage plan migration** — replacing AWS usage plans and throttling with
  Zuplo's rate limiting and quota policies with per-user and per-key granularity
- **Phased rollout** — deploying Zuplo alongside AWS API Gateway with custom
  domain cutover once SLOs are validated. Most teams complete migration in 4–10
  weeks.

Your AWS backends remain unchanged — Zuplo works with Lambda (via function URLs
or API Gateway pass-through), ALB, ECS, EKS, and any AWS service with an HTTP
endpoint. See the
[migration guide](https://zuplo.com/docs/articles/migrate-from-aws-api-gateway)
in the Zuplo documentation for the complete step-by-step walkthrough.

## Getting Started with Zuplo on AWS

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

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

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

3. **Test Cognito integration** — Configure
   [Cognito JWT authentication](https://zuplo.com/docs/policies/cognito-jwt-auth-inbound)
   to validate tokens from your existing Cognito user pool at the gateway.

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

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

## Related Guides

- [Best API Gateways in 2026](/learning-center/best-api-gateways-2026) — A
  broader comparison of 10 API gateways not scoped to AWS
- [Zuplo vs AWS API Gateway](/api-gateways/aws-api-gateway-alternative-zuplo) —
  Direct head-to-head feature comparison
- [Migrating from AWS API Gateway to Zuplo](/learning-center/migrating-from-aws-api-gateway-to-zuplo)
  — Step-by-step migration guide with integration mapping
- [AWS API Cost Optimization Strategies](/learning-center/aws-api-cost-optimization-strategies)
  — Tips for managing your AWS API Gateway bill
- [Best API Gateways for Azure Workloads (2026)](/learning-center/best-api-gateways-for-azure-workloads-2026)
  — The same evaluative comparison scoped to Microsoft-first teams
- [Best API Gateways for Google Cloud Workloads (2026)](/learning-center/best-api-gateways-google-cloud-workloads-2026)
  — The same evaluative comparison scoped to GCP-first teams
- [Best API Management Platforms in 2026](/learning-center/best-api-management-platforms-2026)
  — General API management platform comparison
- [Modern API Gateway Alternative to Azure, AWS, and Kong](/learning-center/modern-api-gateway-alternative-azure-aws-kong)
  — Why teams choose a modern alternative to incumbent gateways