F5 NGINX Ingress Controller (Premium Edition)

My main use case for NGINX Ingress Controller is routing external traffic, HTTP or HTTPS into services inside a cluster, basically acting as a single entry point that replaces managing individual load balancer services per app. I also use it for host-based routing, TLS termination, and multi-service orchestration.

A quick specific example of how I used NGINX Ingress Controller for routing or orchestration in a recent project is that I had TLS terminated at the edge for one of my ingress resources, and my services were routed by path, so no separate load balancer per service. That is majorly what I used it for.

Additional use cases for NGINX Ingress Controller include using it for rate limiting via annotations, canary deployments which split traffic between stable and new service versions by weights, WebSocket support, and custom error pages.

NGINX Ingress Controller has positively impacted my organization by achieving cost reduction since we have just one load balancer instead of one per service, which cuts down our cloud spending. It has also enabled faster deployments with centralized security, simplified observability through single metrics endpoints covering all ingress traffic, reduced downtime, and provided developer autonomy, allowing teams to update their own ingress rules without needing infra team involvement.

Regarding numbers on cost savings, I would say that eliminating multiple load balancers has roughly saved us between $150 to $250 per month. For deployment speed, ingress config changes deploy in seconds via GitHub Actions compared to the manual load balancer reconfiguration, which could take 10 to 30 minutes. Also, canary deployments have cut production incidents from bad releases by an estimated 60 to 70 percent compared to full cut-over deploys, and auto renewal for cert management eliminates expiry-related outages entirely, meaning we are not manually renewing certs every 60 to 90 days per domain.

Some of the best features NGINX Ingress Controller offers in my experience are annotation-driven config, which gives fine-grained control without actually touching the NGINX config file directly, TLS termination plus cert-manager integration, path and host-based routing, rate limiting, and connection throttling, as well as canary traffic splitting.

Out of those features, I find myself relying on TLS termination plus cert-manager integration the most because it removes an entire class of operational burden. Certificates renew automatically, so we never chase expiry dates across eight services or more. Every service behind the ingress gets HTTPS without any app-level changes, which is essential since managing certs per service manually does not scale, especially on a multi-service platform.

I think NGINX Ingress Controller could be improved with a better native dashboard, simpler annotation discovery, faster reload times, a built-in canary UI, and better multi-tenant isolation.

Regarding the needed improvements, there is also the hot reloading without connection drops, improved role-based access control granularity, and built-in circuit breaking.

I have been using NGINX Ingress Controller for over two years, getting into three years now.

I dropped two points for the annotation-heavy config approach that does not scale cleanly and the connection drop issue on config reloads.

My advice for others looking into using NGINX Ingress Controller is to start with cert-manager from day one, learn the annotations thoroughly, set resource limits on the controller pod, enable Prometheus metrics immediately, and test config reloads under load.

Regarding NGINX Ingress Controller's governance and security strength, it is solid due to the ModSecurity, WAF integrations, and TLS enforcement providing a solid baseline of security controls. However, there are gaps since there is no built-in secret management, meaning annotation-based config can be modified by anyone with cluster access if role-based access control is not tight. Additionally, the open-source version lacks some security features available in NGINX Plus.

In terms of NGINX Ingress Controller's accuracy and reliability of output, I find it very reliable, as it is battle-tested at scale across thousands of production clusters. Routing decisions are deterministic and rule-based, so accuracy is essentially 100 percent when configured correctly. The main reliability concerns are config reload drops, not routing errors. I would give this review an overall rating of 8.

I use NGINX Ingress Controller mainly for routing purposes inside the cluster. I connected our ALBs and NLBs with NGINX Ingress Controller. From that point onward, I used it for path-based routing. Some of the APIs and some of the UIs and the internal connectivity were hosted by NGINX Ingress Controller.

I think one of the interesting facts about NGINX Ingress Controller is the simplification of routing configuration. The routing configuration is very simple in the case of NGINX Ingress Controller in comparison with other service meshes or other routing tools. I would say that simplification of routing is one of the attractive parts that I find.

A negative point about NGINX Ingress Controller is configurational control over the traffic distribution. When the request comes in, it has given a bit light control over the configuration of how it is supposed to define its rules when it comes to traffic in the case of NGINX Ingress Controller. I think other service meshes, Istio, Envoy, they have it better.

