How to choose a WAF? The answer is not in the feature list, but in where your traffic comes from

The three mainstream WAF (Web Application Firewall, a firewall that understands web content) products all block common attacks. The difference is where that protection happens. This page does not score or rank vendors; it simply lays the scenarios out for comparison.

Ask four questions first

Akamai, F5®, and Fortinet FortiWeb all block SQL injection (smuggling malicious commands into a database through a form), cross-site scripting (XSS, injecting malicious code into a page so visitors execute it), and DDoS (distributed denial of service, flooding a site with fake traffic). The difference is not whether they can block these, but where the blocking happens. Answer the following four questions first.

1
Who are you protecting?
A service open to the general public (a corporate website, e-commerce, a public API), or an internal or B2B system limited to staff and vendors? The former faces global scanners and high-volume attacks; the latter faces account abuse.
2
Can your traffic leave your own data center?
If regulatory or audit requirements mean traffic must stay inside the data center, this question rules out cloud edge protection outright. It is the most decisive question, so ask it first.
3
Do you already have equipment in place?
Do you already have BIG-IP® handling load balancing (distributing connections across multiple backend servers), FortiGate, or another CDN (content delivery network)? Existing equipment usually determines the path of least change.
4
Where do your systems run?
Traditional servers, a cloud virtual private cloud (VPC), or containers and Kubernetes (a container orchestration platform)? If you already deliver via containers, protection should ideally deploy alongside the application.

Scenario comparison: three protection points

None of the three options is inherently better. Each fits a different scenario. They are listed from outside in by protection point, without scoring or ranking.

Akamai | Protection at the internet edge

Protection point: the internet edge (per vendor public data: spanning 700+ cities). Traffic is cleaned before it reaches your data center.

Equipment needed: none. Point your domain (DNS) to Akamai and you are live.

Typical customer size: medium-large and up, with high external traffic and a high cost of downtime.

Added value: global acceleration comes as a bonus; per vendor public data, 32 scrubbing centers and 20+ Tbps of defense bandwidth.

Less suitable for: low-traffic brand websites; systems whose traffic cannot leave the data center.

Public-facingHigh trafficDDoSNo equipment
See Akamai deployment services
F5® | Stay online, stay unbreached

Protection point: the perimeter of your own data center. Traffic never leaves it.

Equipment needed: on-premises requires hardware or a virtual appliance license; a cloud service is also available to extend policy.

Typical customer size: medium-large, with an in-house data center and high audit requirements.

Added value: BIG-IP® is already a load balancer in front of your servers; adding the WAF module solves both "must not go down" and "must not get breached" at once. Container environments also have NGINX®.

Less suitable for: a single website that only needs a WAF, with no load balancing or disaster recovery requirement.

Data stays localLoad balancingDisaster recoveryContainer environments
See F5 deployment services
Fortinet FortiWeb | Deployed inside your data center

Protection point: inside your data center or cloud VPC; a FortiAppSec Cloud (formerly FortiWeb Cloud) option is also available.

Equipment needed: available as hardware, virtual machine, container, or cloud service.

Typical customer size: small to medium, or branch and internal systems within larger enterprises.

Added value: shares a management console and logs with existing FortiGate deployments, so there is one less system to learn.

Less suitable for: very high-traffic public services that need scrubbing at global points of presence.

Internal / B2BExisting FortiGateDeployment flexibility
See Fortinet deployment services
A public e-commerce, gaming, or media site that has been hit by DDoS before
Suggested direction: push the defense line to the internet edge, absorbing attacks before they reach the data center, with the side benefit of faster overseas connections.
Financial, public sector, or healthcare systems where data cannot leave the country
Suggested direction: address availability and protection together at the data center perimeter, especially when you also need load balancing and disaster recovery.
Internal or B2B systems with only one or two IT staff, already using FortiGate
Suggested direction: choose in-data-center protection that shares a management console and logs with your existing firewall.
Applications already containerized, delivered by the development team itself
Suggested direction: choose a software form factor that deploys alongside the application, without reworking the network architecture.
A checkout page that accepts credit cards and must meet PCI DSS 4.0 requirements for monitoring third-party JavaScript
Suggested direction: prioritize solutions with a client-side script protection module, typically offered as a cloud service. Standard WAF rules cannot cover this.

All three can coexist

The most common setup for large customers is a two-stage architecture: outer layer plus inner layer.

For customers with higher traffic, two layers are most common:

  • Outer layer: a cloud edge service absorbs high-volume attacks and malicious bots, filtering out noise before it reaches the data center.
  • Inner layer: F5® or FortiWeb forms the last line of defense inside the data center, enforcing rules only you know, such as which internal API should never be exposed.
The point of a two-layer architecture is division of labor: the edge handles volume, the data center handles detail. Adding a layer does not automatically mean more security. If one layer is enough, plan for only one.

Going live is not the finish line. Rules need ongoing tuning to match how the site actually behaves, or you end up either missing attacks or blocking legitimate customers. Vendor version updates and security advisory tracking are also part of annual maintenance. See Web & API Protection (WAF) and Services for details.

We source vendor products and support through authorized channels in Taiwan, and provide planning, deployment, migration, training, and annual maintenance services. As an independent systems integrator, we make selection decisions based on your actual environment.

How to evaluate which to choose

The assessment starts with a current-state review and follows four steps.

Site survey and current-state review
An on-site look at the data center: which services face the public, how domains and certificates are managed, and existing equipment models.
Traffic and architecture assessment
Assess the scale and source of external traffic, peak hours, how many APIs exist, and which should not be exposed.
Compliance and data residency review
Confirm whether data must stay in-country or traffic must remain inside the data center. This directly determines the range of viable options.
POC and deployment recommendation
Run a POC (Proof of Concept) to measure the false-positive rate and performance impact, then propose deployment scope and migration steps.
"The current-state assessment recommends based on your actual environment. If the assessment finds your existing setup is already sufficient, we will say so."
- GN-AI Information Consulting, Technical Team

Related reading: solution overview and single-vendor deployment services.

Web & API Protection (WAF) Akamai F5 Fortinet
Book a current-state assessment See our services

Contact us about WAF selection and assessment

Leave your contact details and a description of your needs, and an engineer will get in touch to help assess architecture planning, deployment approach, and annual maintenance scope.

Send an enquiry
LINE Ask us on LINE