Apache APISIX vs Istio: API Gateway vs Service Mesh (2026)
By API7.ai Team
Last updated: June 2026
Apache APISIX and Istio solve different problems in the same stack — a north-south API gateway versus an east-west service mesh. This guide compares architecture, traffic scope, performance, security, and operations so you can decide whether you need one, the other, or both.
Apache APISIX is an NGINX-based API gateway for north-south traffic — ingress, authentication, rate limiting, and API management at the edge. Istio is an Envoy-based service mesh for east-west traffic — automatic mTLS, authorization, and tracing between microservices. They are complementary, so many teams run APISIX for the gateway and Istio for the mesh.
- North-south API management and ingress: Apache APISIX
- East-west zero-trust service mesh: Istio
- Edge API management and internal mesh together: Run both (APISIX + Istio)
Apache APISIX vs Istio at a glance
Apache APISIX is an API gateway for north-south traffic; Istio is a service mesh for east-west traffic. APISIX leads on edge API management; Istio leads on internal mTLS and service-to-service policy.
| Dimension | Apache APISIX | Istio |
|---|---|---|
| Category | API gateway (north-south) | Service mesh (east-west) |
| Core & runtime | NGINX/OpenResty (LuaJIT) + etcd | Istiod + Envoy sidecars |
| Traffic scope | Client-to-service: ingress, auth, rate limiting | Service-to-service: mTLS, authz, tracing |
| Deployment model | Centralized gateway pods + etcd | Per-pod sidecar (or ambient) + control plane |
| API management | ✓ Auth, rate limiting, transformation | — Minimal (ingress only) |
| Service mesh | — Not its primary role | ✓ Automatic mTLS, SPIFFE identity |
| License | Apache-2.0 (ASF project) | Apache-2.0 (CNCF project) |
What is Apache APISIX?
Apache APISIX is an open-source API gateway built on NGINX/OpenResty and etcd, handling north-south traffic — routing, authentication, and rate limiting — with a stateless data plane and a 100+ plugin ecosystem.
Apache APISIX is a high-performance, open-source API gateway built on NGINX/OpenResty (LuaJIT) and etcd. It manages north-south traffic at the edge — routing, authentication, rate limiting, and API management — with a stateless data plane and a 100+ plugin ecosystem.
Category
API gateway (north-south)
Architecture
NGINX/OpenResty (LuaJIT) + etcd
License
Apache-2.0 (ASF project)
Best for
Edge API management and ingress
Pros
- Single-core 18,000 QPS at 0.2 ms latency in the official benchmark
- 100+ open-source plugins with no enterprise paywall
- Only etcd as a dependency; stateless, horizontally scalable nodes
- Broad protocol support: HTTP/3, gRPC, TCP/UDP, WebSocket, MQTT, Dubbo
Cons
- Focused on north-south traffic, not a full service mesh
- No automatic per-service mTLS across the whole cluster like a mesh
- East-west service-to-service governance has smaller adoption than Istio
- Advanced lifecycle management and IAM come from API7 Enterprise, not core
What is Istio?
Istio is a CNCF service mesh built on Envoy, handling east-west traffic between microservices with automatic mTLS, identity-based authorization, and distributed tracing — typically via a sidecar injected into each pod.
Istio is a CNCF service mesh built on the Envoy proxy. It manages east-west traffic between microservices — injecting a sidecar (or using ambient mode) to provide automatic mTLS, identity-based authorization, retries, circuit breaking, and distributed tracing without changing application code.
Category
Service mesh (east-west)
Architecture
Istiod + Envoy sidecars
License
Apache-2.0 (CNCF project)
Best for
Zero-trust internal service mesh
Pros
- Automatic mTLS and SPIFFE identity between all services
- Fine-grained authorization via AuthorizationPolicy CRDs
- Built-in distributed tracing and Kiali service-graph visibility
- Retries, circuit breaking, canary, and fault injection for resilience
Cons
- Per-pod sidecar adds ~0.20 vCPU and ~60 MB at 1000 RPS (Istio v1.24 docs)
- Two proxies add ~2.65 ms p90 latency at 1000 RPS (Istio benchmark)
- Steep CRD model and Envoy/sidecar debugging raise the learning curve
- Ingress gateway lacks full API-management features (consumer auth, versioning)
Architecture: edge gateway vs sidecar mesh
Apache APISIX runs as centralized gateway nodes at the edge; Istio runs as a distributed mesh, attaching an Envoy proxy to every pod. One is a single hop; the other is a per-service layer.
Apache APISIX is a centralized gateway: a small number of NGINX/OpenResty nodes handle all ingress traffic, with configuration stored in etcd and propagated to the data plane via etcd watch. The footprint is small — a few gateway pods plus a 3-node etcd cluster — and nodes are stateless, so they scale horizontally without a database bottleneck.
Istio is a mesh: its Istiod control plane configures an Envoy sidecar injected into every pod (or a shared proxy in ambient mode). That model enables transparent service-to-service mTLS and per-service policy, but it adds a proxy to each workload and a CRD-driven control plane to operate. The two are complementary — an edge gateway plus an internal mesh — rather than substitutes.
Performance and resource overhead
Apache APISIX adds one centralized gateway hop; Istio adds a proxy per service. APISIX reports 18,000 QPS per core at 0.2 ms; Istio's own benchmark shows its proxies add ~2.65 ms p90 latency and ~60 MB per sidecar.
Apache APISIX's FAQ reports a single-core throughput of 18,000 QPS at 0.2 ms average latency (its separate benchmark page describes the test conditions). Because APISIX is a centralized edge gateway, a request crosses one gateway hop regardless of how many services sit behind it.
Istio's published benchmark (v1.11, 1 KB payload at 1000 RPS with mutual TLS) shows the two proxies adding about 2.65 ms at the 90th percentile and 2.91 ms at the 99th percentile over baseline, and its v1.24 docs put a sidecar at roughly 0.20 vCPU and 60 MB of memory at 1000 RPS. That overhead is per pod and per hop, so a request traversing several services accumulates it at each step. Istio ambient mode reduces this but is newer than the established sidecar model. Treat all figures as vendor-published and benchmark your own workload.
Apache APISIX vs Istio: feature comparison
Across role, architecture, performance, security, and operations, the two cover different layers — edge API management versus internal service mesh.
| Feature | Apache APISIX | Istio |
|---|---|---|
| Primary role | API gateway for north-south traffic: ingress, edge proxy, external API management | Service mesh for east-west traffic: service-to-service communication and policy |
| Architecture | NGINX/OpenResty (LuaJIT) + etcd; stateless data plane, config synced via etcd watch | Istiod control plane + Envoy sidecar per pod; sidecar injection via admission webhook |
| Traffic scope | North-south: client-to-service routing, rate limiting, authentication, API versioning | East-west: service mTLS, retries, circuit breaking, canary, fault injection |
| Performance | Single-core 18,000 QPS at 0.2 ms average latency (APISIX FAQ benchmark) | Two proxies add ~2.65 ms p90 / ~2.91 ms p99 at 1000 RPS with mTLS (Istio benchmark) |
| Resource footprint | A few centralized gateway pods plus a 3-node etcd cluster | Sidecar ~0.20 vCPU and ~60 MB per pod at 1000 RPS (Istio v1.24 docs) |
| Plugin / extension model | 100+ open-source plugins (auth, traffic, observability) — no enterprise paywall | Envoy filters (C++, Lua, Wasm); mesh-focused extension surface |
| Security & auth | JWT, OAuth2, OpenID Connect, key-auth, HMAC, mTLS, CORS, OPA at the gateway edge | Automatic mTLS, SPIFFE identity, PeerAuthentication, AuthorizationPolicy (zero-trust) |
| Observability | Prometheus, OpenTelemetry, SkyWalking, Zipkin, Datadog via plugins | Distributed tracing, Kiali service graph, Prometheus metrics, access logs |
| Configuration model | Admin API + dashboard; routes, plugins, upstreams via REST API or declarative YAML | Kubernetes CRDs: VirtualService, DestinationRule, Gateway, AuthorizationPolicy |
| Kubernetes integration | APISIX Ingress Controller + Gateway API support; runs in or out of Kubernetes | Deep Kubernetes-native; requires Kubernetes; sidecar or ambient data plane |
| Protocol support | HTTP/1.1, HTTP/2, HTTP/3, gRPC, TCP, UDP, WebSocket, MQTT, Dubbo | HTTP/1.1, HTTP/2, gRPC, TCP; automatic protocol detection |
| Operational complexity | Low — etcd is the only dependency; stateless nodes scale horizontally; no sidecars | Higher — sidecar lifecycle, CRD model, Envoy debugging, upgrade coordination |
When to choose Apache APISIX vs Istio
Choose Apache APISIX for north-south API management at the edge; choose Istio for east-west zero-trust networking between services. Many teams run both — APISIX as the gateway, Istio as the mesh.
Choose Apache APISIX if you…
- Need an API gateway for north-south traffic and external clients
- Want auth, rate limiting, transformation, and routing at the edge
- Prefer a low-dependency, NGINX-based gateway that scales statelessly
Choose Istio if you…
- Need east-west service mesh: automatic mTLS between microservices
- Want identity-based authorization and distributed tracing internally
- Run many services on Kubernetes and accept per-pod proxy overhead
Bottom line: Apache APISIX and Istio are complementary, not competing — APISIX governs north-south traffic at the edge, while Istio secures east-west traffic between services. If your need is mainly edge API management, APISIX alone is usually enough; if you also need internal mTLS and service authorization, pair it with Istio. Teams that want this gateway layer with full API lifecycle management, RBAC/IAM, and enterprise support can look at API7 Enterprise, built on the same NGINX/OpenResty and etcd foundation as Apache APISIX.
Frequently asked questions
Related comparisons
Apache APISIX vs Envoy · Apache APISIX vs AWS API Gateway · All gateway comparisons
Ready to get started?
For more information about full API lifecycle management, please contact us to Meet with our API Experts.
