External reviews are not included in the AWS star rating for the product.
NGINX Ingress Controller is primarily used for routing in my team's Kubernetes cluster where we run multiple microservices. We deployed NGINX Ingress Controller on a cluster with around 20 microservices and different endpoints that we wanted to route requests to, so we specified all the paths we wanted to route to in the YAML files.
Apart from my current projects, I have also used NGINX Ingress Controller in some open-source deployments where I needed to route requests.
The overall time and manual work have been reduced since we started using NGINX Ingress Controller. Earlier we used some other routing tools, but NGINX fits quite well in our Kubernetes cluster setup, making it easy to deploy and get running. NGINX Ingress Controller has helped my team reduce workload, particularly in the time saved.
The best part of NGINX Ingress Controller is how it works, particularly the annotation feature, which allows us to specify all our details through annotations, making it quite easy to integrate with our system.
The rewrite path is one of the annotations provided by NGINX Ingress Controller, which lets us route requests to a different path based on specified weights. For example, we can send 50% of the requests to one endpoint and 50% to another.
The annotation part of NGINX Ingress Controller is good, but it can be tedious when there are many features to specify in the annotation section, which sometimes gets messy and could be improved. However, there is a new project called Gateway APIs that has solved that problem.
The annotation part itself could be improved, as overall it was good but sometimes having everything in the annotation section can be a bit cumbersome.
Overall NGINX Ingress Controller is a good tool to use, but the main drawback is the annotation part, as managing many paths and features can get quite tedious and complicated.
I have been using NGINX Ingress Controller for more than three years now across my different projects.
NGINX Ingress Controller is stable in my experience.
The scalability of NGINX Ingress Controller is overall good for our needs.
The customer support for NGINX Ingress Controller is good. I would rate the customer support for NGINX Ingress Controller around a 7 or 8.
We were earlier using HAProxy to route requests, but we found it quite confusing and complicated, which is why we switched to NGINX Ingress Controller.
The main advantage of NGINX Ingress Controller is the deployment and ease of use. The way we deploy NGINX Ingress Controller is quite easy, as we just need the Helm install command or we can directly apply the YAMLs, which makes it unique.
We have seen a return on investment from using NGINX Ingress Controller, specifically in needing fewer people.
The pricing for NGINX Ingress Controller is overall acceptable, and I would not say it is great. The setup cost was also acceptable, and the licensing was straightforward.
NGINX Ingress Controller's governance and security features of AI capabilities are good, with all the basic guardrails available.
The accuracy and reliability of NGINX Ingress Controller's AI capabilities are not 100%. Sometimes it hallucinates and requires more prompting to get what I want exactly, but overall it is a good feature that still needs improvements.
NGINX Ingress Controller is a good tool to use. If you have a Kubernetes cluster, then it is easy to deploy and use, though you might face issues with the annotation part. I would give this review a rating of 9.
My main use case for NGINX Ingress Controller is load balancing as well as an API Gateway to perform reverse proxy for our backend applications.
A specific example of how I use it as a load balancer and API Gateway in my environment is that we have our own DNS resolver, which we use ACME with as a free DNS resolving service. We bind it to the Ingress Controller and add our own rules and hosts to specific Ingress resources to bypass and forward all requests to the specific backends. This helps balance the load by making replicas on-demand.
Regarding my main use case, we implement custom configurations as well as custom port mappings and annotations. We use specific server snippets and follow security best practices to drop SSL terminations at the Ingress level instead of in the backend.
The best features NGINX Ingress Controller offers for my team include all of the commonly available features in the community version. The community version is now obsolete, and Kubernetes wants to move users to something else like the API Gateway feature, but we are still using NGINX Ingress Controller. The features are excellent.
While the features are exceptional, ease of use is not as straightforward because certain configurations probably require the paid version. We are using the free version, and in some cases, features like DNS Route 53 are not available in the free version, so we have to address that use case with alternative solutions.
NGINX Ingress Controller has positively impacted my organization by allowing us to handle many requests from different applications and customers, serving as the frontier of all our backend applications. It performs very well and is both scalable and lightweight. It integrates easily with Kubernetes, so it can be configured and used effectively.
NGINX Ingress Controller can be improved with better documentation. Good documentation in the Bitnami Helm chart would have made implementation easier for us, as we had to search for many things back and forth. Most of the information we found was confused with the community version of NGINX Controller, which created confusion initially. I would appreciate an AI-based solution so that we could easily find the actual use case relevant to our situation.
I have been using NGINX Ingress Controller for five years.
In my experience, NGINX Ingress Controller is stable.
Scalability and lightweight design have helped my team greatly. We recently had issues when multiple backend applications were accessed simultaneously from the same client browser, which caused slowdowns after a certain number of requests, around four or five of the same backend application or different backend applications from the same client. We configured this using a custom annotation configuration with HTTP/2, which solved the overall slow performance easily. NGINX Ingress Controller scales well and is very lightweight. The product manager appreciated the solution because it requires just a simple configuration in the Ingress resource, so no backend application changes are needed. NGINX Ingress Controller scales effectively to support whole load balancing scenarios, routing everything to the specific backend services.
I have seen a return on investment from using NGINX Ingress Controller, as I need fewer employees. I do not have to maintain a large DevOps team for this purpose. Any developer can set up and configure NGINX Ingress Controller if they have adequate knowledge on how to set up an Ingress Controller. It saves time because it is easier to set up, though I am uncertain how it translates to monetary savings.
My advice to others looking into using NGINX Ingress Controller is to review the documentation first and ensure it serves your purpose. On a scale of one to ten, I rate NGINX Ingress Controller overall as a nine. I chose nine because I do not know the complete use case of the product, so I do not give it a perfect ten. That is my opinion, and while I have encountered some problems and hurdles, I have overcome all of them. It has worked very well for my purposes.
My main use case for NGINX Ingress Controller has been in Kubernetes-based consulting work, especially when a team needs a controlled and observable entry point for application traffic.
In a typical setup, a user or client application sends a request to a public endpoint. That request first reaches an external load balancer, depending on the environment — for example, a cloud load balancer, MetalLB in a lab or bare-metal setup, or another external load-balancing layer. From there, the traffic is forwarded to the NGINX Ingress Controller running inside the Kubernetes cluster.
That is where NGINX Ingress Controller becomes important. It evaluates the Kubernetes Ingress rules, applies routing decisions based on hostnames and paths, and forwards the request to the right Kubernetes Service. The Service then sends the traffic to the correct backend pods, such as web pods, API pods, or authentication pods.
What I value most is that NGINX Ingress Controller is not just a way to expose services. It gives teams a practical control point for TLS termination, HTTP routing, rewrites, annotations, timeouts, security headers, rate limits, and observability. But it needs to be operated carefully. In production, the biggest risk is usually not NGINX itself, but weak configuration, missing monitoring, unclear ownership, or unsafe upgrades.
NGINX Ingress Controller helped by giving teams a predictable entry point for Kubernetes workloads. Instead of exposing services one by one, traffic could be routed through a controlled layer for TLS, host/path routing, rewrites, headers, logs, and metrics. The main benefit was operational clarity: better visibility, safer exposure of services, and fewer ad hoc networking decisions.
The best features are Kubernetes-native routing, TLS termination, flexible host/path rules, annotations, ConfigMaps, and observability when metrics and logs are configured well. In practice, it turns ingress into a clear control point for HTTP/HTTPS traffic. The trade-off is governance: annotations, rate limits, certificates, and upgrades need discipline.
I would improve diagnostics and guardrails. A built-in support bundle command that safely collects controller config, events, logs, versions, certificate status, and redacted error data would help teams troubleshoot faster. I would also like stronger policy controls around risky annotations, rate limits, TLS expiry, and upgrade validation. It should help security, but not pretend to replace Zero Trust or vulnerability management.
I have been using NGINX Ingress Controller for more than two years.
I consider it stable when deployed with disciplined configuration. In my experience, the controller itself is not usually the weak point. Problems tend to come from unclear annotations, certificate issues, poor observability, under-sized resources, or upgrades without staging. With good operational practices, it is reliable.
Scalability is strong because it fits naturally into Kubernetes. You can run multiple controller replicas, use resource requests/limits, autoscaling, and a load balancer in front of it. The important point is to test the whole path: controller capacity, backend services, TLS, rate limits, observability, and failure behavior under load.
My experience with support was mostly community/self-managed. In the environments I worked with, the client did not use NGINX Plus or premium support, so issues were handled through internal expertise, documentation, and consulting help when needed. For mission-critical production use, I would consider paid support or a supported controller path.
Yes. Before using NGINX Ingress Controller, I worked with more traditional network controls such as Layer 3 firewalls and manual routing rules. They were useful, but not enough for cloud-native workloads because Kubernetes needs application-aware routing by host, path, TLS, and service. That gap pushed me toward an ingress controller.
The initial setup is usually straightforward for a basic lab or small environment, but production setup is more complex. Installing the controller is not the hard part. The real work is DNS, TLS, load balancer integration, annotations, observability, resource sizing, security headers, staging, and upgrade/rollback discipline.
In the implementations I worked with, I did not rely on a dedicated integrator or reseller. The solution was deployed as part of the Kubernetes environment, and in one context it was obtained through AWS Marketplace. Most of the value came from internal/consulting implementation discipline rather than from a third-party integrator.
Yes. The ROI comes from reducing networking complexity and improving the safety of exposing Kubernetes services. Instead of handling every service separately, teams get a consistent ingress layer for TLS, routing, headers, logs, and metrics. The value is strongest when it prevents downtime, misrouting, expired certificates, or insecure exposure.
My experience was positive because the implementation I worked with was deployed as part of the Kubernetes stack, without premium NGINX support. That made the initial cost low. The real cost is operational: proper configuration, monitoring, certificate management, testing, upgrades, and people who understand Kubernetes ingress behavior.
I considered lower-level approaches such as iptables and traditional firewall/load-balancer rules. They can work, but they become hard to maintain as the number of services grows. NGINX Ingress Controller is easier to operate in Kubernetes because routing lives closer to the application model. The trade-off is that annotations and controller configuration must be governed carefully.
I would rate it 9/10 when it is operated intentionally. My advice is not to treat it as just a YAML shortcut. Use it with clear ownership, staging, controlled annotations, TLS monitoring, logs, metrics, resource limits, and rollback plans. For new designs or long-term roadmaps, also evaluate Gateway API or a supported controller path.
NGINX Ingress Controller serves our organization primarily for routing, SSL/TLS termination, and load balancing.
A specific example of how I used NGINX Ingress Controller for routing is that we define the paths and the applications inside the NGINX.conf. The traffic routes to the services, and we set up the load balancing at their own configurations level. Apart from that, we see limitations in NGINX Ingress Controller, as we have multiple services. We need to define the configurations in the annotation section, which causes a mess. Regarding SSL/TLS termination, since the traffic comes from outside to inside, the load balancer reads it out and redirects it to NGINX. We terminate that traffic at the NGINX configuration and then redirect the traffic to the services and ports without SSL/TLS. We used it for a long time before we shifted towards ALB for the last six months.
In my use case with NGINX Ingress Controller, when we have multiple services, it becomes messy and overburdened to add the annotations to define the policy and the annotations of each service, making it a bit complex. It is not straightforward. NGINX documentation is friendly and very handy, but with a large cluster, as we have a company running around 70 plus services, it is very difficult for us to manage these things.
NGINX Ingress Controller offers several best features, including SSL/TLS and flexible routing, which are the most powerful features. In the Ingress we define path-based routing, and we can define host-based routing; in NGINX, we can also define path-based routing and redirect to service level. The same applies to host-based routing in NGINX. The canary deployments feature allows us to shift a specific amount or percentage toward the new version when a new version is released. These are the very best features that I value in NGINX Ingress Controller.
My experience using canary deployments with NGINX Ingress Controller worked really well, by simply adding canary annotations in the NGINX sections, such as nginx.ingress.kubernetes.io/canary. When we define those annotations in the NGINX configurations, it works well. By adding those, we are able to route a specific percentage of traffic toward the new versions while keeping the remaining percentage on the stable version. This gives us confidence to release the new version without risking the entire user base. The setup is straightforward, though we had to manually monitor the canary traffic since there are no built-in analytics.
NGINX Ingress Controller has positively impacted our organization by efficiently routing the traffic. Previously, we were planning to move toward Traefik, but we see that NGINX is a widely used open-source controller that is easy to deploy in Kubernetes. NGINX documentation is very friendly, making traffic management easy. Managing load balancing configurations does not require significant effort, and deployments are smoother and faster. Managing SSL certificates is also simple. I think it has significantly impacted our organization.
NGINX Ingress Controller can be improved in multiple ways according to my suggestions. First, it takes time when we have many services, making routing complex. It is very difficult to manage the configurations using annotations, as we need to define the annotations of each service separately. A small mistake can break the whole routing policies and structure, making it challenging to debug deployments at large scale, which takes time. I also suggest integrating with Prometheus and Grafana for better visibility into traffic and performance. Overall, pairing NGINX with proper monitoring and GitOps practices makes it much more powerful and manageable.
From a security perspective, we can implement a WAF. That might work to tune the processes. For automation, adopting GitOps strategies instead of manual configurations can mitigate risks. These are improvements that can be added.
In my experience, NGINX Ingress Controller is very reliable and stable. It is very handy during our tenure with NGINX Ingress Controller, and it manages things easily. However, as I mentioned, with a very large cluster, it is challenging to spend time on adding and managing configurations. These are what I suggest could be improved in NGINX Ingress Controller, especially considering it is deprecated in March 2026.
I have been using NGINX Ingress Controller since I started my working profession when I used Ingress Controller in a Texan company, and then in this company, we are using Kubernetes. We deploy our applications on Kubernetes, and at that time we were using Ingress Controller for a long time. Then we decided that we should go with the ALB because we heard news that NGINX Ingress Controller is now deprecated and is going to be deprecated. We used it for one to two years.
NGINX Ingress Controller scalability is excellent. It is highly available and scalable, designed to manage high traffic in Kubernetes. The features include horizontal scaling, so we can scale the controllers by increasing the number of replicas in our deployments. It handles traffic effectively. Since my organization has a large cluster, we utilized this feature. The optimization is good, with a build on NGINX web binaries leveraging an asynchronous event-driven architecture that handles thousands of concurrent connections. The load balancing algorithm is supportive, with options such as round robin and least connections to distribute incoming traffic effectively across backend services.
Regarding customer support for NGINX Ingress Controller, I do not think we had a chance to sync with them. Given its high performance and dynamic reconfigurations, we handle it by our own expertise. We are using the community edition, which is open source, so support is primarily self-service via GitHub issues, Stack Overflow, or the Kubernetes Slack community. We did not get an opportunity to connect with customer support.
From my experience, if someone is a startup and does not want to spend money, I definitely recommend NGINX as a best option. For medium-tier companies also planning to implement an ingress controller, I think NGINX is the best for that. For enterprises seeking a cost-effective solution, NGINX is excellent in that case. The configurations, routing policies, and load balancing management are straightforward, so I highly recommend using NGINX. Additionally, since it has more features, we can implement management tools that do not require manually managing DNS records or SSL certificates. Fine-tuning performance is very good, as NGINX is fast, and the keep-alive feature reduces the overhead of TCP and TLS handshakes. Always set CPU and memory requests for your ingress to reduce throttling or OOM kills during traffic spikes. These are the recommendations I have.
It has been a great experience with NGINX Ingress Controller, and I am definitely looking forward to its return with new features and possibly a new name. We will certainly work with them. I would rate my overall experience with this product as an 8 out of 10.
Our main use case for NGINX Ingress Controller is that we are using it in our EKS and our open source Kubernetes as a controller where it handles our traffic.
A specific example of how we use NGINX Ingress Controller to handle our traffic is that we are configuring the Kubernetes cluster as a private endpoint only, so it will not be accessible through the internet for anyone. We are securing it through a private endpoint only, so we are using NGINX Ingress Controller for handling the traffic. We are configuring NGINX Ingress Controller as pods, and then we are configuring the Ingress rules for that to serve which traffic is coming from the load balancer and to where the traffic will be routed. We are configuring the Ingress rules based on the rules, and it will route to the different services, and from the services, it will route to the different pods and deployments. Using that, we will configure the SSL certificate for the security, and in NGINX Ingress Controller only, it will handle the certificate termination. SSL termination will happen within the controller. It is very reliable for us.
The best features NGINX Ingress Controller offers include SSL termination, where it handles the certificate terminations, and if I had to pick a favorite feature, that would be it.
NGINX Ingress Controller has positively impacted our organization by improving security when it comes to the certificate. As I mentioned, SSL termination is one of the points where it improves. When it comes to handling the traffic, where we are configuring the Ingress rules, we can say that it is very highly improved for us. Even though the traffic is very high, it will be handled very well, routing the traffic based on the Ingress rules to the particular service and to the particular pod.
When it comes to how NGINX Ingress Controller can be improved, I think we can add documentation as one of the points. We can improve it so that everyone can directly refer to the particular document in a precise way, and we will be getting very specific information. When we have any specific issues, it will be much easier for us to troubleshoot things. Documentation is one of the points, and everything is so far good for me.
We are using NGINX Ingress Controller for the past two to three years.
NGINX Ingress Controller is stable and has been reliable for me over time.
NGINX Ingress Controller's scalability is good and can handle increased load easily.
The customer support for NGINX Ingress Controller is good; I have reached them a few times, and it was good.
I did not evaluate other options before choosing NGINX Ingress Controller.
The advice I would give to others looking into using NGINX Ingress Controller is that we are using this for the past three to four years, and it is very reliable for us and it can handle the traffic based on our load as well. So I can suggest it to them when they are starting with new clusters and thinking to opt for any controllers for their cluster. I can directly suggest it. I would rate this product an 8 out of 10.
My main use case for NGINX Ingress Controller is that I commonly use it as a reverse proxy.
I have used NGINX Ingress Controller for SAP API calls, so whenever I am using these API calls on my frontend application, I don't want to expose the SAP server details. Therefore, I normally ingress it through NGINX Ingress Controller, mapping all these APIs to the SAP APIs, and from the frontend, I have access to it as a local post, effectively hiding all the SAP server URLs. A specific use case includes sales order APIs and posting something into SAP to get the business partner details from SAP, and similar actions.
NGINX Ingress Controller offers primarily reverse proxying capabilities, and the proxy feature stands out for me due to some performance benefits, definitely security as the first thing, and also the load balancing aspect and the ability to route traffic to multiple servers.
NGINX Ingress Controller has positively impacted my organization by definitely improving my team's efficiency in terms of multiple load balancers and complex routing rules we can configure there, resulting in a single, easy-to-manage layer. Hence, routing, SSL termination, and rate limiting contribute to making us much faster and efficient.
NGINX Ingress Controller can be improved by implementing faster deployment of new services, simplifying SSL or TLS management, and enhancing faster troubleshooting by providing more logs. While I have debug logs, using more techniques to reduce the mean time to resolution would be beneficial.
I have been using NGINX Ingress Controller for ten years.
NGINX Ingress Controller is stable.
In the Kubernetes environment, NGINX Ingress Controller scales very well.
As a developer, I can definitely say that NGINX Ingress Controller improves performance in terms of load balancing, especially in a microservices environment with many APIs. I don't have closely related metrics, but in a past microservices environment where I had fifty or more services, maintaining around one thousand to one thousand five hundred APIs was very hard without ingress. However, with ingress, it is easier to maintain them, and I think it doesn't charge more than thirty dollars a month for usage.
NGINX Ingress Controller is pretty standard and very lightweight, making it highly recommendable to use in local development environments, and it is especially useful in test environments for enabling SSL and rate limiting.
On a scale of one to ten, I would rate NGINX Ingress Controller around eight point five, near to nine, due to the ease of setup, although there is a slight learning curve with some advanced features. The documentation is good and reliable, and it performs well as it is lightweight and handles traffic loads sufficiently. While debugging, the logs are generally helpful, debugging complex routing can sometimes be tricky, so I may need to have more NGINX internals to be logged. Overall, scalability, performance, and upgrades are all good, and using it in Kubernetes integrates very well.
NGINX Ingress Controller is my main tool for managing access in our Kubernetes clusters, where we have multiple clusters, and for the access of different microservices, we use NGINX Ingress Controller.
For a specific example of how we use NGINX Ingress Controller with our services, we have multiple front-end and back-end services, including back-end APIs, and some services need to be exposed publicly through an ingress resource, so we use NGINX Ingress Controller to expose those services publicly by applying an ingress resource on that service.
In addition to my main use case with NGINX Ingress Controller, we also use custom resource definitions, CRDs for Transport Server and Transport Servers mainly, and Virtual Routes.
The best features NGINX Ingress Controller offers for my use cases include ingress resources and different annotations that allow us to expose a publicly accessible URL by whitelisting IPs and so on.
The annotations that we utilize with NGINX Ingress Controller help our team by allowing us to block or whitelist IPs for certain publicly accessible services, ensuring that only specific public IPs can access those ingress URLs while blocking others.
NGINX Ingress Controller has positively impacted my organization in that all my ingress resources, services, and internal and external communications between different services are quite smooth, and we can control our service exposure and service access easily using NGINX Ingress Controller, which makes my organization really happy.
I think NGINX Ingress Controller could be improved by adding many features and functions regarding firewalls, similar to what a professional API gateway offers, so those functionalities can be integrated with NGINX Ingress Controller.
I gave it a rating of 9 out of 10 because I noticed that there are some things that need improvement or additional features and functionalities, such as more firewall-related options that can be added.
I have been using NGINX Ingress Controller for almost three years or more.
In my experience, NGINX Ingress Controller is stable; so far, it has been quite good.
NGINX Ingress Controller demonstrates quite good and straightforward scalability.
Over the last couple of years regarding customer support for NGINX Ingress Controller, I have not encountered any scenarios where we needed customer support, so I have not felt any requirement for customer support so far.
Previously, we used Istio for service mesh, and we decided to switch to NGINX Ingress Controller due to the complexity of Istio and version conflicts between the Kubernetes cluster and Istio.
I have seen a return on investment with NGINX Ingress Controller since the time saved is considerable, especially because it is simple to use.
My experience with pricing, setup cost, and licensing is good, but I am not sure about those aspects since I am using the community edition.
Before choosing NGINX Ingress Controller, I evaluated other options such as Traefik.
My advice for others looking into using NGINX Ingress Controller would be that it is easier to use and anyone can explore and use it. I would rate this product 9 out of 10.
My main use case for NGINX Ingress Controller involved a banking application that was a cluster of Kubernetes where they wanted to monitor if the ingress controller could act as a load balancer.
I set it up for their banking application by initially working with the community edition of NGINX Ingress Controller. We then proposed NGINX Plus to them, which is now acquired by F5.
The best features that NGINX Ingress Controller offers in my experience are that the ingress controller can perform content-based routing and SSL termination, which is usually not available on software-only solutions and typically comes with hardware-based solutions.
Content-based routing and SSL termination have helped our customers significantly. For example, one customer, a bank, needed to utilize their own GPT which had two instances, one on the cloud and one on-premises. They had to route between the on-premises and cloud instances, which we could not have accomplished without the ingress controller.
NGINX Ingress Controller has positively impacted my organization and my customers because, since F5 acquired NGINX, the support is quite responsive. When you contact them, they immediately respond to the problems we have.
A specific example is that we usually open cases based on priority, and when we set a priority for a site down, the engineer came within approximately fifteen minutes. This response time was excellent.
NGINX Ingress Controller itself is a great product, but when considering a complete solution, there are limitations. NGINX Ingress Controller does not provide the security and web application security features that come with full application delivery controllers, such as WAF and AWAF.
NGINX Ingress Controller can be improved in terms of security and WAF features, but it should remain lightweight as it is currently. This lightweight characteristic is a very significant advantage that prevents any overheads on the systems running the applications.
Additionally, there should be a dashboard for NGINX that shows all the metrics and monitoring information. For example, monitoring solutions such as DataDog have one pod in the entire environment that takes all information from all other pods and displays it on a dashboard. If there were an NGINX pod that could monitor the applications as well, it would be a great addition.
I have used it for some customers who were already using it while they were on Kubernetes environments with containerized applications. They wanted to deploy F5 as a load balancer for the Kubernetes environments. We proposed NGINX Ingress Controller for their Kubernetes environments and F5 as a load balancer for their monolithic applications.
In my experience, NGINX Ingress Controller is quite reliable and I have not faced any downtime or reliability issues.
NGINX Ingress Controller's scalability is excellent. The scaling of containerized environments became really easy when we use NGINX Ingress Controller. Before that, it was really difficult to maintain all the scaling up and scaling down manually. We had to manually determine if the number of users increased to a specific limit, then scale up to more pods, and if concurrent sessions reduced, then reduce the pods. However, with the ingress controller, we can do this automatically.
Customer support for NGINX Ingress Controller is great. When I reported that there was a connection mismatch between a customer's existing environment and their DR, the technician came within fifteen minutes. This response was excellent.
I previously used the default ingress controller for Kubernetes before switching to NGINX Ingress Controller. This switch helped me because the configuration is really easy on NGINX compared to other software.
I have seen a return on investment with NGINX Ingress Controller because most organizations, especially small organizations or SMBs, don't buy a specific load balancer, such as F5 load balancer or Fortinet ADC. They go with a software-based load balancing solution. This represents a huge cost-cutting opportunity for them. Since the acquisition by F5, having support on NGINX is really great. Even the organizations that need to ensure they have support can take NGINX Ingress Controller as their go-to solution.
My experience with pricing, setup cost, and licensing for NGINX Ingress Controller is that we discussed the pricing with our distributor in Pakistan, which is Awan Distribution. The setup cost does not involve any capital expenditure. It is basically a license through a subscription model. The subscription renews regularly. I believe this is a better licensing model rather than selling the product once and then doing a subscription for services. It is better to go with subscription-based models.
I suggest that it would be great if we could integrate NGINX Ingress Controller with F5 so we can see all the pods and all the applications running in the cluster environments or containerized environments on the F5 interface.
I would rate NGINX Ingress Controller as an eight on a scale of one to ten. The reason I give it an eight instead of a higher or lower score is that since the acquisition by F5, the prices of NGINX Plus have increased drastically, which is a downside. However, I gave a good number, more than five, because NGINX usually comes up to the mark when we talk about application load balancing and communication between containers. If a container dies and comes up again with a new IP, then NGINX Ingress Controller automatically routes the traffic to it instead of sending the traffic to the wrong container that is no longer present.
My advice for others looking into using NGINX Ingress Controller is that if they are deploying it in their production environment, they should take the support from F5 for NGINX Plus because without the support, they are really stuck. If they get a problem and cannot resolve it, they have to take downtimes. My overall rating for this product is eight out of ten.
I have worked on NGINX Ingress Controller with an on-premises deployment model. There is an option for cloud as well, and SaaS solutions are also available. The recent project I completed was NGINX Ingress Controller in Google Cloud for one of our clients.
I have utilized NGINX Ingress Controller SSL and TLS termination feature. We have done extensive SSL offloading on NGINX Ingress Controller and made the TLS configurations to match security requirements, allowing certain TLS versions while disabling others such as 1.0, 1.1, and 1.2, and allowing 1.3. The choice depends upon the application requirement.
The reverse proxy capabilities of NGINX Ingress Controller in managing distributed applications is central to its main concept. We need to configure it to allow the server to access the outside world and the internet. That is achievable, and we can install and configure NGINX Ingress Controller as a reverse proxy. It can work as a load balancer, but the main part is NGINX Ingress Controller's role as a reverse proxy. If any applications need to be accessed through the proxy to the outside world, then NGINX Ingress Controller is a good product for you.
I employ the IP whitelisting feature in NGINX Ingress Controller, which helps secure my application environment. In IP whitelisting, there are several options available. You can determine which IPs to block, for example, if you do not want to give access to specific regions. You can find the list of IP addresses registered in those regions and blacklist them. There is also the web application firewall (WAF) where you can create policies to identify the type of traffic trying to access the application.
I have not integrated NGINX Ingress Controller with solutions such as Prometheus or Grafana. We have not received any projects of that nature yet.
Integrating capabilities with third-party tools are mostly about monitoring or sending logs. Working with the upper layer, such as upper layer firewalls, depends on what kind of integration you are looking for.
I have worked with NGINX Ingress Controller for only a couple of years, and I recently started working on it. I do not have extensive experience with it, but with other F5 products, I have more than fifteen to twenty years of experience.
I have not seen any issues integrating NGINX Ingress Controller with other security products, such as firewalls. We have implemented it in AWS, using NLB and the AWS product firewall. For the WAF, we have used Akamai products. For WAF solutions, we have integrated with NLB on the AWS side and the internal AWS firewalls. Sending logs and integrating with firewalls has not presented any issues. It may depend on the kind of software; sometimes older software may not integrate properly, and we might need upgrades or patching. Normally, when issues arise, I reach out to the vendor; they provide patches to fix those issues. After that, I upgrade the software, and the issues usually go away.
Implementing NGINX Ingress Controller and installing the instance requires a few hours. After that, depending on what applications you are going to deploy and how many applications you are going to deploy, it might take time. If you are going to deploy one hundred or two hundred applications, then it is going to take a considerable amount of time. If you have only a few applications, such as five or ten, or you are planning for only a single application, then it is not going to take much time. So, within a day, you can bring up the devices and make them active.
My experience with F5's technical support was excellent around ten years ago, with very good response rates. Nowadays, the quality has been degrading, and I do not expect the same level of service. While they have improved their ticketing system, allowing online submissions and status checks, the skill levels of the technical staff seem to have reduced. That is what I am observing day by day, as I have worked with many highly skilled professionals in the past, and I notice a difference now.
I would rate their technical support somewhere around a three on a scale of one to ten.
The deployment process of NGINX Ingress Controller is not complex, I would say, because as a network engineer, I may not be able to know all those HTML coding aspects. That is a challenge I faced, because the coding part is new for me. I need to learn and do it. Other than that, I have not seen any other challenges. It is similar to a normal server installation; after that, you need to do the configurations such as network configuration to make the system available in the network. Then, you can implement the load balancer concept, such as installing web in the backend servers. If there is any SSL offloading, that may be the challenging part I faced.
There are a couple of options available for purchasing NGINX Ingress Controller. You can buy your own license, or you can use it based on the usage. It is similar to AWS coming up with their own license, and based on the usage, they will charge you. Another option is to buy a license directly from F5 or a vendor, which is a bring your own license (BYOL) option, and use that license to install it on the AWS Marketplace. You can install your instance, use this instance, and make use of that. Several options are available.
Regarding licensing costs for NGINX Ingress Controller, if you are talking about costs, F5 is always very costly. The license is very costly compared to other vendors such as VMware or AWS inside load balancer or other Akamai load balancers. However, the response, throughput, and solid performance we receive after implementation are often worth it. Most of the time, I have not seen any issues, and the systems run very smoothly. This is just my experience, and opinions may vary per person. I have not encountered significant issues; the feedback from end users and clients has been very positive.
NGINX Ingress Controller is functional, but it is achievable and may take some extra time. The major issues typically relate to vulnerabilities, which F5 addresses with patches that require timely software upgrades to mitigate. I would rate this review a nine overall.
The simplest and most common use case in my country is somebody adopting microservice technology who was using Ingress Controller community edition and wanted to move to enterprise level. Someone wanting to have microservices and containerization applications desired commercial, enterprise-grade Ingress Controller, so they moved to F5 Ingress Controller, which is NGINX Ingress Controller.
The performance and stability are what I like about NGINX Ingress Controller. The more important concern is that it can apply App Protect and DDoS protection within NGINX Ingress Controller Plus. Security and performance are better, and all customers love it because of these options.
The main benefit is that it is better in performance, provides security with App Protect and WAF and DDoS, and delivers high performance and high stability. However, there is still a major limitation in GUI capability to manage and observe. That is one of the major limitations.
NGINX Ingress Controller is doing better than the community edition for sure and works well when replacing Ingress Controller for OpenShift router. It is doing fine, but it is easy for the developer to develop and not easy for the other teams to work with. It is not something designed for a network security team anyway, so they cannot apply App Protect and other items. It is just for the developer. The drawback is that it is not targeting or is not easy for other non-developers to work with.
The capability to manage and observe should be better for NGINX Ingress Controller. We should not rely on Prometheus and Grafana so much. The management is still in Kubernetes Master, but there is a better way for managing it.
I have been using NGINX Ingress Controller for one year and a half. Coming from a background in network security and information security, it was not easy to recognize the deep involvement without having extensive reading about it.
NGINX Ingress Controller is working fine with both NGINX community edition and NGINX Plus. We cannot see a difference when using NGINX Plus instead of community edition in SSL/TLS terminations. The stability in SSL for NGINX Ingress Controller Plus, which is the commercial one, is better than the open source. However, I do not have comparison data with other vendors as I have never seen a comparison between NGINX Ingress Controller and other Ingress Controllers in SSL/TLS.
NGINX Ingress Controller is perfect for scaling. NGINX is really awesome in scaling.
I have had one or two cases open with them. They are fast in response, but they are at an average level. The F5 team, which is the BIG-IP team, is faster in response and resolving issues.
NGINX Ingress Controller as a reverse proxy itself, which I have already tested as a software as a standalone server and not just as an Ingress Controller, is perfect. As an Ingress Controller, it is doing fine. NGINX Ingress Controller must perform reverse proxy functions, path-based routing or host-based routing, and target which container to route traffic. It is deep technical work, but it is doing fine overall.
Configuration is simple to start. To get deeper, I need to be a developer.
Prometheus and Grafana are definitely necessary. The metrics I find really important is latency and request latency. That is one of the major metrics we love.
I have configured a new use case once in my life when something required it to work. I did not test it again after that, just once in my life.
Deployment works at small, medium, and large scales. I am working with different deployments.
For the sales and pre-sales, I simplify the message as much as possible. The message for NGINX Ingress Controller is always complicated when delivered, and it requires simplification.
I would rate this product 9 out of 10.