Amazon Web Services offers AWS WAF (web application firewall) to protect web applications from malicious behavior that might impede the applications functioning and performance, with customizable rules to prevent known harmful behaviors and an API for creating and deploying web security rules.
$0.60
per 1 million requests
NGINX
Score 9.2 out of 10
Enterprise companies (1,001+ employees)
NGINX, a business unit of F5 Networks, powers over 65% of the world's busiest websites and web applications. NGINX started out as an open source web server and reverse proxy, built to be faster and more efficient than Apache. Over the years, NGINX has built a suite of infrastructure software products o tackle some of the biggest challenges in managing high-transaction applications. NGINX offers a suite of products to form the core of what organizations need to create…
N/A
Pricing
AWS WAF
NGINX
Editions & Modules
Resource Type - Request
$0.60
per 1 million requests
Resource Type - Rule
$1.00
per month (prorated hourly)
Resource Type - Web ACL
$5.00
per month (prorated hourly)
No answers on this topic
Offerings
Pricing Offerings
AWS WAF
NGINX
Free Trial
No
Yes
Free/Freemium Version
No
Yes
Premium Consulting/Integration Services
No
No
Entry-level Setup Fee
No setup fee
Optional
Additional Details
—
—
More Pricing Information
Community Pulse
AWS WAF
NGINX
Features
AWS WAF
NGINX
Application Servers
Comparison of Application Servers features of Product A and Product B
AWS WAF is highly appropriate to interrupt or prevent cyber attacks because when implementing rules, whether they are specific or centralized, so any application that has these vulnerabilities is protected.
Implementing managed rules creates greater security to protect both API and applications. If implemented along with other AWS tools, the security is much better, so if you want to protect applications against more specific attacks, it is ideal to integrate with Amazon CloudFront, which is a great benefit because it warns when thresholds are exceeded or specific attacks occur. AWS WAF is ideal to avoid common web attacks. For more specific attacks and scenarios, I don't recommend this.
Nginx is well suited for serving any static content - whether that be images, JS files, HTML files, CSS files, videos, etc. If you have a high-traffic website, Nginx will be a great fit because it handles large number of requests extremely efficiently. Nginx has full support on Unix systems, but only has limited support on Microsoft Windows machines.
AWS WAF has the most developer-friendly API to create firewall rules.
AWS WAF provides OWASP security controls, which reduces developers' burden (i.e., SQL injection and cross-site scripting).
AWS WAF has customizable web security rules. The user can even push the rules through the API available, which is the great feature and helped me a lot.
It protects applications at layer 7 (HTTP) of the OSI model and not just layer 4 (TCP).
Straight-forward configuration format that users of all skill levels can learn, and yet is powerful enough for the huge breadth of features that Nginx provides.
Massive scale right out the box. We've never had a Nginx instance overwhelmed by requests, and if we did it would be trivial to spin up more Nginx instances to handle the load.
SSL termination means that we can deliver content over HTTPS without needing our individual services to require TLS support. This saves us a lot of time and headache while keeping us secure.
Nginx is open-source and free, meaning that anyone can use it to power their services, from individual projects to billion-dollar websites.
Nginx often requires some initial configuration. It's worth doing, because you'll end up with great results, but it can be slightly daunting for someone to get started using it. Apache might have a leg up in that regard--When you install Apache, typically it's just about ready to do what you want already. But the issue with Apache is that most people skip the extensive tuning phase required after that, and with nginx it becomes more just a part of the configuration process.
Sometimes, the configuration syntax, even though it's powerful and terse, isn't the most intuitive. Luckily there's plenty of documentation about what things mean and how to accomplish certain things. There may not be much that can be done about this--to have a powerful web server, you need a powerful-enough configuration language.
The nginx brand is somewhat fragmented, and it can be confusing. There's the open source nginx web server, which I've primarily been referring to. But then there's NGINX Plus, a premium subscription-based service which works with a range of other NGINX products (NGINX WAF, NGINX Amplify, NGINX Controller). I've met a number of people who weren't very familiar with nginx, and instinctively went to nginx.com first, and from there it seems like everything costs money. It's only when they realize there's a different site, nginx.org, that they find what they went looking for.
We have been using AWS WAF for the past 3 years in front of our websites. We find it useful in preventing data crawling, DDOS attacks, etc on our websites, and hence we are going to use it in the future as well. AWS WAF is one of the best Firewalls in business.
The product is highly scalable. It is easy to configure the rules and thereby helps us to mitigate many vulnerabilities. The interface and programming of the firewall provisions were easy to setup. Amazon clearly spent a lot of time figuring this out and perfecting it. It allows users to do customized configurations based on their needs. It provides protection against a number of security issues like XSS, SQL injection, etc. I would definitely recommend this for protecting your infra as you scale, since this basically protects and filters all requests hitting your application server.
Front end proxy and reverse proxy of Nginx is always useful. I always prefer to Nginx in overall usability when you have application server and database or multiple application servers and single database i.e. clustered application. Nginx provides really good features and flexibility which helps the system administrator in case of troubleshooting and also from the administration perspective. Also, Nginx doesn't delay any request because of internal performance issues.
If you're intending to use AWS WAF, I would say that you absolutely should sign up for support. AWS Support is excellent and they can help you in a really good way to solve your issues.
Community support is great, and they've also had a presence at conferences. Overall, there is no shortage of documentation and community support. We're currently using it to serve up some WordPress sites, and configuring NGINX for this purpose is well documented.
Easy of use. Setup and configuration is fairly quick. There are the usual advantages of it being a cloud solution where you can buy into the solution, configure it and set it up and get it up and running. If you are already a subscriber to AWS, having a native service has its advantages.
I have found that [NGINX] seems to perform better throughout the years with less issues although I've used Apache more. I would definitely recommend [NGINX] for any high volume site and I've seen this to usually be the case from most provided web hosts who will pick [NGINX] over alternatives
When we first migrated our primary bidding environment architecture to Nginx, it was under duress due to Apache's inability to keep up when we consolidated away from an HAproxy model to a central HTTP proxy. So we even when we did not know what we were doing, we were able to make it work in a bad situation, and everyone was quite happy.
The biggest complaint I have is that I find the module compilation requirements for nginx+ rather burdensome. If we pay for Nginx+, I'd love to see then have pre-built modules for ready for each release of more modules. We are spending our own time engineering an in-house solution for module testing for nginx+ releases, which is disappointing.
I've also, as the primary Nginx person at my organization, inserted my expertise into other projects, and have saved our company lots of money getting rid of big $$$ appliances for general SSL proxying.
Speaking of Nginx replacing SSL appliances, we had an instance where we had to suddenly enable elliptic-curve SSL ciphers and our big $$$ appliances (you know who they are), were falling over. Even their SSL accelerator cards, after all, are just a few extra cores to process SSL. But in an environment of our size, we use DNS to spread the load to hundreds of frontend proxies with dozens of cores each to spread this load out, all at a lower price than ONE of the appliance pairs running Nginx. We couldn't even tell the change in load in our Nginx architecture when we enabled the ciphers.
