API gateway vendor lock-in is one of those risks that's easy to dismiss early and painful to confront later. You pick a gateway that solves your immediate problem — maybe it's the default option in your cloud provider, maybe a colleague recommended it — and within a year your team has hundreds of routes configured in a proprietary format that only that platform understands. Migrating means rewriting everything. This isn't hypothetical. Teams using AWS API Gateway discover their [VTL mapping templates](https://docs.aws.amazon.com/apigateway/latest/developerguide/models-mappings.html) don't translate to any other platform. Organizations on Azure API Management realize their XML-based policy definitions with C# expressions are Azure-specific. Kong users find that their custom Lua plugins need complete rewrites to work anywhere else. The pattern is consistent: proprietary abstractions create invisible walls. This guide breaks down how API gateway vendor lock-in happens, gives you a practical framework for evaluating portability risk, and explains how standards-based API management can keep your options open. ## What Is API Gateway Vendor Lock-in? Vendor lock-in in the API gateway context means your gateway's configuration, policies, and operational workflows are so deeply tied to a specific platform that switching to an alternative requires significant time, money, and engineering effort. It's not just about the gateway software itself — it's about the entire ecosystem of tooling, knowledge, and processes that accumulate around a proprietary platform. Lock-in manifests in several ways: - **Configuration formats** that only one platform can interpret - **Policy languages** that aren't transferable (VTL, Lua, C#/XML policy definitions) - **Infrastructure dependencies** that tie you to a single cloud provider - **Operational workflows** built around a vendor-specific dashboard or CLI - **Knowledge silos** where your team's expertise is platform-specific rather than transferable The cost of lock-in isn't always obvious upfront. It shows up when you need to adopt a multi-cloud strategy, when your provider raises prices, when a critical feature is missing, or when your organization's compliance requirements change and your current gateway can't adapt. ## The Three Types of Gateway Lock-in Not all lock-in is created equal. Understanding the different categories helps you identify where your greatest risks lie and where to focus your mitigation efforts. ### Cloud-Provider Lock-in Cloud-native gateways like AWS API Gateway and Azure API Management are designed to integrate tightly with their parent cloud. AWS API Gateway uses IAM for authorization, Lambda for custom logic, and VTL for request/response transformations. Azure API Management uses Microsoft Entra ID, Azure Functions, and XML-based policy definitions with embedded C# expressions. This integration is convenient when you're already committed to a single cloud. But it means your API gateway is inseparable from the rest of your cloud infrastructure. If you decide to go multi-cloud — or if your organization acquires a company running on a different provider — your gateway configuration doesn't come with you. The proprietary tooling compounds the problem. AWS VTL templates, for example, have [limited library support and no logging capability](https://aws.amazon.com/blogs/compute/best-practices-for-working-with-the-apache-velocity-template-language-in-amazon-api-gateway/), along with a minimal testing ecosystem. You're investing in skills that only apply to one platform. ### Platform Lock-in Open-source and third-party gateways like Kong and Tyk avoid cloud-provider lock-in but introduce their own form of platform lock-in through proprietary plugin systems and configuration formats. Kong's plugin ecosystem relies on Lua and a custom PDK (Plugin Development Kit). Tyk uses a Go-based middleware system with its own API definitions. Apigee has its own policy framework with XML-based proxy configurations. In each case, the configuration and customization you build is specific to that platform. Even when the gateway itself is open source, the investment in plugins, custom middleware, and operational tooling creates switching costs. You might not be paying for a proprietary license, but you're still locked into a proprietary architecture. ### Data and Configuration Lock-in The third form of lock-in is subtler: your API definitions, analytics data, developer portal content, and operational history are stored in a format or system that's difficult to export. Some gateways store configuration in internal databases accessible only through their own APIs. Others use proprietary serialization formats that don't map cleanly to standard specifications. When your gateway's configuration can't be expressed as an open-standard document — like an [OpenAPI specification](/learning-center/openapi-first-api-gateway) — you're locked in at the data level, even if the rest of the stack is portable. ## How Lock-in Happens: Real-World Patterns Lock-in rarely results from a single decision. It accumulates through a series of reasonable choices that each deepen your dependency on a particular platform. ### The Convenience Trap Your team picks AWS API Gateway because you're already on AWS. The initial setup is fast — IAM handles auth, Lambda handles custom logic, and CloudWatch handles logging. Within weeks, you have VTL templates transforming request payloads and API Gateway authorizers calling Lambda functions that check Cognito tokens. Every component is AWS-specific. No single piece is hard to replicate elsewhere, but replicating _all_ of them simultaneously means rebuilding your entire API layer. ### The Plugin Creep You start with Kong and a few community plugins. Rate limiting, key auth, CORS — straightforward stuff. Then you need custom logic: a plugin that validates request bodies against your internal schema, another that enriches requests with data from a sidecar service, a third that formats error responses for your mobile app. Each custom Lua plugin represents weeks of development and testing. After two years, you have fifteen custom plugins that your team maintains. Migrating means rewriting all of them in whatever language the new gateway supports. ### The Dashboard Dependency Your team manages everything through a vendor's web dashboard. Routes, policies, rate limits, API keys — it's all configured through clicks. There's no export button for the complete configuration. There's no Git repository backing the dashboard state. The configuration exists only inside the vendor's system. When you want to move, you discover that the vendor's API exposes only a subset of the configuration. Some settings are dashboard-only. Recreating your setup means manually clicking through a different vendor's dashboard — a tedious, error-prone process. ## Evaluating Lock-in Risk: A Decision Framework Before choosing an API gateway — or evaluating your current one — run through this portability checklist. Each question targets a specific dimension of lock-in. ### Configuration Portability - **Is the configuration format based on an open standard?** OpenAPI, for instance, is an industry standard that multiple tools understand. Proprietary YAML schemas or internal database formats are not portable. - **Can you export your full gateway configuration to a file?** If the only way to access your configuration is through a vendor-specific API or dashboard, portability is limited. - **Does the configuration separate gateway logic from cloud-specific infrastructure?** Your routing rules and policies should be expressible independently of where they're deployed. ### Policy and Logic Portability - **Are policies written in a general-purpose programming language?** TypeScript, JavaScript, Go, and Python are transferable skills. VTL, Lua PDK, and C#/XML policy definitions are platform-specific. - **Can custom logic run outside the gateway for testing?** If your request-transformation logic can only execute inside the gateway's runtime, it's tightly coupled to that platform. - **Do built-in policies use standard protocols?** OAuth 2.0, JWT validation, and OpenID Connect are standards. Proprietary auth mechanisms aren't. ### Infrastructure Portability - **Does the gateway run on multiple cloud providers?** A gateway that only deploys to AWS is an AWS dependency, regardless of what it calls itself. - **Can you change deployment models without rewriting configuration?** Moving from managed to self-hosted (or vice versa) shouldn't require changes to your routes and policies. - **Is the gateway's operational tooling cloud-agnostic?** If monitoring, logging, and alerting require a specific cloud's services, you're introducing infrastructure lock-in through the back door. ### Organizational Portability - **Are the skills your team is building transferable?** Learning TypeScript or OpenAPI is an investment that pays off regardless of your gateway choice. Learning VTL or a proprietary policy DSL only helps you on that one platform. - **Is your CI/CD pipeline gateway-agnostic?** If your deployment process uses standard Git-based workflows, it's more portable than one that depends on a vendor-specific CLI or deployment mechanism. ## Standards-Based API Management as the Antidote The most effective way to prevent API gateway vendor lock-in is to build on open standards rather than proprietary abstractions. Here's what that looks like in practice. ### OpenAPI as Your Configuration Format When your API gateway uses an [OpenAPI specification as its native configuration](/learning-center/openapi-first-api-gateway), your API definition is inherently portable. OpenAPI is an [industry-standard format](https://spec.openapis.org/oas/v3.1.0) understood by hundreds of tools — documentation generators, testing frameworks, client SDK generators, and other API gateways. This is fundamentally different from gateways that _import_ OpenAPI but convert it to an internal format. In an OpenAPI-first gateway, the spec _is_ the configuration. There's no drift between your documentation and your gateway behavior, and there's no proprietary format trapping your definitions. ### Standard Programming Languages for Policies Custom gateway logic written in TypeScript or JavaScript is portable by definition. Your team's knowledge transfers to any platform that supports web-standard APIs. The policy code itself can be tested independently, reviewed in standard code editors, and understood by any developer — not just gateway specialists. Compare this with VTL templates that require specialized AWS knowledge, Lua plugins that need Kong-specific PDK expertise, or C# expressions embedded in XML policy definitions that only Azure API Management interprets. ### GitOps for Configuration Management When your gateway configuration lives in a [Git repository](/learning-center/gitops-api-management-comparison) — not in a vendor's proprietary database — you control your own data. Every change is versioned, reviewable, and exportable. If you need to switch gateways, your configuration is right there in your repo, ready to be adapted. GitOps also decouples your deployment workflow from the vendor's tooling. You can use any CI/CD system that integrates with Git — GitHub Actions, GitLab CI, Bitbucket Pipelines — rather than depending on a vendor-specific deployment mechanism. ### Standard Auth and Security Protocols Building your API security on standards like OAuth 2.0, OpenID Connect, and JWT validation means your security architecture isn't tied to a specific gateway. These protocols work the same way regardless of which gateway enforces them. When your gateway uses IAM-specific authorization or a proprietary API key system, migrating means rebuilding your security layer. When it uses JWT validation with standard claims, you can swap the gateway without touching your identity provider. ## Zuplo's Approach: Cloud-Agnostic, Standards-First [Zuplo](https://zuplo.com) is built around the principles outlined above — not as a retroactive marketing positioning, but as foundational architectural decisions. ### OpenAPI-Native Configuration Zuplo uses your [OpenAPI specification as its native configuration format](https://zuplo.com/docs/articles/openapi). Your routes are defined in a `routes.oas.json` file that's a valid OpenAPI 3.1 document. This means your API definition is always exportable, always standard-compliant, and always usable with other OpenAPI-compatible tools. You're not learning a proprietary configuration language. You're writing OpenAPI — a skill that's valuable regardless of which gateway you use tomorrow. ### TypeScript Policies on Web Standards Custom policies and handlers in Zuplo are [written in TypeScript](https://zuplo.com/docs/articles/custom-code-patterns) using standard web APIs — `fetch`, `Request`, `Response`, and Web Crypto. This is the same programming model used across modern web platforms. Your team's investment in TypeScript skills is transferable, and your custom logic can be tested with standard testing frameworks. There's no proprietary DSL to learn. No VTL. No Lua PDK. No vendor-specific policy definitions. Just TypeScript and standard HTTP APIs. ### Deploy Anywhere: Three Hosting Models Zuplo offers [three deployment models](https://zuplo.com/docs/articles/hosting-options) that all use the same runtime, configuration, and APIs: - **Managed Edge** — Serverless deployment across 300+ data centers worldwide, with no infrastructure to manage. - **Managed Dedicated** — Zuplo operates your gateway in isolated infrastructure on your chosen cloud provider (AWS, Azure, GCP, Akamai, and others). - **Self-Hosted** — Run Zuplo on your own Kubernetes infrastructure in any cloud or private data center. The critical point: your configuration and custom code are portable across all three models — the same runtime powers each deployment option. If you start on managed edge and later need to move to self-hosted for compliance reasons, you don't rewrite anything. This is infrastructure portability in practice. ### GitOps From Day One Every Zuplo project is backed by a [Git repository](https://zuplo.com/docs/concepts/source-control-and-deployment). Your routes, policies, custom code, and environment configuration all live in source control. Zuplo supports GitHub, GitLab, Bitbucket, and Azure DevOps. With GitHub, pushing to your main branch triggers automatic global deployment within seconds. Other providers integrate through CI/CD pipelines using the Zuplo CLI. This means you always have a complete, exportable copy of your gateway configuration. It's not locked in a vendor's database. It's in your Git repo, under your control. ### Multi-Cloud Backend Routing Zuplo's [multi-cloud capabilities](https://zuplo.com/features/multi-cloud) let you route API traffic to backends across any cloud provider from a single gateway. You can direct requests to AWS for one service, Azure for another, and an on-premises system for a third — all from the same unified configuration. This means your gateway itself doesn't force a cloud choice on the rest of your architecture. ## Migration Paths: From Locked-in to Portable If you're currently locked into a gateway and want to move toward a more portable approach, here are the high-level strategies. ### From Cloud-Native Gateways (AWS, Azure) The biggest challenge is untangling cloud-specific integrations. Start by inventorying your VTL templates (AWS) or policy expressions (Azure) and mapping them to equivalent TypeScript logic. Replace cloud-specific auth with standard JWT/OAuth 2.0 flows. Then migrate routes incrementally using traffic splitting. Zuplo's [migration guide](https://zuplo.com/docs/articles/migration-overview) covers the specifics for AWS API Gateway, Azure API Management, Apigee, and Kong, including concept mapping and step-by-step instructions. ### From Self-Hosted Gateways (Kong, Tyk) The primary lock-in here is custom plugins and middleware. Audit your custom Lua (Kong) or Go (Tyk) plugins and rewrite the most critical ones as TypeScript policies. You'll likely find that many custom plugins replicate functionality that Zuplo provides out of the box — rate limiting, authentication, request validation — eliminating the need for custom code entirely. ### General Migration Strategy Regardless of your starting point, the pattern is similar: 1. **Export your OpenAPI definitions** from your current gateway 2. **Import them into the new gateway** and verify route coverage 3. **Map proprietary policies** to standard equivalents 4. **Run both gateways in parallel** during a transition period 5. **Shift traffic incrementally** using DNS or load balancer rules 6. **Decommission the old gateway** once traffic is fully migrated For a deeper look at the managed vs. self-hosted tradeoff, see our [deployment model comparison](/learning-center/managed-vs-self-hosted-api-gateway). And for more on multi-cloud gateway architecture, see [deploying API gateways in multicloud environments](/learning-center/deploying-api-gateways-multicloud-environments). ## Conclusion API gateway vendor lock-in is a technical debt that compounds over time. Every proprietary template, every platform-specific plugin, every configuration trapped in a vendor's database makes it harder and more expensive to change direction when your requirements evolve. The antidote is straightforward: choose tools built on open standards. An OpenAPI-native configuration format means your API definitions are always portable. TypeScript policies mean your custom logic is written in a general-purpose language. GitOps means your configuration is under your control, not locked in a vendor's system. And flexible deployment models mean you're not tied to a single cloud provider's infrastructure. You don't have to accept lock-in as the price of using an API gateway. You just have to choose one that was built to avoid it. [Start building with Zuplo](https://portal.zuplo.com) and see how standards-based API management keeps your options open. Already locked into another gateway? Check out the [migration guide](https://zuplo.com/docs/articles/migration-overview) for step-by-step instructions on moving from AWS API Gateway, Azure API Management, Kong, or Apigee.