I have been using NGINX Ingress Controller for almost four to five years.

In terms of stability regarding crashing, it used to happen sometimes. NGINX Ingress Controller needs to give more traffic configurational control to the user. If there is a spike, I have seen that the pod sometimes creates a bottleneck, or sometimes it rejects some requests. I have seen some bottleneck issues and some spike issues.

Regarding scalability, I think NGINX Ingress Controller is in the middle. It is not too much good, it is not too much bad. It is in the middle.

The initial deployment of NGINX Ingress Controller was easy. I would not compare it as difficult or medium difficult. It was easy.

Regarding the pricing of NGINX Ingress Controller, I think till now it was free. Nowadays, I think since last March, they have started charging. Till March 2026, I think it was free. Then later on, they told us that they are going to stop the end of life support in March 2026. That is when I started looking out for another controller. I cannot say that I have an opinion on its pricing.

I have done POCs with Istio, Istio ambient mode, then traffic controller, Envoy gateway controller, then Kubernetes's own gateway API controller.

I do not think NGINX Ingress Controller requires that much maintenance. In the case of maintenance, it is one of the best tools I have. With the version it comes with, and even if it does a version upgrade, it comes with very light configurational changes that need to happen. I have had only a few times when I had to really go and manage some annotations and other things. It is really easy maintenance. I would give NGINX Ingress Controller a score of 7.5 on a scale from 1 to 10.

I use NGINX Ingress Controller for reverse proxy, forwarding client requests while placing it in front of my backend servers. This removes my app from direct internet exposure. I also use it for load balancers to distribute incoming traffic across multiple backend instances using various strategies, which improves availability and throughput.

For example, we run multiple backend services in Docker containers, each running on different internal ports. Instead of exposing each service directly, I place NGINX Ingress Controller in front as a reverse proxy. It handles my SSL termination by managing HTTPS at the NGINX layer using a Let's Encrypt certificate, so the backend containers only speak plain HTTP internally. This simplified the app code and centralized certificate management in one place. It also helps with routing by path, allowing a single domain to route to different services based on path prefix. Without NGINX Ingress Controller, I would have had to separate the domains or expose my ports to the outside. Additionally, it has helped with stability under load.

Since I work with Kubernetes, NGINX Ingress Controller is a natural extension of what the standalone version does. Instead of writing the config manually, I define Ingress resources in YAML files, and the controller reconciles them into NGINX config automatically. The same concepts apply: reverse proxying, path-based routing, and SSL termination. However, it is now managed declaratively and integrates with Kubernetes' native tooling.

I remember one instance when we had a Python Flask inference endpoint running behind NGINX Ingress Controller on Kubernetes. The service processed documents and returned structured data, with some requests taking thirty to sixty seconds depending on document size. The problem we faced was users were intermittently getting gateway timeout errors. The Flask service logs showed the request completing successfully, but clients were still getting the error before the response came back. We diagnosed it by pulling the NGINX Ingress Prometheus metrics into Grafana and filtering by upstream response time per Ingress. This showed clearly that requests beyond sixty seconds were being dropped. The default proxy read timeout on NGINX Ingress Controller is sixty seconds, and nobody had changed it. The app was fine, but NGINX was cutting the connection first. The fix was one annotation on the Ingress resource to increase the timeout. We did not change anything on the app, no redeployment, and no global config map modifications. The timeout was scoped only to that specific Ingress. This resulted in zero timeouts from that endpoint. Since the fix was annotation-based, it did not affect any other services' timeout behavior in the cluster.

The path and host-based routing that NGINX Ingress Controller offers allows me to route traffic to different backend services based on URL path or hostname. There is SSL/TLS termination, which handles HTTPS at the Ingress layer. I pair it with cert-manager and Let's Encrypt for fully automated certificate provisioning and renewal with zero manual certificate management. There are annotations for fine-grained control, which allows me to customize behavior per Ingress without touching global config. Additionally, there is rate limiting, authentication, WebSocket support, and observability. NGINX Ingress Controller exposes Prometheus metrics out of the box.

