All Products
Search
Document Center

Microservices Engine:Comparison of Nginx Ingress and MSE Ingress gateways

Last Updated:Mar 11, 2026

Kubernetes clusters require an ingress gateway to route external traffic to backend services, but choosing the wrong gateway can lead to performance bottlenecks, operational burden, or security gaps. In Container Service for Kubernetes (ACK) managed clusters, ACK Serverless clusters, and Container Compute Service (ACS) clusters, you can use either NGINX Ingress gateways or Microservices Engine (MSE) Ingress gateways. This comparison covers architecture, performance, routing, security, observability, and other dimensions to help you select the right gateway.

Quick decision guide

Choose NGINX Ingress if:

  • Your traffic volume is low and your security, scalability, and stability requirements are low.

  • You need a highly customizable, self-managed gateway.

Choose MSE Ingress if:

  • Your traffic volume is high and you need strong security, scalability, and stability guarantees.

  • You want fully managed operations with no gateway maintenance overhead.

  • You need multiple service discovery methods (Kubernetes, Nacos, Eureka, DNS, fixed IP addresses).

  • You need integrated Web Application Firewall (WAF) protection and advanced authentication (JWT, OIDC, IDaaS, custom authentication).

  • You need end-to-end observability with access logs, distributed tracing, metrics, and alerts.

Architecture

AspectNGINX IngressMSE Ingress
EngineNGINX with Lua plug-inIstiod + Envoy
TenancySelf-managed componentsDedicated instances per user
Resource managementManual replica count and resource limit configurationFully managed
Traffic forwarding--Directly connected to pod IP addresses for request forwarding

Performance

MetricNGINX IngressMSE Ingress
OptimizationManual tuning requiredOptimized at the OS level with internal improvements
HTTPS accelerationNot available~80% HTTPS performance improvement with hardware acceleration
Throughput vs. open source NGINXBaseline~40% higher based on OS and internal optimization
TPS at 30%--40% CPU utilizationBaseline~90% higher than open source NGINX Ingress
Plug-in impactHeavy Lua script usage significantly degrades performance--

Routing and load balancing

CapabilityNGINX IngressMSE Ingress
Content-based routingYesYes
HTTP header rewritesYesYes
Redirects and URL rewritesYesYes
ThrottlingYesYes
Cross-origin resource sharing (CORS)--Yes
Timeouts and retries--Yes
Load balancing algorithms--Round-robin, random, least-requests, consistent hashing
Traffic warm-up (prefetching)NoYes. Traffic to new backend pods ramps up gradually over a configurable time window.

Configuration updates

BehaviorNGINX IngressMSE Ingress
Configuration changesRolling updates via Lua plug-in (except certificates)Rolling updates supported
Certificate updatesRequires reload, which disrupts persistent connectionsRolling updates supported
Plug-in updatesRequires reloadRolling updates for WebAssembly plug-ins
Update mechanismReload-basedList-Watch for near-real-time configuration propagation

Service discovery and governance

CapabilityNGINX IngressMSE Ingress
Service discoveryKubernetes onlyKubernetes, Nacos, Eureka, DNS, fixed IP addresses
Canary releasesYesYes
Tag-based routingNoYes
Traffic distribution by percentageNoYes (canary release, A/B test, blue-green deployment)
ThrottlingYesYes
Circuit breaking and degradationNoYes, integrated with Application High Availability Service (AHAS)
Service mockingNoYes

Security

CapabilityNGINX IngressMSE Ingress
HTTPSYesYes, integrated with Certificate Management Service
WAF protectionNoYes, integrated with Alibaba Cloud WAF
IP-based access control (blacklists and whitelists)YesYes

Authentication

MethodNGINX IngressMSE Ingress
BasicAuthYesYes
OAuthYesYes
JWTNoYes
OIDCNoYes
IDaaSNoYes
Custom authenticationNoYes

Operations and maintenance

AspectNGINX IngressMSE Ingress
Management modelSelf-managedFully managed
ScalingHorizontal Pod Autoscaler (HPA)HPA (under development)
Specifications tuningManual configuration required--

Protocols and conversion

CapabilityNGINX IngressMSE Ingress
HTTPYesYes
HTTPSYesYes
HTTP-to-Dubbo conversionNoYes
HTTPS-to-Dubbo conversionNoYes

Ingress and cloud-native integration

CapabilityNGINX IngressMSE Ingress
Kubernetes Ingress resourcesYesYes
NGINX Ingress annotation conversionN/AAutomatic conversion supported. For details, see Annotations supported by MSE Ingress gateways.
Supported cluster typesACK managed clusters, ACK Serverless clusters, ACS clustersACK managed clusters, ACK Serverless clusters, ACS clusters

Extensibility

ApproachNGINX IngressMSE Ingress
Plug-in languageLuaWebAssembly (supports multiple programming languages)
Lua plug-inYesUnder development

Observability

CapabilityNGINX IngressMSE Ingress
Access logsYesYes, integrated with Simple Log Service (SLS) and Application Real-Time Monitoring Service (ARMS)
Metrics and alertsPrometheusIntegrated with ARMS and Managed Service for Prometheus
Distributed tracingNoYes, integrated with Managed Service for OpenTelemetry

Ecosystem

IntegrationNGINX IngressMSE Ingress
Service meshNginx Service MeshIstio service mesh (de facto standard)

Typical use cases

NGINX Ingress gateways are built on open source NGINX and serve as the default Kubernetes Ingress gateway. They are best suited for:

  • Workloads that require highly customized gateway configurations.

  • Environments with lower traffic volumes where self-managed operations are acceptable.

  • Teams with existing NGINX expertise who want direct control over the gateway.

  • Cloud-native applications that use canary releases or blue-green deployments.

MSE Ingress gateways are built on cloud-native gateways from MSE and combine traffic gateway, microservices gateway, and security gateway capabilities into a single managed platform. They are best suited for:

  • High-traffic production environments that require strong security, scalability, and stability.

  • Architectures that use multiple service discovery methods or need protocol conversion (HTTP/HTTPS to Dubbo).

  • North-south traffic scenarios with backend service discovery through Nacos, Kubernetes, DNS, or fixed IP addresses.

  • East-west traffic scenarios that require hybrid cloud, multi-data-center, or multi-service-domain interoperability with seamless service mesh integration.