Nginx Ingress and APIG Ingress both route external traffic into Kubernetes clusters, but differ in management model, architecture, and feature depth. Nginx Ingress is self-managed with full customization control, while APIG Ingress is fully managed with built-in security, advanced service discovery, and no operational overhead.
When to choose each gateway
Choose Nginx Ingress if:
Traffic is moderate and the gateway is not a resource bottleneck
Your team can maintain self-managed components: replica tuning, plugin updates, and certificate reloads
You need deep customization through Lua scripting
Standard Kubernetes Ingress annotations cover your routing requirements
Your workloads run in ACK managed clusters, ACK Serverless clusters, or ACS clusters
Choose APIG Ingress if:
High traffic demands consistent throughput without manual tuning
You want a fully managed gateway with no operational overhead for scaling or upgrades
You need built-in Web Application Firewall (WAF), JWT/OIDC authentication, or circuit breaking without extra 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 already run Nginx Ingress and want a migration path — APIG Ingress converts Nginx Ingress annotations automatically
Feature comparison
|
Dimension |
Nginx Ingress |
APIG Ingress |
|
Product positioning |
Layer 7 gateway with advanced routing. Self-managed component with full customization control. |
Unified traffic, microservice, and security gateway. Multiple service discovery patterns and grayscale release strategies: canary, A/B testing, blue-green, and custom traffic ratios. Deeply integrated with containers; connects directly 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 Lua use degrades throughput. |
Hardware acceleration boosts HTTPS throughput by ~80%. With OS and internal tuning, performance is ~40% higher than self-built gateways. Transactions per second (TPS) is ~90% higher than open-source Nginx Ingress 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, CORS, timeout, and retry. Standard load balancing (round-robin, random, least connections, consistent hashing) plus prefetch — gradually ramps traffic to a backend instance over a configurable window. |
|
Operations |
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. Converts Nginx Ingress annotations automatically (Supported annotations for APIG Ingress). |
|
Configuration changes |
Certificate and Lua plugin changes require a process reload, disrupting persistent connections. Other changes use Lua hot updates. |
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 and tag-based routing. High availability: Application High Availability Service (AHAS) integration for rate limiting, circuit breaking, and degradation. Service testing: mocking. |
|
Security |
HTTPS; IP allowlists and blocklists. |
HTTPS (integrated with SSL Certificate Service); WAF protection (integrates with Alibaba Cloud Web Application Firewall); IP allowlists and blocklists; 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 |