Apache APISIX and Apigee are often compared, but they sit at different layers. APISIX is a high-performance, open-source API gateway focused on moving and governing traffic. Apigee is a comprehensive, commercial API management platform that includes a gateway plus the surrounding business and lifecycle tooling. For the gateway layer itself — performance, cost, and portability — APISIX is the stronger and far more economical choice; Apigee earns its place only when you genuinely need the full enterprise management suite wrapped around the gateway.

Overview#

Apigee is Google Cloud's enterprise API management platform. Beyond the gateway runtime, it provides a developer portal, detailed API analytics, monetization, and full API lifecycle management, with policies configured through a console and an XML-based policy model. It is offered as Apigee X (fully managed on Google Cloud) and Apigee hybrid (runtime in your own Kubernetes, management plane in Google Cloud). It targets large organizations running formal API programs.

Apache APISIX is an Apache Software Foundation top-level project: a gateway built on NGINX and LuaJIT, with etcd-backed dynamic configuration and 100+ plugins. It is free, self-hosted, and focused on the data plane, prioritizing performance, flexibility, and low cost.

Scope: Gateway vs Platform#

The most important distinction is scope.

APISIX is a gateway. It excels at routing, authentication, rate limiting, traffic shaping, protocol support, observability, and AI proxying. It is the runtime layer that sits in front of your services.

Apigee is a platform. It includes a gateway, but its value proposition extends to the full API business: onboarding external developers through a portal, analyzing API usage for product decisions, monetizing APIs, and governing them across their lifecycle.

This means the comparison is rarely feature-for-feature. The real question is whether you need a focused, high-performance gateway you can run anywhere, or an end-to-end managed API management suite, and whether you are willing to trade cost and portability for that breadth.

Architecture and Deployment#

Apache APISIX#

APISIX is self-hosted on any cloud, on-premises, or in Kubernetes. The data plane and control plane (Admin API plus etcd) deploy together, configuration changes propagate in real time, and you retain full control over where traffic flows and what it costs. There is no dependency on a specific cloud provider.

Apigee#

Apigee X is fully managed within Google Cloud, removing operational burden but coupling you to that environment. Apigee hybrid lets you run the runtime in your own Kubernetes clusters while the management plane remains in Google Cloud, offering more deployment flexibility while retaining the platform's management capabilities and its commercial model.

Cost#

Cost is frequently decisive. APISIX has no license fee; you pay only for the compute it runs on, and a single node sustains very high throughput, so cost per request stays low as traffic grows. Apigee is priced as an enterprise platform, typically based on API call volume and the capabilities you enable, which can become a major line item at scale. For teams whose primary need is a capable gateway, APISIX delivers that at a fraction of the platform cost.

Feature Comparison#

When to Choose Apache APISIX#

• You need a high-performance gateway, not a full management platform.
• Cost efficiency matters and per-call platform pricing is unattractive.
• Multi-cloud, hybrid, or on-premises deployment and no vendor lock-in.
• Flexibility to assemble your own management tooling around a focused, open-source core.

When to Choose Apigee#

• You need a complete API management program: developer portal, analytics, monetization, and lifecycle governance in one product.
• A fully managed platform is preferred and Google Cloud is your environment.
• Enterprise governance and a polished external developer experience are priorities.
• Budget exists for an enterprise platform in exchange for that breadth.

FAQ#

Is Apache APISIX a full API management platform like Apigee?#

Not on its own. APISIX is a high-performance API gateway focused on the runtime: routing, authentication, rate limiting, traffic management, observability, and AI gateway features. Apigee is a broader API management platform that also includes a developer portal, deep API analytics, monetization, and lifecycle governance. To build a full API management program around APISIX, you pair it with complementary tooling for those higher-level functions.

How do the costs of Apache APISIX and Apigee compare?#

APISIX is free and open source under the Apache 2.0 license; your cost is the infrastructure you run it on. Apigee is a commercial enterprise platform with pricing based on API calls and capabilities, which can be substantial at scale. Organizations focused primarily on gateway functionality often find APISIX far more cost-effective, while those needing Apigee's full management suite weigh that against its platform cost.

Does Apache APISIX offer a developer portal and analytics like Apigee?#

APISIX provides strong runtime observability through integrations with Prometheus, OpenTelemetry, Datadog, SkyWalking, and others, but the open-source project does not bundle a polished developer portal, business-level API analytics, or monetization the way Apigee does. Teams that need those capabilities integrate additional tools alongside APISIX, whereas Apigee delivers them as part of one platform.

How do I migrate from Apigee to Apache APISIX?#

Migration usually starts with the gateway runtime: map Apigee API proxies to APISIX routes and upstreams, and translate Apigee policies (for authentication, quotas, spike arrest, and transformation) to the equivalent APISIX plugins. Higher-level Apigee features such as the developer portal and monetization are addressed separately with complementary tooling. Running both in parallel and shifting traffic incrementally allows a controlled, low-risk migration.

Related#

• All API gateway comparisons
• What is an API gateway?
• Apache APISIX vs AWS API Gateway
• Apache APISIX vs Kong
• Get started with Apache APISIX

Apache APISIX and AWS API Gateway solve the same problem from opposite directions. APISIX is a self-hosted, open-source gateway you run on any infrastructure, while AWS API Gateway is a fully managed, serverless service tightly integrated with the AWS ecosystem. The choice comes down to control and cost versus managed convenience and lock-in.

Overview#

AWS API Gateway is a managed service that handles API traffic without any servers for you to operate. It offers REST APIs, lower-cost HTTP APIs, and WebSocket APIs, and integrates natively with AWS Lambda, IAM, Cognito, CloudWatch, and WAF. You configure it through the AWS console, CloudFormation, or Terraform, and AWS operates and scales the underlying infrastructure.

Apache APISIX is a top-level Apache Software Foundation project: a high-performance gateway built on NGINX and LuaJIT, with configuration stored in etcd and pushed to all nodes in real time. You deploy and operate it yourself, on any cloud, on-premises, or in Kubernetes, with no per-request platform fees.

Architecture Comparison#

Apache APISIX Architecture#

APISIX runs as a self-hosted data plane with a built-in control plane: an Admin API, etcd-backed configuration, an optional dashboard, and a 100+ plugin ecosystem. Because configuration lives in etcd and propagates instantly, routes and policies change without restarts. You own the full request path, which means you can deploy APISIX next to your services in any environment and tune it to your hardware.

AWS API Gateway Architecture#

AWS API Gateway is serverless. There is no instance to size, patch, or scale, and high availability is handled by AWS within a region. Backends are typically Lambda functions, HTTP endpoints, or other AWS services, wired through integrations. The tradeoff is that the data plane is a black box: you configure behavior through AWS abstractions (stages, resources, authorizers, mapping templates) rather than operating the proxy directly, and behavior is bounded by AWS service limits.

Pricing and Cost at Scale#

The pricing models are fundamentally different, and this is often the deciding factor.

AWS API Gateway charges per request, plus data transfer and optional caching. This is attractive at low volume because you pay nothing when idle, but cost grows linearly with traffic. At high, sustained request volumes the per-request fee can dominate the total cost of an API platform.

Apache APISIX has no per-request fee. The cost is the compute you run it on, which is largely fixed regardless of how many requests flow through. A single modest node handles very high throughput, so cost per request falls as traffic grows.

A useful rule of thumb: managed per-request pricing favors low or unpredictable traffic, while self-hosting favors sustained high volume where fixed infrastructure cost is amortized across many requests.

Performance and Limits#

AWS API Gateway is designed for elasticity rather than minimal latency, and it enforces hard service limits such as integration timeouts and per-region request quotas (some of which are soft limits you can request increases for). These rarely matter for typical workloads but can constrain long-running, high-throughput, or large-payload APIs.

APISIX is optimized for low, predictable per-request overhead using NGINX's event-driven model and radix-tree route matching. Running it close to your backends removes extra network hops. Because you control the deployment, you can benchmark and tune for your own latency and throughput targets rather than working within a managed service's quotas.

Feature Comparison#

Vendor Lock-in and Portability#

The strongest argument for a self-hosted gateway is portability. AWS API Gateway configuration, authorizers, and VTL templates are specific to AWS; moving to another cloud or on-premises means rebuilding the gateway layer. APISIX configuration is portable: the same routes, plugins, and upstreams run identically on any cloud, in your own data center, or across a hybrid deployment. For organizations pursuing multi-cloud strategies, data-residency requirements, or simply avoiding lock-in, this portability is decisive.

