The Fastly Next-Gen WAF (powered by Signal Sciences) Reviews

The CDN is for caching and The Fastly Next-Gen WAF (powered by Signal Sciences) is for protecting the servers from malicious traffic. They both perform different jobs and serve different purposes, so they complement each other. We actually tried both deployment methods, but the cloud option is easier. For the on-premises option, you need to have all sensors installed in your cluster, which was not suitable for our use case.

We wanted to control everything through the cloud and then hit our servers before classifying whether the traffic is malicious or not. We wanted to have that logic offloaded to the cloud so we wouldn't have to manage it.

We tried both options but decided to go with the cloud deployment.

It is managed through Infrastructure as Code, so all configurations can be managed in the code itself, which is beneficial.

Because it uses rules, it is easy to set up, and we have many different sites where the configurations are straightforward. Though the UI is not very interactive, which is a downside, we can manage many things. The UI is not very intuitive and could be better. However, we manage all the configurations through code, which is easy to maintain.

It has extensive anomaly detection capabilities, so the traffic is classified into several categories where thresholds can be defined and customized based on false positives and false negatives. This is advantageous because you do not need to tweak it very often. Once you set it up, an audit once a quarter would suffice.

Because The Fastly Next-Gen WAF (powered by Signal Sciences) is API-driven, we have integrations with the CI/CD pipeline through GitHub Actions, making it easy to integrate.

We do use it, but the UI can be improved as we mostly work through the CI/CD.

It provides support, but sometimes it is hard to navigate unless you are very familiar with it.

It has the same support team handling all aspects of the service.

It provides support, but sometimes it is hard to navigate unless you are very familiar with it.

Neutral

We were using Akamai.

When you opt for the in-cloud deployment, there are multiple ways to deploy it on your servers in the containerization environment. You can implement it as a sidecar or as a proxy. It becomes a complex setup when you manage it in your environment. It is easier to be cloud-based, where all the deciding factors would be in the cloud, and then if everything passes, the request is passed through to the internal server.

The pricing is very competitive compared to other providers. The pricing is definitely a factor in our decision-making process.

The pricing and modern features are the positive aspects of The Fastly Next-Gen WAF (powered by Signal Sciences). Not having a point of presence in China is the downside. We tried different approaches to address this limitation.

The Fastly Next-Gen WAF (powered by Signal Sciences) was originally a different company's product, but Fastly acquired it and integrated it into their product portfolio. It provides all the necessary functionality. On a scale of 1-10, this solution rates a 7.

We use it to protect all our public-hosted sites. It's a replacement for Akamai. We migrated from Akamai to Fastly.

It gives us fully enhanced dashboards, making it easy to identify and allow or deny traffic based on the signals it provides. 

Fastly (Signal Sciences) integrates and tags the intermittent traffic based on patterns. It generates signals and provides them in a dashboard where we can view them and decide whether to allow or deny traffic. It's a more advanced and easy-to-navigate dashboard.

It has very similar features to Akamai but is more maintainable and has a different way of doing things. 

Feature-wise, it has everything Akamai has: CDN and caching. The advantage over Akamai is that it's in Varnish Configuration Language (VCL), so programmers understand how to create rules, hardening, and all that. Caching and everything else can be written as code.

Fastly don't support caching for China users. That's the only feature lacking compared to Akamai.

I have been using it for six months. Fastly is the CDN, and Signal Sciences provides the API protection. It's a WAF, a web application firewall, but Fastly acquired Signal Sciences, and now it's working as a single product: CDN plus WAF.

So far, the customer service and support have been good. They are quick, they are on top of things and we get responses in a day or two. Unless there's an incident, we don't expect them to be responding in less than a day. So far, it's good. I haven't seen any downtime in the last six months or a year, which is good.

We used Akamai before. We switched because of cost optimization. It's 50% less than Akamai. So, it is cost effective. 

Fastly can be provisioned through Infrastructure as Code (IaC). Akamai has that feature, but with Fastly, we can write the code and manage it in our Git repository. We don't need to go to the dashboards; you can deploy changes through your own repository. That's an advantage.

The initial setup was super easy. The migration was super easy. The only part we were missing was China cache. Other than that, it has everything Akamai was providing: image optimization, CDN, WAF, and all the other security aspects. The China cache was the one thing we were missing in Fastly, so we had to do it differently.

Deployment was a few weeks for the migration. If you're starting a brand new site, it's straightforward; maybe in a week or two, you can be up and running. But if it's a migration from a different CDN, it would probably take four to six weeks.

We wanted to know the caching rules and how teams were doing things differently, so we had each member from the team gather inputs. Then we migrated and started writing the VCL code.

It's very little maintenance. But with every draft, you need to periodically check the dashboard for anomalies and take action. Once a month or once a quarter, you need to do that exercise.