In many ways, NGINX Ingress Controller has provided cost reduction by eliminating our per-service load balancers. Instead of each service having their own load balancer, we consolidated them behind NGINX Ingress Controller. There are faster deployments, as routing changes previously required infrastructure-level changes, updating DNS, and provisioning new load balancers. With NGINX Ingress Controller, we can apply all these changes in YAML files and reduce the deployment time drastically. There is centralized SSL management, which helped us centralize our certificate provisioning and renewal. Additionally, there is improved reliability with better observability across our services.

There is annotation overload. We could move toward a better API annotation work, though currently the annotations are stringy-typed YAML with no validation, making it easy to create typos. Better error feedback is needed, as when an annotation is wrong or unsupported, the controller often ignores it with no clear error surfaced back to the engineer. Observability depth should be increased. Performance at very high scale should be improved. At extreme scale with hundreds of Ingress resources, the controller can experience reload latency.

Three specific things stand out. The reload problem is architectural, not fixable with a config tweak. The annotation model has no safety net, so if I type an annotation incorrectly, the controller silently ignores it. Configuration snippets are effectively disabled in serious multi-tenant clusters, as those are among the first things security-conscious platform teams turn off.

I have been using NGINX Ingress Controller for over a year.

NGINX Ingress Controller is stable.

NGINX Ingress Controller scales well in horizontal pod autoscaling. The controller itself scales horizontally, and you can run multiple replicas behind the cloud load balancer. There is solid connection handling.

I have had a pretty good experience with customer service. They respond when I reach out and help resolve whatever support issues we have.

I evaluated three main alternatives before settling on NGINX Ingress Controller: Traefik Ingress Controller, the AWS ELB Ingress Controller, and Istio Ingress Gateway.

The initial setup was very fair with no major complications and no overcharging.

The implementation was handled through a vendor relationship only.

For direct cost savings, after consolidating our services behind NGINX Ingress Controller, we were previously spending approximately twelve hundred dollars per year but have significantly reduced those costs.

Each service was previously using its own cloud load balancer. After consolidating every service behind NGINX Ingress Controller, this actually cut down our costs significantly.

I would give NGINX Ingress Controller a rating of six. I recommend starting with the community version. My overall review rating for this product is eight.

NGINX Ingress Controller is my primary solution for managing traffic requests to my Kubernetes workloads. Most of my projects are based on containerization, meaning the applications are completely built on Kubernetes and require traffic routing from the external world to my Kubernetes infrastructure.

I worked on a project with more than 200 microservices where we needed a single entry point solution into the Kubernetes cluster. I deployed one NGINX Ingress Controller and configured HTTP routes for multiple domains through which clients can browse the application. We also implemented some internal private NGINX Ingress Controller instances where internal applications communicate with each other based on domain names. NGINX Ingress Controller allowed us to set up path-based routing and traffic splitting.

In another interesting use case, we had multiple GCP projects and used NGINX Ingress Controller as a single source of truth. We deployed a cluster in one common project with NGINX Ingress Controller and navigated requests to other Kubernetes clusters. All Kubernetes clusters were connected through a mesh called Anthos.

NGINX Ingress Controller offers several valuable features. Unlike other native ingress solutions, we get only one load balancer in the background, which means no matter how many ingresses we create, we receive only one IP address. This significantly saves costs. Additionally, we get all the native NGINX features in NGINX Ingress Controller, including proxy functionality, upstream configuration, rate limiting, header passing, and header control capabilities. These are features that other ingress solutions do not provide to the same extent.

The cost-saving feature of NGINX Ingress Controller is excellent, and the rate-limiting and header control features work very well together. I use these three combinations frequently as they help me control costs and manage headers. Rate limiting also helps secure NGINX Ingress Controller by preventing DDoS and phishing attacks.

Cost was significantly reduced compared to launching another load balancer. We configured NGINX Ingress Controller to work as a gateway. When something breaks, we have a single point of truth for troubleshooting instead of investigating different load balancer stacks. These improvements helped my team troubleshoot issues more efficiently. The time to solve an issue was reduced from thirty to forty minutes to ten to twelve minutes. NGINX Ingress Controller is lightweight, which enhances performance and reduces network request latency.

Some ingress controllers are becoming outdated, and if the features that gateways offer nowadays could be integrated into NGINX Ingress Controller, it would be greatly beneficial.