When to Choose Apache APISIX#

• Sustained high traffic where per-request pricing would dominate cost.
• Multi-cloud, hybrid, or on-premises deployments and data-residency requirements.
• Full control over the data plane, custom plugins, and the latency floor.
• Rich gateway features (advanced traffic management, multi-protocol, AI proxy) without a managed service's constraints.
• Avoiding vendor lock-in with a portable, open-source configuration.

When to Choose AWS API Gateway#

• All-in on AWS with Lambda or other AWS services as backends.
• Low or spiky traffic where paying per request beats running infrastructure.
• No operational appetite for running and scaling a gateway yourself.
• Tight AWS-native integration with IAM, Cognito, and CloudWatch as a priority.

FAQ#

Is Apache APISIX cheaper than AWS API Gateway?#

It depends on traffic volume. AWS API Gateway charges per request plus data transfer, so cost scales linearly with traffic and becomes significant at high volumes. Apache APISIX is free and open source; you pay only for the compute you run it on, which is a largely fixed cost regardless of request count. For low or spiky traffic, the managed convenience of AWS API Gateway often outweighs its per-request cost. For sustained high-volume APIs, self-hosting APISIX is typically far cheaper per request.

Can I run Apache APISIX on AWS?#

Yes. APISIX runs anywhere you can run a container or a Linux host, including EC2, EKS, and ECS. Many teams run APISIX on AWS to keep traffic inside their VPC while avoiding per-request gateway fees and retaining the ability to move to another cloud or on-premises later without rewriting their gateway configuration.

How do I migrate from AWS API Gateway to Apache APISIX?#

The common approach is to stand up APISIX behind the same DNS or load balancer and shift routes incrementally. Map each API Gateway stage and resource to an APISIX route and upstream, translate authorizers to APISIX authentication plugins, and replace VTL mapping templates with request and response transformation plugins. Shifting traffic route by route with health checks allows a zero-downtime migration.

Does AWS API Gateway or Apache APISIX add more latency?#

A self-hosted APISIX deployment running close to your backends typically adds sub-millisecond proxy overhead and avoids extra network hops. AWS API Gateway is a managed regional service, so requests traverse AWS infrastructure and are subject to service limits such as integration timeouts. For latency-sensitive workloads where you control the network path, a self-hosted gateway gives you more control over the latency floor.

Related#

• All API gateway comparisons
• What is an API gateway?
• Apache APISIX vs Apigee
• Apache APISIX vs Kong
• Get started with Apache APISIX

If you need an API gateway, Apache APISIX is the more direct choice. APISIX is a complete gateway you can run immediately, with a built-in control plane and a 100+ plugin ecosystem. Envoy is a powerful, programmable proxy, but on its own it is not an API gateway: it is a data plane that has to be driven by a separate control plane, and it is most at home as the sidecar inside a service mesh. For the typical north-south API gateway need, APISIX gets you to a working gateway with far less to assemble and operate.

Overview#

Envoy is a CNCF graduated project, a high-performance L7 and L4 proxy written in C++. It was created as a universal data plane and is best known as the sidecar proxy in service meshes such as Istio, as well as a building block for edge gateways like Gloo and Contour. Envoy is configured statically through a bootstrap file or dynamically through the xDS family of APIs, which requires a control plane to supply that configuration.

Apache APISIX is an Apache Software Foundation top-level project: a gateway built on NGINX and LuaJIT, with configuration in etcd and a 100+ plugin ecosystem. It includes its own control plane, so a single deployment gives you a fully functional API gateway without assembling additional components.

Architecture Comparison#

Apache APISIX Architecture#

APISIX bundles the data plane and control plane together. The Admin API writes configuration into etcd, which pushes changes to all proxy nodes in real time. Gateway features are delivered as plugins that run in the request lifecycle, and an optional dashboard provides a UI. Because the control plane is built in, getting from zero to a working, dynamically configurable gateway is fast.

Envoy Architecture#

Envoy is intentionally just the data plane. Its power comes from the xDS APIs (LDS, RDS, CDS, EDS, and others), which let an external control plane reconfigure listeners, routes, clusters, and endpoints at runtime. This separation suits large platforms that want to build their own control logic, and it is the foundation of service meshes. For a team that simply needs an API gateway, though, it is overhead: Envoy alone is not a turnkey gateway. You either hand-write verbose bootstrap configuration or adopt and operate a separate control plane such as Istio, Gloo, or Contour, each significant software in its own right — whereas APISIX ships its control plane in the box.

Extensibility#

APISIX extends through plugins. It ships with 100+ built-in plugins and supports custom plugins in Lua, plus Go, Java, and Python through external plugin runners and Wasm for sandboxed extensions. Adding a capability is usually a matter of enabling and configuring a plugin.

Envoy extends through native C++ filters and Wasm filters, and increasingly through control-plane abstractions. This is extremely powerful and is how advanced mesh features are built, but it generally demands deeper engineering investment than enabling a plugin.

Feature Comparison#

When to Choose Apache APISIX#

• You need a complete API gateway for north-south traffic without assembling a control plane.
• Faster time to a working gateway, with authentication, rate limiting, and routing ready to enable.
• A plugin ecosystem and AI gateway features available immediately.
• Lower operational complexity for edge and ingress use cases.

When to Choose Envoy#

• A service mesh with sidecar proxies and service-to-service mTLS, typically via Istio.
• A custom platform where you want to build your own control plane on xDS.
• Deep, low-level programmability through native C++ filters.
• Standardizing one data plane across both edge and in-mesh traffic with your own tooling.

Working Together#

These projects are not mutually exclusive. A common pattern places APISIX at the edge as the API gateway, handling authentication, rate limiting, and routing for incoming traffic, while Envoy operates inside the cluster as the service mesh data plane for service-to-service communication. Choosing APISIX for the gateway role does not preclude using Envoy where it excels.

FAQ#

Are Apache APISIX and Envoy competitors or complementary?#

They overlap but often complement each other. APISIX is most commonly used as a north-south API gateway for traffic entering your platform from clients, while Envoy is most commonly used as the east-west data plane inside a service mesh for service-to-service traffic. Many organizations run APISIX at the edge and Envoy inside the mesh. They compete directly only when you evaluate one of them for the edge gateway role.

Is Envoy faster than Apache APISIX?#

Both are high-performance proxies and both are fast enough that raw proxy speed is rarely the deciding factor. Envoy is written in C++ and APISIX is built on NGINX and LuaJIT; real-world throughput depends heavily on your configuration, plugin or filter chain, and hardware. The more meaningful difference is operational: APISIX gives you a complete gateway out of the box, whereas Envoy's performance comes with a more complex configuration model.

Does Apache APISIX need a separate control plane like Envoy does?#

No. APISIX ships with its own control plane: an Admin API, etcd-backed configuration, and an optional dashboard. You can run a working gateway immediately. Envoy is a data plane only; to configure it dynamically you must run a separate control plane that speaks the xDS protocol, such as Istio, Gloo, or Contour. That control plane is additional software to operate.

Should I use Apache APISIX or Envoy for a service mesh?#

For a full service mesh with sidecar proxies and service-to-service mTLS, Envoy (typically through Istio) is the established choice; it was designed for that role. For an API gateway handling north-south traffic at the edge, with authentication, rate limiting, and a plugin ecosystem ready to use, APISIX is the more direct fit. The two roles are different, and many platforms use both.

Related#

• All API gateway comparisons
• What is an API gateway?
• Apache APISIX vs NGINX
• Apache APISIX vs Traefik
• Get started with Apache APISIX

NGINX is the foundation that powers much of the web as a reverse proxy and load balancer, and Apache APISIX is built directly on top of it. The real comparison is not NGINX versus a competitor, but whether to assemble an API gateway from NGINX yourself versus using a purpose-built gateway that already provides the gateway layer on the same high-performance core.

Overview#

NGINX (open source) is a web server, reverse proxy, and load balancer. It can act as an API gateway, but you build that capability yourself through configuration files and, for advanced logic, the njs scripting module or Lua. NGINX Plus, the commercial edition, adds dynamic reconfiguration, active health checks, JWT authentication, and a monitoring dashboard.

