Nginx Ingress and APIG Ingress solve the same core problem — routing external HTTP/HTTPS traffic into a Kubernetes cluster — but with different architectural trade-offs. This page compares them across product positioning, architecture, performance, routing, security, observability, and operations to help you choose the right gateway.
When to choose each gateway
Choose Nginx Ingress if:
-
Traffic volumes are moderate and gateway resource usage is not a bottleneck
-
Your team has the capacity to maintain self-managed components (replica tuning, plugin updates, certificate reload management)
-
You need deep customization through Lua scripting
-
Your routing requirements are covered by standard Kubernetes Ingress annotations
-
Your workloads run in ACK managed clusters, ACK Serverless clusters, or ACS clusters
Choose APIG Ingress if:
-
High traffic volumes demand consistent throughput without manual performance tuning
-
You want a fully managed gateway with no operational overhead for scaling or upgrades
-
You need built-in Web Application Firewall (WAF) protection, JSON Web Token (JWT)/OpenID Connect (OIDC) authentication, or circuit breaking without additional integrations
-
Your backend services are registered in Nacos, Eureka, or DNS-based registries (not only Kubernetes)
-
You handle north-south and east-west traffic in hybrid cloud or multi-datacenter environments
-
You are already running Nginx Ingress and want a migration path — APIG Ingress supports automatic conversion of Nginx Ingress annotations
Feature comparison
The following table compares Nginx Ingress and APIG Ingress across key dimensions.
| Dimension | Nginx Ingress | APIG Ingress |
|---|---|---|
| Product positioning | Layer 7 gateway with advanced routing. Self-managed component with full customization control. | Three-in-one gateway combining traffic gateway, microservice gateway, and security gateway. Supports multiple service discovery patterns and various grayscale release policies, including canary, A/B testing, blue-green, and custom traffic distribution ratios. Deeply integrated with containers and directly connects to backend pod IPs. |
| Service architecture | Nginx + Lua plugin extensions. Replica count and resource limits are configured manually. | Istiod + Envoy. Each user gets a dedicated instance. |
| Performance | Depends on manual tuning. Lua scripts support hot updates for some configuration changes, but heavy use of Lua degrades throughput. | With hardware acceleration enabled, HTTPS throughput increases by ~80%. Combined with OS and internal tuning, overall performance is ~40% higher than self-built gateways. Compared to open source Nginx Ingress, Transaction Per Second (TPS) is ~90% higher at 30%–40% CPU utilization. |
| Basic routing | Content-based routing; HTTP header modification, redirects, rewrites, and rate limiting. | Content-based routing; HTTP header modification, redirects, rewrites, rate limiting, cross-origin access, timeout, and retry. Supports standard load balancing algorithms (round-robin, random, least connections, consistent hashing) plus prefetch, which gradually increases traffic to a backend instance over a configurable time window. |
| O&M | User-maintained. Scale with Horizontal Pod Autoscaler (HPA). Requires proactive specification tuning. | Fully managed. Scale with HPA. No manual specification tuning. |
| Cloud-native integration | Works with ACK managed clusters, ACK Serverless clusters, and ACS clusters. | Works with ACK managed clusters. Supports seamless conversion of Nginx Ingress annotations. |
| Typical use cases | Scenarios requiring highly customized gateways. Canary and blue-green deployments for cloud-native applications. | North-south traffic: backend service discovery supports Nacos, Kubernetes, DNS, and fixed IPs. East-west traffic: internal communication across hybrid clouds, multiple data centers, and multiple service domains, with seamless integration into service mesh systems. |
| Supported protocols | HTTP, HTTPS | HTTP, HTTPS |
| Protocol transformation | Not supported | HTTP to Dubbo; HTTPS to Dubbo |
| Ingress support | Standard Kubernetes Ingress | Standard Kubernetes Ingress. Supports automatic conversion of Nginx Ingress annotations (see Supported annotations for APIG Ingress). |
| Configuration changes | Certificate changes require a process reload, which disrupts persistent connections. Non-certificate changes use Lua hot updates. Lua plugin changes require a reload. | Hot updates for all configuration changes, including certificates and Wasm plugins. Uses the List-Watch mechanism for near-real-time propagation. |
| Service administration | Service discovery: Kubernetes. Grayscale release: canary deployments. High availability: rate limiting. | Service discovery: Kubernetes, Nacos, Eureka, DNS, and fixed IPs. Grayscale release: canary deployments and tag-based routing. High availability: integrates with Application High Availability Service (AHAS) for rate limiting, circuit breaking, and degradation. Service testing: service mocking. |
| Security | HTTPS; blacklists and whitelists. | HTTPS (integrated with SSL Certificate Service); WAF protection (integrates with Alibaba Cloud Web Application Firewall); blacklists and whitelists; integrates with SSL Certificate Service. |
| Authentication and authorization | BasicAuth; OAuth | BasicAuth; OAuth; JWT; OIDC; IDaaS; custom authentication |
| Extensibility | Lua scripts | Wasm plugins (multi-language support); Lua plugins |
| Observability | Access logs; Prometheus | Access logs (integrates with Simple Log Service (SLS) and Application Real-Time Monitoring Service (ARMS)); metrics (integrates with ARMS Prometheus); tracing (integrates with Tracing Analysis); alerts (integrates with ARMS Prometheus) |
| Ecosystem integration | Nginx Service Mesh | Istio Service Mesh (de facto standard) |