The main feature I want to see included is the ability to reduce namespace specifications. Currently, gateways are not namespace-specific in Kubernetes, whereas ingresses are namespace-specific. If these namespace specifications could be reduced, it would be a great addition.

I have been using NGINX Ingress Controller for quite a long time because it is an ingress-based solution that works on top of Kubernetes.

NGINX Ingress Controller is stable in my experience. I have not faced many issues with NGINX Ingress Controller so far.

NGINX Ingress Controller is scalable because it is deployed in the form of pods. When additional traffic arrives and NGINX Ingress Controller cannot handle it, it scales based on CPU and memory percentage.

I have not experienced significant issues requiring customer service. When issues do arise, we go through the Marketplace and receive resolutions via email. Since we have not faced substantial issues, the customer service experience has been good.

We were using native cloud solutions and ingresses. We also used other ingresses such as Kong. We compared other ingress solutions in the market including Kong, Apigee, and cloud-native ingresses.

NGINX Ingress Controller is a truly good tool that has proven its capability in the market. I advise others who are looking for solutions to seriously consider NGINX Ingress Controller.

Concerning AI governance and security, there should be proper guardrails around AI capabilities so that I know what components NGINX Ingress Controller is accessing and what things are involved. I am more concerned about the guardrails surrounding NGINX AI Controller capabilities.

Those AI capabilities are reliable because they are AI-based and would be faster than humans. However, I am more concerned about accuracy because all AI capabilities, including NGINX AI capabilities, are based on data. I am aligned with the idea that these are reliable, but sometimes they may produce false positives. This is the main thing that concerns me.

I gave NGINX Ingress Controller a rating of 8 out of 10.

I have used NGINX Ingress Controller in a couple of projects as a controller that is supposed to route traffic to Kubernetes clusters. One of the main reasons I chose it is because it is a free product with a lot of documentation that is very easy to set up. It has a great community around it to help with answering questions and providing feedback on architecture.

In one of the projects where I used NGINX Ingress Controller to route traffic in Kubernetes clusters, we have a cluster running in Azure AKS with several services deployed as pods on a multi-node cluster. An F5 NGINX controller routes the traffic that comes through the load balancer, the Azure Standard Load Balancer, and then routes it using the ingress controller to the different pods. There is a lot of configuration involved, including whitelisting specific IP ranges and headers in order to add an additional security layer to the traffic routing mechanism.

NGINX Ingress Controller offers a lot of different configurations, making it very flexible in terms of how you can configure the routing and traffic steering. It supports all kinds of header-based routing, regex capabilities, canary releases, and TLS terminations. I have used it a few times as a reverse proxy as well, and many security controls can be configured.

Out of all those features, including flexible configurations, header-based routing, regex, TLS termination, and security controls, I find myself using the routing and security controls the most.

The obvious positive impact of NGINX Ingress Controller is the cost saving. I have seen those savings in terms of cost compared to other enterprise products which come with a cost to implement, maintain, and support.

I do not see anything that frustrates me about NGINX Ingress Controller or that I wish was different. There are a few gimmicks that need learning, such as annotations and precedence over annotations and config maps that could be a bit clearer at times, but other than that, I do not see a lot of other things that would annoy me in my work with NGINX Ingress Controller.

I have used NGINX Ingress Controller for approximately four to five years, give or take, in different projects.

NGINX Ingress Controller is stable.

NGINX Ingress Controller scales very effectively because it can be deployed on a cluster, so it performs pretty much the same as anything running on Kubernetes.

I have not used the customer support for NGINX Ingress Controller.

I have used different solutions before, but I have not switched between them. Those were different projects with different requirements.

NGINX Ingress Controller is very easy to set up, easy to deploy, and easy to maintain.

I did not purchase NGINX Ingress Controller through the Azure marketplace.

The only measurable thing I can say about return on investment is money saved in comparison to other commercial products.

I do not have any experience with pricing, setup cost, and licensing because I have used the open-source version.

I have evaluated other options before choosing NGINX Ingress Controller, including Traffic and Kong.

Regarding NGINX Ingress Controller's AI capabilities, I do not have any experience with its governance and security. I have not used NGINX Ingress Controller's AI capabilities, so I cannot speak to the accuracy and reliability of its output. My overall review rating for NGINX Ingress Controller is 9.