Apache APISIX uses NGINX and LuaJIT (through OpenResty) as its data plane, then adds a complete API gateway on top: etcd-backed dynamic configuration, an Admin API, 100+ plugins, service discovery, and a dashboard. It is an Apache Software Foundation top-level project under the Apache 2.0 license.

Architecture Comparison#

Apache APISIX Architecture#

APISIX keeps NGINX's event-driven request handling for raw performance, but moves configuration out of static files and into etcd. Changes to routes, upstreams, and plugins propagate to every node in real time, with no reloads. Cross-cutting concerns are handled by plugins rather than hand-written configuration, and everything is managed through a REST Admin API. The result is NGINX-class throughput with the operational model of a modern, dynamic gateway.

NGINX Architecture#

Plain NGINX stores its configuration in nginx.conf and related files. Applying a change requires a reload, and while reloads are graceful, configuration is fundamentally static at runtime. API gateway behavior such as per-consumer rate limiting, token authentication, or request transformation must be expressed through directives, njs, or Lua modules that you write and maintain. NGINX Plus relaxes some of these limits with a runtime reconfiguration API and built-in modules, on a commercial subscription.

Dynamic Configuration#

This is the clearest practical difference. With open-source NGINX, adding a route or changing an upstream means editing configuration and reloading the process. In dynamic environments, such as Kubernetes with ephemeral pods or frequent deployments, this static model adds friction.

APISIX treats configuration as live data. Routes and policies can be created, updated, and removed through the Admin API and take effect within milliseconds, with no reload and no dropped connections. This makes APISIX a natural fit for service discovery, canary releases, and automation-driven platforms.

Feature Comparison#

When to Choose Apache APISIX#

• You need API gateway features (dynamic routing, authentication, rate limiting, transformation) without hand-building them in NGINX configuration.
• Dynamic, automation-driven environments where reload-based config is a bottleneck.
• A rich plugin ecosystem and AI gateway without a commercial license.
• NGINX-class performance combined with a modern control plane.

When to Choose NGINX#

• Simple reverse proxy, load balancing, or static web serving without full gateway requirements.
• An existing, finely tuned NGINX deployment that already meets your needs.
• Deep, low-level control over NGINX directives for specialized use cases.
• An existing NGINX Plus subscription that already covers your dynamic configuration and authentication needs.

FAQ#

Isn't Apache APISIX just NGINX with extra steps?#

APISIX is built on top of NGINX and LuaJIT (via OpenResty), so it inherits NGINX's proven performance, but it is not just NGINX. APISIX adds a full API gateway layer that plain NGINX lacks: dynamic configuration through etcd with no reloads, an Admin API, a 100+ plugin ecosystem for authentication, rate limiting, and observability, service discovery, and a dashboard. You get NGINX's data plane plus a complete control plane out of the box.

Do I need to know NGINX to run Apache APISIX?#

No. APISIX is configured through its Admin API, declarative YAML, or its dashboard, using high-level concepts like routes, upstreams, services, and plugins. You do not write or maintain nginx.conf. Familiarity with NGINX concepts can help with advanced tuning, but day-to-day operation does not require editing NGINX configuration files.

How does Apache APISIX compare to NGINX Plus?#

NGINX Plus is the commercial edition of NGINX, adding dynamic reconfiguration, active health checks, JWT authentication, and a dashboard on a subscription. APISIX provides comparable dynamic configuration, health checking, and authentication, plus a much larger plugin ecosystem and AI gateway features, as open-source software under the Apache 2.0 license with no per-instance fee. Teams evaluating NGINX Plus for gateway features often find APISIX covers the same needs without licensing cost.

Can I migrate my nginx.conf to Apache APISIX?#

Most nginx.conf reverse-proxy setups map cleanly onto APISIX concepts: server and location blocks become routes, proxy_pass upstreams become APISIX upstreams, and directives like rate limiting, header rewriting, and access control become plugins. The main shift is moving from a static file that requires reloads to dynamic configuration managed through the Admin API, which removes reload-related downtime.

Related#

• All API gateway comparisons
• What is an API gateway?
• Apache APISIX vs Envoy
• Apache APISIX vs Traefik
• Get started with Apache APISIX

Apache APISIX and Traefik are both modern, cloud-native gateways, but they optimize for different things. APISIX prioritizes raw performance and a broad, ready-to-use feature set. Traefik prioritizes developer experience through automatic service discovery and configuration. For most production API workloads — where throughput, feature breadth, and predictable, auditable configuration matter — APISIX is the stronger choice; Traefik is most compelling for container-native setups that value automatic discovery over fine-grained control.

Overview#

Traefik (Traefik Proxy) is an open-source edge router written in Go. Its signature feature is automatic configuration: it discovers services from providers such as Docker labels, Kubernetes resources, and Consul, and wires up routes without manual definitions. It includes automatic HTTPS through Let's Encrypt, a dashboard, and middlewares for cross-cutting concerns. Commercial tiers (Traefik Hub and Traefik Enterprise) add further capabilities.

Apache APISIX is an Apache Software Foundation top-level project built on NGINX and LuaJIT, with configuration stored in etcd and a 100+ plugin ecosystem. It targets high throughput, low latency, broad protocol support, and rich gateway features, configured explicitly through an Admin API, declarative YAML, or a dashboard.

Architecture Comparison#

Apache APISIX Architecture#

APISIX uses NGINX's event-driven data plane with Lua plugins and stores configuration in etcd, which propagates changes to all nodes in real time. Routes, upstreams, and plugins are defined explicitly, which gives precise control over behavior. The architecture is tuned for high single-node throughput and predictable latency, and it supports a wide range of protocols beyond HTTP.

Traefik Architecture#

Traefik is built around providers and dynamic discovery. Instead of defining routes by hand, you label your containers or annotate your Kubernetes resources, and Traefik builds its routing table automatically and keeps it in sync as services come and go. This is excellent for fast-moving container environments. Being written in Go, Traefik benefits from a simple deployment model (a single binary) but generally trades some raw throughput compared to an OpenResty-based data plane.

Performance#

Performance is a frequent reason teams choose APISIX. Its NGINX and LuaJIT foundation and radix-tree route matching deliver high throughput and low per-request overhead, which becomes important at scale where small overheads multiply into real infrastructure cost. Traefik is fast enough for a large share of workloads, but Go's runtime characteristics typically place its peak throughput below an OpenResty-based gateway. For latency-sensitive or very high-volume APIs, APISIX usually has the edge; for moderate traffic, both perform comfortably. Benchmark with your own workload to be sure.

Developer Experience and Configuration#

Traefik's strength is auto-discovery: a developer can deploy a container with a few labels and have it routed and served over HTTPS automatically, with minimal gateway knowledge. In container-heavy environments this is genuinely convenient, but it is a tradeoff — implicit, label-driven configuration is harder to audit, and behavior can shift as labels change.

APISIX favors explicit configuration. Routes and plugins are declared deliberately, which is more setup up front but yields fine-grained control, clearer auditability, and behavior that does not change implicitly as labels change. APISIX also supports service discovery integrations (Nacos, Consul, Eureka, Kubernetes), narrowing the gap for dynamic environments while keeping configuration explicit.

Feature Comparison#

When to Choose Apache APISIX#

• High throughput and low latency are priorities, especially at scale.
• A broad, built-in feature set including advanced traffic management and AI gateway capabilities.
• Multi-protocol support beyond HTTP (gRPC, MQTT, Dubbo, TCP/UDP).
• Explicit, auditable configuration with real-time dynamic updates.

When to Choose Traefik#

• Container-native auto-discovery with minimal manual configuration.
• Automatic HTTPS through built-in Let's Encrypt integration.
• Docker and Kubernetes label-driven workflows where convention beats configuration.
• A simple single-binary Go deployment for small to moderate workloads.

FAQ#

Is Traefik easier to set up than Apache APISIX?#

Traefik is known for fast setup in container environments because it auto-discovers services from Docker labels or Kubernetes resources and configures itself, with automatic HTTPS through Let's Encrypt. For a small containerized setup this is very convenient. APISIX requires defining routes and upstreams explicitly, but provides more control and a richer feature set in return. For simple auto-wired deployments Traefik feels lighter; for feature-rich gateways APISIX's explicit model pays off.

How do Apache APISIX and Traefik compare on performance?#

APISIX is built on NGINX and LuaJIT, while Traefik is written in Go. APISIX generally achieves higher single-node throughput and lower, more predictable latency, which matters most at high request volumes where per-request overhead compounds. Traefik performs well for many workloads, but teams prioritizing maximum throughput and a low latency floor tend to favor APISIX. As always, benchmark with your own workload and hardware.