Moreover, there are a couple of integrations with other observability tools like Datadog and Slack. It's easy to enable access with SSL, Okta, and Flash teams.

We work with Fastly. We have quarterly reviews with them.

CDN is our primary thing, and it improved page speed and load times compared to Akamai. 

Fastly is super fast because they take a slightly different approach to caching. We see a lot of improvement in client experience and page speeds.

The pricing is 50% less than Akamai. 

It's a good product. We can manage SSL certificates within the CDN, and they're auto-renewed and auto-purchased outside the CDN, which is a cool feature. 

So, I would rate this product a nine out of ten. I recommend this product. If anyone is looking for a next-gen WAF and next-gen CDN, it's the best product I've come across.

It utilizes AI to enhance features, especially while tagging anomalies and traffic anomalies, but I'm not 100% sure. I've heard they're using some AI to identify bot traffic and malicious traffic.

The product's most valuable feature is its ability to set up the rules easily. The agent-based approach allows for efficient policy control per agent, simplifying managing rules for various websites or apps hosted on platforms like AWS or Azure.

The areas that could be improved in Signal Sciences include the effectiveness of rules, as many didn't function optimally and required custom rule-writing to address bypasses for WAF. Additionally, the agent-based approach presents challenges with managing agents across versions and dependencies on specific application platforms like Apache or NGINX, leading to compatibility issues and complexity in integration. This agent-based system proved particularly difficult to manage.

We have been using Signal Sciences for two years.

The product has high stability.

We have around 500 to 600 systems running on Signal Sciences.

We contacted the technical support team during migration from one of the agent approaches to the reverse proxy method. We had to call them multiple times. The services could be better. However, we received assistance from an executive who knew how to set it up.

The initial setup for Signal Sciences is challenging. It requires technical expertise. Various factors, such as the operating system, web server, and their respective versions, need meticulous consideration. It leads to multiple potential points of failure, resulting in numerous errors during setup. It is not easy, similar to solutions like Amazon WAF, which offer a streamlined deployment process with just a few clicks.

The product has an affordable cost.

We did evaluate Cloudflare and Barracuda. We went with Signal Sciences as it is most cost-optimal. This led to the decision to proceed with the product particularly due to its compatibility with Kubernetes and the utilization of a reverse proxy agent in deployment. Its cost-effectiveness at that time, especially considering Fastly acquired it, made it a relatively more affordable option than others.

I advise others to make a purchase decision depending on the budget. If they have a budget, they should go with Cloudflare. I have used Signal Sciences, Azure, and AWS. They need to work more efficiently to protect web applications.

I rate Signal Sciences a six out of ten. It has good granularity features, but maintenance and agent approaches could be more convenient.

We used Signal Sciences to implement a web application firewall for some of our applications.

When configuring a web application firewall using Signal Sciences, we configure a rule whereby no one except a few people can access the application. We can create a corporation rule and a site rule separately. We can have a global rule which can be used for all other applications, as opposed to a site rule, which will be specific to a specific website. With Signal Sciences, we can define a rule based on our application requirements.

There are some lags in Signal Sciences for the web application firewalls. Even if we create some custom rules, Signal Sciences cannot capture some of the malicious traffic. There is a little bit of complexity with custom rules that should be removed.

Signal Sciences should add a feature called rate limiting with multiple options, wherein I can create a rate limiting based on the cookie request or the IP.

I used Signal Sciences for almost two years.

Signal Sciences is a stable product, but it takes longer for new custom rules, implementations, or a new feature request.

Signal Sciences is a scalable product because it fulfills most of the major requirements.

More than 100 people used Signal Sciences in my company because multiple teams and application owners needed access to the solution.

The Fastly team is handling Signal Sciences' support team. Sometimes they do not understand the issue and go with their own understanding. I faced this issue, because of which, sometimes our website went down. However, the solution's customer support is pretty good.

Neutral

Signal Sciences' initial setup is quite straightforward if you are familiar with the UI. However, it will be a little bit tricky for new users to understand. The solution's navigation is also good.

It takes at least one month to complete the solution's configuration and monitoring. However, if you remove the monitoring part, it will hardly take one week. There are some lags in creating the custom rules, and sometimes it is not able to fulfill the requirement. We struggled almost for more than a month to fix that issue.

Signal Sciences is pretty cheap compared to other solutions. We could handle the cost because the solution was on-premises and installed on our server.

My organization used Signal Sciences for the internal application or in case any customer tried to integrate their application with our application. We found that the solution was secure for such applications.

I advise users to choose Signal Sciences. However, they should evaluate the solution based on their requirement and ask for the feature request if something is missing.

Overall, I rate Signal Sciences an eight out of ten.