Which has a larger plugin ecosystem, Apache APISIX or Traefik?#

APISIX ships with 100+ built-in plugins and supports custom plugins in Lua, Go, Java, Python, and Wasm. Traefik uses middlewares for cross-cutting concerns and supports plugins through a Go interpreter and Wasm, with a smaller catalog. Teams needing a broad set of ready-made capabilities, including AI gateway features, generally find more available in APISIX out of the box.

Do both Apache APISIX and Traefik support Kubernetes and the Gateway API?#

Yes. Both run as Kubernetes ingress controllers and both support the Kubernetes Gateway API. Traefik is known for automatically discovering Kubernetes services and configuring routes from annotations and CRDs. APISIX provides its own ingress controller with CRDs, standard Ingress support, and Gateway API support, with configuration propagated through etcd in real time.

Related#

• All API gateway comparisons
• What is an API gateway?
• Apache APISIX vs NGINX
• Apache APISIX vs Envoy
• Get started with Apache APISIX

API gateway authentication is the practice of verifying client identity at a centralized entry point before requests reach backend services. By enforcing authentication at the gateway layer, organizations eliminate redundant auth logic across services, reduce attack surface, and gain a single enforcement point for access policies.

What is API Gateway Authentication#

In a distributed architecture, every service that exposes an endpoint must answer a fundamental question: who is making this request? Without a gateway, each service independently implements its own authentication stack. This leads to inconsistent enforcement, duplicated code, and a broader attack surface.

An API gateway centralizes this concern. It intercepts every inbound request, validates credentials against a configured identity provider or local store, and either forwards the authenticated request downstream or rejects it immediately. Broken authentication consistently ranks among the top API vulnerability categories, making centralized enforcement critical.

Centralizing authentication at the gateway layer provides three key advantages. First, it significantly reduces per-service authentication code by consolidating auth logic into a single component. Second, it creates a single audit log for every authentication event. Third, it enables credential rotation and policy changes without redeploying individual services.

Authentication Methods#

Key Auth#

Key authentication is the simplest method. The client includes a static API key in a header or query parameter. The gateway validates the key against a stored registry and maps it to a consumer identity.

Key Auth works well for server-to-server communication where transport security (TLS) is guaranteed and the client population is small. API keys remain common for machine-to-machine authentication, though their share is declining as organizations move toward token-based methods.

Apache APISIX supports Key Auth natively through its key-auth plugin. Configuration requires only defining a consumer and attaching the plugin to a route.

JWT (JSON Web Tokens)#

JWT authentication uses digitally signed tokens that carry claims about the client. The gateway validates the token signature, checks expiration, and optionally verifies audience and issuer claims. Because JWTs are self-contained, the gateway does not need to call an external service on every request.

JWTs dominate modern API authentication. The compact format and stateless verification make JWTs particularly well-suited for high-throughput gateways where microsecond-level latency matters.

APISIX implements JWT validation through its jwt-auth plugin, supporting both HS256 and RS256 algorithms with configurable claim validation.

OAuth 2.0#

OAuth 2.0 is an authorization framework that enables third-party applications to obtain limited access to an API on behalf of a resource owner. The gateway validates bearer tokens issued by an authorization server, typically by introspecting the token or verifying a JWT access token locally.

OAuth 2.0 is widely adopted across enterprises for API integrations. The framework's delegation model makes it essential for any API exposed to external developers or partner ecosystems.

OpenID Connect (OIDC)#

OpenID Connect extends OAuth 2.0 with a standardized identity layer. It adds an ID token (a JWT) that carries user identity claims alongside the OAuth 2.0 access token. The gateway can validate the ID token to confirm user identity and use the access token for authorization decisions.

OIDC is the de facto standard for single sign-on in API ecosystems. Major identity providers including Okta, Auth0, Azure AD, and Google Identity all implement OIDC. APISIX provides native OIDC support through its openid-connect plugin, which handles the full authorization code flow, token introspection, and token refresh.

mTLS (Mutual TLS)#

Mutual TLS requires both the client and server to present certificates during the TLS handshake. The gateway validates the client certificate against a trusted certificate authority, establishing strong machine identity without application-layer tokens.

mTLS adoption has surged alongside zero-trust architecture initiatives. In Kubernetes environments, mTLS between services has become increasingly common. At the gateway level, mTLS is particularly valuable for B2B integrations and internal service-to-service communication where certificate management infrastructure already exists.

HMAC Authentication#

HMAC authentication requires the client to compute a hash-based message authentication code over the request content using a shared secret. The gateway independently computes the same HMAC and compares the results. This method provides request integrity verification in addition to authentication.

HMAC is common in financial APIs and webhook verification scenarios where request tampering must be detected. AWS Signature Version 4, used across all AWS API calls, is an HMAC-based scheme processing billions of requests daily.

Comparison Table#

Best Practices#

Layer your authentication. Use mTLS at the transport layer for service identity and JWT or OAuth 2.0 at the application layer for user identity. Defense in depth reduces the impact of any single credential compromise.

Enforce short-lived tokens. Set JWT and OAuth 2.0 access token lifetimes to 15 minutes or less for user-facing flows. Use refresh tokens to obtain new access tokens without re-authentication. Short token lifetimes limit the window of exploitation if a token is leaked.

Centralize consumer management. Define consumers at the gateway level with consistent identity attributes. Map every API key, JWT subject, and OAuth 2.0 client ID to a named consumer entity. This enables unified rate limiting, logging, and access control across authentication methods.

Validate all claims. Do not trust a JWT solely because its signature is valid. Verify the issuer (iss), audience (aud), expiration (exp), and not-before (nbf) claims. Reject tokens with unexpected or missing claims.

Log authentication events comprehensively. Record every authentication success and failure with client identity, timestamp, source IP, and the route accessed. These logs are essential for incident response and compliance audits. NIST SP 800-92 recommends retaining authentication logs for a minimum of 90 days.

How Apache APISIX Handles Authentication#

Apache APISIX provides a plugin-based authentication architecture that supports all six methods described above. Each authentication plugin runs in the gateway's request processing pipeline before the request reaches any upstream service.

APISIX's consumer abstraction ties authentication credentials to named entities. A single consumer can have multiple authentication methods attached, enabling gradual migration between methods. For example, an organization migrating from Key Auth to JWT can configure both plugins on the same consumer during the transition period.

Key plugins include:

• key-auth: Static API key validation with header or query parameter extraction.
• jwt-auth: JWT signature verification with configurable algorithms and claim validation.
• openid-connect: Full OIDC flow support including authorization code, token introspection, and PKCE.

APISIX also supports chaining authentication plugins with authorization plugins such as consumer-restriction and OPA (Open Policy Agent), enabling fine-grained access control decisions after identity is established.

Performance benchmarks show APISIX processing authenticated requests with sub-millisecond overhead for Key Auth and JWT validation, and under 5ms for OIDC token introspection with a local identity provider. These numbers hold at sustained loads exceeding 10,000 requests per second on modest hardware.

FAQ#

Should I use JWT or OAuth 2.0 for my API?#

JWT and OAuth 2.0 are not mutually exclusive. OAuth 2.0 is an authorization framework that often uses JWTs as its access token format. If your API serves first-party clients only, standalone JWT authentication may suffice. If third-party developers need delegated access, implement the full OAuth 2.0 framework with JWT access tokens.

Is API key authentication secure enough for production?#

API key authentication is secure for server-to-server communication over TLS when keys are rotated regularly and scoped to specific consumers. It is not recommended for client-side applications (browsers, mobile apps) because keys cannot be kept secret on end-user devices. For any client-facing API, prefer OAuth 2.0 or OIDC.

How does mTLS differ from standard TLS at the gateway?#

Standard TLS authenticates only the server to the client. The client verifies the server's certificate, but the server accepts any client connection. mTLS adds a second handshake step where the client also presents a certificate that the server validates against a trusted CA. This provides strong machine identity for both parties and is a foundational component of zero-trust network architectures.

Can I combine multiple authentication methods on a single route?#

Yes. Apache APISIX supports configuring multiple authentication plugins on a single route. The gateway attempts each configured method in order and accepts the request if any method succeeds. This is useful during migration periods or when a route serves clients with different authentication capabilities.

Microservices architectures need an API gateway to provide a single entry point that abstracts the complexity of a distributed service fleet from API consumers. The gateway handles cross-cutting concerns like authentication, routing, rate limiting, and observability centrally, preventing each microservice from reimplementing these capabilities independently and ensuring consistent behavior across the entire API surface.

Why Microservices Need a Gateway#

A microservices architecture decomposes a monolithic application into independently deployable services, each owning a specific business domain. While this approach improves development velocity and scaling flexibility, it introduces operational challenges that compound as the number of services grows.

Without a gateway, every client must know the network location of every service it needs. A single mobile application screen might require data from five different services, forcing the client to manage multiple connections, handle partial failures, and aggregate responses. As organizations scale their microservices fleets, client-side orchestration becomes impractical.

The API gateway pattern, first described by Chris Richardson and widely adopted since, solves this by interposing a single component between clients and the service fleet. The gateway accepts all client requests, routes them to the appropriate services, and returns consolidated responses. The pattern has become a standard component in production microservices architectures.

The gateway also addresses a second fundamental problem: cross-cutting concern duplication. Authentication, logging, rate limiting, CORS handling, and request validation must be applied consistently across all services. Without a gateway, each service team implements these independently, leading to drift, inconsistency, and duplicated effort. Centralizing cross-cutting concerns at the gateway significantly reduces per-service boilerplate code.

Core Gateway Patterns#

Request Routing#

The most fundamental gateway pattern routes incoming requests to the correct upstream service based on URL paths, headers, methods, or other request attributes. A gateway might route /api/users/* to the user service, /api/orders/* to the order service, and /api/products/* to the catalog service.

Dynamic routing takes this further by reading route configurations from a control plane or configuration store, allowing routes to be updated without restarting the gateway. Apache APISIX supports dynamic route configuration through its Admin API and etcd-backed configuration store, enabling zero-downtime route changes.

API Composition (Aggregation)#

API composition combines responses from multiple microservices into a single response for the client. Instead of requiring a mobile application to make five separate API calls to render a dashboard, the gateway fetches data from all five services in parallel and returns a unified response.

This pattern reduces client-side complexity and network round trips. Consolidating multiple API calls into a single gateway request significantly decreases page load time, especially on mobile networks where each round trip adds noticeable latency.

Backend for Frontend (BFF)#

The BFF pattern creates gateway configurations tailored to specific client types. A mobile BFF provides compact responses optimized for bandwidth constraints and small screens. A web BFF returns richer data structures suited to desktop layouts. An internal BFF serves admin tools with elevated access.

Each BFF acts as a specialized gateway layer that transforms and filters upstream service responses for its target client. Netflix, Spotify, and SoundCloud have publicly documented their BFF implementations. The pattern prevents a one-size-fits-all API from forcing compromises on every client type.

Service Mesh Integration#

In architectures that deploy both an API gateway and a service mesh, the gateway handles north-south traffic (client to cluster) while the service mesh manages east-west traffic (service to service). The gateway provides external-facing features like API key authentication, rate limiting, and response transformation. The mesh handles internal concerns like mTLS, circuit breaking, and service-to-service load balancing.

Most organizations using a service mesh also deploy an API gateway with clear boundaries between the two components. This separation avoids the complexity of running a full mesh for external traffic while preserving mesh benefits for internal communication.

Key Features for Microservices#

Service Discovery#

In a microservices environment, services scale dynamically and their network locations change frequently. Static configuration of upstream addresses becomes impractical at scale. Service discovery enables the gateway to automatically detect available service instances and their health status.

Apache APISIX integrates with multiple service discovery systems, documented in its discovery configuration guide. Supported registries include Consul, Eureka, Nacos, and Kubernetes-native service discovery. When a new service instance registers or an existing instance becomes unhealthy, APISIX updates its routing table automatically.

In Kubernetes environments, APISIX can read Service and Endpoint resources directly, eliminating the need for a separate discovery system. Kubernetes-native service discovery typically provides faster routing updates compared to polling-based approaches.

Circuit Breaking#

Circuit breaking prevents cascading failures by stopping requests to an unhealthy upstream service. When error rates exceed a configured threshold, the circuit opens and the gateway returns a fast failure response instead of forwarding requests to the struggling service. After a cooldown period, the circuit enters a half-open state and allows a limited number of test requests through. If those succeed, the circuit closes and normal traffic resumes.

Without circuit breaking, a single unhealthy service can consume all available connections and thread pools in the gateway, causing failures to cascade across the entire system. Organizations using circuit breakers typically experience significantly shorter outage durations.

Canary Deployment#

Canary deployment routes a small percentage of production traffic to a new service version while the majority continues to hit the stable version. The gateway controls the traffic split, enabling teams to validate new releases with real traffic before committing to a full rollout.

APISIX supports traffic splitting through weighted upstream configurations. A typical canary deployment starts with 5% of traffic routed to the new version, gradually increasing to 25%, 50%, and finally 100% as metrics confirm stability. If errors spike, the gateway reverts the traffic split without any service redeployment.

Distributed Tracing#

In a microservices architecture, a single client request might traverse ten or more services. Distributed tracing tracks the request's path through the entire service chain, recording latency at each hop. The gateway plays a critical role by injecting trace context headers (W3C Trace Context or B3) into every request it forwards.

APISIX supports trace context propagation to observability backends including Zipkin, Jaeger, SkyWalking, and OpenTelemetry. With tracing enabled at the gateway, operations teams gain end-to-end visibility into request flows, enabling faster incident resolution compared to relying solely on logs and metrics.

API Gateway vs Service Mesh#

API gateways and service meshes both manage network traffic in a microservices architecture, but they target different communication patterns and offer different feature sets.

The two technologies are complementary, not competitive. Organizations deploying both an API gateway and a service mesh generally report improved overall system reliability compared to using either component alone.

How Apache APISIX Supports Microservices#

Apache APISIX is designed for microservices environments, offering dynamic configuration, multi-protocol support, and native integration with cloud-native infrastructure.

Dynamic configuration without restarts. APISIX stores configuration in etcd and applies changes in real time. Routes, upstream definitions, plugins, and consumers can be added, modified, or removed through the Admin API without restarting any gateway node. This is essential in microservices environments where service endpoints change frequently.

Plugin pipeline architecture. APISIX's plugin system runs a configurable pipeline of plugins on each request. For microservices, this means authentication, rate limiting, request transformation, and logging execute as independent pipeline stages. Plugins can be enabled per-route, per-service, or globally, providing fine-grained control over cross-cutting behavior.

Kubernetes-native operation. The APISIX Ingress Controller deploys APISIX as a Kubernetes-native gateway, supporting both the legacy Ingress resource and the newer Gateway API specification. This allows platform teams to manage gateway configuration using familiar Kubernetes declarative workflows.

Service discovery integration. APISIX's service discovery capabilities connect directly to Consul, Nacos, Eureka, and Kubernetes DNS, ensuring the gateway always routes to healthy, available service instances without manual configuration updates.

Observability. Built-in plugins export metrics to Prometheus, traces to Jaeger, Zipkin, and OpenTelemetry, and logs to HTTP endpoints, syslog, or Kafka. This enables a complete observability pipeline with the gateway as the instrumentation point for all external API traffic.

FAQ#

Do I need an API gateway if I already use a service mesh?#

Yes. A service mesh manages internal service-to-service communication but does not address external API concerns like consumer authentication, API key management, rate limiting per consumer, request transformation, or developer-facing documentation. The API gateway handles the north-south boundary where external clients interact with your microservices. Deploy both for comprehensive traffic management.

How does an API gateway handle partial failures across microservices?#

An API gateway can be configured with circuit breakers, timeouts, and retry policies for each upstream service. When using the API composition pattern, the gateway can return partial results with degraded status rather than failing the entire request when one backend is unavailable. APISIX supports configurable timeouts and retry counts per route, and health checks automatically remove unhealthy nodes from the upstream pool.

Should each microservice team manage their own gateway routes?#

A decentralized model where service teams own their route configurations works well at scale, provided the platform team controls the global policies (authentication requirements, rate limiting defaults, logging standards). APISIX supports this through its Admin API, which can be integrated into CI/CD pipelines. Service teams declare their routes in version-controlled configuration files, and the deployment pipeline applies changes through the Admin API after policy validation.

What is the performance impact of adding an API gateway to a microservices architecture?#

Apache APISIX, built on NGINX and LuaJIT, adds 1-2ms of latency per request with a typical plugin configuration (authentication, rate limiting, logging). For most microservices architectures where end-to-end request latency is 50-500ms, this overhead is under 2% of total latency. The operational benefits of centralized security, observability, and traffic management significantly outweigh the minor latency cost.

API gateway rate limiting is the practice of controlling how many requests a client can make to your API within a defined time window. Implemented at the gateway layer, rate limiting protects backend services from overload, prevents abuse, ensures fair resource allocation across consumers, and maintains predictable service quality under variable traffic conditions.

What is Rate Limiting#

Rate limiting enforces a maximum request throughput for API consumers. When a client exceeds its allowed quota, the gateway returns an HTTP 429 (Too Many Requests) response instead of forwarding the request to the upstream service. The response typically includes a Retry-After header indicating when the client can resume making requests.

The need for rate limiting has grown alongside API traffic volumes. API traffic now represents the majority of HTTP requests processed globally, and a significant portion consists of automated requests, many of which are abusive or unintentional high-frequency polling.

Without rate limiting, a single misbehaving client can consume disproportionate backend resources, degrading performance for all consumers. Rate limiting is also a contractual tool: it enforces the usage tiers defined in API monetization plans and SLAs.

Why Rate Limit at the Gateway#

Implementing rate limiting at the API gateway rather than in individual services provides several structural advantages.

Single enforcement point. When rate limits are defined at the gateway, every request passes through the same throttling logic regardless of which upstream service handles it. This eliminates the risk of inconsistent enforcement across a microservices fleet and reduces availability incidents caused by traffic spikes.

Reduced backend load. Rejected requests never reach the upstream service. This means the gateway absorbs the cost of excess traffic, keeping backend services operating within their designed capacity.

Consistent client experience. Centralized rate limiting ensures all consumers receive the same HTTP 429 responses with standardized headers (X-RateLimit-Limit, X-RateLimit-Remaining, X-RateLimit-Reset), making it straightforward for client developers to implement backoff logic.

Operational visibility. Gateway-level rate limiting produces unified metrics on throttled requests, enabling operations teams to identify abusive clients, undersized quotas, and traffic anomalies from a single dashboard.

Rate Limiting Algorithms#

Token Bucket#

The token bucket algorithm maintains a bucket of tokens for each rate-limited entity. Tokens are added at a fixed rate up to a maximum capacity. Each request consumes one token. If the bucket is empty, the request is rejected.

Token bucket allows short bursts up to the bucket capacity while enforcing an average rate over time. This makes it well-suited for APIs where occasional traffic spikes are acceptable but sustained overuse is not.

Pros: Permits controlled bursting, simple to implement, low memory footprint.

Cons: Burst size must be tuned carefully; overly generous bursts can still overwhelm backends.

Leaky Bucket#

The leaky bucket algorithm processes requests at a fixed rate, queuing excess requests until the queue is full. It smooths traffic into a uniform output rate regardless of input burstiness.

Leaky bucket is ideal for backends that require strictly uniform request rates, such as third-party APIs with their own rate limits or services with fixed connection pools.

Pros: Produces perfectly smooth output, prevents backend overload from bursts.

Cons: Higher latency for bursty traffic due to queuing, queue size requires tuning.

Sliding Window#

The sliding window algorithm divides time into overlapping windows and counts requests across the current and previous windows using weighted proportions. This eliminates the boundary problem inherent in fixed windows.

For example, if the window is 60 seconds and the current position is 40 seconds into the window, the algorithm weights 33% of the previous window's count and 100% of the current window's count to determine if the limit is exceeded.

Pros: Accurate rate enforcement without boundary spikes, reasonable memory usage.

Cons: Slightly more complex to implement than fixed window.

Fixed Window#

The fixed window algorithm divides time into non-overlapping intervals and counts requests within each interval. When the count exceeds the limit, subsequent requests are rejected until the next window begins.

Fixed window is the simplest algorithm but has a well-known boundary problem: a client can make double the intended rate by clustering requests at the end of one window and the beginning of the next. Despite this limitation, fixed window remains widely deployed due to its simplicity and low overhead.

Pros: Minimal memory and computation, easy to understand and debug.

Cons: Boundary burst problem allows temporary rate doubling.

Algorithm Comparison#

Rate Limiting Strategies#

Per-Consumer#

Assign rate limits based on authenticated consumer identity. This is the most common strategy for APIs with tiered pricing plans. A free tier consumer might receive 100 requests per minute while a paid enterprise consumer receives 10,000.

Per-consumer rate limiting requires the rate limiting plugin to execute after authentication so the consumer identity is available. APISIX's consumer abstraction makes this straightforward: attach rate limit configurations directly to consumer definitions.

Per-IP#

Throttle requests based on the client's source IP address. This strategy is effective for public APIs that do not require authentication, such as health check endpoints or public data feeds. IP-based rate limiting is a practical first line of defense against volumetric API abuse, especially when combined with reputation scoring.

Per-IP limiting has limitations in environments where many clients share a single IP (corporate NATs, mobile carriers). Use it as a coarse first defense layer, not as the sole rate limiting strategy.

Per-Route#

Apply different rate limits to different API endpoints based on their resource cost. A search endpoint that triggers expensive database queries might have a stricter limit than a simple metadata lookup. This strategy protects the most resource-intensive parts of your backend.

Global#

Enforce an aggregate rate limit across all consumers and routes. Global limits protect the overall system capacity and are typically set well above individual consumer limits. They serve as a safety net when the sum of individual limits exceeds actual infrastructure capacity.

How Apache APISIX Implements Rate Limiting#

Apache APISIX provides three complementary rate limiting plugins, each targeting a different dimension of traffic control.

limit-req (Request Rate Limiting)#

The limit-req plugin implements a leaky bucket algorithm that controls the request rate per second. It accepts configuration for the sustained request rate (rate), the burst allowance (burst), and the rejection status code.

This plugin is ideal when you need to smooth traffic to a uniform rate. It supports keying on remote address, consumer name, service, or any variable available in the APISIX context.

limit-count (Request Count Limiting)#

The limit-count plugin enforces a maximum number of requests within a configurable time window. It supports both fixed window and sliding window algorithms, with the window size configurable from one second to one day.

limit-count is the best choice for implementing API quota plans (e.g., 10,000 requests per day). It returns standard rate limit headers so clients can track their remaining quota. For distributed deployments, limit-count supports shared counters via Redis, ensuring accurate enforcement across multiple gateway nodes. In benchmarks, Redis-backed distributed counting adds less than 1ms of latency per request at the 99th percentile.

limit-conn (Concurrent Connection Limiting)#

The limit-conn plugin restricts the number of concurrent requests being processed simultaneously. Unlike rate-based limits, connection limits protect against slow-client attacks and long-running requests that tie up backend connections.

This plugin is essential for APIs that serve large file downloads, streaming responses, or long-polling connections. It works by counting active connections per key and rejecting new connections when the limit is exceeded.

Combining Plugins#

APISIX allows stacking all three plugins on a single route. A typical production configuration might combine limit-count for daily quotas, limit-req for per-second smoothing, and limit-conn for concurrent connection caps. The plugins execute in order, and a request rejected by any plugin does not consume quota in subsequent plugins.

This layered approach mirrors industry best practice. Production APIs benefit from enforcing at least two independent rate limiting dimensions to provide comprehensive protection.

FAQ#

What HTTP status code should I return for rate-limited requests?#

Return HTTP 429 (Too Many Requests) as defined in RFC 6585. Include a Retry-After header with the number of seconds the client should wait before retrying. Additionally, include X-RateLimit-Limit, X-RateLimit-Remaining, and X-RateLimit-Reset headers so clients can proactively manage their request rate. APISIX's limit-count plugin returns these headers automatically.

How do I handle rate limiting in a distributed gateway deployment?#

Use a shared counter store such as Redis. APISIX's limit-count plugin natively supports Redis and Redis Cluster backends for distributed counter synchronization. This ensures that rate limits are enforced accurately regardless of which gateway node processes the request. The trade-off is a small latency increase (typically under 1ms) for the Redis round-trip on each request.

Should I rate limit internal service-to-service traffic?#

Yes, but with different thresholds. Internal rate limiting prevents cascading failures when one service sends an unexpectedly high volume of requests to another. Set internal limits based on measured capacity rather than commercial quotas. Circuit breakers complement internal rate limiting by stopping requests entirely when a downstream service is unhealthy.

How do I communicate rate limits to API consumers?#

Document rate limits in your API reference and include them in onboarding materials. Use standard rate limit response headers on every response (not just 429 responses) so clients can monitor their consumption in real time. Provide a dedicated endpoint or dashboard where consumers can check their current usage against their quota. For paid tiers, send proactive notifications when consumers approach their limits.

API gateway security is the practice of protecting your API infrastructure at the edge by enforcing authentication, authorization, rate limiting, and traffic filtering before requests reach backend services. A properly secured gateway reduces attack surface, prevents data breaches, and ensures compliance across every API endpoint in your organization.

Why API Gateway Security Matters#

APIs have become the primary attack vector for modern applications. According to the OWASP API Security Top 10 (2023 edition), broken object-level authorization and broken authentication remain the two most critical API vulnerabilities, affecting organizations across every industry. The explosive growth of API-first architectures has created an equally explosive growth in API-targeted attacks.

The cost of getting API security wrong is substantial, as breaches involving API vulnerabilities tend to take longer to identify and contain and carry significant financial impact. The API gateway sits at a unique vantage point: it processes every inbound request, making it the single most effective location to enforce security policies consistently.

Common API Threats#

Understanding the threat landscape is essential for building an effective defense. The following categories represent the most frequent and damaging attack patterns targeting APIs today.

Broken Object-Level Authorization (BOLA)#

BOLA attacks exploit weak authorization checks to access resources belonging to other users. An attacker modifies object identifiers in API requests (for example, changing /users/123/orders to /users/456/orders) to retrieve unauthorized data. BOLA remains one of the most exploited API vulnerability classes, particularly in organizations where API management and authorization enforcement have not kept pace with API proliferation.

Injection Attacks#

SQL injection, NoSQL injection, and command injection remain persistent threats. Attackers embed malicious payloads in query parameters, headers, or request bodies. Despite being a well-known vulnerability class, injection attacks continue to appear frequently in web application security assessments.

Broken Authentication#

Weak or improperly implemented authentication mechanisms allow attackers to assume legitimate user identities. Common failures include missing token validation, weak password policies, credential stuffing vulnerabilities, and improper session management. Credential stuffing attacks account for billions of login attempts monthly across the internet.

Excessive Data Exposure#

APIs frequently return more data than the client needs, relying on the frontend to filter sensitive fields. Attackers bypass the frontend and consume raw API responses directly, gaining access to data never intended for display. This over-exposure is especially dangerous in mobile applications where API traffic is easily intercepted.

Rate Limit Bypass#

Without proper rate limiting, attackers can launch brute-force attacks, denial-of-service campaigns, and credential enumeration at scale. Automated bot traffic constitutes a significant portion of all internet traffic, and much of it targets API endpoints specifically.

Security Layers at the Gateway#

A defense-in-depth approach applies multiple security controls at the gateway layer, each addressing a distinct category of risk.

Authentication#

The gateway should verify identity before any request reaches a backend service. Common mechanisms include JWT validation, OAuth 2.0 token introspection, API key verification, and mutual TLS (mTLS) for service-to-service communication. Centralizing authentication at the gateway eliminates the risk of inconsistent enforcement across individual services.

Authorization#

Beyond verifying identity, the gateway must enforce access control. Role-based access control (RBAC), attribute-based access control (ABAC), and scope-based authorization ensure that authenticated users can only access resources and operations they are permitted to use. Fine-grained authorization at the gateway prevents BOLA vulnerabilities at scale.

Rate Limiting and Throttling#

Rate limiting protects backend services from abuse and ensures fair resource allocation. Effective rate limiting operates at multiple granularities: per consumer, per route, per IP address, and globally. A substantial share of traffic on the average website comes from bots, and rate limiting is the first line of defense against automated abuse.

IP Restriction#

IP allowlists and denylists provide coarse-grained access control. While not sufficient as a sole security measure, IP restriction is valuable for restricting administrative endpoints, limiting partner API access to known address ranges, and blocking traffic from regions associated with attack activity.

WAF and CORS#

A Web Application Firewall (WAF) at the gateway layer inspects request payloads for known attack patterns. CORS policies prevent unauthorized cross-origin requests from browser-based clients. Together, they address both server-side injection attacks and client-side cross-origin abuse.

TLS Termination#

TLS termination at the gateway ensures that all client-to-gateway traffic is encrypted. The gateway handles certificate management, cipher suite configuration, and protocol version enforcement, relieving backend services of this operational burden. The vast majority of web traffic now uses HTTPS, and TLS is considered a baseline requirement for any production API.

Request Validation#

Schema-based request validation rejects malformed or oversized payloads before they reach backend services. Validating request structure, data types, and content length at the gateway prevents injection attacks and reduces the attack surface of downstream services.

Zero-Trust API Architecture#

Zero-trust architecture assumes that no request is inherently trustworthy, regardless of its origin. Every API call must be authenticated, authorized, and validated, whether it arrives from the public internet, an internal service, or a trusted partner.

At the gateway layer, zero-trust principles translate into several concrete practices. Every request carries verifiable identity credentials. Authorization is evaluated per request rather than per session. Network location (internal vs. external) does not confer implicit trust. All traffic is encrypted, including east-west service-to-service communication. The API gateway enables zero-trust by serving as a policy enforcement point. It validates tokens, checks permissions, and applies security policies uniformly across all traffic, creating a consistent security boundary regardless of the underlying network topology.

Security Best Practices#

The following practices represent a comprehensive approach to API gateway security that organizations should adopt incrementally based on risk profile.

1. Enforce authentication on every endpoint. No API route should be accessible without verified identity. Use JWTs with short expiration times and validate signatures on every request.

2. Implement least-privilege authorization. Grant the minimum permissions required for each consumer. Default to deny and require explicit grants for sensitive operations.

3. Apply rate limiting at multiple levels. Configure per-consumer, per-route, and global rate limits. Use sliding window algorithms to prevent burst abuse while accommodating legitimate traffic spikes.

4. Validate all request inputs. Enforce request schema validation at the gateway. Reject payloads that exceed expected sizes, contain unexpected fields, or fail type checks.

5. Use mutual TLS for service-to-service calls. Encrypt and authenticate all internal traffic. Rotate certificates automatically and enforce certificate validation on every connection.

6. Enable WAF rules for known attack patterns. Deploy rulesets targeting SQL injection, XSS, and command injection. Update rules regularly to address emerging attack vectors.

7. Log and audit all security events. Capture authentication failures, authorization denials, rate limit triggers, and WAF blocks. Feed security logs into a SIEM for correlation and alerting.

8. Rotate credentials and secrets regularly. Automate API key rotation, certificate renewal, and token signing key rotation. Never embed secrets in client-side code or version control.

9. Restrict administrative API access. Protect management APIs with strong authentication, IP restrictions, and separate credentials from data-plane APIs.

10. Conduct regular security assessments. Perform API-specific penetration testing, not just general web application assessments. The OWASP API Security Testing Guide provides a structured methodology.

How Apache APISIX Secures APIs#

Apache APISIX provides a comprehensive set of security plugins that implement each layer of the defense-in-depth model described above.

For IP-based access control, the ip-restriction plugin supports allowlists and denylists at the route level, enabling fine-grained control over which addresses can reach specific endpoints.

Cross-origin resource sharing is managed through the CORS plugin, which configures allowed origins, methods, and headers to prevent unauthorized cross-origin requests from browser clients.

CSRF protection is available through the CSRF plugin, which generates and validates CSRF tokens to prevent cross-site request forgery attacks on state-changing API operations.

For mutual TLS, APISIX supports mTLS configuration for both client-to-gateway and gateway-to-upstream connections, ensuring encrypted and mutually authenticated communication at every hop.

APISIX also supports JWT authentication, key authentication, OpenID Connect, rate limiting with multiple algorithms, and request body validation. The plugin architecture enables security policies to be composed per route, allowing teams to apply exactly the controls each endpoint requires without over- or under-securing traffic.

FAQ#

What is the difference between API gateway security and API security?#

API security is the broad discipline of protecting APIs across their entire lifecycle, including design, development, testing, and runtime. API gateway security specifically refers to the security controls enforced at the gateway layer during runtime, such as authentication, rate limiting, and input validation. The gateway is one component of a comprehensive API security strategy, not a replacement for secure coding practices and security testing.

Should I terminate TLS at the API gateway or at the backend service?#

Terminate TLS at the gateway for client-facing connections. This centralizes certificate management and offloads cryptographic processing from backend services. For traffic between the gateway and upstream services, use mTLS to maintain encryption and mutual authentication throughout the request path. This approach balances operational simplicity with end-to-end security.

How many rate limiting layers should an API gateway enforce?#

Apply at least three layers: a global rate limit to protect overall infrastructure capacity, a per-consumer limit to prevent any single client from monopolizing resources, and per-route limits for endpoints with expensive backend operations. Use sliding window or leaky bucket algorithms rather than fixed windows to provide smoother throttling behavior and prevent burst abuse at window boundaries.

An API gateway and a load balancer serve different primary purposes. A load balancer distributes network traffic across multiple backend servers to maximize throughput and availability. An API gateway operates at the application layer to manage, secure, and transform API traffic with features like authentication, rate limiting, and request routing. In modern architectures, they complement each other and are frequently deployed together.

What is a Load Balancer#

A load balancer sits between clients and a pool of backend servers, distributing incoming requests to ensure no single server becomes overwhelmed. Load balancers operate at either Layer 4 (TCP/UDP) or Layer 7 (HTTP/HTTPS) of the OSI model.

Layer 4 load balancers route traffic based on IP address and port number without inspecting the request content. They are fast, protocol-agnostic, and add minimal latency. Layer 7 load balancers inspect HTTP headers, URLs, and sometimes request bodies to make more intelligent routing decisions.

Load balancers are foundational infrastructure. The vast majority of organizations use some form of load balancing in their production environments. The technology has been a networking staple for over two decades, with the core algorithms (round-robin, least connections, weighted distribution) remaining largely unchanged.

The primary value of a load balancer is availability. By distributing traffic and performing health checks, load balancers ensure that the failure of a single backend instance does not cause a service outage. They also enable horizontal scaling: adding more backend instances to handle increased traffic without changing the client-facing endpoint.

What is an API Gateway#

An API gateway is an application-layer proxy that acts as the single entry point for API consumers. Beyond routing requests to the correct backend service, an API gateway provides a rich set of cross-cutting concerns: authentication, authorization, rate limiting, request and response transformation, caching, logging, and monitoring.

API gateways emerged from the needs of microservices architectures and API-first product strategies. When an organization exposes dozens or hundreds of microservices, a gateway centralizes the operational concerns that would otherwise be duplicated across every service.

An API gateway typically operates exclusively at Layer 7 and understands application-level protocols like HTTP, gRPC, WebSocket, and GraphQL. It makes routing decisions based on URL paths, headers, query parameters, and even request body content.

Feature Comparison#

The table makes the distinction clear: load balancers focus on network-level traffic distribution, while API gateways focus on application-level API management. The overlap exists primarily in Layer 7 load balancers, which have gradually added some application-aware features.

Key Differences Explained#

Scope of Concern#

A load balancer answers the question: which backend server should handle this connection? An API gateway answers a broader set of questions: is this client authenticated? Are they authorized for this endpoint? Have they exceeded their rate limit? Does the request need transformation before forwarding? Should the response be cached?

In practice, most organizations using API gateways configure multiple cross-cutting policies (authentication, rate limiting, logging, and CORS), none of which fall within a traditional load balancer's responsibility.

Protocol Awareness#

Load balancers, especially at Layer 4, are largely protocol-agnostic. They route TCP connections without understanding the application protocol. API gateways are deeply protocol-aware. They parse HTTP methods, match URL patterns, inspect headers, and in many cases understand domain-specific protocols like gRPC and GraphQL.

This protocol awareness enables capabilities that load balancers cannot provide. For example, an API gateway can route GraphQL queries to different backend services based on the query's requested fields, or translate between REST and gRPC protocols transparently.

Configuration Granularity#

Load balancer configuration centers on server pools, health check parameters, and distribution algorithms. API gateway configuration is far more granular: per-route authentication requirements, per-consumer rate limits, request header injection, response body transformation, and conditional plugin execution.

A typical enterprise API gateway configuration manages 50-200 routes with distinct policy combinations, compared to a load balancer managing 10-30 server pools. The operational complexity reflects the difference in scope.

Performance Profile#

Layer 4 load balancers add microsecond-level latency because they operate below the HTTP layer. API gateways add millisecond-level latency because they must parse, inspect, and potentially transform HTTP requests. High-performance gateways like Apache APISIX, built on NGINX and LuaJIT, keep this overhead under 1ms for typical configurations. According to APISIX benchmark data, the gateway processes over 20,000 requests per second per core with authentication and rate limiting enabled.

When to Use Which#

Use a Load Balancer When#

• You need to distribute TCP or UDP traffic across backend instances.
• Your primary concern is availability and horizontal scaling.
• You are load balancing non-HTTP protocols (databases, message queues, custom TCP services).
• You want minimal latency overhead with no application-layer processing.

Use an API Gateway When#

• You expose APIs to external consumers who need authentication and rate limiting.
• You run a microservices architecture and need centralized cross-cutting concerns.
• You need request or response transformation between clients and services.
• You require detailed API analytics, logging, and monitoring.
• You manage multiple API versions or need protocol translation.

Use Both Together#

In most production architectures, load balancers and API gateways coexist at different layers. A common deployment pattern places a Layer 4 or cloud-native load balancer (AWS NLB, Google Cloud Load Balancing) in front of a cluster of API gateway instances. The load balancer distributes traffic across gateway nodes for high availability, while the gateway handles application-level API management.

This separation of concerns allows each component to do what it does best.

How Apache APISIX Combines Both#

Apache APISIX is an API gateway that includes built-in load balancing capabilities, effectively combining both roles into a single component for many use cases.

APISIX supports multiple load balancing algorithms natively, documented in its load balancing guide:

• Round-robin (weighted): Distributes requests across upstream nodes based on configured weights.
• Consistent hashing: Routes requests to the same backend based on a configurable key (IP, header, URI), useful for cache-friendly distributions.
• Least connections: Sends requests to the upstream node with the fewest active connections.
• EWMA (Exponential Weighted Moving Average): Selects the upstream node with the lowest response latency, adapting to real-time backend performance.

By combining API gateway features with production-grade load balancing, APISIX reduces architectural complexity for many deployments. Organizations that would otherwise deploy a separate load balancer and a separate API gateway can consolidate into a single APISIX layer, reducing operational overhead and network hops.

For large-scale deployments, a dedicated Layer 4 load balancer in front of APISIX nodes still makes sense for TCP-level high availability and DDoS protection. But within the application layer, APISIX handles both traffic distribution and API management without requiring an additional component.

FAQ#

Can an API gateway replace a load balancer entirely?#

For HTTP and gRPC traffic, a modern API gateway like Apache APISIX can replace a Layer 7 load balancer because it includes equivalent load balancing algorithms. However, for non-HTTP protocols (raw TCP, UDP, database connections) or for Layer 4 DDoS protection, a dedicated load balancer remains necessary. The most common production pattern uses both: a Layer 4 load balancer for network-level distribution and an API gateway for application-level management.

Does adding an API gateway increase latency compared to a load balancer alone?#

Yes, but the increase is typically small. A Layer 4 load balancer adds microseconds of latency. An API gateway adds 0.5-2ms depending on the number of active plugins. For most APIs where upstream service response times are 10-500ms, the gateway overhead is negligible. The operational benefits of centralized authentication, rate limiting, and observability far outweigh the minor latency cost.

Should I use a cloud provider's managed API gateway or deploy my own?#

Managed gateways (AWS API Gateway, Google Apigee) reduce operational burden but limit customization and can become expensive at high traffic volumes. AWS API Gateway charges per million requests, which can reach thousands of dollars monthly for high-traffic APIs. Self-managed gateways like Apache APISIX offer full control, unlimited throughput on your infrastructure, and no per-request fees, but require your team to operate the gateway cluster. Evaluate based on your traffic volume, customization needs, and operations capacity.

How does an API gateway differ from a reverse proxy?#

A reverse proxy forwards client requests to backend servers and is the foundation of both load balancers and API gateways. An API gateway is a specialized reverse proxy that adds API-specific features: authentication, rate limiting, request transformation, API versioning, and developer-facing analytics. NGINX, for example, can function as a reverse proxy, load balancer, or (with extensions) an API gateway. Apache APISIX is purpose-built as an API gateway with load balancing built in.